Previously speaking with @nathanletwory, he stated that the MeshInstance’s InstanceId was obtained through a CRC of several data of the instance, returning an unique Uint that identifies it. Is it possible to precalculate this value from the RhinoDoc itself, this meaning, before raising a changequeue?
I suppose in theory it is possible, but since that is an implementation detail that can change without warning. So it is better to not attempt that, since it can break suddenly.
What is the usecase where you need to be able to predetermine this id before using the changequeue?
It would be that the same parallel scene data used with export purpouses and “on save” is used for the visualization in real time. This arises while wanting to identify the instances unambiguously getting the data from a rhinodoc or a changequeue.
I guess I am also being a bit dense here, so you’ll have to hold my hand in understanding your needs
If you already use the ChangeQueue (for whatever reason), couldn’t you just use that data as well for your export so that you have the same data in both cases? Are you somehow also wanting to save the geometry and render content data to a fileformat, while also feeding it directly to a rendering solution? Or is there object data that you need besides the mesh geometry, materials, lights and view?
You are not being dense at all, @nathanletwory, seeing that your questions are quite on point. My explaination was maybe too sparse.
In the case of the changequeue, I was somewhat worried about having it continuously activated, as I percieved it as a suboptimal solution; unless the viewport rendering solution was active, in which case, in order to have the desired behaviour it was unavoidable.
What I mean is that it is not compulsory to use it continuously, but it seems that it might be a solution to several problems I encountered (creation/deletion of materials and the previous univocous identification of names)
To this:
Are you somehow also wanting to save the geometry and render content data to a fileformat, while also feeding it directly to a rendering solution?
That is true, i want to be able to do that, but i think I could do this regardless of the changequeue being active or not thanks to the parallel scene structure.
Thus, maybe the way to go is to initiate a ChangeQueue with the plugin as a unique instance (singleton), and register every change of the scene continuously to my secondary structure? Will it impact the performance significantly? It is probable that, as they say, “the trees didnt allow me to see the forest”.
Also, answering this:
Or is there object data that you need besides the mesh geometry, materials, lights and view?
You can have a ChangeQueue continuously running without instantly reacting to changes posted to the queue. Yes, you do get notified there are new changes, but you don’t have to flush the queue right away. You could just choose to ignore for a while those pending changes, and then call the flush when you feel you are in the mood to handle these changes. Take for instance the lock icon in the HUD of Raytraced. When a user presses the icon to “lock” the scene what happens is that the queue still gets all notifications as generated by the underlying system. A user can modify the scene however is wanted, the Raytraced viewport keeps on rendering the state of the scene as it was when the lock got engaged. When the user opens the lock you’ll see that the end result of all those changes are handled and Raytraced continues rendering that new state.
This is what you can do with your plug-in as well. You start the changequeue, do the very first flush as well so you get the initial seed. Then you let the changequeue just run, but don’t flush the changequeue - you essentially ignore the NotifyBeginChanges, NotifyEndChanges and NotifyDynamicChanges calls. When your plug-in is in the mood it can then opt to flush the changequeue, and get all the data changes as needed. This obviously includes environments as well - all mesh geometry, lights, and other render content (materials, textures, environments). And you’ll still have all the IDs consistently as generated by the changequeue.
It shouldn’t matter that these changes are buffered in your running changequeue - unless you expect huge amounts of data that could bog down your machine.
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!
There is no such mechanism. Changes to the same objects are folded into one, i.e. moving an object three times between flushes will act as one move, changing a material color several times will fold into only one material change between flushes, and so on.
The changequeue might get big if you manipulate many huge objects, but that is essentially the case for the initial CreateWorld() as well anyway.
The Notify* calls are there to tell you there are changes, what you do is up to you. Calling base-class doesn’t change anything.
Yes
No
I have been active since 2003 indeed. In the Blender community I use the IRC and forum handle jesterKing, just like I do in my Discourse name If you check my profile you’ll see that I work on the Cycles integration into Rhino as Raytraced. This integration is also one of the reason the ChangeQueue has sprung into existance.