I've done an implementation of GPU lightmaps in my test Direct3D engine. This was already done for RMQ (and a forked version of DirectQ) but with this one I bumped the hardware requirements up to full Shader Model 3 and took advantage of extra instructions, floating point textures, longer shaders, extra constants registers space, vertex texture fetch and dynamic branching.
Speed is very competitive; I can safely predict that when this moves to DirectQ (release 1.9.0) it will run faster and look better.
Here we have one clear advantage of bumping hardware requirements - something that previously wasn't possible suddenly becomes not only possible, but much better in every concievable way than what went before.
This is just scraping the tip of the iceberg; there is so much more than can be done to improve things and I'm quite excited about the prospect of throwing out the old lower-spec code and putting in something nice, clean and efficient.
Overall it's definitely the right decision. With Shader Model 3 hitting 8 years old this year, retaining compatibility with the older stuff is no longer a productive thing.
Wednesday, January 4, 2012
Even more Lighting
Subscribe to:
Post Comments (Atom)
6 comments:
Radical left field question, how hard would it be to implement bump mapping or gloss textures in DirectQ?
I've poked around from time to time thinking about shaders and as I understand it from what I've seen, this would be very difficult.
I only wonder because support for a couple of those types of features might make the remodel/retexture types extremely happy.
Of various docs floating on the internet describing support for these kinds of things, they tend to be long and involved descriptions of the changes.
[If I have accidentally hit upon an RMQ Engine secret feature, just silently ignore this .. hehe]
Did you subscribe to the post and see my cavalcade of rubbish as I posted it? The first one was about reflection & bump-mapping on the water... and it would be an awfully big coincidence for someone else to pick that up & run with it ;)
I'm not a remodel/retexture type necessarily (I didn't like the HD face textures in HalfLife, for example), but I love to see updated engines making more of a game by employing more modern rendering technology. Someone did a realtime raytraced Doom 3, IIRC - similar idea.
There's plenty of other stuff that's been upgraded - lighting, fog, particles, that sort of thing - so I don't think this idea would necessarily be out of place or out of project scope.
Specular highlights would make a bumpmap visible, but I don't know how Quake lightsources work and if there are even any environmental lightsources? It wouldn't necessarily be very pretty, but you could probably do some optimised mathematical trickery to simulate a watery bumpmap.
Reflections are more difficult - you have to render the scene twice, the second time at the same distance away from the opposite side of the reflective plane and at the opposite angle (by which I mean 270 degrees when at 90 degrees to the plane, or 315 when at 45 degrees to the plane) and then composite the resultant images, with one vertically inverted. Horizontally inverted if you're talking about a mirror on a wall. It may be more efficient to invert all the vertexes before rendering than to invert the actual image, but I don't know enough to make any actual guess. To then combine that with a bumpmap, you have to warp the reflected image depending on the angle you're viewing the bumpmap at. Seems like a lot of work. Probably a non-flyer unless you're at a very very loose end.
Quake has a great handmade quality to it, phong/blinn tends to break that.
Also, good phong and blinn needs both specular coefficent and exponent to not appear plasticky all over, color allows a lot of artistic freedom also.
That's another 32 bits if you want everything perpixel -- dxt5 compresses that nicely though.
Also, you'dd need to store lighting vectors in the lightmaps for bumpmapping to work, either that of go fully realtime -- eg. deferred shading.
One thing I would be interested to see though is fake reflections using a mask and a reflection texture. Could be a cubemap, but a flat texture works surprisingly well I think. Quake 3 used that extensively, and when it's done subtly I think it still looks good, even if you know it's fake.
I try to think about those things almost platonically. What broadly seperates materials? One is color and large scale texturing,
eg brown -- wood, gray -- metal, another is simply a binary choice between "is this material shiny or dull?" Specular highlights don't really need to be perpixel to make something appear shiny or translucent.
I just saw a few "this post has been deleted by the user" comments and cleared them down myself. :)
Bumpmapping/etc is non-trivial. On the surface it's quite simple - there are a few well-defined calculations that you do and bumpmapping comes out the other side.
For Quake, things are different.
Numpmapping is entirely dependent on lights in the current scene. Because of the lighting model Quake uses, you might have 50+ lights in any given scene. That means accumulating the effects from that number of lights, which means performance can go to the less than 10fps region.
That's why DarkPlaces needs .rtlights files to run reasonably.
Now, I'm not a replacement content person either - I actually regret adding external texture support. And I've no ambition to or interest in the idea of recreating DarkPlaces: if you want to use DarkPlaces you can always just use DarkPlaces, after all.
So, long story short, is that DirectQ is always going to lean heavily on the traditional side. RMQ may go beyond that, but it's features are decided by requirements of the game conent.
I'm not a fan of technology or graphics for the sake of such things and fall squarely in the game play matters most (but visuals matter some) department.
My question was kind of trying to emulate to the thought of possible questions/concerns/interests I thought might be logical extensions of recent thought patterns.
For instance, the cost/ratio benefit of a more detailed feel without much of a decrease of performance and had wondered whether the recent hardware requirement thoughts + D3 experimentation and the shader talk and interests of possibly someone like ijed or some things that gb has blogged might lead.
Current experiments are prompted by a number of things. The kickstart to it all was an RMQ map that went totally nuts with animating lightstyles; having to re-upload textures every time a style changed made framerates very ragged - they went from maybe 3ms per frame normally to 12ms or more when textures got updated.
That was just time spent in the renderer; at the default 72fps, 12ms per frame doesn't leave much headroom for everything else to run, so input, movement and generally performance was rwally really jerky.
Moving lightmap updates to the GPU didn't make things faster - the general case went from 3ms per frame to 4 or 5 - but what it did do was make framerates steady. No matter how many animating styles you threw at it, you were always getting that 4 or 5; there was no sudden hitch from new maps beings uploaded.
Adding dynamic lights on the GPU is an interesting problem. I've written maybe 4 or 5 implementations of this, and they all have their individual strengths and weaknesses - bad performance, high hardware requirements, low quality. For the most part dynamic lights are very short-lived so for RMQ I chose a lower-quality option that fit nicely inside the current hardware requirements and that ran well enough.
So that's the background, but where is it all leading to?
GB wants higher resolution lightmaps.
ijed has mentioned something about Doom 3 lighting with normal maps.
I'd love to see all moving geometry being lit and shaded properly.
Everybody would probably like something better than Quake offers by default.
These desires are interesting in that they're all mutually compatible, and they lead to a single point in the future, which is a deferred renderer with realtime shadowmaps. I've long believed that if you're going to do anything with light and shadows you should do it properly, otherwise you end up with a fairly fragile implementation that only works in certain well-defined special cases (witness Quake's r_shadows 1 mode, for example).
That opens a whole can of worms. There's a tradeoff between functionality and hardware requirements here, and you just can't have both. You can only optimize so far, but if some crucial things are missing (like bitwise ops in a shader, f'rex) you've hit a wall.
So all in all it seems correct to experiment with this stuff in a different engine rather than work on a live codebase, and using a modern API that's designed around doing this kind of rendering (like D3D11) is the way to go.
Post a Comment