Real time position of the center of a moveable object

[snatcher]

Dear all,

How can I tell via script the absolute (world) coordinates of the center of an object in real time, in this case, of a crate? My math does not compute

 

 

[Dragofer]

You could getMins() and getMaxs() to get the minimum and maximum coordinates of the model bounds, then add half the difference to the minimum coordinates to get the center of the bounds.

Alternatively, if you know the offset between the entity origin and the center of its model bounds when it isn't rotated you can rotate that offset by the current getAngles and add it to the entity origin.

vector center = getOrigin() + sys.VecRotate( offset, getAngles() );

If you're working with bound objects you can use getWorldOrigin() instead of getOrigin(), as the latter just gets the offset relative to the bind master.

[snatcher]

Thank you very much, Dragofer.

Unless the offset can be calculated on the fly I assume an offset arg won't always be available since it must apply to any moveable object, not only crates.

Can you elaborate a little more getMins() and getMaxs() ? I cannot find any example in any of the missions.

The crate in the example gives the following values:

getWorldOrigin() = -316.74 -1193.98 24.09
getOrigin() = -316.74 -1193.98 24.09
getSize() = 27.79 27.54 27.79
getMins() = -13.89 -13.73 -13.89
getMaxs() = 13.89 13.81 13.89

[Dragofer]

Bounds are like a cube that completely encases the model. The cube is always aligned with the x, y and z axis, so if you rotate the model the cube will grow or shrink to make sure the model is still exactly contained inside the cube.

You can get the coordinates of the bottom left and top right corners of this cube with getMins() and getMaxs(). Exactly halfway between them is the center of the model.

[snatcher]

Thanks for the help.

Makes sense and this should do:

vector center = (object.getMaxs() + object.getMins()) * 0.5;

But, how do I correctly position this point in the world? "center" coords are relative and the crate can be in any position and its origin can be anywhere in the model.

(head about to explode)

[Dragofer]

Yeah, I believe theyre relative to the entity origin and can therefore just be added to the entity origin.

object.getOrigin() + center

Mins and maxs are almost identical here because you're working with a crate whose origin is in the center of the model anyway, but with something else you might get i.e. mins = -5 0 -5 and maxs = 10 30 10 relative to origin, with center = 2.5 15 2.5

[snatcher]

Yes, perhaps one of those rectangular moveable packages were a better test sample to start with.

Anyway, Dragofer: it works beautifully (but).

To confirm that it works I am flying around a map and placing flames at the center of any object I can frob and while all the moveables I tested get the flame at their core I found a problem with doors.

Depending on how a doors is setup we get to the core or somewhere else nearby. I guess we have to, in addition, take into account either one of these or both:

1. The initial spawn rotation ("rotation" arg, it seems)
2. The current rotation the door (GetFractionalPosition(), perhaps)

Regarding the first point ("rotation" spawn arg) how do I go from matrix "-1 0 0 0 -1 0 0 0 1" to something more meaningful?

(Perhaps you can think of a more elegant way for doors)

[snatcher]

To test all this here is what I am using:

tdm_playertools.script

Add inventoryUse() to playertools_compass:

object playertools_compass : player_tools {

[...]

    void inventoryUse(player userEntity, entity frobbedEntity, float buttonState);

[...]

};

And then anywhere in the script add:

void playertools_compass::inventoryUse(player userEntity, entity frobbedEntity, float buttonState)
{
	vector center = frobbedEntity.getWorldOrigin() + ((frobbedEntity.getMaxs() + frobbedEntity.getMins()) * 0.5);

	entity testCenter = sys.spawn("light_candleflame");
	testCenter.setOrigin(center);
}

Bring the compass up and "use it" on any frobable.

Edited December 16, 2022 by snatcher

[Dragofer]

Doors might sometimes work differently in some ways because they can be created from scratch from brushes in DarkRadiant instead of using real models. Nevertheless, I believe getMins() and getMaxs() still work as expected.

For getting the orientation of a model, getAngles() is all you need, but it probably won't work for "models" created in DarkRadiant. The "rotation" spawnarg only sets the initial orientation anyway, and I'm not aware of a way to convert it to angles.

Have you noticed any patterns for where the "center" gets placed relative to a door? Does the center move when the door moves?

[snatcher]

23 minutes ago, Dragofer said:

Doors might sometimes work differently in some ways because they can be created from scratch from brushes in DarkRadiant instead of using real models. Nevertheless, I believe getMins() and getMaxs() still work as expected.

For getting the orientation of a model, getAngles() is all you need, but it probably won't work for "models" created in DarkRadiant. [...]

Sure, I expect some oddities here and there but I assume (perhaps I am wrong) the vast majority of doors follow a simple set of rules.

21 minutes ago, Dragofer said:

Have you noticed any patterns for where the "center" gets placed relative to a door?

If we consider all doors as static at mission start, the current solution doesn't work in all doors. Grab yourself my "compass flame trick" and take a trip to the first floor in the Canonbury Tabern in the "A New Job" mission.

21 minutes ago, Dragofer said:

Does the center move when the door moves?

That would be the next (and second to final) step. I will gladly brief you about what all this is about but privately and tomorrow, if you don't mind.

Thanks for your support with this. Success shall bring interesting stuff.

[datiswous]

38 minutes ago, snatcher said:

I will gladly brief you about what all this is about but privately and tomorrow, if you don't mind.

What?? You are not going to share this with the whole community?

Edited December 16, 2022 by datiswous

[snatcher]

Sorry, fellow. I need to first confirm *it* can be done to a decent standard. In the meantime, this topic "as is" could be useful to others. Thanks for your patience.

[Dragofer]

14 hours ago, snatcher said:

That would be the next (and second to final) step. I will gladly brief you about what all this is about but privately and tomorrow, if you don't mind.

I meant more this: if you use the compass when the door is opened and when it's closed, do the flames spawn in different positions? That would suggest that getMins() and getMaxs() still work correctly on moving doors.

[snatcher]

2 hours ago, Dragofer said:

[...] if you use the compass when the door is opened and when it's closed, do the flames spawn in different positions? [...]

No, same pos. What does that tell you?

Meanwhile I figured something out that will allow my next project to be realized in some form or another. I will raise a new topic so that we can discuss it openly. Regardless, it would be good if we can find out in this topic how to detect the x,y,z center of a door.

[Dragofer]

This works, including for doors made from brushes in DR:

vector center_offset	= 0.5 * (object.getMins() + object.getMaxs());
vector center		= object.getOrigin() + sys.VecRotate( center_offset, object.getAngles() );

Turns out that getMins() and getMaxs() don't take current orientation into account, they only state the bounds when the entity is in its default orientation. Therefore you need to rotate the offset by the object's current orientation.

[snatcher]

99% perfection Dragofer!

Let's however use getWorldOrigin() instead of getOrigin() in case the frobbed object is bind to something:

vector center_offset = 0.5 * (object.getMins() + object.getMaxs());
vector center = object.getWorldOrigin() + sys.VecRotate( center_offset, object.getAngles() );

Many thanks for the help. Your solution is the absolute winner and we shall soon put it to good use.