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

Jacob Merrill blueprintrandom1 at gmail.com
Sat Jul 19 17:46:40 CEST 2014


I have game logic that does the same thing as slow parent but is more
predictable, however it's like 6 logic bricks.

I can provide an example, it's called Mr.pew pew
On Jul 19, 2014 3:53 AM, "brita" <britalmeida at gmail.com> wrote:

> >
> >
> > 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):
> >
>
> 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     *- 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
> too?*
> 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 +
> VGroups)
>
> > 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
> 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).
> So it just stays like this? Maybe the child shouldn't move at all in the
> viewport..?
> 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 :)
>
> thanks!
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>


More information about the Bf-committers mailing list