[Bf-committers] Re: [Bf-blender-cvs] CVS commit: blender/source/blender/python/api2_2x Object.c

Ton Roosendaal ton at blender.org
Sun Mar 5 10:52:42 CET 2006


Hi,

Yes, the DAG_object_flush_update() is for individual cases, and not to  
be used within a loop.

But even worse; Joilnen first sets the object 'recalc' tag to "Object  
changed", and then call the DAG to update as if the object's geometry  
changed (OB_RECALC_DATA).
That is not the case in this function (Object_setLocation).

Here's a short tutorial!

Setting this tag:

	object->recalc |= OB_RECALC_OB;

Will tell Blender - on a first redraw - to recalculate the object  
matrix. So in that sense the code was OK. However, if there are other  
objects depending on this object's location, they wouldn't become  
updated.

To flush all tags through the dependency graph, you can call

	DAG_scene_flush_update()

This will set recalc tags in all objects that should be recalculated.  
This calculating then still only happens on a first redraw. Currently  
only two types of recalculations are used, for object matrix (_OB) and  
its geometry (_DATA).
The call allows optionally to use the current visible layers in a  
screen, like this:

	DAG_scene_flush_update(G.scene, screen_view3d_layers());

screen_view3d_layers() will use the scene layers when no UI is running  
(background render).

This works fine for Blender C code, but for our Python API it's  
different. Ideally you should not bother the scripter with such  
details. But the current API is very lowlevel anyway, so I'd suggest to  
just add a Scene method like:

	scene.flushDependency(layer)

Which scripters should call if they want to get correct redraws on  
complex animation systems.

Much nicer would it be if we can devise a better way to pin down  
context for python scripts. A 3D UI level context description could  
have information like "current scene, current screen, current area,  
current object-base". The script execution engine can fill this context  
on start, and all C api calls can read it when needed, and set  
additional tags in the context for events that have to be handled like  
redraws and recalc flushes. That way you never have to call a redraw  
either.

This context system doesn't exist on C level either (well, very  
primitive with global variables). It is one of the things I want to  
look at for the event refactor project, related also to the 'unified  
tools api' we like to have. :)

-Ton-

(Joilnen; please note that a CVS log should have more information than  
just 'bug fix <number>'. Add a short description of the actual fix!)


On 4 Mar, 2006, at 23:36, Toni Alatalo wrote:

> On Friday 03 March 2006 19:45, Joilnen Leite wrote:
>>     blender/source/blender/python/api2_2x Object.c
>>   fix for bug 3903
>
> i dont know if this is correct. AFAIK that update is an expensive  
> call, and
> the idea is that operations (like parenting there?) that need a recalc  
> have
> that flagging which was already there.
>
> then it is unclear when to do the actual update. basically the whole  
> DAG
> should be hidden from users (including scripters), but it may not make  
> sense
> to have the update call there always in every method. like if a script
> changes the parenting of thousands of objects .. well that flush seems  
> to be
> tied to a certain object, so perhaps it is good.
>
> just wanted to bring this up so that a possible problem wont go  
> unnoticed. but
> hopefully that is already the good solution and i reacted in vain..
>
>  	/* since we have messed with object, we need to flag for DAG recalc  
> */
>  	self->object->recalc |= OB_RECALC_OB;
> +	DAG_object_flush_update(G.scene, self->object, OB_RECALC_DATA);
>
> ~Toni
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers
>
>
------------------------------------------------------------------------ 
--
Ton Roosendaal  Blender Foundation ton at blender.org  
http://www.blender.org



More information about the Bf-committers mailing list