Hammer: lighting preview after EP2

[Furyo]

Saw it working at work, but we had to revert to some other tools versions so I no longer have it.

It's not a 3D cam, as there's no way you could compile the map on the fly as you move around it in Hammer. It blocks your 3d View and renders the currently displayed scene. Once you move around, you're back to unlit status.

[Zyn]

Most likely it it radiosity rendering of the current scene, just like most modelling applications. Suits me just fine.

[MJ]

better then nutin :/

[Warby]

the real light maps are never gonna be visible in hammer unless they implement a csg preview first ...and preview really is the wrong word here just DISPLAY the csg result is what i mean.

basically like unreal !

or they could display everything with dynamic tnl light sources which would mean that your entire level can only have 8 light sources ^^ and will run even slower than everything does already

[Defrag]

The 8 light limit is only for the fixed function pipeline -- you can sum up a zillion lights using shaders (though obviously it'll cost you). I'm not really bothered what they do, as long as it's fairly fast to render and gives a good indication of the final result.

[^Slick]

The 8 light limit is only for the fixed function pipeline -- you can sum up a zillion lights using shaders (though obviously it'll cost you). I'm not really bothered what they do, as long as it's fairly fast to render and gives a good indication of the final result.

I argee, looking forward to it in my opinion.

[Warby]

defrag can you explain that in more detail i am very interested in this topic !?

[Defrag]

The fixed function pipeline (FFP) is just the bog-standard method of rendering. The programmer has little control over effects and lighting -- it's basically like dialling in some values and the API (D3D / OpenGL) takes care of various algorithms for you. This makes it nice and easy, but since the algorithms are fixed, you have little control over the result. There are various hardware limits as to what you can do and the 8 light thing is one of 'em. You can have a zillion lights, but only turn 8 on at any one time. I couldn't tell you in much detail why these limits exist (probably just to ensure a base level of compatibility), but they do.

However, the FFP has been effectively replaced by shaders now. Instead of dialling in the values via the API, the graphics programmer has complete control over what happens to each vertex & fragment/pixel. The graphics cards now have little/no notion of what it's 'meant' to be doing. All the graphics card knows is that at the end of a vertex shader, it outputs some values (vertex position, normal, whatever else the programmer wants) and, at the end of a pixel shader, it outputs some more values (usually just a single colour). What you do to get these values is completely flexible now -- it could be any kind of lighting model (say Cook-Torrence[sp] instead of just Phong) and any kind of lighting setup (calculate the contribution of one light per rendering pass, or sum up an arbitrary number of lights in a single rendering pass).

Now we've got support for static & dynamic branching and loops in shaders. What this means is that you can run a loop in a lighting shader and have an almost unlimited number of lights (you'd only be limited by the number of registers storing the light parameters and graphics cards have tonnes of those). It'd run like a dog if you're not careful, but the power is there. For something like a lighting preview, it'd probably be acceptable to cull unseen lights and render at a horrid framerate.

DX10 doesn't even have a FFP -- it's entirely shader-based. Shader capable cards have been around since 2001 and many games don't even use the FFP (as if you're writing shaders to do various things, it's more work to create in parallel a FFP equivalent of the shaders you're writing). What I'm trying to say is that these days, if you have the need for it, you technically can use as many lights as you want.