Netherlands
Joined: Apr 8, 2022
Post Count: 790
Status:
Offline
Re: ROOF WINDOW / VELUX WINDOWS
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.
followin the quote I posted earlier:
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.
If I read that correctly the direction is "from the largest dimension of the global bounding box of the hinge parts".
I suspect what happens is when you combine two hinges into a single piece of furniture the bounding box changes in size because now two hinges set the bounding box. I suspect this because just last week I had this happening with two vertical cylinders on top of each other, each as a hinge for their own half circle turn table. Individually they worked fine but after combining and changing one hinge from 1 to 2 they turned wrong and I had to move the sweethome3d_hinge_ designator to the next g group of each cylinder to correct the deformation. The only reason I can guess at is that by combining the total height made for a different "largest dimension of the global bounding box of the hinge parts".
I still have to experiment with defining hinges using sweethome3d_hinge_1_top and sweethome3d_hinge_1_bottom because from the thread explaining the hinges that should also work and will probably set the direction fixed between the two points.
I think you're on the right track with using the o line. If the bounding box used for the direction calculation limits itself to the actual o part bounding box (for a single hinge) there's far less of a chance that the drirection changes.
Joined: May 18, 2021
Post Count: 219
Status:
Offline
Re: ROOF WINDOW / VELUX WINDOWS
Ugh. The exporter checks for "valid" chars in the group name, but ignores the whole string if there is a single invalid char. Instead you end up with a number (i++) as the group name. Of course this breaks lots of things if the naming is part of a hinge/rail that gets reimported.
It's a shame we only have the option to do this export/import malarky using the prehistoric obj format.
Netherlands
Joined: Apr 8, 2022
Post Count: 790
Status:
Offline
Re: ROOF WINDOW / VELUX WINDOWS
Ugh. The exporter checks for "valid" chars in the group name, but ignores the whole string if there is a single invalid char. Instead you end up with a number (i++) as the group name. Of course this breaks lots of things if the naming is part of a hinge/rail that gets reimported.
Nothing wrong with the exporter checking for valid chars, I wouldn't have programmed it any other way if I had to do it. It's essential that you can rely on exporting an object that is not corrupted by invalid naming.
It's a shame we only have the option to do this export/import malarky using the prehistoric obj format.
Prehistoric? Hardly. Just try to implement the hinges/rails in any other format and have them retained when exchanging the object between Sweethome3D and Blender. It's open source, very generic, widely supported, and in a plain text format which allows easy editing. For software like Sweethome3D it's an almost perfect format. The only thing is that only a relatively small set of the features is implemented in Sweethome3D through it's user interface and export/import. For example the d for transparency and Ni for optical density (glass refraction!) properties should be made available through the user interface just like shininess.
Joined: May 18, 2021
Post Count: 219
Status:
Offline
Re: ROOF WINDOW / VELUX WINDOWS
I'm cursed with only getting half the thought from my head to the screen.
I don't have a problem with character validity checking. It is the action that is the problem. Better to remove, or change the problem character to an OK one. Currently export drops the entire name.
Example: the "small window" model, a window (hinged), roller shutter (rail), and a roller shutter crank (hinged). The line:
g sweethome3d_opening_on_hinge_2_Roller_Shutter_Crank_Cylinde.000
fails because of the ".", and just becomes "15" or some such number. This breaks the hinging. It also makes it impossible to detect when hinge_2 was used, meaning you cannot watch for the hinge being redefined.
.obj was first created around 1990. As far as I'm aware there is no body or organisation managing the spec. There doesn't even seem to be a golden source for the spec. It seems it has acreted additional features over time that as far as I can tell are adopted ad-hoc. Many libraries and loaders of varying feature sets, speed, and quality. Then there are all the programs that roll their own code to load/save.
So yeah... I stick by prehistoric. There are people out there writing code for this spec where the coder is much fresher than the spec!
So actions speak louder than words: 1. Amend my export patch to stop nuking the entire name. 2. Amend my export patch to make the hierarchy renaming an option. 3. Write a simple script to make the hinges not clash when exporting/importing. 4. (Stretch-goal) Change my export patch into a plugin.
Romania
Joined: Apr 24, 2014
Post Count: 555
Status:
Offline
Re: ROOF WINDOW / VELUX WINDOWS
From my point of view, at this moment, the problem could have an applicable solution: Note: the velux windows have to remain separate selectable objects. 1. Create roofs from walls and add windows as described above. 2. Make invisible all windows materials (not the entire object). Will remain holes in walls. 3. Select all and export/import roof. 4. Insert again the windows as objects (not as DoorOrWindow) and make them feet in roof holes. 5. Optionally you could than group roof with windows.
I know it's not so simple and need a lot of work. Until we will have roofs objects which will act as actually walls (insert widows) we will have to wait.
---------------------------------------- A computer program does what you tell it to do, not what you want it to do. Murphy's Law (Greer's Third Law) When all else fails, read the instructions.Murphy's Law
Joined: May 18, 2021
Post Count: 219
Status:
Offline
Re: ROOF WINDOW / VELUX WINDOWS
Hmmm. OK, so basically the hinging and rails are broken for any object where the hinge/rail component is rotated away from one of the world axis'. It seems the objects rotational transformation is not taken into account when moving the opening_on parts. Sometimes you're lucky and the hinge/rail lines up with a world axis in your model. If not, you get weird movements. I can see this even without doing an import/export: Add the "Small window" with shutter and crankshaft. Rotate it in the plan to 45 degrees. Then try and move the crank. It will snap to one of the world axis and move diagonal to the window frame. If I export/import it, for adding to a loft roof, it is worse, because now all three movable parts are not world axis aligned, and they all behave wrong.
It is just a fluke that my method for constructing a loft roof with veluxes (once my script fixes the hinge/rail numbers) results in the velux hinges being world axis aligned, and they behave correctly.
