|
Sweet Home 3D Forum » List all forums » » Forum: Features use and tips » » » Thread: Optimizing objects for display in the htmlviewer? » » » » Post: Optimizing objects for display in the htmlviewer? |
Print at Dec 18, 2025, 2:47:05 PM |
| Posted by Keet at Feb 29, 2024, 11:08:08 AM |
|
Optimizing objects for display in the htmlviewer? I fully understand the construction of an object. I also understand the OBJ and MTL file formats and the meaning of the different lines. What I don't know is how an object is processed for display. What I'm trying to do is to optimize all my custom furniture to achieve the most optimal format for use in the htmlviewer and maybe as a side benefit for the 3Dview and photo rendering too. I want to display huge projects with the htmlviewer but when a project gets too big it doesn't work very well because it's way too slow or stops working when you try to move it. In another thread Emmanuel mentioned this: By the way, I see that your model contains 74 lines starting by "g" followed by different names. That example object was a prototype and not the end result but fortunately it did point to a problem so Emmanuel could mention it.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. In short: the object is not constructed for optimal speed in display. Look at the different possible formats for a box: Format 1 Just a regular box export where all sides are given the same material name. All groups use the same material but still have their original group name. g bottom_1Format 2 The same box but with all group names changed to 'g box_...'. (6 groups all starting with "g box_") Format 3 The result when you run it through Blender to merge the groups into a single group (object). I think this is what Emmanuel pointed out to be more efficient. o boxFormat 4 Export the Blender result from Sweet Home 3D and 'o box' changes to 'g box_1' and Sweet Home 3D adds vn lines. Import/export with Blender removes those vn lines again. It's obvious that format 1 is the least optimized because it requires processing different group names. But is there a difference between the other three formats? Between formats 3 and 4: Does the presence of the vn lines influence the processing efficiency in the htmlviewer? Remember, I want to optimize for the htmlviewer. If I assemble a kitchen with multiple cabinets where every door uses the same material: Is it beneficial to export the whole kitchen and merge all doors into a single group? (like in formats 3 and 4.) Even the smallest win in speed can be significant in the end result: A theater has many rows of the same seat. If merging all those seats results in faster processing I would gladly do that just for that project. I already optimize objects by removing faces that you can't see anyway. For example with two boxes side-by-side you can't see the two sides where they touch so I remove them. In the same way I often remove faces at the bottom and/or the back that you can't see when placed on a floor or against a wall. It looks strange as a single object but you can't see any difference when placed in a project. That can be a lot of faces that don't have to be rendered when you think about all the theater seats with or without a bottom. I already try to use identical objects where possible. That enhancement option for large projects was mentioned in another thread but every one still has to be displayed so I don't know if that makes much difference. I also found that merging into single groups with Blender (formats 3 and 4) makes adding deformations like 'opening_on_' much easier. A wire basket constructed with dozens of cylinders can have over a hunderd g groups with top, bottom, cylinder. And each one of those needs an opening_on_rail_1_. Or you can have a single group 'g sweethome3d_opening_on_rail_1_wirebasket_1'. Much, much easier. There is a disadvantage though to merging multiple groups into a single one: no separate groups to assign a different material in Sweet Home 3D. You will have to go back to Blender to select faces to split of as a new group and assign a new material. It all boils down to two important questions: What is the most optimal format for 3D display in the htmlviewer? Is there anything else I can do to increase the performance for large projects? This made me think of a very usefull tool that could be added to Sweet Home 3D: An separate installable SH3Dviewer that only has a 3Dview with zoom/pan/tilt/rotate controls. No way to edit the project, just a viewer. When a project is too large for htmlview, a download can be provided for such a 3Dviewer with the possible added benefit of light and deformation features. In fact, what the htmlviewer is but as an installable Java viewer application. ---------------------------------------- Dodecagon.nl 1300+ 3D models, manuals, and projects |
|
|
Current timezone is GMT Dec 18, 2025, 2:47:05 PM |