[RELEASE] System Features: Sunspots and Rings OXPs

[Eric Walch]

So every planet looks like a ball of stripes with a seam.

Not every, only the ones that are textured by oxp. With Oolites own generated new textures you get:



This is Entere in G6. For some reason, this planet has a main station just above the north pole. (I just shot the picture while the station reflected the sunlight) Will be cold at the ground station
That probably explains the description of Entere: "This planet is a tedious place". I think most visitors just describe the situation around the shuttle landing site and never explored the vast forests that the planet seems to have. No oceans, but some very big lakes.

[Rxke]

stationary at the pole?

That should be physically impossible w/o a lot of handwavium.

[cim]

We have inertialess drives for spaceships, so this should be straightforward using the same technology. Possibly the pole is where the handwavium mines are.

[JazHaz]

Jazhaz and Wildeblood's screenshots show the interesting bug in the current trunk planets code where a cube map is treated as if it were a latlong map, rescaled, and applied. So every planet looks like a ball of stripes with a seam. Admittedly, this makes it a lot easier to find a planet which looks like a gas giant, so maybe it's not all bad.

OK well I apologise. I quite liked the messed up texture, it looks like a gas giant to me!

[submersible]

Okay - shader-fixed OXP uploaded and first post updated.

As regards textures in trunk, the answer is simple: I compiled my personal copy with -DNEW_PLANETS=0, which returns planet rendering to 1.76 mode. Since the current trunk new planet code will eventually be replaced by submersible's shader branch, I figure I might as well enjoy the existing textures while I fly about and test other things.

Jazhaz and Wildeblood's screenshots show the interesting bug in the current trunk planets code where a cube map is treated as if it were a latlong map, rescaled, and applied. So every planet looks like a ball of stripes with a seam. Admittedly, this makes it a lot easier to find a planet which looks like a gas giant, so maybe it's not all bad.

This is correct and indeed the current state of trunk with NEW_PLANETS macro enabled. Also similar on shady-planets , shaders are supported - however backward compatibility is still not working regarding the detection of cube vs latlong planet textures. I attempted a merge from trunk yesterday - however some conflicts arose where shady-planets has stomped all over the NEW_ATMOSPHERE macro #if sections. I will post in the About Planets thread I think to inquire as to the plan for NEW_ATMOSPHERE.

Oh - also , Nice work with the rings - they're a very tasty visual effect.

[Wildeblood]

As regards textures in trunk, the answer is simple: I compiled my personal copy with -DNEW_PLANETS=0, which returns planet rendering to 1.76 mode.

I can't make it work. Step-by-step idiot's instructions, please.

[cim]

Try building with make debug=no OBJCFLAGS="-DNEW_PLANETS=0" (which is not what I use, but my build process is a little idiosyncratic)

Do a make clean first to clear out anything with the old options.

[Wildeblood]

More guidance for the clueless, please. I've no idea what this means...

Me@BLACK ~
$ cd /c/myoolite/trunk/

Me@BLACK /c/myoolite/trunk
$ svn up
...[snipped]...
Updated to revision 5348.

Me@BLACK /c/myoolite/trunk
$ svn log -r 5000:HEAD > myChangelog.txt

Me@BLACK /c/myoolite/trunk
$ make clean
rm -rf ./*~ ./obj
rm -f -rf obj.win obj.win.spk obj.win.dbg obj.win.spk.dbg

Me@BLACK /c/myoolite/trunk
$ make debug=no OBJCFLAGS="-DNEW_PLANETS=0"
Making all for objc_program oolite...
Compiling file src/Core/legacy_random.c ...
Compiling file src/BSDCompat/strlcpy.c ...
Compiling file src/Core/Debug/OOTCPStreamDecoder.c ...
Compiling file src/Core/OOPlanetData.c ...
Compiling file src/Core/Debug/OODebugMonitor.m ...
In file included from o:/gstep1201/Local/Library/Headers/Foundation/NSClassDescr iption.h:30,
from o:/gstep1201/Local/Library/Headers/Foundation/Foundation.h :49,
from src/Core/OOCocoa.h:34,
from src/Core/Debug/OODebugMonitor.h:38,
from src/Core/Debug/OODebugMonitor.m:33:
o:/gstep1201/Local/Library/Headers/Foundation/NSException.h:42:2: error: #error The current setting for native-objc-exceptions does not match that of gnustep-ba se ... please correct this.
make[3]: *** [obj.win.spk/oolite.obj/OODebugMonitor.m.o] Error 1
make[2]: *** [internal-objc_program-all_] Error 2
make[1]: *** [oolite.all.objc-program.variables] Error 2
make: *** [internal-all] Error 2

[cim]

Try make debug=no OBJCFLAGS="-DNEW_PLANETS=0 -D_NATIVE_OBJC_EXCEPTIONS"

[quatermass]

handwavium mines .

These should produce some very lucrative cargo. Only rivalled by the treacle butty mines.

[Griff]

wow cim, you're the new lord of the rings! Really awesome stuff!

[Svengali]

wow cim, you're the new lord of the rings! Really awesome stuff!

Yes, it's a great example.

[Eric Walch]

I just noticed a quirk is Galaxy 5, system 71. At some locations, the ring suddenly disappears. Not only location, but also when in one position, changing the ship orientation makes the ring appear/disappear. This happens specially near the station and going in a direct line away from the station.

NB I use a modified addition routine, so I don't know if the ring is there by default.

[cim]

Should be fixed in r5472.

I've tweaked the shader a bit, too - I think this version looks a bit better: http://compsoc.dur.ac.uk/~cim/oolite/Vi ... gs_0.4.zip

[Eric Walch]

Yes, r5472 did fix the problem.

While testing I mainly watched by back while flying away from the planet. There I noticed another quirk:

The planet throws a shade over part of the ring. Looks very good, but when my exhaust plume is drawn on the top of that shaded are, it lights up as if it is in direct sunlight. (Looks as realistic as using a flash when photographing a new moon phase )