Issue with planet texture for extra planets

[phkb]

This one is a strange one.



And that's not a black hole! (Well, technically it is a black, round hole, but ... actually, let's just move on!)

Here's the OXP set I used to create this:

Code: Select all

16:15:29.899 [searchPaths.dumpAll]: Resource paths: 
    Resources
    C:\Oolite-Trunk/oolite.app/GNUstep/Library/ApplicationSupport/Oolite/ManagedAddOns
    ../AddOns
    ../AddOns/Additional_planets_sr_base_0.8.oxz
    ../AddOns/Basic-debug.oxp
    ../AddOns/Oolite.oxp.LittleBear.GalacticAlmanac.oxz
    ../AddOns/oolite.oxp.redspear.additional_planets_sr_others_gas_giants.oxz
    ../AddOns/oolite.oxp.spara.additional_planets_sr_pack_redux.oxz

And to be clear, I don't think there's anything wrong with any of these OXP's - they're just the the ones I used to demonstrate the issue. I'm also not sure what the issue actually is: this doesn't happen with 1.90, or with releases prior to the latest 1.91 trunk (at least, I don't think it did).

Anyway, here's the steps to recreate the issue.
1. Install the OXP's listed above, then start a new game with the "Easy start" option. Strictly speaking, the Galactic Almanac isn't needed - it just adds all the planets/moons to the compass so the next steps are easier to do.
2. Award yourself some extra cash to buy the Advanced Space compass (and possibly the fuel injectors in case you need to get around the planet a little faster). This isn't part of the issue, it just helps us locate it.
3. Launch, then cycle through the space compass targets until you get to "Charon V".
4. Put the planet "Charon V" directly in front. If you see what I'm seeing, you get a big black circle with nothing in it. Obviously hard to see against a black space background, but if you swing around and put it directly behind you, you'll be able to see it in your exhaust plumes, as per my screenshot.

Now, I'm assuming this is a texture issue, but there are no errors in the log. I've tried turning on the "$texturedebug" option in logcontrol.plist, and I can see when the texture file is loaded, but nothing that indicates a problem. See this snippet from the log referring to "others_giant3.png":

Code: Select all

16:17:39.913 [texture.planet.generate.begin]: Started generator <OOStandaloneAtmosphereGenerator 0x311c0df0>{seed: 151719696,219224860}
16:17:39.913 [texture.planet.generate]: Planet <OOPlanetEntity 0x209cad00>{position: (0, 0, 0) radius: 200000 m} has atmosphere <OOConcreteTexture 0x1f3d6fd0>{OOStandaloneAtmosphereGenerator-@3
1024,512/3013876107,3948849589/0.000000/0.090000/0.000000,0.000000,0.000000/0.279617,0.247664,0.358203/0.441097,0.412597,0.511191, loading}
16:17:39.914 [texture.load.asyncLoad]: Loading texture others_giant3.png
16:17:39.919 [texture.load.asyncLoad.done]: Loading complete.
16:17:40.014 [texture.load.asyncLoad.done]: Loading complete.
16:17:40.032 [texture.upload]: Uploaded cube map texture 14 (1024x1024x6 pixels, Textures/others_giant3.png:0x1046/0/0)
16:17:40.034 [texture.planet.generate]: Preparing atmosphere for planet <OOPlanetEntity 0x209cad00>{position: (0, 0, 703980) radius: 200000 m}
16:17:40.034 [texture.planet.generate]: Initialising standalone atmosphere generator
16:17:40.035 [texture.planet.generate]: Extracting parameters for generator <OOStandaloneAtmosphereGenerator 0x311be2f0>{seed: 0,0}
16:17:40.035 [texture.planet.generate]: Extracting atmosphere parameters
16:17:40.035 [texture.load.asyncLoad]: Loading texture OOStandaloneAtmosphereTexture@0x311be2f0

And I've kind of reached the end of what I can debug. I can see textures have been applied to other planets. But for some reason this one is an issue. If I take out the "additional_planets_sr_others_gas_giants" OXP, the planet gets a texture successfully.

So, first question: can anyone else reproduce this (latest trunk 1.91 release and the 4 OXP's above)? If so, any suggestions on what might be happening here? Is there a setting in logcontrol.plist that would reveal what the issue might be?

[hiran]

While I have no clue about the black circle here a comment about the OXP set:

You listed the resource paths from the logs. You could also use OoliteStarter and export your OXP set into a file. No big difference here.
But someone else could use OoliteStarter to load that file, and all the correct expansions would magically get sorted. That makes it easier to reproduce what you perceived.

A screenshot for the OoliteStarter UI is hidden here: https://postimg.cc/SYnTmf5p

[phkb]

Unfortunately I can't use OoliteStarter on the PC I use for Oolite testing. Otherwise that would be a good suggestion.

[phkb]

Oh, and in case anyone asks, yes, I can confirm the black planet is not just in the shadow of the main planet.

[Cholmondely]

It's screaming out for one of your hand-crafted OXPs!

Is it a Thargoid base? Or - whisper it softly - have you finally found Raxxla?


Edited to add: one presumes that a texture appears if you add in more "EP" texture packs....

[hiran]

Unfortunately I can't use OoliteStarter on the PC I use for Oolite testing. Otherwise that would be a good suggestion.

It is strange. You cannot install software but have Oolite and the compilation suite?
So if it is the fact that you cannot run the installer, you could go for the generic package and install yourself. All you need on top of that is
OpenJDK 17 or later.

[phkb]

It is strange. You cannot install software but have Oolite and the compilation suite?

Not really. It is a work computer with security protocols in effect. I had a special dispensation for Oolite and the build environment. But that's as far as that goes. Anything else is blocked.

I could only run the Oolite Starter in a VM, and that VM is struggling to launch Oolite.

[cbr]

I think it works ok, but i couldnt find that spara.additional oxz and used Additional_planets_sr_pack_redux_1.1 instead.

[Cody]

I had a special dispensation for Oolite and the build environment.

Colour me impressed! Go Lionesses!

[phkb]

I think it works ok, but i couldnt find that spara.additional oxz and used Additional_planets_sr_pack_redux_1.1 instead.

That should be the right one. But you can check the log file to confirm you have the same identifiers as I did.

In which case, this looks like a local issue. Possibly graphics drivers, I guess.

[hiran]

It is strange. You cannot install software but have Oolite and the compilation suite?

Not really. It is a work computer with security protocols in effect. I had a special dispensation for Oolite and the build environment. But that's as far as that goes. Anything else is blocked.

I could only run the Oolite Starter in a VM, and that VM is struggling to launch Oolite.

So the solution would be to move OoliteStarter from my personal into OoliteProject.

[phkb]

So the solution would be to move OoliteStarter from my personal into OoliteProject.

No, that still wouldn't help. The restrictions are based on the executable name.

[Redspear]

I recently found that these 'black holes' were created during the rescaling experiment whenever a non-main planet got too large - reducing the size led to the textures appearing.

Compared to the regular game however, such planets were huge, even in their 'reduced' state when the testures actually appeared.

I too was using aditonal planets oxp to test this. The limit led to my 'gas dwarf' explorations...
If it could be solved then it would certainly give the rescaling some leeway re gas giants.

[another_commander]

Repro'd it and confirmed it. The issue is indeed scaling and, more specifically, radius of the gas giants. The planet-info.plist of the redux OXP gives a radius of 20000 for gas giants but reducing it a bit allows the gg to appear. The below modification fixes the bug.

Code: Select all

//gas giant
"ap-planet9" = {
	position = "pwm 0 0 -100000";
	radius = 16000; // was 20000
	orientation = "0.0 1.0 0.0 1.0";
	seed = "1 2 3 4 5 6";
	polar_color_factor = 0.0;
	rotational_velocity = 0.002;
	"cloud_alpha" = "0.0";
};

In this case the value of 16000 seems to be the tipping point. Making it 16001 will result in a black hole for Charon V. As to why this happens, my best (un)educated guess is that it might have to do with the different framebuffer types we are using now, combined with usage of cubemaps, which are much larger textures than the equirectangular ones we normally have for planets. At this time I have no good solution to propose other than to keep the planet sizes a bit regulated when using cubemaps as their diffuse texture types.

[Redspear]

In this case the value of 16000 seems to be the tipping point

For the rescaling it was over 40,000.

Given my limited tinkerings with the source code (rather than attempting a major rewrite), this would appear to suggest that the lesser limit is not especially difficult to surmount.

Meanwhile, the cubemaps could be relevant, I will try experimenting with that when I can.