Development > Artwork
Normalmaps Updates [WIP]
MCR:
I cannot start building the normalmaps until I am 100% sure to know what I am doing & how to do them perfectly, but I also do want to use the overlay method described here:
http://cgtextures.com/content.php?action=tutorial&name=normalmap
I want to adapt this method to work perfectly with our normalmapping code...
Otherwise we will not be able to create normalmaps with such a ultra-high level of details...
Normalmapping Experts - Your Help Is Needed Here !
arisian:
First off, I just want to point out that the code is still a work in progress, and shouldn't be considered representative of what to expect yet. That said, the normalmaps for the geoscape and the normalmaps for the battlescape are not actually handled the same way. The reason for this is that the geoscape uses orthographic projection, and the battlescape uses perspective projection. The alpha channel of the geoscape normal maps is actually used to specify specular reflectiveness; the alpha channel of the battlescape normal maps is used to specify height (for parallax, which is meaningless for orthographic projections).
There are also some issues with the models; all the normal vectors for the verticies of the earth on the geoscape are correct, and nicely smoothed. It's easy to get them right, because it's a sphere. For the arbitrary meshes in the battlescape, there are places where two triangles share a vertex (in the actual .md2 file) but where smoothed normals look very strange. This results in surfaces where the mesh looks flat but the normals look curved; while this is nice for smoothing things that *should* be curved, it looks strange when applied to sharp corners. I'm planning on writing some code to attempt to de-construct and re-construct models to fix this, but haven't done so yet.
Another issue is that the light sources are generally not in locations that make any sense. This is because up until now they never had any effect on the actual appearance of things. The lighting system is going to need some work before things will really start to look good.
Finally, load-times in the latest build are long; this should be fixed soon. Right now all the normal and tangent vectors are being calculated at runtime, but Mattn is working on a tool to compute them off-line and store them in data files. Once he's done, load times should go back to the way they were before.
Mattn:
it would be nice if you could also add the normalmap information you posted here to the wiki article at http://ufoai.ninex.info/wiki/index.php/Artwork#Normalmaps
the tool is almost done - just one minor issue to solve and c::b project files. maybe i find the time in the evening. it would be nice if you could have a look at ufomodel.c (especially into the WriteToFile function) whether the file layout makes sense for you.
MCR:
YOU ARE THE MAN !
Thanks for explaining things. Now I understand better, because I checked just from observation that it is a different code...
There is enough other stuff to do, so there is no need for me to know everything now & I suggest you give me a wink when code ready for testing is finished & we can find out then which normalmap making method will be able to deliver the most beautiful, most stunning & correctly looking gfx...
/offtopic on
arisian could you maybe tell me which tool is able to produce 12 or 16 bit pngs ?, as I am able to make 1, 2, 4, 8, 24 & 48 bit pngs only & 256 colors are not enough to deliver what I want to have, ideal would be to have 4096 & 65536 colors also...
/offtopic off
H-Hour:
Thanks for the work on all this arisian and mattn. It's hard on the "artists" side to comprehend all the work that goes into making an object look like an object, and we often forget how incredibly complex it can be to take an image, wrap it around an organic-looking model, then move all the vertices around.
I am reminded of Clark's third law: "Any sufficiently advanced technology is indistinguishable from magic."
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version