#261 Compact tree at < 6KB

[OK Hoff]

I need trees. But refuse to put 500KB+ extra into my lean models. Here is one at the other end of the scale, weighing in at 5,6 KB compressed, for the puritans amongst us.

ok

PS: It looks to me as if sh3d only keeps one set of obj/mtl/png files for multiple model instances in the file. So you could add a little forest of trees copied, scaled and rotated to different sizes without playing havoc with the file size.
PPS: I will propose a full set of compact models/textures in a bit, including something like this.

[Emmanuel Puybaret]

Nice idea, even if it's really at the other end. :-)
For a given 3D model used many times during a session, Sweet Home 3D doesn't copy its geometry, but copies its color to let the user change them if necessary.
Feel free to propose more models of this kind. If you want to generate the trunk and branches, maybe Arbaro will help you.

[OK Hoff]

Thanks, here's an autumnal tree, that looks better and still doesn't eat up more than 9 KB. Just need to fix it up for summer too - and look at Arbaro.
ok

[OK Hoff]

Another - slightly corrected version of the simple tree (should not have wrongly oriented normals).

[OK Hoff]

And - on a related topic - sun passage through seasons, visualized.

[OK Hoff]

Another take on simple tree. Ref forum thread - trunk and branches by arbaro - very simple foilage wraparound. While arbaro generates leaves too, that makes for large models. Point is to replace foilage with a simple .png. Not as pretty, but much, much lighter on SH3D. Possible to replace with nicer tree for rendering. Zipped size 16,2 KB (foilage only 2,2 KB).

[OK Hoff]

With the help of arbaro and blender, trimmed down tree versions

1) quaking aspen starting with Wolfram Diestel's xml. Like Puybarets version, only simplified a lot more and converted to a birch. At 1071kB uncompressed, less than a third of the size of the original quaking aspen. Of course, not as rich in detal (like my garden birch).
2) a generic tree at < 300 kB uncompressed.

A lot fewer surfaces so these models can work better with SH3D on slower computers.

ok

[Emmanuel Puybaret]

Thanks for posting this new tree. You could make it even twice smaller by removing some useless g lines and letting Sweet Home 3D computing normals. See attached file.

[OK Hoff]

Thanks, Interesting, I will try that. I had already tried to regroup to avoid the repeated g lines manually (it is a re-export from SH3D after adjusting colors etc). But my off-the-cuff script (or rather my lack of understanding .obj elements) must have messed up, because the file became illegible. Did you edit the file with Blender?

If I understand correctly, the number of surfaces will be the same, so in terms of rendering and 3D view performance, the reduced file size will not improve SH3D speed? Still - shrinking the model size in half is still worth the effort, and I suppose SH3D calculating the normals will not impair performance noticably?

Thanks again. Most useful. It may seem like a detail, but getting a half-decent tree that does not slow down the work, will be a huge help - and thread xxx
seems to suggest I might not be the only one.

ok

[OK Hoff]

Not very successful at shrinking, but as the result is so nice... Made another tree, generic, more oak-like, with even fewer surfaces, which lands me with this compromise for different plants as suggested in forum thread 8110.

Made an example in a .sh3d file with different experiments, but the main point is the tree simplified by Puybaret (and possibly the generic one). Anyone wants to improve further on this, please post ...

[Emmanuel Puybaret]

Simplifying isn't very difficult once you understood the specifications of v vt vn and f lines in OBJ files:
v specifies the 3 coordinates of a vertex
vt specifies 2 textures coordinates
vn specifies the 3 coordinates of a normal
f defines a face with 3 or more vertices cited by groups of indices separated by slashes.

The vertices cited in f lines can have 4 different formats:
1 simple value cites the index (starting from 1) of a v vertex (like in f 2 3 4 6 which defines a quad joining the 2nd, 3rd, 4th and the 6th vectices cited in v lines)
2 values separated by a slash (xv/yvt) cites the indices of a v vertex and of vt coordinates
2 values separated by two slashes (xv//zvn) cites the indices of a v vertex and of a vn normal
3 values separated by slashes (xv/yvt/zvn) cites the indices of a v vertex, of vt coordinates and of a vn normal.

So for example, the line:
f 1/5/10 2/6/10 3/1/2
defines a triangle joining the first, second and third vertices among the v lines. The first vertex will use the 5th textures coordinates among vt lines and the 10th normal among vn lines. The second vertex will use the 6th textures coordinates and the 10th normal, and the second vertex will use the 1st textures coordinates and the 2nd normal.
When you want to reduce or simplify an OBJ file, it's important to understand how these 3 values are used because if ever you change the indices in f lines or change the order of v, vt or vn lines, you'll get a different result and possibly an error if an index doesn't exist anymore.

To reduce OBJ files, my idea is that often normals are not needed because they can be computed automatically, even with a smooth look on joining faces when s off lines are replaced by s 1 lines (by the way, I should have added these lines after usemtl lines for the trunk and branches in the modification of my last post).
To remove normals, you can change all the lines:
f xv/yvt/zvn xv/yvt/zvn xv/yvt/zvn
by f xv/yvt xv/yvt xv/yvt
or lines:
f xv//zvn xv//zvn xv//zvn
by f xv xv xv
and then safely remove all the lines starting by vn since they are not referenced anymore.
If you use an advanced text editor that supports regular expressions (like Eclipse), this can be done very easily:
(\d+/\d+)/d+ -> $1 will replace all ocrrurences of xv/yvt/zvn by xv/yvt
(\d+)//d+ -> $1 will replace all ocrrurences of xv//yvn by xv
vn .+\n -> nothing will remove all lines stating by vn

The other optimization consisted of removing pairs of lines starting by g and usemtl when they specify a material equal to the one set in the last previous usemtl line.
So the following lines:

g leaves1
usemtl leaves
...
f xv xv xv
g leaves2
usemtl leaves
...
f xv xv xv

would be simplified as:

g leaves1
usemtl leaves
...
f xv xv xv
...
f xv xv xv

Doing so will also speed up Sweet Home 3D, because each g or o line implies the creation of a separate group of vertices, whereas using groups is necessary only to manage different colors or materials in a 3D model until now.

Hope this will help. Don't hesitate to request me to perform it on your files if needed.

[OK Hoff]

Thanks for taking the time to explain all of this. Much appreciated. Very useful and fun... Models changed accordingly (with s off / s 1 for leaves and branches/trunk respectively. Not only are the files smaller than I thought possible, but a pleasant surprise is how fast the rendering is, and that it does not seem to slow down sh3d work.

The attached grove may have visual shortcomings, but an entire forest reuses one tree in different flavors so the .sh3d file is only 140 kB compressed. Red/orange gradient .jpg for leaves creates autumn...

ok

[OK Hoff]

Quite contagnous and very informative having the .obj file explained. Realising this, it is incridible how much it is possible to shrink a model. A couple of notes before messing with the .obj file. In a model editor (tested with Blender and Sketchup, but some of this will also apply to geometry from SH3D):

• Group same material before saving and exporting to give a tidier .obj file with fewer groups (and groups in correct order).
• Sometimes multiple surfaces can be reduced to one. E.g. a window with many small window panes (2x3), the glass itself can often be reduced to one surface.
• Pay attention to unneccesary surfaces - e.g. inside other surfaces that are not visible anyway.
• Curved / round elements can often be reduced dramatically, e.g. a round object can be reduced to a polygon with 6 or 8 sides. With smoothing (s 1 as opposed to s off in the .obj file), the object will appear quite round anyway.
• Advanced tools such as Blender offers tools for simplifying the geometry of a model (e.g. Edit mode,X,LimitedDissolve - Objectmode, Join - etc.). Yet to explore this fully, but some great potential here.

I have experimented with some previous models, and could in most cases bring the size down to a fraction of the original size. Unfortunately, many models available online are created with little attention to efficient models. Especially many 3D warehouse models are pretty bloated. Sometimes to a point where it can ruin the entire SH3D design experience by slowing everything down. But then, that is a good argument for making your own models (and sharing them)...

The enclosed model is a simplified pine tree (arbaro, blender, obj simplify). While it is pretty rough, it gives the illusion of a pine with a relatively small model (67,4 zip / 190 plain). Interestingly, even if the file is pretty small thanks to the obj cleanup etc. it still has many surfaces. So while it does not bloat the SH3D file by much, the rendering seems to be as slow as models many times the size in kB.

ok

[OK Hoff]

I took another experimental turn in shrinking further. Mostly reducing number of decimals in the .obj file. It will reduce file size further, but the main idea is that it makes the .obj file more readable and also introduces an inaccuracy for the leaves so they do not all look the same. It appears that rendering is also faster, but that may just be wishful thinking as the number of surfaces are not really reduced.

[Emmanuel Puybaret]

Yours models pinex, tree birch and tree generic were added to the Free 3D models page and to the Trees furniture library 1.7.
Thank you for your contribution :-)