BGE KX_GameObject new 'worldDimensions' and 'localDimensions' properties accessible from Python API #42017

New Issue

Razvan Cosmin Radulescu · 2014-09-29T22:47:33+02:00

2014-09-29 22:47:33 +02:00

The Python API misses a "dimensions" property on KX_GameObject. This patch addresses this issue. I don't know if it's the best implementation, but it works.

There are two new functions now:
KX_GameObject:NodeGetWorldDimensions and
KX_GameObject:NodeGetLocalDimensions used to create the new Python accessible variables:

worldDimensions (the dimensions of the object on x, y, z relative to the world axis)
localDimensions (the dimensions of the object on x, y, z relative to the local axis)

Both new attributes are of type MT_Vector3.

I could not find a simple way to add this to SG_Spatial so instead I'm just calculating the dimensions on the fly in KX_GameObject.KX_GameObject.patch

The Python API misses a "dimensions" property on KX_GameObject. This patch addresses this issue. I don't know if it's the best implementation, but it works. There are two new functions now: KX_GameObject:NodeGetWorldDimensions and KX_GameObject:NodeGetLocalDimensions used to create the new Python accessible variables: * worldDimensions (the dimensions of the object on x, y, z relative to the world axis) * localDimensions (the dimensions of the object on x, y, z relative to the local axis) Both new attributes are of type MT_Vector3. I could not find a simple way to add this to SG_Spatial so instead I'm just calculating the dimensions on the fly in KX_GameObject.[KX_GameObject.patch](https://archive.blender.org/developer/F113655/KX_GameObject.patch)

Razvan Cosmin Radulescu commented

2014-09-29 22:47:33 +02:00

Changed status to: 'Open'

Razvan Cosmin Radulescu commented

2014-09-29 22:47:33 +02:00

Added subscriber: @razvanc87

Sergey Sharybin commented

2014-09-30 11:52:35 +02:00

Added subscribers: @Moguri, @brita, @Sergey

Razvan Cosmin Radulescu commented

2014-09-30 13:16:08 +02:00

KX_GameObject.patch

Just a quick update: dummy_dimensions are changed to positive values now.

[KX_GameObject.patch](https://archive.blender.org/developer/F113756/KX_GameObject.patch) Just a quick update: `dummy_dimensions` are changed to positive values now.

solarlune commented

2014-10-22 20:00:15 +02:00

Added subscriber: @solarlune

Jorge Bernal was assigned by Sergey Sharybin

2015-02-26 10:54:20 +01:00

Sergey Sharybin commented

2015-02-26 10:55:05 +01:00

Added subscriber: @dr.sybren

Sybren A. Stüvel commented

2015-02-26 22:33:04 +01:00

If I read the code correctly, KX_GameObject::NodeGetWorldDimensions() results in a transformation of the world bounding box to local coordinates, only to convert it back to world coordinates. Seems like a waste.

If I read the code correctly, `KX_GameObject::NodeGetWorldDimensions()` results in a transformation of the world bounding box to local coordinates, only to convert it back to world coordinates. Seems like a waste.

Razvan Cosmin Radulescu commented

2015-02-26 22:42:25 +01:00

I don't disagree. It's my first try at changing / looking at the Blender code so if anyone has a better idea, please do implement it. Also I need to point out that this won't work for font objects which is a shame. So again, if anyone else knows how to do it or if it's possible then you're more than welcome.

Inês Almeida commented

2015-02-28 16:03:41 +01:00

What is the motivation for this? Why would this be useful?
You are returning the dimensions of the bounding box, which is axis aligned and may not correspond to the actual dimensions.
It could be better to store the object's dimensions from Blender during the DataConversion step and try to make sure it doesn't change.

What is the motivation for this? Why would this be useful? You are returning the dimensions of the bounding box, which is axis aligned and may not correspond to the actual dimensions. It could be better to store the object's dimensions from Blender during the DataConversion step and try to make sure it doesn't change.

Sybren A. Stüvel commented

2015-02-28 16:08:13 +01:00

@brita storing the bounding box during conversion only works when the object doesn't deform. I'm also curious for the motivation.

Inês Almeida commented

2015-02-28 19:08:45 +01:00

@dr.sybren I meant storing the dimensions during conversion, because blender does take into account the object space, instead of a bb.
Then for what could change that in runtime... scaling an object? or if it is a softbody or cases that don't even come up to mind easily. So I foresee an easily broken property, without further motivation I'd say not to add.

@dr.sybren I meant storing the dimensions during conversion, because blender does take into account the object space, instead of a bb. Then for what could change that in runtime... scaling an object? or if it is a softbody or cases that don't even come up to mind easily. So I foresee an easily broken property, without further motivation I'd say not to add.

Razvan Cosmin Radulescu commented

2015-02-28 20:12:00 +01:00

So, for the motivation, I decided to make a dimension property available in BGE because I was programatically creating a tiled map with hexagons and to place the hexagons well obviously I needed to get have the dimensions. It seemed rather weird not to be able to get such a basic property from BGE. The workaround at the time for me was to create the hexagon at the proper dimensions and then apply the scaling and use the scale in BGE instead.

And for the rest... the way I did it I was pretty sure wasn't the correct way to do it, but I had to try anyway.

So, for the motivation, I decided to make a dimension property available in BGE because I was programatically creating a tiled map with hexagons and to place the hexagons well obviously I needed to get have the dimensions. It seemed rather weird not to be able to get such a basic property from BGE. The workaround at the time for me was to create the hexagon at the proper dimensions and then apply the scaling and use the scale in BGE instead. And for the rest... the way I did it I was pretty sure wasn't the correct way to do it, but I had to try anyway.

Sybren A. Stüvel commented

2015-03-01 10:37:14 +01:00

@brita I was thinking about human characters. When you walk, your bounding box keeps changing in size all the time.

@razvanc87 your "workaround" would actually be my first approach ;-)

@brita I was thinking about human characters. When you walk, your bounding box keeps changing in size all the time. @razvanc87 your "workaround" would actually be my first approach ;-)

Razvan Cosmin Radulescu commented

2015-03-01 11:05:34 +01:00

@dr.sybren but that only mean that the programmer needs to be careful and aware of this and update the dimensions every frame he makes calculations based on it, no?

Inês Almeida commented

2015-03-01 17:16:09 +01:00

@razvanc87 I would also programatically do a grid and place scaled objects there. So all good..
as to have to update the dimensions every frame, are your hexagons changing? It is totally scenario dependent.

@dr.sybren anything rotating about would be changing the dimensions of the GE AABB all the time, and I can not foretell if that is what you want or not, or in what coordinate set.

I'd say that to handle this on top of bge instead of inside is best.

@razvanc87 I would also programatically do a grid and place scaled objects there. So all good.. as to have to update the dimensions every frame, are your hexagons changing? It is totally scenario dependent. @dr.sybren anything rotating about would be changing the dimensions of the GE AABB all the time, and I can not foretell if that is what you want or not, or in what coordinate set. I'd say that to handle this on top of bge instead of inside is best.

Razvan Cosmin Radulescu commented

2015-03-01 17:24:37 +01:00

@brita I was just making a point to @dr.sybren's statement about the bounding box changes shapes. I didn't need this for my specific scenario

Jorge Bernal removed their assignment 2015-03-09 07:43:58 +01:00

Jorge Bernal commented

2015-03-09 07:43:58 +01:00

Added subscriber: @JorgeBernalMartinez