Quake3e
Quake3e copied to clipboard
ec-
Map/view inprecision.
On very big maps, the view starts to shake depending on how far the viewer is away from map origin. This is an old Q3 bug, and I think it would be cool if this issue will be fixed in Q3e, especially because Q3e does more precise math, afaik. Here is a good example of a map where you can see the bug: https://de.ws.q3df.org/map/ossas_challenge4/ Is this a rounding error? Can you fix this? Please let me know if you need more informations about this bug.
I can't check it now but I assume that it is fp rounding errors, yes. If those values somehow connects with QVM and internal mod memory structures then there is no luck...
Heh! I thought this is just pure collision inprecision (engine side). What values could be QVM connected in this regard? Sorry, that I ask but I think I don't understand this bug/issue anymore now.
Viewpos maybe, I can't tell exactly. But all pmove code is 32-bit floats so it will suffer from precision loss not depending from engine-side fixes
It depends how much precision you need: for -65535/+65535 map bounds you will have 23 (mantissa) minus 16 (65535) = 7 bit fraction = 0.0078125 units granularity at the enge of the map and so on
@ensiform the map bounds are -131072/+131072 as it seems (at least when I have a look at the map file). @ec- I don't understand a single word of what you're saying :) Can you at least point me in the right direction WHERE to change the 'units granularity/precision'? Or is this a multi-layered operation, affecting too many code parts?
@KuehnhammerTobias can you demonstrate the issue (video)?
Map it that big:
"model#0": {
"minmax": {
"mins": [-634880.0, -647680.0, -629760.0],
"maxs": [650240.0, 645120.0, 486400.0]
},
"firstBSPSurface": 0,
"numBSPSurfaces": 3364,
"firstBSPBrush": 0,
"numBSPBrushes": 11016
},
Ic no any shaking there. When it occurs (with much bigger coords), it looks sooner like triangles earthquake.
Can you at least point me in the right direction WHERE to change the 'units granularity/precision'?
You can't change it, read about 32-bit floats and how its precision scales when you increase distance/range
You're giving up too soon before figuring out the problem's source.
Cases i'v seen looked like rendering pipeline imprecision, which is improvable.
We can reopen this ticket if you want, assuming you can contribute fixes for this issue. As far as I'm concerned I'm too low skilled, and I trust ec. If he says I can't change it, I believe him.
I tried testing the map, and it seemed like the only thing that was really showing jerkiness was the weapon view model. I did some experimenting and found some changes in cgame which seem to fix that problem:
- comment out the line
CG_AddViewWeapon( &cg.predictedPlayerState );in CG_DrawActiveFrame - add the following lines to CG_DrawActive, after trap_R_RenderScene:
VectorCopy( vec3_origin, cg.refdef.vieworg );
trap_R_ClearScene();
CG_AddViewWeapon( &cg.predictedPlayerState );
cg.refdef.rdflags |= RDF_NOWORLDMODEL;
trap_R_RenderScene( &cg.refdef );
This is just a rough proof of concept, not a properly tested patch, but perhaps it might be useful.
Okay, multiple experts show interest, so I reopened the ticket. @Chomenor you are using baseq3a for your tests, right? Just asking because we are in cgame now. Though, I assume it really doesn't matter what game code we're using.
Yes, but it should work on the original cgame as well.
Just to clarify, the idea behind this fix is that since the view weapon is drawn relative to vieworg, it doesn't matter what vieworg is as long as you render the weapon in its own scene, so you can just set it to null. That avoids the rounding issues from having vieworg set to the real origin.
Oh, this is nice. At least it looks better that way, the shaking of the waepon is most noteable.
What I wonder is that a player's bounding box also shakes (or vibrates) but it doesn't affect pmove code as it seems.
When I use code that shows a bounding box I can notice a small vibration along all three axes.
Ofc, this screenshot doesn't show the vibration, but just to demonstrate what I'm talking about:
There are a few game modules that can draw bboxes, I'll check how far other idtech3 games are affected (as far as bboxes are concerned).
EDIT: or is everything shaking, the camera, the map (world), and the bbox?
Probably everything is affected. Anything that moves will have more granular movements due to lower precision of origin values, which could be perceived as shaking. The view weapon is just more noticeable due to being positioned closer to the screen.
@Chomenor Yeah thats true, hence at least suppressing weapon shaking would be nice. Is it okay to use your 'proof of concept' code snippet for my own game module for further tests? So far I tested: WoP drawing Bbox -> everything (weapon, bbox) is shaking ( = same as Q3e + baseq3a). Spearmint drawing Bbox -> the weapon is shaking, strange enough the bbox seems to not shake at all. Thanks to all of you for your comments and explainations so far.
Yes, you can use it however you wish. I can't say anything about the quality though, as it is a very quick test implementation, and somebody with more experience in this area might recognize issues with this implementation or ways to improve it.
Oh, I'm getting old, I remember that this way the lightning of the wepon model is broken. I remember that rendering the weapon in its own scene, destroys the lightning of the weapon, this was also the case with Spearmint games, where zturtleman seperated the weapon scene. I'll see what I can do...