Bug #26423

Units stuttering, maybe getPos command/s unreliable on both SP and MP

Added by neokika almost 4 years ago. Updated over 3 years ago.

Status:Closed Start date:11/17/2011
Priority:Normal Due date:02/01/2012
Assignee:Suma % Done:

0%

Category:Multiplayer
Target version:1.60.87580
Affected ArmA II version:1.60 BETA First affected build:Please Specify...
Reproduced by another DH user:Yes First affected ArmA II version:1.60 BETA
I am using some Mods:No Single / Multi Player?:
I am using: BIForumURL:
Reproducible for you:Yes NGUrl:
Related to content of DLC: WIKIurl:

Description

Units stuttering, maybe getPos command/s unreliable on both SP and MP.
This happens with all recent Betas, not true for 1.59.

Repro:
- Run attached mission in SP with latest Beta patch
- See the camera stuttering a lot when following the unit
- Switch to v1.59 and see the smooth camera following

camera_test.Desert_E.rar (1.1 kB) neokika, 11/17/2011 21:02

camFollowStutter.Chernarus.pbo - camFollow stutter experiments (6.6 kB) ruebe, 11/18/2011 16:41


Related issues

related to ARMA2 Community Issue Tracker - Bug #24940: Camera stuttering increased Duplicate 09/27/2011 11/10/2011
related to ARMA2 Community Issue Tracker - Bug #25110: Various issues with switchCamera Assigned 10/03/2011
related to ARMA2 Community Issue Tracker - Feature #26591: Add new command visiblePosition Closed 11/25/2011
related to ARMA2 Community Issue Tracker - Bug #26791: [86882] Camera stuttering in "attached" armory scene mode. Closed 12/03/2011 02/03/2012

History

Updated by kju almost 4 years ago

  • Due date set to 02/01/2012
  • Category set to Multiplayer
  • Assignee set to Dwarden
  • Reproducible for you changed from No to Yes
  • First affected ArmA II version changed from Please select... to 1.60 BETA

Updated by ruebe almost 4 years ago

Yeah, I can confirm this. My own camera script, which follows a unit (similar to the repro mission here, so without attachTo) started to stutter too at some point.

Could it be that now positions are out of sync at times? Such that the command `position` on a unit (used to relatively position the camera accordingly) returns non-interpolated values? With the result that the unit moves continuously/interpolated, but the camera can't because `position _unit` does return hard positional data which is not interpolated/smooth.... And therefor the stutter?

Updated by Dwarden almost 4 years ago

  • Status changed from New to Assigned
  • Assignee changed from Dwarden to Suma
  • Target version set to 1.60 BETA
  • Reproduced by another DH user changed from No to Yes

yep, regression

Updated by Suma almost 4 years ago

I am afraid this is a change which you will probably have to learn to live with. The simulated position of an object can no longer be considered to be exactly the position where the object is rendered, unless a camera is attached to it.

Is there some specific reason why attaching camera is not possible, and you need to use getPos?

Updated by neokika almost 4 years ago

Well, it is a bit unfortunate then, not the end of the world though.
Basically, my spectator script third-person cameras are calculated more or less the way you can see in the Repro-Mission attached. Making it using attachTo will be more difficult, because the camera will orbit the viewing unit by mouse input.

Thanks a lot,
neo

Updated by ruebe almost 4 years ago

Suma wrote:

I am afraid this is a change which you will probably have to learn to live with. The simulated position of an object can no longer be considered to be exactly the position where the object is rendered, unless a camera is attached to it.

Isn't it possible to either
  1. have a new get-position command, that returns the "rendered" or interpolated position of an object, or
  2. would it be possible to implement a toggle we could switch on for a unit we want to follow by camera, such that the simulated position for that unit equals the rendered/interpolated position? Only one unit could have that toggle active at a time - so only one object would send rendered/interpolated positions over the network, instead of the less frequent `simulated position` update? (does this make sense?)

Is there some specific reason why attaching camera is not possible, and you need to use getPos?

Yes there is. The camera is not stiffly following some unit (which looks/feels not that good). Instead the camera shall have it's own movement/momentum around the target, so we don't always look on the cam-target with the same angle/distance...

I really hope we may find a solution which still allows awesome `follow camera` scripts.

Updated by Suma almost 4 years ago

would it be possible to implement a toggle we could switch on for a unit we want to follow by camera,

Actually once you attach a camera to the object using switchCamera, you should get this behaviour even now. You should be able to switch to a scripted camera using cameraEffect and the object to which switchCamera was done should still keep that property. If this does not work, we might introduce this functionality using a similar interface, but first I would like you to check if existing comands are enough for the task.

Updated by neokika almost 4 years ago

Suma wrote:

would it be possible to implement a toggle we could switch on for a unit we want to follow by camera,

Actually once you attach a camera to the object using switchCamera, you should get this behaviour even now. You should be able to switch to a scripted camera using cameraEffect and the object to which switchCamera was done should still keep that property. If this does not work, we might introduce this functionality using a similar interface, but first I would like you to check if existing comands are enough for the task.

After a quick test seems when using switchCamera to a unit, the problem does not exist at all, but once you set the cameraEffect back to the custom camera it will be the same stuttering as before, even following that same unit.

neo

Updated by ruebe almost 4 years ago

Suma wrote:

Actually once you attach a camera to the object using switchCamera, you should get this behaviour even now. You should be able to switch to a scripted camera using cameraEffect and the object to which switchCamera was done should still keep that property.

I'm not sure I fully understand this. But please, have a look at the submitted `camFollowStutter.Chernarus.pbo`, where I've tried to follow your suggestions.

With radio 0-0-1 a cam-script starts like the reported one (no attachTo, but relatively positioned each tick) without further tricks, so that one stutters as reported. (hit any key to exit the cam-script)

With radio 0-0-2 I've tried to do what you suggest: first we introduce a "hack-camera" that gets attached to the unit/object to be followed. But here, I'm really not sure, what I was supposed to do. Did you suggest to use `_unitToBeFollowed switchCamera "INTERNAL";` to then cameraEffect to the scripted camera? Anyway, I've tried some variations without any success. The moment I "cameraEffect" to the manually positioned camera, it stutters as in 0-0-1. So I couldn't spot/make any difference. (again hit any key to exit and start the next experiment)

With radio 0-0-3 we don't watch the manually positioned camera anymore, but the attachedTo "hack"-camera. The thing is, that I don't attach it once and be done with it. Instead I (counter-intuitively!) (re-)attach the camera every tick as desired, to create an effect as in 0-0-1 with the manually positioned camera. With the result that it doesnt stutter anymore. Ha.

So maybe we indeed need to simply rewrite our camera-scripts, so that following-cameras are always attached to the object to be followed. And then we simply re-attachTo the camera every tick, althought that doesn't seem to be very intuitive (at least I associate attachTo with a fixed offset).

EDIT: ok, I think I understand your suggestion now, and no, this:

Actually once you attach a camera to the object using switchCamera, you should get this behaviour even now. You should be able to switch to a scripted camera using cameraEffect and the object to which switchCamera was done should still keep that property.

... does NOT work. That is, the object (or unit our scripted camera follows) does not keep that property you speak of. So:

// switchCamera to followed unit
_unit switchCamera "EXTERNAL";

// and then to the scripted camera
_cam cameraEffect ["INTERNAL", "BACK"];

does not change anything - _cam still stutters as without that switchCamera to the followed unit.

Updated by Suma almost 4 years ago

  • Status changed from Assigned to Resolved

The issue is fixed for 86697, but you need to change the camera script a bit. The script now contains:

_cam2 switchCamera "INTERNAL";

It needs to contain:

_unit switchCamera "INTERNAL";

With this change the unit will be simulated in each frame and can be tracked by the camera reliably.

And then we simply re-attachTo the camera every tick, althought that doesn't seem to be very intuitive (at least I associate attachTo with a fixed offset).

To me this sounds like a clean and compatible solution. Reattaching with a different position sounds OK to me (note that there were some issues with repeated attachto before 85747 - see #25272 - I am not sure if it might affect a camera, though).

Updated by ruebe almost 4 years ago

Suma wrote:

The issue is fixed for 86697, but you need to change the camera script a bit.

Great. I'm eager to try this out, once the next beta patch is released.

It needs to contain:
_unit switchCamera "INTERNAL";

Ok, that's what I've figured (and tried) in my last tests.

With this change the unit will be simulated in each frame and can be tracked by the camera reliably.

I just wonder if this shouldn't be handled in a more generic way. I mean, retrieving the correct (simulated or interpolated) position of a unit can be important in other contexts too, besides camera scripts.

So the behaviour for the upcoming version will be:
  1. position _unit := returns non-simulated/non-interpolated position that is off from the visible, actual position of _unit.
  2. _unit switchCamera "INTERNAL";
  3. After 2) position _unit now returns the correct/simulated position of _unit
  4. Let's have another unit: _unit2, position _unit2 at this point will return the non-simulated position.
  5. _unit2 switchCamera "INTERNAL";
  6. After 5) the returned position for _unit2 is now correct/simulated, but that of _unit is now the non-simulated/non-interpolated position again.

Is this correct? There can be only one unit that currently returns the correct/simulated position?

My point is: instead of that slightly obscure _unit switchCamera "INTERNAL"; toggle-hack, shouldn't there be a new getPosition command that returns the correct/simulated position? Wouldn't that make more sense and be more clear/easier to use?

The current solution could stay as is, but should be abstracted away, so that such a new getSimulatedPosition would keep track of the currently simulated unit and issue _unit switchCamera "INTERNAL"; (or whatever is needed to make this work) behind the scenes if needed, prior to returning the position.

Please correct me if I'm wrong, but in the end, this problem is not about camera scripts, but about the command position, which doesn't return the position we actually are interested in; the simulated one.

Updated by Suma almost 4 years ago

that is off from the visible, actual position of _unit.

retrieving the correct 

It is a bit more complicated. "Actual" or "correct" are dangerous words here, as "actual" for a simulation may be different from "actual" for rendering. However, I agree it is possible (and easy) to create new command "visiblePosition", which would return the interpolated position always matching to what you see on the screen.

about the command position, which doesn't return the position we actually are interested in; the simulated one.

I am afraid it is not this easy. The position does return the "simulated position", the trouble is for some objects what you see on screen is a bit behind. Interpolation complicates things here, but I am convinced the positives are significant enough to make it a worthy feature.

http://www.bistudio.com/index.php/english/company/developers-blog/230-experimental-betas-interpolating-the-future

Updated by neokika almost 4 years ago

Confirm fix, thanks for listening.
Also, if it's possible t create a new getPos command for this like you suggested, please, do not hesitate.

neo

Updated by kju almost 4 years ago

  • Status changed from Resolved to Closed

Thanks.

Please create a new feature ticket for a new SQF command: visiblePosition

Updated by kju over 3 years ago

  • Target version changed from 1.60 BETA to 1.60.87580

Also available in: Atom PDF