Sign in to follow this  
instinKt

Large scale of planetary rendering.

Recommended Posts

A question for those in the know. I'm wondering about the scale of things in a planetary rendering system, the kind where you can jump from planet to planet and go right down to the terrain on the surface. I'm assuming that you can't just render a large sphere and just move the camera close enough to it. Having a view frustum that large would play havoc with the z-buffer for one, and the accuracy of floats and doubles wouldn't allow you to get the kind of resolution used in these systems. So how are these distances handled? Is it a matter of, when the "sphere" gets too close and you redo the LOD etc, do the coordinates of the "ground plane" also change so that you're rendering a larger mesh at a further distance? Are there any articles or source code around that I could have a read of? All help would be appreciated.

Share this post


Link to post
Share on other sites
Sean O'Neil wrote a (now fairly dated) article on the topic. I have to say however, that I am using most of the tricks from Sean, Ysaneya and others, and still haven't entirely solved precision, so there is certainly room for improvement.

The basic idea is to position each planet using doubles, which you subtract from the camera position to yield floats for the rendering API. For the planets themselves, you need to provide each tile/patch of the surface in its own coordinate system, relative to the centre of the planet, and pre-transform (i.e. keep the calculations in double precision) those patches into camera space when rendering.

You will probably still need to play with the near and far planes for each planet, which makes compositing overlapping planets a right pain, but c'est la vie.

Share this post


Link to post
Share on other sites
Thanks heaps for the link.

I had a feeling it wasn't a simple problem but in a way that's a good thing. It makes it so much more fun (well maybe interesting) to play around with different methods etc.

Does Ysaneya have a journal post about how he handles it? I had a quick look through his previous development entries but didn't see anything.

Share this post


Link to post
Share on other sites
Quote:
Original post by instinKt
Does Ysaneya have a journal post about how he handles it? I had a quick look through his previous development entries but didn't see anything.
I don't recall a particular journal post, but there were several that touched on the precision issue, such as this one. That particular trick (rendering all objects in camera space) is the big one.

Of course, if you are lucky, Ysaneya or Sean will notice this thread [wink]

Share this post


Link to post
Share on other sites
I'm using a slightly different method, so as not to have to move everything every frame into camera space. So called local-space is used only from a certain level of the planetary quad-tree, all more detailed tiles are generated in the coordinate space of their parent node at that level. The level is chosen so that there's enough precision in 24-bit floats (old ATI cards), but not unnecessarily higher.

Objects on or near the surface are always managed in local-space; they would not be visible on global-space tiles anyway since these are too distant when rendered.

I didn't have any precision problems until I tried to render water surface with proper color extinction and reflection and noticed that the amount of reflection varies with moving camera - but it turned out that I was giving imprecise local-space camera coordinates to the shader, that did not manifest before because for the atmosphere it did not matter [embarrass]

Share this post


Link to post
Share on other sites
Quote:
Original post by cameni
I'm using a slightly different method, so as not to have to move everything every frame into camera space. So called local-space is used only from a certain level of the planetary quad-tree, all more detailed tiles are generated in the coordinate space of their parent node at that level. The level is chosen so that there's enough precision in 24-bit floats (old ATI cards), but not unnecessarily higher.

Objects on or near the surface are always managed in local-space; they would not be visible on global-space tiles anyway since these are too distant when rendered.
I use your method as well as the camera space trick, and I *still* have precision problems - go figure [wink]

Think I have probably implemented the camera space trick incorrectly, but that should be a relatively easy fix.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this