Pioneer dev forum

In the core, the physics engine for the most part uses doubles (including matrix3x3d, matrix4x4d and vector3d) while the renderer mostly uses floats (again, including matrix3x3f, matrix4x4f and vector3f). Both these makes sense - the physics engine needs high precision, while the renderer rarely does and OpenGL tends to prefer floats anyway (at least, these things are my understanding of the situation).

This is all fine up until the point that these things interact, and then we end up having to convert between the two. And then things get messy.

So for anyone that knows, how are these things usually handled? I doubt that the CPU overhead of converting between the two is significant, but it always makes the code messy. Should we just make sure we've got good cast operators on hand and leave it at that?

Right now I'll just hack it, but I'd like to remove this mess soon.

I don't think there's any way around it, as you say the physics engine requires double precision, but OpenGL requires floats.
There is therefore going to be some conversion where those two meet.

Not many engines use doubles at all because they have no need too, or they use ways of avoiding the precision problems like we do for terrain patches.
Some engines chop the world into chunks that are integer indexed, then use floating point for the position of the character within each chunk, wrapping the position around to zero and incrementing/decrementing the chunk index as they move across chunk boundaries. This can complicate rendering things a bit though, and you get jitter on far away objects, but it's ok since it's usually sub-pixel.

Erm, my meandering point being, we can't avoid it. What would be your preferred way of dealing with it?

Cool, thanks for clarifying my thinking.

I guess then its just down to what's readable/maintainable. Which means a clearly understood line of where floats should be used and where doubles should be used, and consistent conversion functions.

By way of example, Graphics::Frustum operates entirely on doubles. That complicates its usage if you want to create a frustum from the renderer transforms, or set the renderer transforms from the frustum. So right at this moment I'm converting Frustum to use floats. Naturally that breaks a lot of code, and I'm finding it a little difficult to work out the the best way to convert it. I think I'm doing it right but its slow.

For consistent conversion functions, I actually think that fixing the mess of the matrix and vector interfaces would take care of most of it.

And there you go, I'm not going to convert it right now. Just changing Frustum to use floats and trying to thread it through properly leads me into discovering even things like mouse positions use doubles in some places. Its just too many changes for what I want right now (I'm actually doing camera work).

One day I'm going to need to completely stop work and concentrate on cleaning up.

In the case of the Frustum it might be safe to always have floats but it doesn't it also get used for clipping planets and things which might require doubles? Sometimes there might be cases where it's necessary to duplicate, in the cleanest way possible, functions/methods/classes like that so that they can be used where appropriate.

Tricky one though as I can't see a decent way of doing it other than using templates or going and assessing on a case by case basis.

robn wrote:One day I'm going to need to completely stop work and concentrate on cleaning up.

Perhaps make a note in a list (even just in this thread?) of the things where it's clearly a bit batshit (mouse position uses doubles!!!) and then we can all just split it and take bits.

Actually a better place would be as an entry in the issues where we can all chip in fixes and clean up as and when we find the time?

FluffyFreak wrote:In the case of the Frustum it might be safe to always have floats but it doesn't it also get used for clipping planets and things which might require doubles?

I think floats are ok because its only clipping, so a loss of precision isn't a big deal - you just might end up clipping slightly away from where you should, but usually the object is nearly entirely offscreen at that point anyway. So I think floats are an ok choice there, and it really does make passing the transforms around much easier.

Sometimes there might be cases where it's necessary to duplicate, in the cleanest way possible, functions/methods/classes like that so that they can be used where appropriate.

Tricky one though as I can't see a decent way of doing it other than using templates or going and assessing on a case by case basis.

Yeah, I think you're right. I think I'd prefer duplicated/templated methods etc so that the caller doesn't have to think. It can just say "I want this value in type X form" and gets it. I wouldn't do it with implicit casts because that's too easy to screw up - better for the class to either have a way to service the request, or the caller to explicit cast to say "I know what I'm doing".

That's the approach I'll take in future refactoring.

So maybe its not that simple:



That's a change from calling SetPerspectiveProjection in Camera::Draw to getting the matrix4x4d transforms back from a frustum created with the same values, converting them to float and then feeding them into the renderer.

My tired brain can't quite understand how that's possible since the same conversion process happens the old way, just via a different path. I'll need to think and experiment more.

Yeah, time for bed when you start getting things like that :D

So after a lot of tracing I figured it out. RendererGL2::SetPerspectiveProjection also updates m_invLogZfarPlus1, which sets the clip range in the shaders. SetProjection does not. So if you calculate the projection matrix some other way (eg through a Frustum object), the clip range doesn't get set up correctly and things like that happen.

Look at all those yaks lining up...