[Bf-committers] [Bf-gamedev] game engine scenegraph: design, review and questions

[brita]

Ortiz, i meant to thank you for the example you provided, and asked to see
Jacob's logic brick setup.

Clearing the response for clarity on what I still need feedback:

3) Parenting types
When I parent to a vertex, does it mean I am only parenting to the
position? As a user I am not choosing the specific vertex..
3 Vertices/Triangle  -  at the moment this is doing exactly the same as a
normal parent relation
Shouldn't vertex (and triangle) have the relative/offset/inverse option too?

4) Slowparents
I think it makes more sense to have an object parented to another according
to whether it makes sense or not for the object to be in the other's
transform space (following it's scale, orientation..). I think of this as a
'tight' connection, as if the child totally belongs to / is part off the
parent. If the child is instead meant to track another object, it should
not be it's child, it should follow it according to some function/logic.

Slow parenting is currently calculated in the scene graph as a slerp.
I think this would be better implemented with a 'constraint' controller,
allowing:
- a better user interface: the current one is quite hidden and not very
flexible
- more constraint types and tweaking
- more flexibility in the code as well by having this out of the scene
graph and instead on a step meant to update an object's location relative
to others.
- more accuracy - currently, the slerp is not using a time delta and may be
run several times per frame according to scene graph needs

What I am proposing here is 1) move slow parent out of the scene graph 2)
implement a new controller that reproduces this functionality and more
Does this make sense? Is it a good idea? Does it have enough priority?


5) what are those 'depsgraph hacks' checkboxes at object properties panel >
Relations Extras ?
>Ton added these as a way of telling to depsgraph to tag objects or their
object-data block to get calculated one more time. It's a quick hack aimed
at providing an optional way to fix a very limited number of pseudo-cyclic
scenarios. Does it work? Only in a very limited number of cases, but
hopefully enough to tide us over until the real problem gets solved...
-> Can you give me a concrete example? should I check if the GE scenegraph
is also respecting this checkboxes or it doesn't apply?


6) method consistency on SG_Spatial.cpp
There is a SetLocal and SetWorld for Position, Orientation and Scale. So
far so good.
Then there is a Relative Translate Rotate and Scale:
6.1) I don't really get the point of these functions and they're all
different, Can someone clarify?
6.2) Translate optionally considers the parent, the Rotate and Scale do not.
6.3) RelativeScale does not have a 'local' flag. Of course that applying a
scale in local or world coordinates would be the same, but scaling to a
value would not. Such as scale = 2 instead of scale * 2

The relative translate is used on the Object/Motion Actuator and the
Steering Actuator with local as false.
The relative location is used in the Object/Motion Actuator and the
MouseActuator
Both are hooked in the python API:
http://www.blender.org/documentation/blender_python_api_2_71_release/bge.types.KX_GameObject.html?highlight=applymovement#bge.types.KX_GameObject.applyMovement
According to the python API docs, 'not local' should be world space, not
parent space.
The relativeTranslate is using the parent if existing, also, the caller
ensures that the physics also applies the same transform using world space
and never the parent:

https://developer.blender.org/diffusion/B/browse/soc-2014-bge/source/gameengine/Ketsji/KX_GameObject.cpp$594

Should I change this? It can have an impact in previously made games using
the logic bricks or python.

The relative scaling is not used by logic bricks and does not have a python
hook. Is it only directly connected in places where I think it can be
removed.

---
Inês Almeida