Setpos/Getpos bug finally solved

[chris330 0]

This might not be news to some of you but it's news to me. This may already have been documented but I'm not sure so here goes. I've been trying to find out how this worked for some years now and I finally got to the bottom of it. I would well imagine this will be of good use to someone in the future who comes searching through looking for help on this issue.

For those who have no idea what I'm talking about the problem arises when you want to set an object at a specific point in relation to another vehicle's frame. You'd think that the getpos command would return the [0,0,0] reference of the vehicle's frame. Well unfortunately it doesn't. It returns a totally different point indeed, and it makes accurate setting of an object relative to a vehicle's frame nigh on impossible when it starts to pitch.

It's a well known issue amongst veteran scripters and programmers. I'm not sure but I would imagine the guys who've made hitching scripts in the past with rope addons might have had this trouble.

Anyways what happens is the getpos command returns a value which has something to do with the vehicle's land contact points I think although I've yet to confirm this. It does not return a position that has anything to do with the origin point [0,0,0] in Oxygen as I've checked that with the BIS Cobra. If you took a vehicle and placed a logic unit at the getpos points using the following command:

_logic setpos getpos _vehicle;

it will be placed near the base of the vehicle in question. Now you'd think that if you ran the distance command using the following code:

_logic distance _vehicle;

it would return a value of zero. It doesn't. It returns a significant value normally a couple of meters or more. The same also happens if you use the drop command to drop a particle at the [0,0,0] position. Say you called a drop command on a vehicle to drop a particle at [0,0,0] on the vehicle and then returned to co-ordinates of the particle to a script, then compared those coordinates to those returned by the getpos command. You'd again get a value way above zero.

Infact if you use the drop method and place a logic at the drop's coordinates and then compare it to the returned getpos coordinates, you will get the same distance as you do when you perform the distance command run from the vehicle to the getpos coordinates.

In short, the reference point for a [0,0,0] particle drop and the distance command's starting point are at the same place on a vehicle's frame. The only thing I could possibly think of was that this was it's Centre Of Mass/Centre Of Gravity. I proved that it was using a simple box in O2 with some mass attached to it. I predicted what the distance between the object and getpos coordinates would be and the results matched the predictions perfectly.

So the COG point on a vehicle's frame is very different from the returned coordinates from the getpos command. I used the stock BIS models to check it and found that when on a level surface such as a runway or over water the distance between the COG point and the getpos point is constant regardless of the vehicle's pitch. The displacement also only ever occurs in the 'z' direction. It has a finite value which is different for each vehicle and doesn't change. Incidentally for the stock BIS AH1 Cobra the value is 1.94123 meters. You can see this in the demo mission provided below.

Download the file and place the two cylinder addons in your Res/Addons folder. They're needed to prove the point.

Demo Mission

So what's the point of all this? Basically it means you can now get a reference directly to the vehicle's COG which means you can reliably set other objects in relation to the vehicle's frame regardless of pitch by using some trigonometry.

You could actually do this anyway by using the drop command but the results are quite unstable and very unsmooth which you can see if you try it, because any objects you set with this method will start to warp when the target vehicle builds up speed. I think this is caused by lag due to the fact that the commands are not all kept in one place. You have to bounce back and forth between two scripts to get coordinates from the drop command.

Anyway this is an easier and much more reliable method too. It opens the gate to being able to script extra things stuck onto the side of existing vehicles. For example you could make an object with an animation phase which rotated it 360 degrees in the pitch direction. Then set it a desired point in relation to a target vehicle (the underneath or side of a helicopter for example), get the target vehicle's pitch, set the stuck on object to the correct animation phase to match the target vehicle's pitch, and then using this new data place it correctly in relation to the target vehicle's frame/COG. The stuck on object would appear to be perfectly fixed to the target vehicle.

That's just one use. I'm going to do some more work over the weekend on it. I once discovered that with a fast enough update time and some neat code geometrical interactions between objects' geometry LOD's are quite accurate. You can see this for yourself by placing a heli on the map and then scripting a custom made object with a simple geometry LOD to rise into its tail by small distance increments at a fast update time per execution cycle. The results are very believable. This could potentially mean that vehicles and such like could be held in mid-air by lots of tiny spheres or rods placed in relation to their frame so they were all just touching their geometry LOD. Basically it is potentially the birth of reasonably sophisticated setpitch function for OFP, something which has eluded us for years.

To be frank I wonder why I'm doing this because you can simply buy ArmA for less than 20 quid now and use the setvector command to do the same thing with much less hassle. I think it might still yield something interesting though which could possibly have ripples into even ArmA's engine as it shares much with OFP.

Anyway if nothing else it could at least be used to make hitching scripts look more realistic by having their rope addons stay at the right point on the lifting vehicle's frame as it pitches.

Apologies if this has been done before, but I hope it helps someone

[chris330 0]

Lol done a load of work on this, this weekend and there's no chance of using even this to create setpitch function in OFP. The collision resolution and interpenetration resolution is far too chunky. When I placed a cylinder with an identical geometry LOD to its 0.000 LOD beneath a Cobra and raised it slowly the heli did indeed respond but not gently. It responded with ever increasing magnitude due to over penetration into the cylinder as it was being raised. It began to bounce. Attempting to place other cylinders around the aircraft to stabilise it simply produced more magnified bouncing effects and some seriously unstable behaviour.

It appears the game engine is rendering the appearance and position of the vehicle frames far more frequently than it is resolving collisions and interpenetrations. This I believe includes things such as velocities and accelerations which makes matching geometrical changes to physics in a believable way nigh on impossible even by my own tediously detailed standards. It behaves a bit like the stiff spring problem common to all normal frame-rate simulations that you can realistically run on a home machine but much more exaggerated.

In simple terms vehicles are being given velocities and position changes much more often than collisions are being checked for. I suppose it's possible that Bohemia couldn't even have made OFP back in 2001 if they'd built in a very accurate and high resolution physics engine with high resolution collision detection and interpenetration resolution. Given the size of the maps each run of the game loads, and the amount of vehicles present on each map, it probably would have slowed down to a crawl even a very fast machine for the day.

I proved this to myself by watching the rear end of the cobra bounce up and down off the cylinder with gradually increasing magnitude and interpenetration. I suppose that's why when the game first came out we could run through walls and such things when playing infantry although Bohemia seemed to greatly improve that when they released the resistance patch.

Setpitch without hacking the engine code? Forget it. Even if, like me you still love playing around with old engines to boost your general coding understanding and physics skills (and to just generally see how far you can take something) you're still far better off expending your efforts on something more fruitful than this.

Now I can go and have a nice cup of tea and begin thinking of the next thing to have a look at

[chris330 0]

Incase anyone's interested this is the closest I could get to making this a reality. Rising increments have to be kept very low. Anything above 0.001 is very unstable. Here's a demo mission anyway

Lifting Demo Mission