Oh no not these again! ;)
One for those who don't like to get that back.
My latest model i made on demand for Geraldine an "unwanted" Elite Sidewinder, it feels a little lonely (the ship i mean) and is looking for some company.
The ship as zipped MOD file (to install store it in ".../documents/Pioneer/mods"):
The ship specs equal as far as possible to the ship specs in "Frontier", the MOD will add a different gun model (pardon me) of course only as long as the MOD is installed.
(by deleting the test_gun.sgm out of the MOD you can remove that)
A few experiences i made
First i noticed the "test_gun" model is attached oriented wrong, i can imagine where that comes from, in short terms the laser is oriented -Z and we orient the "tag_gun_xxx" in +Z orientation if you now orient your model heading to -Z it will be due to the orientation of the lasers rotated (and it is as you might have noticed). So either you have to decide to orient the "tag_gun_xxx" oriented "wrong" to -Z or you would have to simply rotate the gun sub-model (what i did in the sidewinder mod) or fix this inside the engine so one won't have to mind about this orientation problem.
Second i liked to use a normal map for the sidewinder but either i'm to stupid or pioneer doesn't handles normal mapping like i expect.
This short clip shows the difference of what appears as normal mapping in blender and what happens if i use the same map for Pioneer. In blender you can see it does what one expects of it it artificially lifts the surface by a different lighting of the surface the faked embossing is very well to see if you watch how the reflection moves around the edges of the outraking flakes.
What appears in Pioneer you have to judge yourself i don't like to lose to much words about it and simply say i don't like it.
on the very end of the clip you see the model how it appears in Pioneer without normal mapping and the result is better without as with, at least in my opinion.
Here's the blender project for the model for the interested ones.
Sidewinder blender project
Ah yes, no i don't like the DXT format, it steals more colors from the bitmap as a common dithering to 8bit color depth even when the color count will tell you them are ten thousends of colors strangewisely the result is worse as a dithering down to 256 colors it looses a lot of depth), i can see no advantage to a .png file except that you could control mipmaps, could but has that done someone so far?
Just to prevent a "why don't you use..."
of course the shading is complete different and yes i already expected that pioneer supports directional normal mapping while i used a greyscale normalmap.
to be honest about the first directional open gl normal mapping i havn't had an idea and had to make myself first a little wiser.
referring to this explanation the color coded normal mapping is what i call directional, you willl see why when you snoop into this explanation.
imho it's ment for static objects (the brick wall is no occasional example) like rooms, objects in rooms, static scenes which i render, something where the object won't rotate in relation to the lightsource, objects which have a given vertical direction "up" and never will be enlighted from underneath. thus the mapping with it's three color codes repaces resp. fakes the directions but has no direction "down", "down" is "no reflection" and i can't rotate the object respectively if i do so the mapping will be wrong and the "faked" edges would receive the light from the wrong direction because left will be right now.
pretty much the reason why blender supports a different sort of normal mapping because it's not very useful for animated objects which rotate in all directions to the lightsource.
i'm not sure but i thought probably i can achieve something useful if i only use the blue channel for the "z" direction, else this type of directional normal mapping isn't useful for spaceships. might work well for buildings because you don't rotate them - usually.
on the other hand a greyscale normal mapping like in blender will work for buildings as well as the directional, thus personally i see no point of using a directional.
yes not exactly i can't make that extreme depth with it like in the brickwall example but i also guess this isn't needed for this sort of game except it would be a ego shooter in which you stumble around in some world with given lightsource directions. here you will need it to make a realistic looking surrounding world likewise an environmental light mapping but all of them are ment for static objects as soon as i change the direction of the lightsource respectively if i turn the object headover the mapping will be wrong.
even such a warrior like in the example is still "static" i know in advance i have a front, rear and side projection and respective influence of light but i will never have a top down situation where left becomes right and up becomes down.
the sun usually don't shines from underneath but well in space it's something quite different.
for any game which is set on a earthly plane (ok globe) a directional normal mapping will be very fine.
but for anything which leaves the small shade of mother earth it's not practical.
ahh yes this behave i noticed in a game it was a racing game and i wondered that if the car turns headover the lighting was "wrong" respectively it was "flat" looking compared to the top surface of the car, no wonder because the downside will never receive proper light in this way.
now that the car is headover in a racing game isn't the common situation and thus it's fine.