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

[Joshua Leung]

Hi,

While I'm not all that familiar with the GameEngine side of things, at
least the Blender side of things I can answer. See replies below:



On Sat, Jul 19, 2014 at 12:57 PM, brita <britalmeida at gmail.com> wrote:

>
> 2) is doing that wiki page a waste of time? I felt it was useful for me to
> understand quite some concepts, but I would spend less time just leaving it
> scribbled in paper for myself.
>
> This is a good idea, and is something I'd recommend other GSoC
students/beginner devs doing.



> 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):
>
>
> https://developer.blender.org/diffusion/B/browse/soc-2014-bge/source/gameengine/Converter/BL_BlenderDataConversion.cpp$2256
>
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
    b. Without offset/inverse
2) Vertex Parenting
    a. Single Vertex
    b. 3 Vertices (gives rotation + scale info too)
    (c. 4 Vertices/Parent to Quad - Isn't in Blender yet, but I have a
hackish patch for this which partially works)
3) Bone Parenting

All the other options you see in the UI are just convenience options which
do Normal Parent + some additional setup stuff (like adding Modifiers +
VGroups)



>
> 4) Slow parents are specific to the GE?
>
They are GE specific. The way they are defined means that they can only be
useful for a realtime environment where time is guaranteed to be
monotonically increasing, and where there is a definite initial "reference
frame" that everything gets reset to.



> Is this really used?

AFAIK, some people like using it for camera-lag setups and other funky
cheapshot stuff like that.



> 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 to
> 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).



> When I do run the GE, it does not work. It looks like a normal parent
> relation. (I added an always motion to the parent, and pressed 'p')
>
> That sounds like a GE bug. If this is the case, that means the feature is
completely broken?



> 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...


>
> 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...