Is there anything that can be done to make undo of exploding meshes faster?
If I explode an 18.000 face mesh then that is done quickly, but undoing it takes a long time (minute +)
explode mesh undo.3dm (1.5 MB)
Hi Jorgen - so far I do not see this here - just opening the file in a new session of Rhino, Explode, wait a bit, Undo, wait is about the same… maybe a second or two longer.
-Pascal
Maybe the mesh was big enough it was pushed off the Undo memory allocation?
Just tried here on another machine, same issue. I don’t think 18.000 faces should be considered that huge though. I’ll try to disable plugins.
Do you have any third party plugins installed? There’s always the possibility that a plugin event watcher is being a bit over zealous.
Yup, disabling LandsDesign and Tibidabo from Asuin did the trick.
@fraguada can you take a look at this?
When installed it takes a few minutes to undo the explosion of the mesh.
The mesh is not created with those plugins so I don’t see why it causes issues, but disabling helps. (unfortunately I need them for IFC import and export and some plant based things)
Hi @Holo,
This is not normal. Tibidabo and Lands shouldn’t do anything when a mesh is undo.
Can you please send me the document to enric@asuni.com so I can look at the issue?
Thanks,
Enric
I tested with the file linked at the top of the tread, can you try with that?
Hi @Holo,
I’ve found the problem: when you explode the mesh, Rhino is creating a material for each exploded face, so the command is creating more than 18.000 new materials in the document. When you undo the explode command, all those materials are marked as deleted. Then, there is an event watcher in Tibidabo that is doing a completely useless check when a material is deleted. I’ve fixed this issue, which will be included in the next versions of Lands 5.8 and VisualARQ 2.13.
FYI, before the fix, 96% of the time of this undo command was spent on our event watcher. Now, the event watcher only consumes less than 2%.
Thanks,
Enric
2 Likes
Excellent! Great work.
Regarding materials:
I discovered that you have an issue with the IFC exporter when dealing with terrain objects too, where all the bases are exported regardless of the objects that are selected for export OR if they have the base toggled on. So I made a mesh extractor for the top meshes of those terrains (rendermesh of each terrain is a list of objects) but then I needed to assign materials to those meshes since they all turn out WHITE.
(IFC doesn’t support textures and all Lands Materials are white with a texture map)
And if I recall correctly the Lands materials are only RenderMaterials and not RhinoMaterials, so they don’t show up in the materials panel, so we can’t set the base color there.
And each terrain gets it’s own material too, so this has to be done for each and every object… which is a pain to trouble shoot when on a deadline.
Hi @Holo,
I have already reported this error with the Ifc exporter so that it is fixed. I will keep you updated about it.
1 Like
Hi @Holo , we have just released a new version of VisualARQ (2.13) which fixes an error you reported here about a slow performance when undoing an explode of a big mesh.
You can check here the news of this new version: VisualARQ 2 - Version 2.13 released
1 Like