When a unit is moving the location data returned in the hitPart event is significantly different from where the model visually appears in that instance (it appears to lag behind).
This seems to demonstrate that the FIRE LOD geometry is not matching the visual Resolution LOD geometry. Since these are the two most important LODs for gameplay they should match, as it would seem to indicate that shooting slightly behind a character could possibly wound it.
This permanent hit location data is provided by a improved memory LOD that contains 3-point data for each bone in the FIRE LOD. Using those points I am trilaterating the impact locations each frame, which provides a location that will continuously match the geometry (or it should, based on the hitPart location data).
When you shoot either person you will see a sideChat and a RPT message showing the trilaterated error, which is essentially 0, so these calculations are correct (especially when you consider a hit on the chest of the standing person is correct and the running person is not).
This is a clear demonstration of desynchronization of the two LODs mentioned above.
Possibly. If this is true hit detection possibly is not where the model visually is.
Eitherway the impact location (where it is doing the intersection with the FIRE geometry) is wrong in comparison to where the visual geometry is. They should match.
Is this possibly a problem with interpolation of the impact data? Just something I thought about just now. Maybe the impact is being interpolated for the time it travels between frames and that interpolation data is off (a hit is registered but its not where the reso lod ever was because its where it was "between" the frames)?
Actually I have a video now that shows how bad this problem is, and that it is a desynchronization between all the LODs (well at least the HIT and memory LOD) and the resolution LOD.
This is a MAJOR bug in my opinion.
Here you guys go: http://www.youtube.com/watch?v=oFDbyZyKxt4
Hopefully this is addressed soon!
So what I have derived from working this over in my head is that all LODs move independently of each other when animated and moving on character models. The FIRE LOD does not match the Memory LODs location, the FIRE LOD doesnt match the Reso LOD location, etc. They are all existing in world space at different locations each frame, totally desynchronized.
This needs fixing. Although difficult to notice without your demonstration, gameplay is potentially being drastically affected unbeknownst to the player. I hope fixing it doesn't heavily increase server traffic, however.
So I think the simple solution for this is to compensate in modelToWorld and worldToModel for the interpolation. This is where precision is being lost it seems. The memory LOD seems to move correctly with the reso LOD, because doing manual coordinate space conversions seems to be smooth and correct, but those two commands lose precision because the origin is updating more slowly for the math that it is using (and that origin doesn't align with the origin used in the FIRE lod in this case, if that origin did align, then we'd not have any problems).
Possibly a visibleModelToWorld/visibleWorldToModel command would be an easy fix for this? Ultimately the best possible solution would be these commands, but taking a LOD argument so you get the specific conversion for that LOD (for example, the FIRE lod seems to be projected in front of the player for predictive impact calculations, and that origin doesn't seem to match whatever origin that modelToWorld uses, etc).
This is assuming of course that only position is projected forward or interpolated and not direction or up vectors, in that case, those need to be compensated for as well.
I hope the developers comment/assign someone to the task. The mods it would allow would be fantastic, and who knows, it could allow some pleasing features for their new addon/mod competition.
You are using modelToWorld / worldToModel that is working in simulation time scope. Render time scope is different. That is why you see the difference.
Sounds amazing, would be great to see render time scope versions of modelToWorld, worldToModel, getDir, vectorDir and vectorUp.
I am confused why you would want any of these commands in simulation scope. I mean... maybe in some very edge case scenarios.
I guess the best of both worlds is good though.
@hladas dude you are legend! Thank you for bunch of XXXvisual commands, this was so needed!
One essential command is missing though, would be great to have it too:
selectionPositionVisual
Thanks
selectionPositionVisual
Don't ask me why, but this one already was in Render time scope.
Thanks a lot for new commands hladas, these will come extremely helpful for our missions.
I've written a test case code to display icons on player heads and now they follow players silky smoothly compared to usage of simulation scope commands.
removeMissionEventHandler ["Draw3d", eh];
eh = addMissionEventHandler ["Draw3d", {
{
drawIcon3D ["A3\ui_f\data\map\diary\icons\playerWest_ca.paa", [1,1,1,1], _x modeltoworldvisual (_x selectionPosition "head"), 0.8, 0.8, 0, "", 2];
} forEach allUnits;
}];
However problem when working with units that are inside vehicles still persists, it seems that modelToWorld command returns coordinates of future visual state of one frame ahead and also looks choppy like in simulation scope.
Here is a video comparison that first shows smooth ideal follow of icons over player heads and then how it works when units are inside vehicle. Is there anything that can be done to improve command functionality when working with units inside vehicles?
@hladas, how difficult would it be to make getPosWorldVisual from recently added getPosWorld (not on stable yet)?