Oolite Bulletins

Dr Beeb wrote:

All, let me know which textures you liked, which ones you did not and I can twiddle for the next release.

I like them all, except the banded ones. Oolite is bad at wrapping them around a sphere. The circles become pentagrams I assume it happens with all textures, but you only notice it with the circles around the planed. Specially when the circle is near the top. Better try to avoid using them.

There is a better planet model in concept. Ahruman published a testversion of the "planet tester.oxp" a half year ago. That one does show the bands correctly, so the mapping once will work nicely, but not in 1.74

We should also mention the support for cubemaps, present in Oolite v1.74 and later. Using these, no artifacts should be visible on planetary textures. Lat/long textures can be converted to cubemaps using the planettool utility, available for download from Berlios.

another_commander wrote:

We should also mention the support for cubemaps, present in Oolite v1.74 and later. Using these, no artifacts should be visible on planetary textures. Lat/long textures can be converted to cubemaps using the planettool utility, available for download from Berlios.

I wondered how these cube maps are applied to planets that are defined in planetInfo. The wiki does not tell anything about using materials here. But maybe I just should try

And I notice a weeks back that the texture does not match the rotation axis. The (future) new planets did rotate around their z-axis and had the poles exact on their top. I remember it working very well in trunk. I was surprised that the current old planets had "moving" poles. I double checked: the planets rotation axis is still the forward vector, but the texture is not wrapped correctly with the pole on top, making planets with poles (or bands) rotating strangely. But that will al be fixed when we get the new planets.

Eric Walch wrote:

I wondered how these cube maps are applied to planets that are defined in planetInfo. The wiki does not tell anything about using materials here. But maybe I just should try

I may need to double check, but I think that any planet texture with height exactly six times its width is treated as a cubemap by Oolite.

another_commander wrote:

I may need to double check, but I think that any planet texture with height exactly six times its width is treated as a cubemap by Oolite.

No that does not work. I discovered that the mac program of planet tools crashes on reading the textures from SD. Apparently it can't handle 8 bit textures. But after converting the texture to 32 bit, it generated a nice cube map. After applying that as texture on the main planet, I saw an interesting planet but not the cube map.

Hmm, this sounds suspiciously like 1.74.3 talk!

Eric Walch wrote:

No that does not work

It seems to work for me. Here are two images of a planet rendered with a cube map. I think it's OK, what problem are you getting Eric?

another_commander wrote:

Eric Walch wrote:

No that does not work

It seems to work for me. Here are two images of a planet rendered with a cube map. I think it's OK, what problem are you getting Eric?

When I use the same texture of the world as in your example and convert it to a cube map and apply the texture to the main planet with: system.mainPlanet.texture = "myCubeMap" I get:

That does definitively look different as in your screen shot.

And I have used the planet tool before to make cube maps for my asteroids. There the maps worked correct. Only the asteroids were not round enough for the maps to be useful. I used the latest version of planettool (0.4.2)

Eric Walch wrote:

And I notice a weeks back that the texture does not match the rotation axis.

This is a known bug documented in the 1.74 release notes.

Eric Walch wrote:

When I use the same texture of the world as in your example and convert it to a cube map and apply the texture to the main planet with: system.mainPlanet.texture = "myCubeMap" I get:

That does definitively look different as in your screen shot.

OK, we seem to have some 1.74.3 talk here indeed. I reproduced the weird planet using your steps. However, it works OK if texture is set from planetinfo.plist. Need for fix.

Ahruman wrote:

[This is a known bug documented in the 1.74 release notes.

That note is about a wrong rotation axis and I was talking about shifted texture as I double checked that planet's forward vector kept pointing in the same direction during rotation. It was the texture that was off. But I am sure we talking about the same bug here.

One other question about cube maps.

Cube mapping is something that is supported by the graphic card (GL_ARB_texture_cube_map). But what if an old card does not support cube mapping? Or is it that basic for a card.

Actually, both Eric and a_c's results are accurate and reproducible.

If the texture is applied via a normal javascript (mine ran off the this.shipWillExitWitchSpace event) - I get a_c's results.

If the texture is applied dynamically via the debug console - I get Eric's results.

Edited for Further testing:
If a cubemap is initially applied via js, the console is able to properly apply a different cubemap, but latlongs appear incorrectly.

If a latlong map is initially applied via js, the console is able to properly apply a different latlong, but cubemaps appear incorrectly.

So, it appears that the decision on how to apply the texture is set once, and is not reevaluated upon texture changes via the debug console. Which makes sense actually to me... Still, it would be nice if it did re-evaluate.

Cmd. Cheyd wrote:

So, it appears that the decision on how to apply the texture is set once, and is not reevaluated upon texture changes via the debug console. Which makes sense actually to me... Still, it would be nice if it did re-evaluate.

Great, it means that the problem is not that big. It must be fixed, but for the current oxp's it is usable. It is not common that a planet is textured twice.

It can happen if SR is overwriting a texture applied by FP but such things should not happen in the first place. And for the main planet it can be checked that the texture property has not yet a value.

And a quick test shows that the "banded" planets from systemDemux now indeed start looking good when using cube maps.

Fixed in r3719.

Eric Walch wrote:

Ahruman wrote:

[This is a known bug documented in the 1.74 release notes.

That note is about a wrong rotation axis and I was talking about shifted texture as I double checked that planet's forward vector kept pointing in the same direction during rotation. It was the texture that was off. But I am sure we talking about the same bug here.

I added cube maps to my planet rotation tester. This oxp adds 4 small planets near the witchpoint after every jump. With plain maps my test planets did not rotate around the "north poles" although I checked that the rotation axis was the z-axis. Now with cube maps, the rotation is correct around the pole. Strengthening my statement that the rotation was correct, but the mapping was not. It now appears to me that cube maps are positioned correct to the poles. (Bug #17243 claims that cubemaps in planetInfo.plist are off position but I don't see that myself. At least not on the secondary planets. They probably are wrong on the main planet and definitely on the miniature planet.)

One other thing I noticed was that all my numbers were mirrored after my first conversion. So maps must first be flipped before converting to cubemaps. (Your planet tool already has a check box to do that during conversion)