Oolite Bulletins

Griff wrote:

i've seen a lot of posts on various forums about normal mapping errors caused by mirroring and overlaying the UV's from opposite sides of the mesh ontop of each other in the UV map to save texture space,

That is indeed a problem. However, you should be able to get around that in a custom shader by flipping the appropriate component of the normal… I think you’d need to pass the untransformed gl_Vertex[/] from the vertex shader so you can tell which side of the mirror plane you’re on.

I saw a few tips about temporarily moving the overlayed UV's out of the 0,1 UV space when you bake out the normal map, then move them back afterwards when you save out the final mesh - does this technique actually work?

I have no idea. :-)

does parallax_mapping suffer from this problem.

no, since the parallax map only encodes one direction, outwards. However, parallax mapping by itself is pretty pointless as it doesn’t affect lighting.

Ahruman wrote:

The default shader now supports normal and parallax mapping. Here’s the same demo as before, only without custom shaders. New material attributes are:

• normal_map: name of a normal map text. Increasing red is down (not quite sure how that happened), increasing green is left.
• normal_and_parallax_map: same as normal_map, except alpha channel contains height value (more opaque = higher).
• parallax_scale: scale of parallax channel. Default is 0.01; if your whole texture corresponds to a 100 × 100 metre square, this means full parallax intensity represents a bump one metre high.
• parallax_bias: value added to parallax map after scaling. If you want your parallax map to represent an inset rather than a bump (which is probably better in most cases), set this to the inverse of parallax_scale (or use a negative scale). Default is 0.

Some very interesting special effects can be achieved by somewhat abusing the above parameters. I accidentally came accross this "liquid metal" effect, while playing with parallax_scale. This is what the cube face looks like with parallax_scale = 2 and shininess = 4:

All sorts of fancy "alien look" effects are possible with this. The above effect, by the way, looks 10x better when animated.

I suspect you’d get a better result with a smoother parallax map and a tiled normal map and diffuse map:

I go away for a weekend and this happens! Wow! Shiny ships (potentially)!

Bring it on!

Ahruman wrote:

I suspect you’d get a better result with a smoother parallax map

Imagine the thargoids dressed with something like that

Mesh data arrays are now dynamically sized, as they should be. This has two major effects:

• Reduced memory use, since simple objects like alloy fragments now only need enough memory for, in this case, eight vertices and twelve faces, rather than enough to fit any possible mesh.
• No vertex or face limits. (In practical terms, you’ll run into memory problems after a few tens of millions. Cold-loading a 21484v/42964f model takes a few seconds on my 2.4 GHz C2D duo; loading from cache is instantaneous.) The eight-material limit is still in place.

Additionally, some data is now shared between instances as the same mesh. This means a further reduction in memory usage, especially for asteroids and debris. In practice, Oolite’s using a bit over 20 MiB less on the demo 1 screen after the changes. (Obviously an unscientific test what with the random population of the system and so forth.) There is room for further improvement of the same magnitude, probably more.

The most useful thing about the removed vertex/face limits is that it will allow integration of a converter for ATI Normal Mapper format (assuming I can get some clarification on licensing), as discussed here.

Unfortunately, leaving this overnight for stress testing resulted in a crash after running out of address space, i.e. a memory leak. I haven’t established whether that’s in the new code, but I’m not checking it in until I know.

I have almost no idea what any of this means but I think I can hear the slobbering of the ship modellers so that has to be a good thing!

Keep up the good work Ahruman - not many applications in this day in age reduce the amount of system resources they require with each upgrade - for that alone you deserve a medal.

Wow, yet another historic milestone in the making!

Oolite is surely going places!

DaddyHoggy wrote:

I go away for a weekend and this happens! Wow! Shiny ships (potentially)!

Bring it on!

Yeah, something like this.....

Captain Hesperus

Ah yes "Nubian" - I remember the modellers/fx must have got lazy as when it landed on Tatooine its shadow was that of an SR-71...

Fortunately (?) the crash manifests even with the old mesh code, so I’ve committed this change.

At some point I introduced %X in strings as an alternative to %R, because %R doesn’t generate the full set of possible random names. I don’t know if anyone’s using %X – I may have forgotten to mention it – but I just realised it’s a terrible choice (because %X is an existing formatting code), so I’m changing it to %N from 1.73.

Ahruman wrote:

Mesh data arrays are now dynamically sized, as they should be. This has two major effects...
- Reduced memory use
- No vertex or face limits

Rock'n'Roll Ahruman. That sounds great and as DaddyHoggy said a very uncommon way these days. :-)

But we (scripters/modellers) are also not so bad in eating up the freed mem again :-)

in regard to normal maps

While most of you i presume dont have acces to 3d max 8 or 9, i found this tutorial on how to make normal maps in 3d max..

But it can also be used to understand the basics for those of you who might be in doubt to how to make normal maps...

And if any of you are using 3d max 8/9 this tutorial is quite handy...

http://www.game-artist.net/forums/spotl ... pping.html

if you can't afford 3d software but you have a digital camera and a torch:

http://www.zarria.net/nrmphoto/nrmphoto.html