Joined: May 18, 2021
Post Count: 219
Status:
Offline
Re: ROOF WINDOW / VELUX WINDOWS
Hmmm. A feature request for the obj exporter would be to track hinges (or rails) and make sure they are unique within the export. i.e. if a hinge_1 already exists in a previous object, and the next object in the export also contains a hinge_1, then rename this next object to use hinge_n, where n is the next unused number. This would avoid the need to manually edit the files.
Netherlands
Joined: Apr 8, 2022
Post Count: 789
Status:
Offline
Re: ROOF WINDOW / VELUX WINDOWS
Hmmm. A feature request for the obj exporter would be to track hinges (or rails) and make sure they are unique within the export. i.e. if a hinge_1 already exists in a previous object, and the next object in the export also contains a hinge_1, then rename this next object to use hinge_n, where n is the next unused number. This would avoid the need to manually edit the files.
Mmmm, and what if you want them to act as one hinge? The current way works just fine, you just have to be carefull when combining multiple hinges. What I do is just create a copy and edit it for the 'next' hinge and then combine them. This way you can easily keep track of the different hinges. Particularly handy when creating a dresser with 6 drawers I just create a drawer, add the rail for deformation, and export the drawer including the rail. Import the first drawer to test. You can do that because the rail is included. If it's ok, copy the obj and mtl files and edit it for the next drawer. This is easy because you have just a single drawer to handle. When all are finished 'insert' them at the correct position into the base of your furniture and export the whole thing. You can't test the other drawers by themself because they don't have the first rail so wait until you have tem all together and they should work fine.
Joined: May 18, 2021
Post Count: 219
Status:
Offline
Re: ROOF WINDOW / VELUX WINDOWS
Respectfully, I think that sounds like more of a corner case use than mine
I'm stumped why you would want to slide out all the drawers at once in say a 6 drawer unit. I'd also guess this only works if the rails are all oriented in the same direction too. To each their own, I suppose.
Netherlands
Joined: Apr 8, 2022
Post Count: 789
Status:
Offline
Re: ROOF WINDOW / VELUX WINDOWS
Respectfully, I think that sounds like more of a corner case use than mine
I'm stumped why you would want to slide out all the drawers at once in say a 6 drawer unit. I'd also guess this only works if the rails are all oriented in the same direction too. To each their own, I suppose.
A little misunderstanding: I don't want all drawers to open with the same movement. The dresser I created has all drawers open individually. I tried to explain how to go about combining different parts with each their own deformation into a single piece of furniture by editing their source before you combine. As you have found out combining identical objects can result in strange deformation movements when the angle changes. You would want to keep control over that yourself. Once you understand how it works it's pretty easy.
Joined: May 18, 2021
Post Count: 219
Status:
Offline
Re: ROOF WINDOW / VELUX WINDOWS
Oh I understood how to edit and fix the issue. It's the previous message I seem to have misunderstood.
And that's the thing. I don't get strange deformation when there is just a single hinge object in the export/import. I don't get strange deformation when following your explanation either. So for me it is far simpler all round to have the application take care of ensuring multiple objects with hinges do not use the same hinge number. The most trivial way is to use a generator to spit out an incrementing number every time a hinge/rail is encountered in the export process, and use that unique number for that rail/hinge.
I raised the problem as #1147, although I um'd and er'd over whether it was a bug or an enhancement.
Netherlands
Joined: Apr 8, 2022
Post Count: 789
Status:
Offline
Re: ROOF WINDOW / VELUX WINDOWS
Oh I understood how to edit and fix the issue. It's the previous message I seem to have misunderstood.
And that's the thing. I don't get strange deformation when there is just a single hinge object in the export/import. I don't get strange deformation when following your explanation either. So for me it is far simpler all round to have the application take care of ensuring multiple objects with hinges do not use the same hinge number. The most trivial way is to use a generator to spit out an incrementing number every time a hinge/rail is encountered in the export process, and use that unique number for that rail/hinge.
I raised the problem as #1147, although I um'd and er'd over whether it was a bug or an enhancement.
I explained how I created 6 separate drawers before integrating them in a dresser base because that makes handling a single deformation easy. Your proposal to automatically renumber deformations would make that impossible because, no matter what rail number I assign to a drawer, with integration they would be renumbered, most likely NOT in the order I want them to be. So at most it would have to be optional. The order and number is particularly important when you have chained deformations. Besides that it requires very complex code to keep the correct parts to the correct hinge with renumbering. It's not only the hinges themselves, it's also important that the parts that deform to a specific hinge stay connected to that hinge.
The issue you raised is more about the change of a deformation itself. In your velux window example the angle of the window probably changes the direction of the hinge. From this blog post:
The axis direction of the hinge x is guessed from the largest dimension of the global bounding box of the hinge parts. Thus, if the largest dimension of a hinge is its height, the axis will be vertical, if its largest dimension is its depth the axis will be horizontal in Y direction and if its largest dimension is its width the axis will be also horizontal but in X direction.
Changing the angle of the window most likely changed what the largest dimension was and thus changed the deformation direction. Exporting, importing as non-window, change angle, exporting, and importing as window could have caused that.
Joined: May 18, 2021
Post Count: 219
Status:
Offline
Re: ROOF WINDOW / VELUX WINDOWS
Yeah, I'm understanding how the hinging gets messed up now.
I can see a way to write a post process script that would fixup the hinges and rails, but there's a problem with delineating the objects in the exported file. For whatever reason SH3D does not export with "o" lines. It only uses "g" lines for the groups. So there is no way to tell one window object from another in the export. The objects are at least added in a serial fashion, so there is no intermixing of the objects' groups. Then there can also be multiple mesh groups with hinge_1 for example in a single object so it makes it tricky (but not impossible) to write a script.
I think the logic would be something like: if hinge_1 has been used in an opening_on_hinge_1 and a new hinge_1 line is encountered, then this is a different hinge. (The multiple hinge_1 lines in a single object have so far always, all preceeded the opening_on_hinge_1 lines in my tests of the doors and windows.
Ideally SH3D would add "o" to exports, and split into separate objects on imports where "o" is used. This would immediately fix the export/import workflow for these kinds of workarounds.
In the absence of this, I might bash something together out of python (my poison of choice). This would also keep it a semi-manual, optional task. At the end of the day, I'm just scratching my own itch.
Netherlands
Joined: Apr 8, 2022
Post Count: 789
Status:
Offline
Re: ROOF WINDOW / VELUX WINDOWS
There's a wish in another thread to add the o line to object exports. Since this doesn't interfere with the g groups I assume that we will see that in one of the coming new versions. Currently I add the o lines manually if I need to bisect an object in Blender because that's a requirement to being able to bisect. Bisecting is one of the few things I can't do in SweetHome3D and I'm hoping that with the introduction of o lines this will become available in the future.
What would make it perfect is if exports used the name you gave it in the plan for the o line (and not something like 'box'). HINT HINT, that's a big and important wish! That would make it much easier to distinguish between multiple objects in furniture. That would also make it a lot easier to create an auto number script if you wanted to. It still doesn't solve the changing directions but at least you can programmatically locate the parts that belong to a specific hinge without having to rely on the order of g lines.
I also wrote a working patch attached to the feature request, that also included adding a "separator" character in the "o" line. And I wrote a patch for the blender legacy python obj importer so that objects with the seperator were grouped into collections in blender by elevation, levels and groups. Walls, ceilings and floors were grouped in their own blender collections too. Finally, groups were assigned to the blender objects as vertex groups.
I didn't touch the SH3D import code though - I'm not a Java dev, so just doing the exporter was hard enough.
Joined: May 18, 2021
Post Count: 219
Status:
Offline
Re: ROOF WINDOW / VELUX WINDOWS
It still doesn't solve the changing directions but at least you can programmatically locate the parts that belong to a specific hinge without having to rely on the order of g lines.
If both export and import paid attention to the o line, I think the hinges would not change direction, as I don't believe mechanisms in one object can affect the mechanism in another. It is just the loss of objects and "crushing" of the objects down to a single one in the export/import that cause the misbehaviour.
