Hi, fellow monkeys. I’m working on a game set in interplanetary space in our solar system. I set up a very simple scene with a lovely skybox wallpapered with NASA images of the surrounding starscape, and a sphere in the center with a nice texture made from astronomical images of the sun.
This is all working nicely, except for one thing: the sun vanishes when I get too far away. I understand why that would happen in the usual case. What I need to know is, how to make a special case of the sun so that it always gets rendered, no matter how far away I get.
I’ll continue to RTFM, but if someone happens to know a straightforward way to provide for this case, and feels like explaining, I’ll be very grateful for the time saved.
@mikelevins said:
Hi, fellow monkeys. I'm working on a game set in interplanetary space in our solar system. I set up a very simple scene with a lovely skybox wallpapered with NASA images of the surrounding starscape, and a sphere in the center with a nice texture made from astronomical images of the sun.
This is all working nicely, except for one thing: the sun vanishes when I get too far away. I understand why that would happen in the usual case. What I need to know is, how to make a special case of the sun so that it always gets rendered, no matter how far away I get.
I’ll continue to RTFM, but if someone happens to know a straightforward way to provide for this case, and feels like explaining, I’ll be very grateful for the time saved.
There are a couple ways of handling this…
You could potentially set the far frustum of the camera to some outrageous distance, however, this probably isn’t the best approach.
Have you considered replacing the mesh with a billboarded quad when hitting a certain distance. Then, instead of moving away from this, you could potentially scale it based on perceived distance?
Not sure if this is an acceptable solution or not, but… but placing/scaling the quad appropriately wouldn’t take much effort and would allow your game to make use of frustum culling when it is appropriate.
Sure, I think replacing it with a billboard is a fine idea. I don’t yet know in detail how to do it, though.
Right now what happens is I back off to a certain distance and POOF! the sun disappears. What I need to know is what calls to make and what parameters to adjust to (1) increase the distance before that happens and (2) swap in the quad when the threshold distance is reached.
I freely acknowledge that I just need to read enough of the docs to figure out how to do these things, and I’ll most certainly do that. But if you happen to have any further tips about where to look, or pointers to sample code showing how to do it, I’ll receive them gratefully.
Space scale rendering is very tricky, unfortunately. You won’t be able to just plop all the objects in and have it work out ok… there just isn’t enough precision in what’s sent to the GPU. So as mentioned, you will end up doing lots of tricks. Probably the easiest is to render your scene at different scales in layers… which is to say not particularly “easy” but it is the “easiest”.
Well, sure, but that’s all meta stuff (that we already have strategies for). What I’m looking for is simple, nuts-and-bolts stuff like:
what are the actual calls I need to make to control the distance at which jme stops rendering the sun? It’s currently disappearing from the scene at a very low distance; what calls to I make to increase that distance?
what are the actual calls I need to make to enable swapping in my billboard quad for a distant object when I reach the threshold distance?
Again, if nobody knows the answers, I’m content to dig until I find them for myself.
I had to deal with this exact same issue in jmeplanet.
Setting the far frustum higher works, but you will probably quickly notice issues with z-fighting when two distant objects overlap. Think of a moon orbiting a planet. If you see flickering between the two objects when one is behind the other you’ve hit the precision limit of the depth buffer.
There are two ways to handle this.
You can change the scale of the depth buffer. The modern depth buffer is actually large enough for very large scenes, but the default scale used “wastes” a lot of precision for very close objects, and doesn’t leave enough for far away objects. This can be fixed by using a logarithmic depth buffer instead.
I first tried this approach in jmeplanet. it worked great but requires custom shaders for everything and breaks many of the filters that also work with the depth buffer (fog, shadows, etc)
So I went to the second approach as pspeed hinted to:
2.Multiple viewport layers. Basically you render the scene twice. Once with a view port that has the near and far frustum set out in the distance. A second render that has the near and far frustrum close in. You layer the two on top of each other for the final image.
Both approaches are in the jmeplanet source control. You’ll have to go back a few revisions to see the logarithmic depth buffer approach.
We’re doing something a little bit different–for example, no flying down to surfaces for now–but your techniques-especially for frustum management, will be very helpful.
Your demo flights are inspirational, too. Very nice effect.
“><img src=”<img src=“http://i.imgur.com/yoZrS62.jpg” title=“Hosted by imgur.com” />" alt="" />