Why do I need Tessellation in some objects to do a Decimate?
I'm working with Decimate to reduce the geometry of objects in IFC files, but some of these need to be tesselated before saving because otherwise I get the following error:
TypeError: 'NoneType' object is not subscriptable
I would like to know why I need Tessellation, to do it only on the objects that need it. Because now I do it on all objects and it takes too long.
Tagged:
Comments
Can you show some example how to reproduce this issue (a short video demo)?
Here you have an example. I have to do "Manually Save Representation" to save the geometry in the Ifc file.
This is a user response, not a developer one, but decimate and other native Blender modifiers act on mesh geometries. In an IFC, a mesh is registered as a tessellation. If your IFC comes from elsewhere and a geometry is, for example, a brep, you shouldn't be able to use Blender modifiers on it, unless you first convert it to a tessellation. Likewise, you shouldn't be able to enter Blender Edit mode unless it is a tessellation. I think so, but maybe someone will correct me.
But the problem is that objects that are not tessellated show the error, but in others it doesn't show. And I don't understand it because the geometry is the same. I think the decimation reduction removes some properties from the object, but that's a guess.
From the video, it looks like the geometry is a 'SweptSolid' not a tessellation.

Try, before you do anything, to
Convert to Tesselation
first.you might have to
manual save representation
after youConvert to Tesselation
.Thanks for the answer @theoryshaw, but some objects that are SweptSolid or use other geometry don't receive an error but in the video they do. So there has to be an other reason to convert to tessellation. Because if the answer is that they are not tessellation, all objects that are not tessellation would get the error.
Hello ! You seem to assume how the inner workings of bonsai works, but I can assure you that not all errors or bugs throw an explicit error to the user. An error can silently fail and still be an error. There are so many edge cases in the IFC schema that it's extremely hard and costly (in terms of man-hours) to cover them all. Besides the error seems to show that an element that should exist isn't initialized, it might as well have nothing to do with the geometric representation of the element, but a byproduct of trying to do an operation on something that should not be allowed. Bonsai is not yet in a state where everything that can be done by the user should be doable by the user. Cheers
Thanks @Gorgious, I going to try to do something other than tessellation (if there is one) to make it faster.