[Bf-committers] script links: new "OnRender" event

Willian Padovani Germano wgermano at ig.com.br
Thu Apr 28 18:48:22 CEST 2005


also from "Meeting Minutes April 25th 2005":

>*IanWill will investigate adding an 'ONRENDER' scriptlink (ie for
>generating geometry during render for things like hair), also to be
>discussed on mailing list
>  
>
There are a few new script link types coders have been requesting.  
Ton's idea for space event handlers takes care of passing mouse buttons 
and key presses to script links.  "OnSelect" for objects might still be 
needed, but we can wait to see.

For now, I propose adding "OnRender" for currently available containers: 
objects, scenes, materials, etc.  Complementing what Tom wrote in the 
minutes with more examples, this is useful to: control LOD, link objects 
to alternate obdata or generate expensive geometry only needed during 
render: hair, grass, etc.; for speeding up rendering in particular 
situations: back face culling, scene simplification, etc. and so on.

And to revert what "OnRender" scripts did, we either:

1) also add an "AfterRender" (name suggestions welcome) script link 
event, to be executed right after rendering or

2) we tell script writers to handle both "before and after" cases in 
their "OnRender" scripts:
if event == "OnRender":
 # prepare for render
else: #if event == "AfterRender"
  # clean up

and so the same script would be called twice, before and after rendering.

(2) is better imo, but we need to make sure it's well documented.

That's it.  Ok to add "OnRender"? What about "AfterRender"? Ideas?

Note: "FrameChanged" can be used to do what "OnRender" is wanted for, 
but it's cleaner for script code and for the interface to have an 
specific event for rendering.

>*Ton will email his comments on the implementation of BPY_interface.c
>  
>
Ton mentioned having it in source/blender/python/ doesn't follow usual 
Blender practice.  When Michel decided to rewrite bpython, he considered 
the (real) possibility that at least one new API could come up later -- 
specially if the 2.25 one couldn't be recoded / maintained, so instead 
of following the usual Blender dir structure he added "api2_2x/" instead 
of "intern/" and left BPY_interface.c on the top Python dir so any new 
API could also access it.

If desired, since bpython is integrated and probably no other API will 
emerge soon, we can move things around and make python/ look like other 
dirs, with .c files only inside api2_2x/ (and rename it to "intern/").

-- 
Willian



More information about the Bf-committers mailing list