About planets

[Cmd. Cheyd]

Happy to try - what OS are you running ? I'm building on ubuntu 686 and have never attempted cross compiling.

Win7. Sorry so long in responding, I've done 6K miles flying since Sunday. Just got home.

[Kaks]

Ouch!
Hopefully you won't have to travel that much for a little while...

Do you still need a windows build now that you're home?

[Cmd. Cheyd]

(All distances are in miles)
Doing a 1.5K trip next week, week after is 3K, week after that is another 3-4K. I forget what all is after that... New job is 80-90% travel, so...

Yes, Kaks, I need a build. I don't have time to set up a build-from-source environment currently.

[Kaks]

Ok, I need to tidy up a few things from submersible's patch (the atmosphere bit is 'a bit broken' at the moment), and the new atmosphere generator in trunk is not that great either at the moment... anyway, I'll post the link to a drop-in .exe asap!

[submersible]

Ok, I need to tidy up a few things from submersible's patch (the atmosphere bit is 'a bit broken' at the moment), and the new atmosphere generator in trunk is not that great either at the moment... anyway, I'll post the link to a drop-in .exe asap!

I've gone back to basics and reverted everything I have - just to test things with NEW_PLANETS=1 and NEW_ATMOSPHERE=1 .

Things I have noticed;

• lighting on F7 screen (fixed recently by Kaks - thank you)
• NEW_ATMOSPHERE is drawn correctly on F7 screen
• NEW_ATMOSPHERE not drawn correctly in-game (scaling problem) see http://assets.povray-planets.org/static ... te-127.png and http://assets.povray-planets.org/static ... te-128.png , the atmosphere seems to be in the middle of the planet.
• NEW_PLANETS normal and specular maps are inverted, IE - ocean is matte and bumpy, land is flat and shiny (still yet to look at the code for this), the debug maps http://assets.povray-planets.org/static/new_planets/ (sorry still .bmp) make it pretty obvious.
• Shader mode 'None' vs 'Simple' vs 'Full' has bizarre effects and possibly side effects such as player materials disappearing (sometimes only the engine exhaust visible in external view), also the harsh terminator can become really harsh (like 0|1 )

So for the time being - I've put on hold any further attempt to use 'materials' and 'shaders' dictionaries for planets - so as to get the drawing of NEW_PLANETS sorted out. Not certain how much help I can be with this as the openGL realm is rather mysterious to me.

[Kaks]

It looks like there are other problems associated with shaders = 'none': I keep getting an error regarding the cobra3_redux png in the log: at a first glance I'd say it's probably connected to the shaders synthesiser stuff added to trunk fairly recently...

[Eric Walch]

[*] NEW_ATMOSPHERE is drawn correctly on F7 screen
[*] NEW_ATMOSPHERE not drawn correctly in-game (scaling problem) see http://swarm.perlide.org/static/new_pla ... te-127.png and http://swarm.perlide.org/static/new_pla ... te-128.png , the atmosphere seems to be in the middle of the planet.

With 'atmosphere' you mean that small dot on the planet that only becomes something when almost hitting the planet?

I think that is because there is only an atmosphere created with the size of the atmosphere depth and not of the planet + depth. As said, it is untested code copied from the normal planets. The collision_radius of the planet is defined in line 144 but already used to generate the atmosphere before that. Defining it sooner will fix that problem.

[pagroove]

Wow I've noticed the movies in this thread and if planets are gonna look like that then it's a very good improvement!
@Submersible. Any Progress? An BTW I could mail you the updated planet info.plist for Famous Planets for Povray the end of next week if you want.

[submersible]

Wow I've noticed the movies in this thread and if planets are gonna look like that then it's a very good improvement!
@Submersible. Any Progress? An BTW I could mail you the updated planet info.plist for Famous Planets for Povray the end of next week if you want.

The potential is there certainly to use "materials" and "shaders" dictionaries for planets in the future. My tests of this had mixed success , those movies are probably the best case result of those tests. Generating the maps presents a fun challenge.

I have stopped mucking about with materials and shaders for the moment. If you can split the FP descriptions plist into gal1 and gal2 that would be a real help.

[Kaks]

We're getting there!

The underlying code is a lot less flakey now, and we should have rock solid(!) materials & shaders via plists in the not-too distant future: possibly a couple of weeks, even!

Mind you, I can see a lump of RL approaching quickly, so it might be 'a bit' longer.
However, considering that the last progress on this was a couple of years before submersible's prodding & poking through that part of the code, we're not doing too bad!

[submersible]

Still prodding and poking. Thanks to your recent commits this is all much more reliable now. I have experimented with using

Code: Select all

yN = pow( yN , slopeExponent );
yS = pow( yS , slopeExponent );
yW = pow( yW , slopeExponent );
yE = pow( yE , slopeExponent );

Which allows for more mountain-ish shapes to the shading when combined with an increased normalScale.
The down side , that's even more operations inside loops inside code that is already time sensitive.

[Eric Walch]

We're getting there!

Nice night sky you added. I was just thinking that it sucks that the sky is blue when you are at the darkside of the planet and had the code for the sky color in front of me when I noticed your commit

I was thinking in terms of dot products and didn't realise this info was already put in a 'isSunlit' variable. A test gave following picture of a sunrise at very low altitude.



The next moment the sky was blue again.

[Kaks]

Great minds think alike! I was following a new, improved landing shuttle when I found myself on the dark side of the planet, surrounded by full daylight sky... it just didn't seem right!

I'm playing with adding some more math, though... at the moment there's still no twilight, which should happen when the sun is just beyond the horizon. Dot products to the rescue!

[Kaks]

In the end I slightly modified what was there already, and lo, we have (basic, yet quite effective) twilight! Next step, night lights!

PS: Submersible, is there any equivalent function that doesn't use exponents? Those are indeed very expensive computations...

[submersible]

In the end I slightly modified what was there already, and lo, we have (basic, yet quite effective) twilight! Next step, night lights!

PS: Submersible, is there any equivalent function that doesn't use exponents? Those are indeed very expensive computations...

Since the source map is an array of floats, perhaps it would be better to store the exponent of each point in a separate map during generation, then do the lookup against that. Reducing the number of calls to pow() from 4 to 1.

I've noticed too that planetinfo.plist "texture"="my_texture.png"; yields a planet with the default white material - no errors in log. This is plaguing my effort with materials and shaders too which are now exhibiting the same problem. I suspect I'm calling [_planetDrawable setMaterial] either at the wrong time , or that somehow the material is destroyed before planetDrawable renderOpaqueParts is called.