Bump Mapping
Afr
Join Date: 2003-05-13 Member: 16240Members, Reinforced - Shadow
Join Date: 2003-05-13 Member: 16240Members, Reinforced - Shadow
<div class="IPBDescription">In half life, yes its true.</div> Taken from <a href='http://www.valve-erc.com' target='_blank'>www.valve-erc.com</a>
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Bump mapping is quickly becoming the “big thing” that every new game must have. It adds detail where there was none before, and provides a much enhanced visual experience. Games are almost relying on it to give their visual intensity; a good example of this is Doom 3.
<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
<img src='http://collective.valve-erc.com/data/docs/1091469531-97736200/files/bump2b.jpg' border='0' alt='user posted image' />
<img src='http://collective.valve-erc.com/data/docs/1091469531-97736200/files/bump3b.jpg' border='0' alt='user posted image' />
The screenshots speak for themself dont they <!--emo&:p--><img src='http://www.natural-selection.org/forums/html//emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif' /><!--endemo-->
The article can be found <a href='http://collective.valve-erc.com/index.php?doc=1091469531-97736200' target='_blank'>HERE</a>.
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Bump mapping is quickly becoming the “big thing” that every new game must have. It adds detail where there was none before, and provides a much enhanced visual experience. Games are almost relying on it to give their visual intensity; a good example of this is Doom 3.
<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
<img src='http://collective.valve-erc.com/data/docs/1091469531-97736200/files/bump2b.jpg' border='0' alt='user posted image' />
<img src='http://collective.valve-erc.com/data/docs/1091469531-97736200/files/bump3b.jpg' border='0' alt='user posted image' />
The screenshots speak for themself dont they <!--emo&:p--><img src='http://www.natural-selection.org/forums/html//emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif' /><!--endemo-->
The article can be found <a href='http://collective.valve-erc.com/index.php?doc=1091469531-97736200' target='_blank'>HERE</a>.
Comments
But, i wana have this if its real, could make models look darn sexy <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html//emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif' /><!--endemo-->
Anyway it would look cool in some areas of the ns maps.
<!--QuoteBegin-Problems/Issues/Caveats/Gotchas+--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (Problems/Issues/Caveats/Gotchas)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->
Firstly, as mentioned above, anything that isn’t a world brush will not have bump mapping applied. There is probably a way to get this working for brush entities, but the only way I can think of would involve a horribly hacky method which is likely to be rather unstable. If someone can prove me wrong, I’d be delighted.
Secondly, transparent objects (models or brush entities) do not work properly. The only kind of transparency that will appear correctly is the colour-keyed pure blue ‘holes’ kind. Other types of transparency will not be rendered correctly – even additive sprites, which means that muzzle flashes on weapons do not appear correctly either.
Thirdly, you cannot use a large number of lights. This is true of all games that use bump mapping, so it is not a problem with this implementation. It is unwise to use more than three or four bump mapping lights in one map if you are aiming for playability on a GeForce 4.
<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
Unless somebody can work around those issues I dont see it being practical in any mods any time soon...
First i think it looks ugly...
Second instead of hacking the map up i rather just add more textures which render the effect that it produces.
Also, this is merely a tech demo shot without proper artwork. I guarantee the talented artists in the community could do some very impressive things with this. <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd-->
If you had read up on the feature, you would see that this actually adds a new type of light entity which behaves completely differently than the existing lights. Thus a map would have to be lit with this in mind from the start.
Unfortunately this technique looks like it would require dynamic shadows, which I guess is the next step. It doesn't fit well with the HL engine though. I've never done much coding with the HL engine, but does anyone know if it is possible to bypass HL’s BSP rendering engine completely and write your own? Doing so would allow you to optimize the renderer for this sort of thing and open up all sorts of worlds (shaders etc).
Nem
I did read it and hence my common sensical and AFAIK accurate response.
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->you would see that this actually adds a new type of light entity which behaves completely differently than the existing lights.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
Yes, I know, this is the "special dynamic light entity" I mention in my post.
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Thus a map would have to be lit with this in mind from the start.
<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
Not possible to do on a larger scale, let me explain further.
It does add a new light entity, this is a DYNAMIC LIGHT essentially, like the flashlight or any other kind of dynamic light(which could also use this very same bump mapping technique as I mentioned). This is needed because you must have directional information, something the light map that half-life uses lacks.
It is VERY COSTLY to use everywhere, if you remade a map using this feature only you would have downright rotten performance and you could not use anywhere near as many light sources and every light would be a pointlight. This is not a problem with this particular implementation, this is allways the case, look at doom 3 or something, just 2-3 lights at a time, any more and it HURTS. This thing has no occlusion, this would, as was mentioned have to be coded for it to be usefull on anything but a tiny one room little test.
Bump mapping could be turned off to support cards that don't have shaders, but the light that must replace it(can't give people with better graphics card additional light sources can we?) would still be DYNAMIC and this hurts perfomance PLENTY and is not usefull at all for stationary lights. Doom 3 also has shadows, but if you turn them off, performance is still hurt ALOT by dynamic lights, it's inescapable.
Thus the only sane usage of this in half-life is as a special effect, used in conjunction with the light map, for lights that allready are dynamic(flash light, welder) or for light sources that shine at a very large angle from the normal of the surface.
It also adds LOTS of texture usage without making anything look nicer, breaks consistency cross machines unless you are carefull and code a simple replacement for those who cannot run the feature.
For this to be worthwile it needs to be used more than just once or twice in a map, to do this you have 2 options, you need to either do clever precomputation or you need to sacrifice all the players who cannot use this feature everywhere, neither seems like a workable idea. If you try precomputation you have big problems to overcome, you should keep the good old standard light maps for compatibillity with older machines, you would need normal maps for all textures, this is not nice work as considering the number of textures. You need transparency for mappers, e.g. modified compile tools that compute an extra light map that also includes directional information or something else clever. You need to elegantly solve the problem of how to combine many different lights shining onto a surface from different angles without using lots of seperate light maps for each and every light and without making omnidirectional/ambient lighting look like the harsh directional lighting of a point source and without making RAD take 10 times longer to complete. If there was a simple and elegant solution for this I bet it would have long since been implemented.
That, and being forced to compile two different types of lighting schemes (for compatibility) would just be one huge headache. It's hard enough getting the lighting just right as is.
I just opt to have HL keep it's "dated" look. Besides, I like the way mods like NS look on the HL engine as they are right now.
One thing I love about mapping for NS is the ability to use tons of light sources. If I feel like making a room that uses nothing both one of those 32x16 lights, but uses it about thirty times, I can. From the engine's point of view it makes no difference as these are all static lights, and that's the only kind of light the engine supports. (Saving entirely precompiled light information to the bsp doesn't count as dynamic lighting IMO) Anyways, trying to do the same thing in doom 3 would bring any current system to it's knees. The point here is that there are advantages inherent in the limitations imposed by the half life engine. People still use bicycles even though we have cars.... sometimes a bike is just what you need to get the job done.
To render a level with bump mapping would require a pass per light, but the number of actual lights would be rather limited. Really you only need a pass per face that the light can see and we already have the perfect system built right into HL1 which can determine which faces are potentially visible, the VIS (you could even use backface culling to cull additional faces from the light's position). Once you have the faces the light can see you can further reduce the faces that actually need to be rendered by removing those that aren't visible by the camera. You might end up with 1000 faces that the camera can see plus 500 faces (on average) that each light can see times 20 lights (on average) that actually touch any visible face; so you'd have 11,000 faces total to render. After some optimizations this number of faces is peanuts to any decent graphics card.
Adding dynamic shadows would be a fair bit more complex but certainly conceivable. You could also use lightmaps for the shadows. All the above would require overriding HL's BSP rendering engine.
Nem