…maybe this is too easy to be true:
I define a prerender callback.
When my prerender callback gets executed, the first lline would be to remove all existing prerender callbacks except mine.
Geometry gets created.
Rendered.
Geometry gets removed.
How can you bypass that?
Davy
other than the fact that if you are setting up those callbacks using scripts, it’s trivial for the user to simply disable the callbacks?
or to set up their own callback for node created / deleted events and make copies at that point?
etc.
…well my callback which will delete any prerender callback, will also create the geometry inside the custom geometry plugin. No node will be created or deleted that can be catched by callbacks. And if my callback is removed, no geometry will be created at all.
So at this point I don’t think one can bypass it unless I am missing something else?
Davy
I think one could still get around it with relative ease, especially if set up from maxscript. If it’s a custom geometry plugin (non-scripted), I’d definitely just go with the viewport vs rendertime meshing (scripted geometry plugins have no access to that differentiation, as far as I know)… I think #preRenderFrame and such callbacks can get at the rendertime meshes, though (pretty sure I used that as an example in a thread here…somewhere)… and users of your plugin may not appreciate having their callbacks removed. Gets pretty iffy – and still isn’t 100%
…I wonder if an SDK plugin can bypass whatever a scripted plugin can’t at prerender time. Cause after all it’s all executed by the same.
You can catch any geometry at render time if you don’t remove all callbacks. SDK or not.
For sure all callbacks at render time have to be removed which have access to the render geometry to be sure it can’t be bypassed. And yes, that’s a choice to make, if you want these kind of objects, no prerender callback support.
Choice is to have render time generated objects with no prerender callback support or just have regular unprotected objects.
Davy