Hacker News Reader

Comment by bpye | Hacker News Reader

I wonder if there isn’t another solution here. It seems like the issue is due to large translations? Presumably your view frustrum is small enough that single precision floats are sufficient for the entire range, so couldn’t you just add subtract some offset when calculating the translation matrix for both your view and the model translation? I suppose this may result in instances where you need to recalculate the translation matrix for some visible meshes, but that seems less complicated that trying to increase the on-GPU precision?

View on HN

That's a common approach to deal with calculations in aerospace and automotive applications. You choose an arbitrary origin point nearby your operational area, and work in vectors relative to that. It's often referred to as "NED", or North-East-Down. Then, you just need to be able to convert between different frames of references as needed.

Your intuition is right, there's a pretty standard algorithm to solve this called "floating origin".

Essentially you translate the world back to origin when the player gets too far away.

Double precision makes sense to me for world space interactions wherein participants are very far apart.

Something like Kerbal space program is an example where I'd probably break out the doubles.

For final projection, clipping, z buffering, etc., single precision is almost certainly enough.

> For final projection, clipping, z buffering, etc., single precision is almost certainly enough.

If you do this in the GPU then you would need it to handle double precision data.

For Kerbal, isn't it easier and more accurate to set the origin on the craft being simulated? Why use world space?

That is what is done in KSP ever since planets beyond the Mun were added - on every frame, the coordinate system is re-centered on the active vehicle. The problem that still remains is mainly in trajectory calculations - you might have an intercept with a planet way on the other side of the solar system, and you can generally see that the predicted trajectory does not pass through the encounter point in these cases due to floating point inaccuracies.

KSP only simulates at most a few hundred things in orbit, does it?

I wonder whether they should just use rational numbers for those?

Other stuff too if you want to look around, I did a quick and dirty solar system a couple of decades ago, one with texture maps where possible, and quickly discovered that Pluto was all lumpy .... simply because tessellating a sphere that far out quickly runs into FP resolution issues if the Sun is the origin

Yeah, I agree that double precision makes sense for modeling a very large system in data, but I've never bought the need for double precision when it comes to rendering a small subsection of it. Unless you have an incredibly high resolution display, single precision should be enough.

You are correct that you can render a small section of a very large data set by re-centering your origin of the data sent to GPU around a small subsection. So, now the question becomes "But, do you really want to?"

> Overall, we are quite happy with how this solution turned out. We think it is the closest to "just works" that we can get.

I think this is the crux of it. The performance penalty is very small and the convenience factor is very high.

But, now I want to know what they do with the positions of lights in the scene... Likely transformed to view space regardless for deferred rendering, I'd guess.

You are right, it is what I did when I was working on a planetary rendering system. Drawing a plane would happen far from the Earth origin, and it would show in the shader computations especially specular highlights. The new origin was at the Earth surface I think. However it's not trivial, all shaders need to change, and having things in world space is useful in your shaders. And now eg. you need to convert light positions into that local space. So likely it wouldn't make sense in the context of Godot.

Reply on news.ycombinator.com