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

brita britalmeida at gmail.com
Sat Jul 19 12:53:29 CEST 2014

> I have just uploaded a blend (with 2.71) to pasteall (
> http://www.pasteall.org/blend/30499) showing the slow parenting in action
> in the bge.
> Press P and use the left/right/up/down arrows.

> thanks, it is definitely not completely broken :)
The difference for my is the relax constraint, you used 80, I used 10. With
10 it is noticeable on the viewport when I drag the parent, but not on the
game engine, thus appearing that is is not working.

@Joshua thanks for the careful reply!

> 3) types of parenting:
>   - normal, vertex, slow and bone are implemented in the GE. I see that
> there are more options in the interface. Is there any that looks important
> to support?
> I also don't know what is this one (in the conversion):
No. Those are the *only* ones that should exist now (* see Q4).

Specifically, for normal Blender, there should really only be:
1) Normal (i.e. standard object parenting - Ctrl-P stuff)
    a. With offset/inverse     *- should be supported*
    b. Without offset/inverse *- should be supported*
2) Vertex Parenting
    a. Single Vertex            *- should be supported*
    b. 3 Vertices (gives rotation + scale info too)  *-  at the moment this
is doing exactly the same as a normal parent relation*
    (c. 4 Vertices/Parent to Quad - Isn't in Blender yet, but I have a
hackish patch for this which partially works)
*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..*
*Shouldn't vertex (and triangle) have the relative/offset/inverse option
3) Bone Parenting *- should be supported*
All the other options you see in the UI are just convenience options which
do Normal Parent + some additional setup stuff (like adding Modifiers +

> 4) Slow parents are specific to the GE?
> They seem to be quite buggy or at least not doing what
> I would expect. What I am doing is 1) parent one object to another 2) go
> the child's object properties panel > Relations Extras > and check slow
> parent, add some time offset.
> If I now do some experiments directly in the viewport.. drag/rotate the
> parent, it seems to be working. There are problems: if I cancel the move,
> the child does not cancel. If I parent more objects to the parent, the
> child jumps..  Where do I need to look at to fix this? (The GE is not
> running yet)
These are entirely expected, and exactly the reason why they are not
supported for standard Blender. (It's also why I have rejected patches for
"spring constraints" and similar physics-based things which assume that
time must be monotonically increasing in fixed size increments).
So it just stays like this? Maybe the child shouldn't move at all in the
Spring based constraints etc.. sound as useful as the slow parent. Maybe
the way this should be done is as a kind of physics/logic setup, and not
directly in the scene graph.. So the position would be calculated in the
logic step, and not in the scene graph that has no time information :P
It is currently just slerping the thing everytime the update is run, which
can be several times per frame because of dependencies.

> 5) @lukas 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) Still waiting for an answer, I will meanwhile check better how it is
being used at the moment. The usage is also not very consistent..

> 7) The SG_ParentRelation interface has an isVertexRelation() and a
> isSlowRelation() . This doesn't feel like a good design, because the
> interface shouldn't know about concrete implementations.
> Indeed. It sounds a bit suspicious. If going for a full-blown OO approach,
you'd have to wonder whether there is actually some kind of handling which
should be delegated off to avoid the need for clients needing such tests.
However, in practical terms, if these are only used in one or two places,
it may be ok for the time being...
Leaving it be :)


More information about the Bf-committers mailing list