• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Imprecision

Imprecision problem on planet

6 posts in this topic

Hello,

because sometimes it's hard to follow an explanation only in mind I added a few pictures to this post. Sorry for those which have a slow internet connection.

First of all, I'm programming a planet renderer. Im using the cube to sphere algorithm from mathproofs: [url="http://mathproofs.blogspot.com/2005/07/mapping-cube-to-sphere.html"]http://mathproofs.bl...-to-sphere.html[/url]
My problem is that it running into the common floation point error because the algorithm forces me into a specific range (imho), and I don't know how to getting arround it.

The algo morphes all 6 sides of a cube in to a sphere.
One side look like this after morphing:

[img]http://www.abload.de/img/prob471dty.png[/img]

Using the algo on all 6 sides I get a sphere inbetween -1 and 1 (scale 1):

[img]http://www.abload.de/img/prob3m2db7.png[/img]

That LOD is implemented as an quadtree. When coming closer the chunk is seperated in 4 smaller chunks each with the same amount of vertices as the old chunk.

[img]http://www.abload.de/img/prob513ffd.png[/img]

These chunks can be seperated too, so I get a smooth surface even if im extremly close to the planet (in theory).
This is how it look like if I create a really deep tree and zoom out:

[img]http://www.abload.de/img/prob6mbdnw.png[/img]

Here comes the trouble.
On the tiny chunks the curvature is extrem small. Its so small that I run into floating point imprecision
and the result is that:

[img]http://www.abload.de/img/prob2zfcq9.png[/img]

As you can see the surface is not flat and when I change the angle of the camera everything is "wobbeling".
The quadtree depth is at 18 that means that the smallest chunk is one 262144th of the original chunk in sidelength.

Visualising this on 2D it looks like this:

[img]http://www.abload.de/img/prob16gde4.png[/img]


What can I do to solve this problem?
I already fixed my camera to Vector3.Zero and just move the world around me to get highest precision near to my camera, but I still got the problem.


I appreciate every comment. Thanks.
0

Share this post


Link to post
Share on other sites
May I ask what the cell edge length actually is at the 18th subdivision of a quadree face for a cube representing, say the size of earth?
0

Share this post


Link to post
Share on other sites
[quote name='Imprecision' timestamp='1331244191' post='4920519']The quadtree depth is at 18 that means that the smallest chunk is one 262144th of the original chunk in sidelength.[/quote]

That's a subdivision size of about 24 metres, on the earth. Do you need to get that close in?

The mantissa in a float is effectively stored with 24 bits of precision. At 18x subdivision you're left with 6 bits of precision, which isn't much - errors will be up to about 1/64th of the actual value.

If you need to get that close in and have the surface look smooth I'd suggest using double precision. That means you will probably to do at least some of the transformation work on the CPU because most GPUs don't handle doubles. You could just give the GPU screen space coordinates. Alternatively move the origin dynamically so 0,0,0 is on the bit of the surface you're looking at - it's currently about 6 million metres away!

You might find http://randomascii.wordpress.com/2012/02/13/dont-store-that-in-a-float/ and the other articles in that series helpful too.
0

Share this post


Link to post
Share on other sites
[quote name='return0' timestamp='1331246804' post='4920526']
May I ask what the cell edge length actually is at the 18th subdivision of a quadree face for a cube representing, say the size of earth?
[/quote]

Earth has 510,000,000km², one side is one 6th: 85,000,000km² divided by 4[sup]18[/sup] is 0,0012km² or [u]1,237m² with a edge length of 35m[/u]
Still huge in my opinion. [img]http://public.gamedev.net//public/style_emoticons/default/sad.png[/img]

[quote name='Adam_42' timestamp='1331252258' post='4920540']
[quote name='Imprecision' timestamp='1331244191' post='4920519']The quadtree depth is at 18 that means that the smallest chunk is one 262144th of the original chunk in sidelength.[/quote]

That's a subdivision size of about 24 metres, on the earth. Do you need to get that close in?
[/quote]

The 24m (or 35m) could be enough, (better would be a depth of 22 divisions) but i get imperfections already on depth of 14 which is definitely to big for me [img]http://public.gamedev.net//public/style_emoticons/default/sad.png[/img]

[quote name='Adam_42' timestamp='1331252258' post='4920540']
The mantissa in a float is effectively stored with 24 bits of precision. At 18x subdivision you're left with 6 bits of precision, which isn't much - errors will be up to about 1/64th of the actual value.

If you need to get that close in and have the surface look smooth I'd suggest using double precision. That means you will probably to do at least some of the transformation work on the CPU because most GPUs don't handle doubles[/quote]

[quote name='hupsilardee' timestamp='1331248380' post='4920530']
...Use double precision?
[/quote]

I already use double precision. All calculations are one the CPU made with double precision. When I send the vertices to the vertexbuffer the're converted to 32bit float. Matrice transformations are on 32bit too.
Limiting factor is the graphicscard is working with 32bit float


[quote name='Adam_42' timestamp='1331252258' post='4920540']
. You could just give the GPU screen space coordinates. Alternatively move the origin dynamically so 0,0,0 is on the bit of the surface you're looking at - it's currently about 6 million metres away!

You might find [url="http://randomascii.wordpress.com/2012/02/13/dont-store-that-in-a-float/"]http://randomascii.w...hat-in-a-float/[/url] and the other articles in that series helpful too.
[/quote]

I tried that out (putting the top surface to (0,0,0), but it didn't helped. I already got the highest precision in range of -1 to 1. [img]http://public.gamedev.net//public/style_emoticons/default/sad.png[/img]
0

Share this post


Link to post
Share on other sites
I use more or less the same technique for my procedural planet, and I am having similar issues.
I generate the whole geometry on the gpu, which makes things even worse because I have to use 32bit precision everywhere.
The wobbliness comes mostly from floating point imprecision during the View & Projection transforms.

I have had moderate success with scaling up the planet and keeping everything close to (0, 0, 0).
In my last test, iirc I used a radius of 1000.0 and kept (0, 0, 0) at the center of the camera (I translated the world instead of the camera).
This did improve things, but I haven't really had much time to investigate this further because I was focusing on other things.

When you're saying that you get issues at level 14 already, is that 14 subdivisions on a quad or on a 33x33 grid as shown in your first picture?
I'm currently running 21 divisions on a quad, and issues are only visible if I move the camera very close to the ground (~200 meters, assuming an earth sized planet)
That is without using the scale/translate optimization for better precision.
Unfortunately I can't test it with the optimization right now, I've broken it quite badly with my latest additions.
0

Share this post


Link to post
Share on other sites
[quote name='Imprecision' timestamp='1331296054' post='4920645']
I tried that out (putting the top surface to (0,0,0), but it didn't helped. I already got the highest precision in range of -1 to 1. Posted Image
[/quote]

I take it you did that translation using doubles on the CPU side of things? Doing it after the conversion to float won't help, because the precision is already gone at that point.

To check that you got it right take a look at any translation that happens in the vertex shader - that needs to be as close to zero as possible to get you the best precision.

Are you combining the world, view and projection matrices on the CPU and passing a single matrix to the vertex shader? If not that can mess up precision if for example the world and view matrices are doing equal and opposite translations.
0

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  
Followers 0