Netherlands
Joined: Apr 8, 2022
Post Count: 790
Status:
Offline
Deformation problem - Bug or by design?
I'm creating a lock&handles for a toilet door. The lock has a turn handle that can be turned to change open(white) to closed(red). Nothing special and there's no problem with this deformation in itself.
I want the complete model to be prepared for adding to any door that has a hinge_1 for opening. To achieve this I used hinge_2 for the lock so the door itself can keep its hinge_1 for opening. I added the prefix "sweethome3d_opening_on_hinge_1_" to the non-turning parts (i.e. the parts that don't turn on hinge_2 but should open when the door is opened on hinge_1).
Notice that I added "sweethome3d_opening_on_hinge_1_" for some parts while there is no "sweethome3d_hinge_1_" defined. This is no problem for importing the model.
However, to make the model completely prepared "sweethome3d_hinge_2_" must be expanded to "sweethome3d_hinge_2_and_sweethome3d_opening_on_hinge_1_". After adding "_and_sweethome3d_opening_on_hinge_1_" you can't import the model anymore. The furniture importer waits indefinitely on 'something' and doesn't import the model.
Combine the model without the "_and_" part with a door, export, add the "_and_" part, and import. Now the door functions completely as it should: the door opens with the complete lock and handles and I can turn the lock from white to red.
Adding the "_and_..." parts should not have been a problem to import the model since there is no requirement that the sourcing hinge is present in the model: several parts are defined to open on hinge_1 while there is no hinge_1. It is only when used as an extension on another hinge ("_and_") that import no longer functions. The resulting problem is that I can not use the model as a hardware piece that can be added to any door without the user having to add the missing string on every door.
The model prototype. The first g group in the object file has a preceding comment line with what it should be.
Netherlands
Joined: Apr 8, 2022
Post Count: 790
Status:
Offline
Re: Deformation problem - Bug or by design?
Any info on this? It only seems to be a problem when the '_and_' part is added but I can't think of any logical reason why this can't be imported.
@Emmanuel: Is it a technical impossibility or does the current programming perform a check that doesn't allow import? And if it is a programming check can this be changed to allow import even if the deformation for the object will not work?
Allowing import of an incomplete deformation will make it possible to create objects that have a hinge_2_ that can be added to doors that already have a hinge_1. Export/import of the combined objects will then result in a fully functioning door with chained deformations without having to manually edit the object file to add the '_and_' part. In other words: It will make it possible to create fully prepared building blocks for furniture creation.
France
Joined: Nov 7, 2005
Post Count: 9182
Status:
Offline
Re: Deformation problem - Bug or by design?
Sorry for the late answer.
If I follow your idea correctly, you want to create some moving subparts of a door that you'll assemble with Export to OBJ feature. Risky but interesting and certainly not a scenario I imagined when I programmed deformation support! In the model you posted, there's no shape name prefixed by sweethome3d_hinge_1, the reason why the program hangs. But you're right, it shouldn't hang and I'll make some changes to ignore deformations which don't exist when the 3D model is read.
By the way, I see that your model contains 74 lines starting by "g" followed by different names. You should know that each of this lines creates a different shape in Sweet Home 3D to manage its vertices, and too many shapes can end up to slow down the program. This could be optimized by creating one shape per material rather that one shape per different "g" line, and this is actually the case in JavaScript version (but not in Java version). But shape names are important to manage deformations in which case such an optimization can't be performed without risks, like in your 3D model. Conclusion: you should try to merge some shapes when possible, or the 3D handling of your home design might become very slow.
I also noticed that the handle shapes in your 3D model are not smooth (the normals of its faces doesn't make it round). But maybe it's on purpose...
----------------------------------------
Emmanuel Puybaret, Sweet Home 3D developer
Netherlands
Joined: Apr 8, 2022
Post Count: 790
Status:
Offline
Re: Deformation problem - Bug or by design?
Thank you for the clear answer and the intention to fix the import.
If I follow your idea correctly, you want to create some moving sub parts of a door that you'll assemble with Export to OBJ feature. Risky but interesting and certainly not a scenario I imagined when I programmed deformation support!
The sub part doesn't have to move on itself, only when merged with other parts. For example the toilet lock that turns the red/white disk. The lock is a sub part that doesn't work by itself but is meant to be added to a door. Ergo, the lock is created with hinge_2 and the whole lock should move on hinge_1 which is supposedly the door it is attached to. This is just an example. I create a lot of parts as separate objects before merging them into the final assembled object. The failed import made that difficult because it required adding a string afterwards that currently causes the import to fail. To make my intended use clear: I created a series of locks and handles that I can use on different doors/windows I create. The same for other parts that are reusable for furniture creation. After the fix I can add them to my parts library and just drag them like any other object into the 2Dview for use on other objects without having to edit deformation strings. The most important thing is I can distribute the models for other users as ready-to-fit.
In the model you posted, there's no shape name prefixed by sweethome3d_hinge_1, the reason why the program hangs. But you're right, it shouldn't hang and I'll make some changes to ignore deformations which don't exist when the 3D model is read.
Correct, hinge_1 is supposed to be provided by the door on which the lock (or other similar handles/locks) can be attached.
By the way, I see that your model contains 74 lines starting by "g" followed by different names. You should know that each of this lines creates a different shape in Sweet Home 3D to manage its vertices, and too many shapes can end up to slow down the program. This could be optimized by creating one shape per material rather that one shape per different "g" line, and this is actually the case in JavaScript version (but not in Java version). But shape names are important to manage deformations in which case such an optimization can't be performed without risks, like in your 3D model. Conclusion: you should try to merge some shapes when possible, or the 3D handling of your home design might become very slow.
Yes and that's exactly what I am currently doing with all my models although I have to resort to Blender: set the o line (object) for the object, import in blender without groups checked, and export. This results in an object with all groups merged by material. While in Blender I even remove and/or merge faces to reduce the face count. Every face I can remove doesn't need rendering. Makes it faster and so far I managed to reduce the size of most models back to one half/one third of it's previous size. That's a lot better than I expected when I started doing this! Export again in Sweet Home 3D and the object file has only one group per material. I started doing this to simply reduce the huge number of groups that made it very difficult to add deformations. Lots of scrolling and very easy to miss a group.
I also noticed that the handle shapes in your 3D model are not smooth (the normals of its faces doesn't make it round). But maybe it's on purpose...
That is intentional, my trademark Dodecagon shapes. Since I already import the models in Blender to merge groups it would be just as easy to smooth the material, but as said, it's intentional.
