Hello @nathanletwory,
Apologies for not replying earlier yesterday, I got to see the email with he notificacion but was unable to get a moment’s peace to answer properly.
First of all, yes, this does make an awful lot of sense; the changequeue having a stack of changes you can flush at will into the scene is perfect, and it would essentially erase the trouble with the naming I talked about in this post.
But I’d like to know, is there any mechanism to check wether the changequeue’s stack of changes is getting too big, so it is possible to periodically flush the changes, not only flush on demand? Also, the bogging might come from high quantities of geometry under certain circumstances, but I have the feeling that is unavoidable. Regardless I have already set up a mechanism for deferred geometry load which should alleviate the problem.
Aditionally, does this mean:
you essentially ignore the NotifyBeginChanges, NotifyEndChanges and NotifyDynamicChanges calls
that I should overload said calls to simply not act unless I want to (a lock flag as you specified to enable a call to the base function). Are the ApplyXChanges callbacks only raised when the Flush function is called? Is the Flush() called within the base’s NotifyEndChanges?
Thanks in advance,
Alonso.
On a side note, a friend of mine told me you are a developer for the Blender foundation. I wanted to say, thanks for making 3D accessible to everyone! I know of several cases close to me in which blender’s being used to make amazing projects with children at school, teaching them programming and other skills. Its becoming integral part of the education around here so… Keep being awesome!