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-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers