A new sky system

This thread is about a new sky system. It is divided up into many parts, and each part is added separately. Currently there is only the skydome available.



You can find the code here: http://code.google.com/p/jme-sky/



There are instructions on how to use it in the wiki part.

18 Likes

An alien sky. You should see these color shifted skies at sunset with HDRR. It’s an experience in itself.



http://www.jamtlandoutdoors.se/images/dist/alien_sky.png

3 Likes

Haha androlo, you kill me! :stuck_out_tongue: And why are you still missing your contributor tag???



Do you also plan to include noise clouds? So clouds changing in real time?

Nice effect!

@Dodikles

Hmm I haven’t thought about the tag, gonna look into it. And yes, there will be noises.



I am focusing on cleaning up the astronomy stuff now. That can be used with whatever sky system people use. It does not have to use my sky (all it does is provide positional data).



What I got now is a functioning calendar, sun position calculator and moon phase calculator. When it comes to the moons position there are problems. Calculating it requires a crapload of calculations, and is way too slow. For example, look at this function in Ogre’s Caelum plugin:





void Astronomy::getEclipticMoonPositionRad (

LongReal jday,

LongReal &lon, LongReal &lat)

{

// Julian centuries since January 1, 2000

double T = (jday - 2451545.0L) / 36525.0L;

double lprim = 3.8104L + 8399.7091L * T;

double mprim = 2.3554L + 8328.6911L * T;

double m = 6.2300L + 648.3019L * T;

double d = 5.1985L + 7771.3772L * T;

double f = 1.6280L + 8433.4663L * T;

lon = lprim

  • 0.1098L * sin(mprim)
  • 0.0222L * sin(2.0L * d - mprim)
  • 0.0115L * sin(2.0L * d)
  • 0.0037L * sin(2.0L * mprim)
  • 0.0032L * sin(m)
  • 0.0020L * sin(2.0L * f)
  • 0.0010L * sin(2.0L * d - 2.0L * mprim)
  • 0.0010L * sin(2.0L * d - m - mprim)
  • 0.0009L * sin(2.0L * d + mprim)
  • 0.0008L * sin(2.0L * d - m)
  • 0.0007L * sin(mprim - m)
  • 0.0006L * sin(d)
  • 0.0005L * sin(m + mprim);

    lat =
  • 0.0895L * sin(f)
  • 0.0049L * sin(mprim + f)
  • 0.0048L * sin(mprim - f)
  • 0.0030L * sin(2.0L * d - f)
  • 0.0010L * sin(2.0L * d + f - mprim)
  • 0.0008 * sin(2.0L * d - f - mprim)
  • 0.0006L * sin(2.0L * d + f);

    }







    I count 20 sines, and it’s still far from done. You then have to convert this into Horizontal coordinates, then rectangular.



    There should be more efficient ways tho. I noticed that Caelum “brute-forces” the sun position (which I do not…), so this could probably be simplified a whole lot, but there are still lots of work involved. A lot more then with the sun.



    I guess in the worst case, both sun and moon positions can be calculated in a callable every day and stored into a table. I’m leaning towards that atm.
1 Like

Hey, this looks really nice uh @androlo. You’ve got a challange over there to calculate the sun and moon positions.



If you think it’s going to be a heavy work, you could do two ways: a dumb one, that doesn’t calculate the actual position, just use a provided input to do it, and then repeat the exact same thing. And a second way, that it could be this complex algo you said. Just start a thread and let it run, so it doesn’t interfere with the rest of the threads.



Just a random idea that came to my head.

Yeah IMO scientific exactitude is overkill.

Also most of the time, artists will want to tweak the position of the sun/moon. Don’t bother doing that…

Just a day/night cycle, with the sun during the day, the moon during the night is fine IMO.

@nehon said:
Yeah IMO scientific exactitude is overkill.
Also most of the time, artists will want to tweak the position of the sun/moon. Don't bother doing that...
Just a day/night cycle, with the sun during the day, the moon during the night is fine IMO.


http://www.telegraph.co.uk/culture/film/9179446/Wrong-stars-force-Titanic-3D-scene-to-be-reshot.html

Having said that I agree with you. Developers/artists/designers need options for either static time or moving time and the ability to control where/how the sun etc move in static time.

For example in a werewolf game the moon position would become very important.

@androlo said:

I count 20 sines, and it's still far from done. You then have to convert this into Horizontal coordinates, then rectangular.

I guess in the worst case, both sun and moon positions can be calculated in a callable every day and stored into a table. I'm leaning towards that atm.


My suggestion would be to calculate the dawn, noon and evening positions once at the start of the day and then generate a spline from the three positions and iterate over the spline.

I have to admit that I am very excited about all the stuff you’re coming up with. If your projects are both in a stable state I will definitely include them in my project.



The sun/moon system is way too sophisticated, as the others pointed out. No player will ever realize that you try to recreate correct moon cycles, also considering that maybe it’s not situated on earth and having multiple suns, moons etc :wink:



Ok, noise clouds is great. Are you maybe also opting for volumetric clouds? For example: http://www.youtube.com/watch?v=I1_f0z3Ht-k



Just know that your work is very appreciated!

I know how to do now. Gonna put the accurate stuff aside for the time beeing, but I need it for my own apps so I’ll keep developing it on the side. If someone want it later I’ll just include it.

Yes. I see how it can be done now. Just gonna throw in my atmospheric scattering model, then put the clouds on top of that. I’ll probably have a lib up in a few days.

4 Likes

Yeah, releasing with a ‘dumb’ and a ‘correct’ version is great for a library, that allows all developers to use it ^^ I’m doing exactly that with my game libs. When it’s done, the main core won’t be release at the first year, but the libraries I developed I’ll be happy to share.

I have finished the simple positions. Basically, you set three parameters:


  1. Sunrise time (default is 7 am, or 07:00).
  2. Sunset time (default is 10 pm, or 22:00).
  3. Maximum declination (default is 50 degrees).



    With these values it calculates the solar noon (sunset time - sunrise time), and then creates a curve that the sun will follow. If you want the sun to climb up all the way to zenith, you just set declination to 90 degrees (max). If you want the sun max to be half way up the skydome, you set the declination to 30 degrees etc.



    The default is using (-1,0,0) as east (which is rightwards if looking in the z direction), or you can set it manually.



    The moon will initially just be at opposite direction of the sun.

So no seasonal changes? What a shame. :wink:

What scattering model are you using?

Moon location should have no connection to sun location (although moon shading should - that’s a different story).

This is the system I use for atmospheric scattering. Seems to be well used and liked. Did it for another app some time ago, but I felt it was too slow. I’m looking at gradient based models, but I guess its better to go all the way… Nobody wants garbage.



http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter16.html

And you can have seasonal variations and accurate moon/sun positions with the accurate system. The lag is on you tho.

1 Like

Been looking into that model before, reasonable choice :slight_smile:



Are just gonna use it for the sky or are you going to have scattering applied to the scene also (far away becomes blue tinted)?



If I’m remembering correctly the approach taken in that applies scattering on the vertices of the terrain, which means that the calculation needs to be in every vertex shader that should have scattering applied…

Good guy androlo…



Contributes a load of amazing code to JME…



doesn’t worry about the contributor tag