Progress Ping…

Dev of late has been consumed by Maggy – rather more than I anticipated on the visibility testing. I’ve now put in ‘flight’ levelling, and a walk mode – with a view to flying down to and landing on the surface, and having a bit of a roam about.

Although I can now fly down from space and then over the terrain, and it all works as hoped – at the moment, I’m just concentrating on a ‘perfect sphere’ (no terrain deformation) just to get the basics working, which they are. But, there’s a but… I have hit the ‘floating point’ wall – as expected, and knew would happen. Developers amongst you may nod appreciatively, and even smirk perhaps at the ‘naivety’. And well you might. I was being deliberately hopeful, but got a big slap in the face regardless.

When approaching the surface (roughly 100m above a planet of Earths radius – 6371km) floating point (in)accuracy rears its ugly head, and the geometry starts wobbling around like a sloppy jelly on a catwalk at high speed – as the granularity of a floating point number breaks down, resulting in values that jitter wildly every time they are computed. Sigh. Here’s a video showing the ‘warts’ aspect of this, as it’s a bit of a larf.

It can be mitigated – by drastically reducing the radial size of the geometry (ie. from 100.0f units radius down to 1.0f or less). This has made it almost stable. But, means the near clipping plane is way too far away to see what you are standing on. Bringing it closer means altering the entire view frustum near/far range – which has other fun impacts. I can balance this off – but it’s a diminishing return. I may have no choice but to consider using ‘doubles’ instead of ‘floats’. Sounds simple perhaps – but it’s a fundamental change to the 666 engine, and not one I want to take lightly.

So, some cogitation and research to do before progressing onto more fun aspects of Maggy’s systems. I’ll park Maggy for the time being and return to Dom before I forget what the code looks like. The brief detour into terrain and noise functions has been worthwhile, and inspired a lot of use cases for noise which are now going to be applied to far more areas than I’d originally been considering – so that’s a good thing!


  • Facebook
  • Twitter
  • Myspace
  • Google Buzz
  • Reddit
  • Stumnleupon
  • Delicious
  • Digg
  • Technorati
Author: Mak View all posts by

2 Comments on "Progress Ping…"

  1. Andrew Copland October 7, 2014 at 9:12 pm -

    We handle it in Pioneer by offsetting the rendering relative to your viewpoint.

    Take a look at the path through here:

    That’s where it actually renders the patch but you’ll have to follow it up the callstack. We do use doubles for the absolute position for obviously that won’t work with us targetting OpenGL 2.1

    Keep at it this stuff is fascinating to read 🙂

  2. Mak October 8, 2014 at 10:08 am -

    Cheers Andrew 🙂 Glad to hear it’s worth me writing this drivel 😉 Pioneer is awesome by the way! and kudos for sharing the code 🙂

    I have been considering that approach (not to be clever!), and certainly for now it may be the best route forward. It’ll certainly allow me to get on with the ‘fun stuff’ that I actually want to do 🙂 I’ve also toyed with splitting out the nearby geometry patches into a separate ‘scene’ which can then be at a larger scale – but that still gives me issues reproducing the original terrain ‘like for like’ with the same precision problems.

    OrganicVectory went through a similar decision process.

    This is a worthy read if you’d not come across it already…

Get an awesome sticky message bar!Download