SWEET HOME 3D ROOF WINDOW SOFTWARE

As far as I'm aware there is no body or organisation managing the spec. It also makes it impossible to detect when hinge_2 was used, meaning you cannot watch for the hinge being redefined. G sweethome3d_opening_on_hinge_2_Roller_Shutter_Crank_Cylinde.000įails because of the '.', and just becomes '15' or some such number. Currently export drops the entire name.Įxample: the 'small window' model, a window (hinged), roller shutter (rail), and a roller shutter crank (hinged). Better to remove, or change the problem character to an OK one. I don't have a problem with character validity checking. I'm cursed with only getting half the thought from my head to the screen. 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. 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.

SWEET HOME 3D ROOF WINDOW SOFTWARE

For software like Sweethome3D it's an almost perfect format. It's open source, very generic, widely supported, and in a plain text format which allows easy editing. 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 a shame we only have the option to do this export/import malarky using the prehistoric obj format.Prehistoric? Hardly.

It's a shame we only have the option to do this export/import malarky using the prehistoric obj format. Of course this breaks lots of things if the naming is part of a hinge/rail that gets reimported. Instead you end up with a number (i++) as the group name. The exporter checks for 'valid' chars in the group name, but ignores the whole string if there is a single invalid char. 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. I think you're on the right track with using the o line.

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. 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'. 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. 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. 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. If I read that correctly the direction is ' 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. The axis direction of the hinge x is guessed from the largest dimension of the global bounding box of the hinge parts.

Sweet home 3d roof window