Arma 3 Feedback Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0016115Arma 3Enginepublic2013-11-17 22:122016-01-28 17:07
Assigned Tohladas 
PlatformPC OSWin VistaOS Version64 bit
Product Version1.04.111.668 
Target VersionFixed in Version 
63 vote(s) 100,00%
0 vote(s) 0,00%
Summary0016115: HitPart impact location is not synced with the Resolution LOD (FIRE LOD not following the Reso LOD frame for frame)
DescriptionWhen 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.
Steps To Reproduce1. 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 InformationThis 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.
TagsNo tags attached.
Game VersionArma 3 Dev
Attached Filesrar file icon Test_Character_01.rar [^] (3,568,896 bytes) 2013-11-17 22:12

- Relationships
related to 0016460assignedDarkDruid [EventHandler] make "HandleDamage" giving the correct selection which have been hit (like "HitPart") 

-  Notes
ProGamer (moderator)
2013-11-17 22:18

So this could be one of the issues that people blame on "bad net code"?
Nou (ticket author)
2013-11-17 22:23

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 (ticket author)
2013-11-18 01:13

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 (ticket author)
2013-11-18 01:33

Here is a video demonstrating the problem: [^]
Nou (ticket author)
2013-11-18 01:58

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 (ticket author)
2013-11-18 02:10

Here you guys go: [^]

Hopefully this is addressed soon!
Nou (ticket author)
2013-11-18 04:41

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.
SaBrE_UK (reporter)
2013-11-18 09:30

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.
SaMatra (reporter)
2013-11-20 01:05

This ticket needs comments from the developers, we must know what's going on.
Nou (ticket author)
2013-11-21 20:23
edited on: 2013-11-21 20:28

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.

SaBrE_UK (reporter)
2013-12-05 16:39

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.
johnnygitarr (reporter)
2014-07-08 18:40


any changes since 2013-12-05?
Bouben (reporter)
2014-07-08 19:07

A major issue indeed.
hladas (Bohemia Interactive - developer)
2014-08-07 22:27
edited on: 2014-08-07 22:27

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 (Bohemia Interactive - developer)
2014-08-08 09:49
edited on: 2014-08-08 09:49

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

SaMatra (reporter)
2014-08-08 09:53

Sounds amazing, would be great to see render time scope versions of modelToWorld, worldToModel, getDir, vectorDir and vectorUp.
Killzone_Kid (reporter)
2014-08-08 10:12

OMG this is Christmas!
Nou (ticket author)
2014-08-08 11:43

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.
Killzone_Kid (reporter)
2014-08-18 21:12

@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:


Killzone_Kid (reporter)
2014-08-18 22:57 [^]
hladas (Bohemia Interactive - developer)
2014-08-19 08:26

> selectionPositionVisual

Don't ask me why, but this one already was in Render time scope.
Killzone_Kid (reporter)
2014-08-19 10:52

Thank you, just knowing this is already helpful.
SaMatra (reporter)
2014-08-19 13:45

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?
Killzone_Kid (reporter)
2014-08-29 22:03
edited on: 2014-08-29 22:05

@hladas, how difficult would it be to make getPosWorldVisual from recently added getPosWorld (not on stable yet)?

- Issue History
Date Modified Username Field Change
2013-11-17 22:12 Nou New Issue
2013-11-17 22:12 Nou File Added: Test_Character_01.rar
2013-11-17 22:18 ProGamer Note Added: 0060347
2013-11-17 22:19 ProGamer Status new => reviewed
2013-11-17 22:23 Nou Note Added: 0060348
2013-11-18 01:13 Nou Note Added: 0060358
2013-11-18 01:33 Nou Note Added: 0060359
2013-11-18 01:58 Nou Note Added: 0060363
2013-11-18 02:10 Nou Note Added: 0060364
2013-11-18 04:41 Nou Note Added: 0060371
2013-11-18 09:30 SaBrE_UK Note Added: 0060387
2013-11-20 01:05 SaMatra Note Added: 0060566
2013-11-21 20:23 Nou Note Added: 0060758
2013-11-21 20:28 Nou Note Edited: 0060758 View Revisions
2013-12-05 16:39 SaBrE_UK Note Added: 0061582
2013-12-09 21:41 Fireball Relationship added related to 0016460
2014-03-27 11:05 Simon Assigned To => Simon
2014-03-27 11:05 Simon Status reviewed => assigned
2014-07-08 18:40 johnnygitarr Note Added: 0073986
2014-07-08 19:07 Bouben Note Added: 0073987
2014-08-07 22:27 hladas Note Added: 0075914
2014-08-07 22:27 hladas Note Edited: 0075914 View Revisions
2014-08-08 09:49 hladas Note Added: 0075944
2014-08-08 09:49 hladas Note Edited: 0075944 View Revisions
2014-08-08 09:53 SaMatra Note Added: 0075945
2014-08-08 10:12 Killzone_Kid Note Added: 0075947
2014-08-08 10:46 Simon Assigned To Simon => hladas
2014-08-08 11:43 Nou Note Added: 0075953
2014-08-18 21:12 Killzone_Kid Note Added: 0079129
2014-08-18 22:57 Killzone_Kid Note Added: 0079137
2014-08-19 08:26 hladas Note Added: 0079155
2014-08-19 10:52 Killzone_Kid Note Added: 0079165
2014-08-19 13:45 SaMatra Note Added: 0079180
2014-08-29 22:03 Killzone_Kid Note Added: 0079981
2014-08-29 22:05 Killzone_Kid Note Edited: 0079981 View Revisions

Copyright © 2000 - 2016 MantisBT Team