Normal mapping
Blitz3D Forums/Blitz3D Programming/Normal mapping
| ||
| Anyone have any ideas on how to use this on the walls of a map? I was thinking you could adjust each BSP face's color by surface, in order to get the normal maps to work in tangent space. However, you can't go splitting your map up into separate surfaces like that, without making the scene unusable for realtime rendering. I tried using vertex colors, but these aren't used in the dot3 calculation. I guess you could split the map up into surfaces that have the same texture and the same normal, but that seems kind of ridiculous, and would cause at least a 6x increase in the number of surfaces. I am starting to think the solution to the surfaces limitation may involve copying chunks of memory to a temporary "render" mesh, from the source meshes which are hidden. I'll have to run some tests. |
| ||
| You'll get it dude!! Just keep at it!! I have faith in your abilities! ;) |
| ||
| If your walls are in 90 degree angles, i can an app i'm working on just for this. Basically create world space maps. I'm working just now to produce them imported geometry. You basically apply the heightmap texture to the model/level and it will convert the heightmpa to world space normal mapping. |
| ||
| I did a normal mapping that did this..basically you map a scene as if you were lightmapping, so you already know that, but instead of calculating light, map the normal map onto it. But convert the normal map rgb into it's vector, then transform this by the facing of the triangle you're mapping onto. Now you hae a valid 3d normal map for the entirely level that's also just 1 texture (use texture leafs, to pack them...you probably already did this for cshop anyway) To get just per pixel-lighting on a level though, just do the above, but instead of mapping a normal map, for each pixel get it's 3d position on the triangle in world space, normalize this, then convert this vector into a normal rgb and paint it onto the normal map. Now just use entityColor with the vector of your light from the mesh, and you get amazing looking volumetric cloudly lighting. (You still dot3 in this map) (Although you could probably use a cube-map with a 360 degree normal map to do this run time too..might be faster Works best on small entities..so you'll probably wanna segment your level anyway. |
| ||
| Are you suggesting non-tiling normal maps? The resolution of a normal texture, but the area of a lightmap? Could you post a demo of your per-pixel lighting? I am having trouble visualizing it. Thanks. I did, however, find out that vertex colors do actually affect normal mapping. So these will be used from here on out. This begs the question why the *%&^%?!!! does the dot3 calculation not just use the vertex normal, since it can be performed on a per-vertex basis, and normals transform to world space?!!  |
| ||
WICKED SICK! |
| ||
| Well, the thing is vertex colors do affect dot3(As it changes the base color you dot3 the normal map with) but if you use vertex colors, you have to use tangant mapping, if using traditional 'tiling' textures. I.e you have to transform the light vector into the 'tangant' space of each tri. It's freakin' tricky and not a lot of fun.(And slow in blitz. You have to update every vert whenever the mesh and or light source moves/rotates) Failing that, you bake the texture it.i.e make the conversation pre-runtime) I.e directly into the geo as you would a lightmap, instead of just mapping the texture thoug, you transform each pixel by the normal of the tri's face. Then you can use vert color, but this time just rely on simple vert/tri to light vectors in the colors, rather than the ugly tangant mapping. Or if it's a small object, just use entity color. but with vert color obviously you can use multiple lightsources as you just blend the results colors. As for posting the per-pixel lighting demo..I'll have to ask ad if he still has them. I don't. |
| ||
| Nm, I'll just use the source to throw a new one together..do you have a mesh I can use? I have one that's not (c) but it's awful and won't exactly show it off.(I made it..nuff said) |
| ||
| Use EntityColor for small, moving entities. Use vertex colors for the non-moving walls of your map. This lets you create the proper light vector, but lets you keep everything merged into a single surface. It only has to be calculated once, because the walls don't move around. |
| ||
| I made a front end for the tangent to world space normal map converter by ATI... I hate using the console; Hopefully this helps some one else out there. www.g0dsoft.com/conversion.zip |
| ||
| In my tests, "per-pixel" lighting with just a flat normal map looks EXACTLY like vertex lighting, and is slower, since you have to calculate the vertex colors. |
| ||
| Nah-ah...;) I was doing test yesterday as well...And it works great still. I'll upload it soon as I've had a smoke and watch some seinfeld... one issue I can't seem to get my head around is dealing with near by vectors..I mean for whatever tri you're you calculating, there's an 'eye' of the vector that just f#$#$ things up royally... It's sick to think in this day and age we still have to do such cheap things for decent lighting on even the best gpus. |
| ||
| What I noticed in tests was that you really need a decently subdivided mesh to get a full effect, much like using vertex lighting. This demo shows exactly what I mean. http://www.tomspeed.com/bb/subdivision_mesh_normals.zip 3 wall meshes, each subdivided more than the last (hit 'w' to see the subdivision amount) mouse to move the light, cursors to move in/out and pan left/right. Obiously updating what could be thousands of verts every game loop isn't an ideal situation. Tom |
| ||
| But doing it once for static lights is fine. I wouldn't really expect to have a million moving bumpmapped surfaces. At this point, I don't see anything really great about using this to replace lightmaps or decal lights. |
   |