Netherlands
Joined: Apr 8, 2022
Post Count: 790
Status:
Offline
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. 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.
That example object was a prototype and not the end result but fortunately it did point to a problem so Emmanuel could mention it. 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_1 usemtl Box v -45.7 0.0 -45.7 v 45.7 0.0 -45.7 v 45.7 0.0 45.7 v -45.7 0.0 45.7 vt 0.0 0.0 0 vt 1.0 0.0 0 vt 1.0 1.0 0 vt 0.0 1.0 0 vn 0.0 -1.0 0.0 f 1/1/1 2/2/1 3/3/1 f 1/1/1 3/3/1 4/4/1 g top_2 usemtl Box v -45.7 91.4 -45.7 v -45.7 91.4 45.7 v 45.7 91.4 45.7 v 45.7 91.4 -45.7 vn 0.0 1.0 0.0 f 5/4/2 6/1/2 7/2/2 f 5/4/2 7/2/2 8/3/2 g left_3 usemtl Box vn -1.0 0.0 0.0 f 1/1/3 4/2/3 6/3/3 f 1/1/3 6/3/3 5/4/3 g right_4 usemtl Box vn 1.0 0.0 0.0 f 2/2/4 8/3/4 7/4/4 f 2/2/4 7/4/4 3/1/4 g back_5 usemtl Box vn 0.0 0.0 -1.0 f 1/2/5 5/3/5 8/4/5 f 1/2/5 8/4/5 2/1/5 g front_6 usemtl Box vn 0.0 0.0 1.0 f 3/2/6 7/3/6 6/4/6 f 3/2/6 6/4/6 4/1/6
Format 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 box v -45.700001 0.000002 -45.700001 v 45.700001 0.000002 -45.700001 v 45.700001 -0.000002 45.700001 v -45.700001 -0.000002 45.700001 v -45.700001 91.400002 -45.699997 v -45.700001 91.400002 45.700005 v 45.700001 91.400002 45.700005 v 45.700001 91.400002 -45.699997 vt 0.000000 0.000000 vt 1.000000 0.000000 vt 1.000000 1.000000 vt 0.000000 1.000000 usemtl Box s off f 1/1 2/2 3/3 f 1/1 3/3 4/4 f 5/4 6/1 7/2 f 5/4 7/2 8/3 f 1/1 4/2 6/3 f 1/1 6/3 5/4 f 2/2 8/3 7/4 f 2/2 7/4 3/1 f 1/2 5/3 8/4 f 1/2 8/4 2/1 f 3/2 7/3 6/4 f 3/2 6/4 4/1
Format 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.
Romania
Joined: Apr 24, 2014
Post Count: 555
Status:
Offline
Re: Optimizing objects for display in the htmlviewer?
In the past I've used some online object simplify until it (the sites) has disappear. I've needed to make the sh3d files less weight and more responsive. There is already a tool HugeFileCleaner but not a tool to reduce the obj files size. I think by reducing (optimizing) every object will make the project to be more easy to display on a html viewer. As a separate application could be write even in C++ and made it cross platform and free. In my view, this tool could have integrated an mechanism to identify all objects and their size (a table) along with the suggestion of which could be reduced without loos too much. The user could have the option to optimize or not some of them (check). After optimization the resulted file need to remain usable by SH3D. One option could be to improve the Huge File Cleaner. Anyway I'm on your side.
---------------------------------------- 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
Netherlands
Joined: Apr 8, 2022
Post Count: 790
Status:
Offline
Re: Optimizing objects for display in the htmlviewer?
I did try the HugeFileCLeaner but for all projects it said that the files are correct. It really is a tool to fix things that are wrong in a .sh3d file. Since all my furniture is correct it does nothing. I'm already trying all I can to optimize objects but I want to know which format is the best for the fasted rendering in the htmlviewer. By-the-way, it's also slow in Sweet Home 3D itself but at least it works. I assume that if I can get it to work in the htmlviewer it will also be much faster in Sweeet Home 3D.
I really want to stay in Sweet Home 3D as much as possible but I'm investigating other options too. For example conversion to glTF or even using a different viewer like view3Dscene. I'm slowly beginning to realize that the obj format is by itself not the best format for 3D display on a web page. There's a reason formats like glTF are developed for the web.
Romania
Joined: Apr 24, 2014
Post Count: 555
Status:
Offline
Re: Optimizing objects for display in the htmlviewer?
You could also try and improve ExportToHTML5-1.7.sh3p or make a dedicated plugin to convert and export as glTF if that help.
---------------------------------------- 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
France
Joined: Nov 7, 2005
Post Count: 9182
Status:
Offline
Re: Optimizing objects for display in the htmlviewer?
Optimizing 3D models can be done on various parameters: - its file size - its file reading process - its data in memory - its display process
Optimizing the file size may consist of reducing the file size used by the 3D model on the hard drive where it's saved, the bandwidth used to download it to the browser and the size it occupies in the cache of the browser.
Optimizing the file reading process may consist of reducing the time required to read a 3D model file to transform it to the internal data required to display it. It includes unzipping the 3D model, reading and converting the decimal numbers it contains to binary data, transforming the polygons it may contain to triangles, and generating normals if the 3D model doesn't specify them.
Optimizing data in memory may consist of reducing the texture coordinates data required to map textures on the model. When texture coordinates are not provided in the 3D model size, they will be computed automatically at the moment a 3D model with textures is displayed (and this may look not as perfect as if you specify these coordinates yourself). Vertices and normals (read or generated) always exist in memory and the numbers they handle always occupy the same space, whatever the number of decimals they have.
Optimizing display process may consist of reducing the time required to display 3D models at screen. The more shapes are handled, the more time it will take to display them. For example, a monochrome model based on one shape of 1000 triangles will occupy a similar space in memory as the same model based on 100 shapes of 10 triangles, but the first one will be displayed faster, moreover if it's half transparent.
Some of these optimizations are bound to each other: When normals are quite straight forward to compute, a good way to reduce the size of a 3D model file is to remove them. The file will be smaller to download, it will contain less decimal numbers to decode but the processor will have to generate normals (not a complicated process which consists of computing cross products). Using more polygons (for example for the base and the top of a cylinder) will reduce the size of a 3D model file too but will oblige Sweet Home 3D to transform them to triangles.
In the examples you gave, formats 1 and 2 are handled at the same speed. The format 3 is smaller and is displayed as fast as formats 1 and 2 in Sweet Home 3D JS / HTMLViewer, because all the shapes of a 3D model are actually grouped by material, except the ones which name starts by "sweethome3d_". Format 4 will be displayed also at the same speed, because line shapes starting by "o" are handled the same way as the line shapes starting by "g", and missing normals are generated in memory when the 3D model is read (otherwise objects would look flat). Lines starting by "vn" don't influence the display processing efficiency. Note that in Blender, there's an option to generate normals or not.
If 3D models at the 4 formats are displayed as fast (except if they contain moving parts), how can you optimize the display of a large project? The key is to reduce the number of shapes to display. For example, let's say you have 10 rows of 20 seats in a theater, and each seat has 2 materials. If you use one 3D model seat, the 3D view will display 10 x 20 x 2 = 400 shapes. If you use a 3D model consisting of a row of 20 seats, the 3D view will have to display only 10 x 2 = 20 shapes and this will run faster (but probably not 20 times faster because the graphics card will have to handle more triangles for each shape). So it's up to you to find the best tradeoff, because in that case, the viewer will use 20 times more memory to handle the coordinates of a whole row of seats. But depending on the file format you use, the 3D model file won't be necessarily 20 times bigger: in OBJ format, it’s not mandatory to repeat normals and texture coordinates when they are equal ("vn" and "vt" lines), and in DAE format, it’s possible to avoid repeating the data for each seat because that format is able to describe a model made of x times the same shape (if the software which exports to DAE format is programmed to handle this kind of assembly).
Note that HugeFileCLeaner won't optimize anything on 3D models size. It's an utility which removes entries in a SH3D file which were useless before version 5.2. If you want to reduce OBJ file size, you can use another utility I just published at https://www.sweethome3d.com/downloads/OBJFileSizeOptimizer-1.0.jar (source code included). I programmed it to optimize OBJ files by removing trailing decimals and equal normals / texture coordinates. I use it to reduce the size of the 3D models that I add to the free models page. As it overwrites the optimized OBJ file, be sure to make some backups first.
----------------------------------------
Emmanuel Puybaret, Sweet Home 3D developer
Netherlands
Joined: Apr 8, 2022
Post Count: 790
Status:
Offline
Re: Optimizing objects for display in the htmlviewer?
Thank you for that very elaborate and helpful answer!
I'm most definitely going to try the FileSizeOptimizer. I would prefer that to using Blender if possible.
I'll experiment with the seats/rows in blocks to see what works best. Probably the whole thing as a single object because they are not that big. For other furniture I will have to try for each one what works best but since I already try to create objects as small as possible they will not use that much memory. It adds up though in a whole project.
I'll report here if all efforts resulted in a workable html5view.
