I was wondering if people would be interested in combining (either now or further on down the line) this project with this one. The way I imagine it, you start off with a planet which is just a textured sphere (like the one I linked to), as you get closer, it replaces it with this one (based on the same randomly generated terrain) and as you reach close to ground level, it is again replaced with jMonkey’s in-built terrain (again, based on the same randomly generated terrain), and try to get them as close to seamless as possible.
@aaronperkins I noticed the original OgrePlanet this is based on used some GPL stuff for random generation, but that the original author wanted to replace it and release the final version under the MIT license. Do you know if that happened yet?
@kd12 said:
I was wondering if people would be interested in combining (either now or further on down the line) this project with this one. The way I imagine it, you start off with a planet which is just a textured sphere (like the one I linked to), as you get closer, it replaces it with this one (based on the same randomly generated terrain) and as you reach close to ground level, it is again replaced with jMonkey's in-built terrain (again, based on the same randomly generated terrain), and try to get them as close to seamless as possible.
I mentioned this idea in this thread actually :) I also think it would bring some awesome functionality into this :D The planets atlas could be made of renderings of the actual terrain so you'd even see the "buildings" etc.
@kd12 @normen
I desperately wanted to use TerrainGrid for this project but I ran into many stumbling blocks. For example TerrainGrid assumes the -YAxis is always up, but if you are on the side or bottom of the planet this obviously changes.
Honestly I feel jmeplanet’s terrain technique can be used to render nice views on the surface as well as far away views without switching to some other technique. The only reason I wanted to use TerrainGrid was to easily leverage the physics and other plugins (like forester) that use that system.
Maybe an expert in jmonkey’s terraingrid can do a better job integrating these then me.
@kd12
As far as the GPL code. There is no GPL code in OgrePlanet or jmeplanet that I could fine. I think an older version of OgrePlanet used a GPL noise generation library.
@aaronperkins said:
I desperately wanted to use TerrainGrid for this project but I ran into many stumbling blocks. For example TerrainGrid assumes the -YAxis is always up, but if you are on the side or bottom of the planet this obviously changes.
Hm, this is a relative issue.. Can be solved by having completely different actual world coords.. Like if you move towards the area where a terrainquad would be then the whole scene slowly turns towards the right direction..?
@aaronperkins said:
@kd12
As far as the GPL code. There is no GPL code in OgrePlanet or jmeplanet that I could fine. I think an older version of OgrePlanet used a GPL noise generation library.
Yeah, that's what I was wondering. Good then, can make it a non-copyleft license.
@normen said:
Hm, this is a relative issue.. Can be solved by having completely different actual world coords.. Like if you move towards the area where a terrainquad would be then the whole scene slowly turns towards the right direction..?
I thought the same thing, I'm sure with some (not too advanced) trickery with node arranged in trees and positioning things, you could make the world turn around so that as the second transition I mentioned is about to occur, everything is positioned correctly. On a properly scaled planet, that transition would happen well before you would see details like trees clearly. (Considering from the peak of Mt Everest the earth looks flat).
Or from a plane, which is higher than the top of Mount Everest, and an all 'round better example. And that’s a sign I need to go to bed.
This is awesome! I want to use it in some of my games!
Aaron, you did a very nice job with this! Hopefully you are still active, and don’t mind answering questions in an old thread such as this.
Question #1:
When I attach other spatials to the rootNode, the lighting is 180 degrees from your planet. I think the shaders on your planet reverse the lighting direction somehow. How would I correct that? I have attached a screen shot for clarity.
Question #2:
What modifications would we need to make to use a PointLight instead of a DirectionalLight? I would like to use your shaders on planets that revolve around a star. So far, my pointlight modifications lead to null pointer exceptions. 
I fixed the lighting direction by multiplying the sunlight vector by -1 when passing it to the material defs. However the moon doesn’t cast a shadow. I actually expected that problem. So now to work on that and pointLight.
I’m not very active but still check the forums from time to time.
I’m surprised a PointLight gave you trouble. It should have worked, though I never actually tested one before with my shaders. I’ll take a look at it when I have a chance.
In your screen shot which object is the jmeplanet? The moon or the planet? If it’s the planet, I’d like to know how you did the clouds. They look very nice.
@aaronperkins i have a question too:
Don’t you want to move your cool project to JME-Contributions? At present all projects are already stored in one place. For better fixing and communication between devs.
Here is the project: http://code.google.com/p/jmonkeyplatform-contributions/
All you need is just to send your gMail to @normen to become the committer.
In this way all projects always will be alive and updated.
At present the projects which are moved to JME-Contributions:
- Shaderblow (shaders library)
- Cubes (minecraft library)
- Forester (grass generation)
- Paging system (something like grass generator)
- MirrorMonkey (sync lib)
- and others…
@normen can explain why this is important.
@aaronperkins said: In your screen shot which object is the jmeplanet? The moon or the planet? If it's the planet, I'd like to know how you did the clouds. They look very nice.The planet. It's your standard jmeplanet unmodified from SVN, with default shader parameters. All I did was change the lighting direction by changing 3 lines in PlanetRenderState:
Vector3f lightPosNormalized = sun.getDirection().mult(-1f); <– in update{}
mat.setVector3("v3LightPos", sun.getDirection().mult(-1f).normalize()); <– in setupGroundMaterial{}
mat.setVector3("v3LightPos", sun.getDirection().mult(-1f).normalize()); <– in setupSkyMaterial{}
@aaronperkins said: I'm surprised a PointLight gave you trouble.
It’s because the material def requires a lighting direction. PointLight has a location but no direction. I’ve tried passing the PointLight location and also static vectors, but the results are… strange.
@Ashard
I think you’re confusing this older project:
http://hub.jmonkeyengine.org/forum/topic/planet-shader-and-atmosphere-scattering/
With mine.
I know, because those three lines aren’t in my project.
OMG… sure did.
I’ll go hide in embarrassment now. Sorry to have bothered you.
I downloaded your source, for real this time. It’s amazing work you did.
crawlBackUnderMyRock(Asharad);
I just finished adding physics engine support.
It was a bit of a challenge because bullet didn’t have a collision type that matched what I was trying to do. Luckily someone else had done this before:
http://recreationstudios.blogspot.com/2010/04/spherical-terrain-physics.html
I just adapted his technique to my project and it seems to work very well.
I’ll post another video when I have a chance, but for now you can get the code from bitbucket.
(I snuck in a link to your Bitbucket so people don’t have to go back to the first post for it)
So, now we can all make Mario Galaxy in a flash? 
Please consider making a plugin for the SDK.
@erlend_sh
Yah very similar to Mario Galaxy, though my planets can be a lot bigger.
A plugin would be cool. I could see a planet builder where you can tweak all the settings and visually design a planet. I have more base work to finish before then though.
There would be some integration issues with a plugin. I use custom materials for everything because I had to implement a logarithmic depth buffer. The normal depth buffer didn’t have the precision I needed to avoid z-fighting at the scales I wanted to achieve. You can’t mix my materials with core jme3 materials because of this. This makes it a poor plugin choice imho. Well unless jme happens to support logarithmic depth buffer as a core feature… 
A FLOSS Mario Galaxy clone would be sweet