|
Sweet Home 3D Forum » List all forums » » Forum: 3D models and textures » » » Thread: Deformation problem - Bug or by design? » » » » Post: Re: Deformation problem - Bug or by design? |
Print at Dec 17, 2025, 8:45:49 AM |
| Posted by Keet at Feb 27, 2024, 3:25:48 PM |
|
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. 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!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. 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.---------------------------------------- Dodecagon.nl 1300+ 3D models, manuals, and projects |
|
|
Current timezone is GMT Dec 17, 2025, 8:45:49 AM |