About the DOOMIII-style normal-mapping demo: is it something that comes with B3D?
Blitz3D Forums/Blitz3D Programming/About the DOOMIII-style normal-mapping demo: is it something that comes with B3D?
| ||
| I just downloaded and ran it. It is awesome. Is it something that B3D does itslef? Or that was written IN BASIC? I mean: Des the latest version of Blitz3D support that kind of mapping? And, if it does, what kind of tool is used in order to get the original high-polygon-count model and convert it to iīs low-polygon-count model PLUS the DOOMIII-style normal maps? Thanks for your time, Rui Barbosa Jr. |
| ||
| It's a new texture blend mode, 4, which is 'dot3' blending. I don't know the answer to the rest! |
| ||
| You can do the same thing in the latest version of Blitz3d. Thats what it was created in. Written in BASIC. There are several routes to making your normal maps, depends on what modeller you use. |
| ||
| Ok, letīs see if I got it right... That was done by using a new texture blending mode, which comes with the latest version of B3D. So, all that I need in order to get that kind of quality is to use this blending mode, as well as providing the appropriate normal-maps. I wonder if that is also available for characters that allow for bones animation. Is this possible, too? Thanks for your answers, Rui Barbosa Jr. |
| ||
| You are correct. You CAN do it for boned animations but it will look wrong in areas of extreme animation (AFAIK). Unless someone discovers a way to improve on current knowledge. Also, this does all come at a cost. Both mentally and processing wise. :) |
| ||
| There's a program called orb that allows you to create normal maps get it here: http://www.soclab.bth.se/practices/orb.html |
| ||
| Thus far a way has not been discovered to use the blending mode on bone animated models and have it look correct. It would only look right in the default pose. When the guy raises his arms though, the shading wouldn't change. Also there are limitations on using it for levels as the only lights that work with the method in that demo are directional lights, not point lights. You can fake point lights with directional lights on characters, but not on levels. I went over this in detail in other threads on dot3 mapping here so I won't go into more detail here. Find those threads by searching for Dot 3 or dot3. |
| ||
| There's no problems with it on animated characters using the shading technique I used. |
| ||
| And exactly what technique was that Rob? |
| ||
| So, basicaly I would still get awesome animation, as long as I create them as separated poses, and apply the correct normals-mapping to each individual pose, right? If that is rigth, then how is all that stored? This could end up using huge ammounts of memory. Cheers, Rui Barbosa Jr. |
| ||
| Flynn: I think he's referring to generating a cubic map every frame for every light source that falls on every character. Obviously a very expensive way to render lighting for characters. I wonder if one could get away with precalculating a number of small cubic maps, and just use the one that most closely approximates the direction of a particular light source. That really depends on how small a cubic map you can get away with. If you can get away with a 16x16 map on each side of the cube, then that'll be somewhere around 6K of texture memory for each cubic map. If you go with just six directions to start, that's 36K of ram there. But that'll just give you left right front back up down. Not enough light directions. So you can add 4 more directions around the middle, making for 8 compass directions, and then four more around the top and bottom of the sphere, making for 16 additional directons, which comes to a total of 22 directions, making for 132K of texture ram. But that's still not really enough. So we add eight more around the middle, and eight more around the top and bottom... maye 16 more actually. It's getting complicated. :-) So 32 + 8 + 22 = 62 which = 327K of ram. Not bad. Light might still be a little choppy chanigng directions though. Might ned to go one higher. Also, 16x16 might not be large enough. So you might have to fo with 32x32 which means you need to multiply the ram requirements by 4. However, if you can do this and keep the textuee ram requirements under 4 megs, I think you'd be good to go. Then you just have to select the right texture out of like 256 of them that most points in the direction of your scene's light source, and it will work with animated meshes, and not come at the cost of rendering a cube map for every character every frame. |
| ||
| Rui: No, I would not reccomend doing that. That is known as "geosprites", when you simply store a bunch of copies of the mesh to make an animation. That results in very choppy animation because the animations take up so much ram. Add on to that the extra ram needed for all the different normal maps and that's crazy. :-) |
   |