Updating collision system to double precision

[motorsep]

As you may know, collision system in idTech 4+ fails outside of 32k radius around 0 0 0 of the map. 32bit is saved by x87 FPU, but if you compile it with /fp:strict, it will fail the same way as 64bit build fails.

How hard would it be to update collisions math to use double precision and what performance impact to expect?

[motorsep]

Anyone?

[BielBdeLuna]

while I recognize the importance of this I have to say that I don't have the sufficient knowledge in order to change it.

[motorsep]

Well, I am just asking what could be potentially involved. We'll do the work.

For example, if double prevision will drop performance by much, then we'd have to reconsider. Or maybe we can't do double precision on collision system without doing the same for animation, physics and idLib.

[mgerhardy]

I'm not sure whether it is related - but I've read this http://box2d.org/2014/01/troublesome-triangle/ and this issue popped up somewhere in the back of my head. Maybe it's useful.

[motorsep]

This is collision system in Doom 3: http://mrelusive.com/publications/papers/Robust-Continuous-Collision-Detection.pdf

It's the same in BFG.

[motorsep]

Apparently quite a lot of math used for collisions is used for rendering (I am guessing matrices and all that), and since OpenGL doesn't play well with double precision, updating collisions to double precision won't be easy, or so I was told. Can someone confirm that collisions related code used in rendering or if collisions code and all related code is CPU bound ?

[BielBdeLuna]

i guess one could write a "double precision" math library, maybe just containing the functions used by the collision system, and then incorporate them to the collision system, so per example instead of idmath you would be using msmath (motorsep math which in this case serves as the double precision math) is the double precision just a change of variables types or does the calculations change? is this the purpose of the "SIMD improvements", which Cramack talks so much, to speed up the math calculations?

[motorsep]

I wouldn't know much about it. All I know is UE4 still uses float, not double internally and is prone to the same collision issues idTech 4/5/BFG.

[kortemik]

@motorsep btw do ase models show for you? testModel only seems to work for me on md5mesh models, .ase don't show up in game, only in darkradiant..

[motorsep]

ASE/LWO and MD5 all work nicely. The issue perhaps in your ASE exporter. Check game's console for errors.

[kortemik]

my ase model shows in listModels with (EMPTY BOUNDS) which might be a problem i need to investigate in

yea i fixed it, the problem was with material

[motorsep]

Back to topic, we are implementing double precision. It's a mess since renderer uses same functions as the rest of the engine, and OpenGL doesn't like doubles.

[motorsep]

small update - renderer and physics/collisions/etc. use same math classes. So upgrading doubles would lead renderer to be fed with doubles, and that's a no-go (I think OpenGL 4.0+ works with doubles). We created classes for double precision math to be used by collisions, but renderer theoretically would use floats. At the end of the day somehow renderer would still get doubles. So, I am going to drop this feature.

[BielBdeLuna]

Motorsep, switching to bullet physics middleware would solve this?

[motorsep]

No, it has nothing to do with physics itself per se. It's the world coordinate system. However, someone can try separating classes - doubles for coordinate system / collisions, floats for rendering (from what I understand we only had doubles, but doubles were typecasted? to floats for renderer, and that didn't work)

Also, you can't just swap out physics in Doom 3 for some middleware. While most game engines run physics on all entities at once, in Doom 3 physics run individually on each entity, which makes it very hard upgrading physics engine. The best thing is to improve exiting system.