Oolite Bulletins

Ahruman wrote:

Micha wrote:

Shouldn't all per-user files under Windows go into the users app-data directory?
ie:
C:\Documents and Settings\{username}\Application Data\Oolite\*

Of course this would need to be read from the registry in case it's been changed.

If that’s the “offical” location for that sort of thing, I favour it, but I don’t know how to poke about in registries. Also, there’s the question of whether Windows users actually expect things to end up in their official locations, which I can’t really comment on. :-) My observation has been that using the app directory seems to be common, especially among games, which as I understand it is why Vista has this whole “virtual store” thing in the first place (and why so many ports to OS X behave so rudely…).

Yes Ahruman, thanks a lot. And please don't use C:\Documents and Settings for the Win-Version. This directory is responsible for most system slow downs while starting or shutting down Windows and it creates a lot of traffic when starting with a network connection (server-based, user defined profiles or such a #§$&§). Users shouldn't store anything there and if possible configure their applications to avoid this too.

Fixes to ship registry:

• is_template is no longer inherited, causing all derived ships to be silently deleted.
• Ships whose model can’t be found are now reported and deleted from the registry.
• Ships used as subentities no longer require roles.
• Ships with invalid subentity definitions (not exactly eight tokens) are now reported and deleted from the registry.
• New is_external_dependency key suppresses errors for missing like_ship and subentity references. (A ship with is_external_dependency will still be deleted from the registry if it can’t be properly resolved, there just won’t be a message about it.)

Added missing compatibility method player.spawnOne() (with the usual deprecation warning and so forth).

Fixed crashes due to bad input validation in the following JS methods:

• Sound.play() (if parameter was not a number)
• Sound.playSound() (if no count specified; if one was, it was ignored)
• expandDescription() when parameter was not a string
• displayNameForCommodity() when parameter was not a string

Also fixed OS X-specific sound crash introduced after 1.72 as mentioned elsewhere.

Tangent generation for shaders is now checked in. An OXP demonstrating it is here (just to be absolutely clear: this won’t work in any released version of Oolite).

The changes ended up being way too big to sneak into a bug fix update as I suggested in a moment of euphoria. :-)

Wow, congratulations Ahruman, that's quite a milestone reached in the Oolite graphics department! I'm gagging to play with normal maps and am tempted to try the 'build the latest Oolite' thing to get my hands on them early

It really looks wonderful. Can't wait to see it on metal hulls instead of just brick walls

Thargoid wrote:

looks like an early stone-age Borg prototype to me

Resistance is futile !!!!!!!

Would it be possible to get this in for the texturing of planets?

Lestradae wrote:

Would it be possible to get this in for the texturing of planets? :shock:

As I’ve said before, shaders on planets probably won’t happen before the MNSR.

another_commander wrote:

It really looks wonderful. Can't wait to see it on metal hulls instead of just brick walls

Introducing a revolutionary new shipbuilding material: Concrete.

Ahruman wrote:

Tangent generation for shaders is now checked in. An OXP demonstrating it is here (just to be absolutely clear: this won’t work in any released version of Oolite

Is tangent generation for shaders available if you build an oolite version from source using the guide on the wiki?

Yes it is. Just make sure you checkout and build the trunk code (not any other branch like tags, or 1.72-maintenance).

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.

Very cool! I've got some worries about normal mapping, maybe you can soothe them away with your technical knowledge!
It seems that what i thought was 'normal mapping' might actually be 'parallax mapping', and that parallax mapping might not suffer from the problem i'm going to describe:
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, i do a lot of this, will we have to make sure that there are no overlapping UV's in our models in the future? 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? does parallax_mapping suffer from this problem.
I think i saw some code that calculates if a normal needs to be flipped at render time to correct the normal map mirrored UV, i can't remember if it was written in the vertex shader or in the game code, if i find it again would you like the link? - i think it was on the gamedev forums.
edit: here it was http://www.gamedev.net/community/forums ... forum_id=0