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

Jacob Merrill blueprintrandom1 at gmail.com
Wed Jul 23 02:40:16 CEST 2014


forgot, A-D move left right *


On Tue, Jul 22, 2014 at 5:14 PM, Jacob Merrill <blueprintrandom1 at gmail.com>
wrote:

> here is my file (it's only handling 1 axis)
>
> http://www.pasteall.org/blend/30589
>
> it's a little tricky, but it gives the effect of slow parent,
>
>
> On Tue, Jul 22, 2014 at 4:00 PM, brita <britalmeida at gmail.com> wrote:
>
>> 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
>>
>> _______________________________________________
>> Bf-gamedev mailing list
>> Bf-gamedev at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-gamedev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-gamedev/attachments/20140722/7dad23b2/attachment-0001.htm 


More information about the Bf-gamedev mailing list