Jump to content
  • Advertisement
Sign in to follow this  
instinKt

Large scale of planetary rendering.

This topic is 3380 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

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
Advertisement
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
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!