[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