Page MenuHomeFeedback Tracker

HitPart impact location is not synced with the Resolution LOD (FIRE LOD not following the Reso LOD frame for frame)
Assigned, WishlistPublic

Description

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.

Details

Legacy ID
3456472913
Severity
None
Resolution
Open
Reproducibility
Always
Category
Engine
Steps To Reproduce
  1. Load attached addon and open attached mission.
  2. Shoot standing soldier. Notice the hit locations appear correctly on the resolution LOD.
  3. Shoot running soldier (preferably in the back or chest for best example) and notice the locations are out of place (10-20cm away from the resolution LOD).
Additional Information

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.

Event Timeline

Nou edited Steps To Reproduce. (Show Details)Nov 17 2013, 10:12 PM
Nou edited Additional Information. (Show Details)
Nou set Category to Engine.
Nou set Reproducibility to Always.
Nou set Severity to None.
Nou set Resolution to Open.
Nou set Legacy ID to 3456472913.May 7 2016, 5:26 PM

So this could be one of the issues that people blame on "bad net code"?

Nou added a subscriber: Nou.May 7 2016, 5:26 PM
Nou added a comment.Nov 17 2013, 10:23 PM

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.

Nou added a comment.Nov 18 2013, 1:13 AM

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)?

Nou added a comment.Nov 18 2013, 1:33 AM

Here is a video demonstrating the problem: http://youtu.be/Qn0Iz9HoN28

Nou added a comment.Nov 18 2013, 1:58 AM

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.

Nou added a comment.Nov 18 2013, 2:10 AM

Here you guys go: http://www.youtube.com/watch?v=oFDbyZyKxt4

Hopefully this is addressed soon!

Nou added a comment.Nov 18 2013, 4:41 AM

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.

This ticket needs comments from the developers, we must know what's going on.

Nou added a comment.Nov 21 2013, 8:28 PM

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.

hi

any changes since 2013-12-05?

Bouben added a subscriber: Bouben.May 7 2016, 5:26 PM
Bouben added a comment.Jul 8 2014, 7:07 PM

A major issue indeed.

You are using modelToWorld / worldToModel that is working in simulation time scope. Render time scope is different. That is why you see the difference.

hladas added a comment.Aug 8 2014, 9:49 AM

Some commands that work in Render time scope will be added.

Sounds amazing, would be great to see render time scope versions of modelToWorld, worldToModel, getDir, vectorDir and vectorUp.

OMG this is Christmas!

Nou added a comment.Aug 8 2014, 11:43 AM

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.

Thank you, just knowing this is already helpful.

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.

http://youtu.be/hi7WQInyPTA

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)?