building tools/icosmesh - OOPlanetData.c

[submersible]

I have been a fool - all the while struggling with planet materials and shaders, not realising that they (synthesised materials and most shaders) need the vertex's tangent attribute which is not bound in OOPlanetDrawable since it has never been required. Digging into that lead me to OOPlanetData.c which contains vertex and normal arrays - but no tangents.

Can someone with more clue than me advise - how to build icosmesh for linux so I can tinker with making it build tangents too?

EDIT - sorry , that is vertex and texture coord arrays . so where are the normals coming from ?
RE-edit , of course the normal of a vertex describing a point on a sphere IS the vertex

[another_commander]

Not sure how much I can be of help as I cannot build this myself. You need to have Obj-C 2.0 (libobjc2) installed, as the source references things like @property and @synthesize which don't exist in the original libobjc. So before anything else, make sure that your GNUstep implementation carries an appropriate Obj-C library. I know for a fact that the version of GNUstep used with the latest releases of Oolite (1.20.1) does not support this so you must check what is in the repositories and use that if it is suitable.

[JensAyton]

I have been a fool - all the while struggling with planet materials and shaders, not realising that they (synthesised materials and most shaders) need the vertex's tangent attribute which is not bound in OOPlanetDrawable since it has never been required. Digging into that lead me to OOPlanetData.c which contains vertex and normal arrays - but no tangents.

If the tool did generate tangents, it would use the same logic as the default shader. I know that’s buggy, but the tangent calculation (as documented in the fragment shader, albeit with slightly confused terminology) is conceptually correct, and using a (large) attribute array for it would be inefficient.

By the way, my plan before shelving the “new planets” back in the day was to switch to supporting cube map textures only – with a converter for old textures, the inverse of OOConvertCubeMapToLatLong(). The sphere data would then consist of only vertex positions, with no texture coordinates. Without the texture seam handling, the subdivision would be simpler and should be done in the game, saving almost 50k(!) lines of “code”. (If you ever get the impression that something in Oolite is prototype-quality, that’s because it is.)

[submersible]

If the tool did generate tangents, it would use the same logic as the default shader. I know that’s buggy, but the tangent calculation (as documented in the fragment shader, albeit with slightly confused terminology) is conceptually correct, and using a (large) attribute array for it would be inefficient.

Thank you - that has fixed it and seems not to be a performance burden on the shader that I can see. Can the synthesised shaders be sensitive to OO_TANGENT_ATTR and use either the attribute or in its absence perform that calculation instead ?

Quick sample of desert planet w/ normal and emission (via shaders)
http://youtu.be/Hc9sdJ-gJlw

[Cody]

Looking good, sub!

[maik]

Yeay, looking forward to seeing this in game

[JensAyton]

Thank you - that has fixed it and seems not to be a performance burden on the shader that I can see. Can the synthesised shaders be sensitive to OO_TANGENT_ATTR and use either the attribute or in its absence perform that calculation instead ?

I don’t think using the ship shader synthesizer for planets is a particularly fruitful approach. Writing a separate one for planets would produce better results with a better configuration interface. I’ll look at that when the new ship shader synthesizer is finished-ish.

I intend to get back in the saddle this weekend, although this “spring” stuff may provide further distraction.

[submersible]

No problem - I'll carry on working with the shader parts. Hopefully fix my SamplerCube notion of parallax mapping then move on to atmosphere shaders.