Any astronomers among jME folks? :-)


I’m currently writing a little game starring Jaime and using jME 3.0 which will be contributed to the jME community. I wanted to have a sun with correct movement - so I implemented one. Day sky, night sky and dusk and dawn look pretty cool already. I somehow must have managed to hack in the right lines of code. The player can chose a time factor and completely decide how many virtual days are passing within a real minute on real earth.

What is still missing now is a moon - basically the same things like for the sun: The player can select a lattitude, longitude and a date and time of the Gregorian calendar - and then some routine will compute azimuth and altitude for the moon (azimuth is the astronomical azimuth counted from South). Also a routine is needed which will compute the moon phase (new moon, full moon, etc.) correctly. There is already a routine to calculate the JD (julian date) and maybe some more stuff can be reused which was previously hacked in to make the sun.

As an extra task for astronomy enthusiasts:
Extremely cool would be a hollow sphere with a night sky texture (CC-BY-SA or similar license or GPL license - CC licenses preferred). It should contain all stars as seen from Earth.

There will soon be another thread under the “contributions” category during next week with a first version of the game there.

Hopefully the stacked frustums technology that two other people committed here in the forum can be demonstrated via the game too - it will help to make a very long viewing range with not so bad precision for the Z buffer.

Have fun,

1 Like

Note: you might take a look at SimFX sometime. Right now, kind of the only effect it implements is atmospheric scattering:

…that’s what does the day/night stuff in the IsoSurfaceDemo. All it needs is stars and a moon basically… but the sun is already there and the sky properly colors for different times of day. It also has a ground shader to color things properly based on day time and distance. For special things, you can even just extract the current light color as it’s directly provided by one the app state.

Might be something you can use to save time or just grab ideas. For example, it splits managing the lighting from managing the atmospherics, etc…

Edit: note that someday this library will have other effects like fire, clouds, etc… I just haven’t gotten there yet.

1 Like

Thanks for that, Paul. That would definitely be interesting for another project.

The thing is: It would be great if the game could be next to CubeField and WorldOfInception. So it only uses assets in the testdata.jar which is included with the SDK. So hopefully someone will be able to add it to jME 3.0 SDK next to the other two games. Maybe I can also fix the CubeField game (which is currently broken) and upload it too.

Just out of curiosity: That atmospheric scattering - is it possible to use that with a planet (real size or mini sized planet)? There is another planet project in the forum, but it seems orphaned at the moment.

In the meantime a little search revealed this website: Computing planetary positions - a tutorial with worked examples
I think with such a side even a non-astronomer like me can do stuff with sun, moon, etc. :chimpanzee_closedlaugh:

It’s suppose to work… the original demo of the technique (C++ demo) used a planet. I don’t know if my hacking broke that or not.

1 Like

lightnings, rain, snow…?? :stuck_out_tongue:

Yeah, those too. Going to do the hard ones first. (Actually, I already have fire but I was trying to keep to myself until I had a game out that actually used it… but the longer that drags on, the sillier it feels.)

1 Like

A good fire I’m still needing for the game that I will release in some hours.

The moon and sun are working since Wednesday. I need to make a better moon if I have the time - currently it just consists of two half spheres (HemiSphere) - one for shadow and one for the bright side. I want to make a better moon for version 2 - this will use a DirectionalLight and a Sphere. I hope that I can get it to look in a way it does now (with the dark side of the moon always in the color of the sky). This would also allow to put a texture from NASA on the moon’s surface (but this conflicts with my goal to only use assets that are in the testdata.jar).

Well, I won’t release it by then. :smile:

But here is the thread on it from way back: Shader Flames - #23 by pspeed

I think the final test version was here: Shader Flames - #23 by pspeed

1 Like

No problem, I will just use an ugly fireplace with standard particles.
Visual perfection is not exactly the goal of that thing anyways.

EDIT: and one goal was to use only what’s available in testdata.jar and stock shaders.

Seems kind of needlessly arbitrary to me. Not sure what the motivation is since assets are distributed in the exact same way as code.

Yes, it’s like this: I want people who are not that familiar with jME to:
Download and install the jME 3.0 SDK,
Create a new project of type “JME_Tests”,
Create a file next to the other two games,
Paste the code of my file there,
Start the game.

One goal I could not achieve: Make the file small (only few hundred lines). It’s now several thousand lines, but almost every line is commented and most important things are first.

This whole process allows new users to quickly explore things and leaves them with the freedom to simply download and install the SDK as it is now.

There will also be some tutorials to make modifications to that simple game - e.g. refactor in the SDK so that one file is split up into many files (refactor > inner to outer). One such tutorial could include the description to download an asset pack which contains a better fireplace / campfire.

1 Like

Well, it’s funny because if someone asked me “What’s the single biggest problem new users to JME have?” Without a doubt, I’d answer “They try to put everything in one giant class.”

To go from noodling around with boxes to developing a real game requires tutorials on how to structure an app… and that is definitely not “shoving it all in one giant class”. Too many of our tutorials accidentally encourage that already.

What we really need are some really good “this is how you use app states and controls” tutorials.

In JME-land, a real game with no app states is absolutely doing it wrong.

Well, there are two AppStates as static inner classes.

I don’t see the problem since one of the first tutorials would do like I wrote: explain users how to put components from the inside into separate files (refactor > move inner to outer). Which could include a package structure or moving all stuff to a different project.
The user will learn from that: Okay now I have packages and they are organized by similarities in meaning (categories like ‘appstate’ or ‘widget’ or whatever). The user will probably like this - having many smaller files instead of one big file - and move on to the next tutorial.
The result will be that users have a first structure. From there they might get further tutorials on what a good structure would look like - or more than one suggestion from different people here.


I just watched outside of my window and saw the moon.
Started the game and looked at the virtual moon.
It looked the same (same phase and position in the sky).
So now I can do this:
Find the moon in the sky.
Start the game and look at the moon.
=> Know which direction (South East) the moon is!
(don’t need a compass for that anymore…)


But you need… well … you know…

a PC.



1 Like

Thanks for this link, BTW. This will be handy for another project that is in my mental backlog.