Prim Bonuses and LODs

[Aquila Kytori]

 

---

Chic Aeon wrote:

.................

.perfection

. This

exercise

IS supposed to be

FUN

.

 

 

---

  Mesh, exercise, fun and cute :

[ChinRey]

Sorry if this appears twice. I tried to post a reply but it didn't appear on the forum so I'm trying again:

I'm working on a set of mesh trees at the moment and one of the trunks just happens to have the same 1.2 LI as Chic's table. And since texture optimisation was mentioned earlier in this thread: it also uses a single 256x256 pixel texture. The two builds are too different for direct comparasion of course but it still should give an illustration what can be achieved with optimised LoD models.

 



[Pamela Galli]

Nice job ChinRey! Trees are challenging to get low LI.

[arton Rotaru]

Aaawwwww....love it! :matte-motes-smile:

[Chic Aeon]

Very nice job. Careful mapping and tiling texture?

 

I will always be using bigger textures as mine almost never tile *wink*. After a year (well more) lerning Cycles and how to get what I want I won't be going back to tiling unless I am on a platform where that is the only option (Cloud Party was pretty much that way but I think now that I am smarter I could probably manage "something" a bit better than I did there ).

 

I guess the point is that one can make some pretty nice stuff with good LODs (and presumably good physics) for 1 land impact. OR one can have some pretty stuff that falls apart at a couple of meters.

 

I vote for the first option .

 

It should probably be noted for folks that don't know, that the BIGGER something is, the easier it is for the LODs to hold (a viewer distance algorythm thingie that I don't really understand). That is why some popular trees in SL work fine when large (and usually fairly primmy) but fall apart when when made smaller and looked at mid distance.

 

I have some old LAQ trees however that look good AND are low prim and can be about any size. So it IS possible to have your cake and eat it too!

 

 

 

[Drongle McMahon]

While I had the table, I tried one more thing that demonstrates how little effect the high LOD complexity has on the LI for something this size. I made a single segment bevel on all the sharp edges (made with edge split modifier in the original high LOD model) and then transferred the normals from the previous high LOD version. This has the effect of adding edge highlights under advanced lighting, as you can see in the left panel of the picture, comapred with the righ panel. Of course, these are only visible when you are this close. This raised the high LOD triangle count to 9136, nearly two and a half times as many as in the original. So that's two and a half times the work for the renderer (is it?). The download weigh and LI were still 1. I would be interested to know people's views about whether all that extra goemetry is worthwhile for this improvement. Doing something similar with much bigger objects, like a house, would not be so cheap, as the high LOD has increasing effect on the LI.



(9 am default sunlight, with shadows.)

[Chic Aeon]

I would be happy to vote, but I tried two different browsers and that photo is so dark on my screen (which I have pretty bright as I like that) that I can't see much at all. I can see a "shine" on an edge (guessing) on the one on the left.

Since any furniture in that triange range would make me gasp and rethink should it happen, I would have to say "no". My only reason to make something that finely detailed and smooth would be if I wanted to take a close up of it for a film. So far in four years there has been one occassion.

 

It would be great if you could get a brighter photo. Not sure why that is so very dark.  Your others weren't.

 

One thing, I think, that is difficult for folks starting with 3D modeling to "get" is that there are MANY purposes and uses for models. On our platform things need to be pretty light in that triangle count area -- not Blockworld, but certainly not like many 3D items that are made for the purpose of RENDERS, not game engines.  There are so many learning videos out there that have you subdividing a few times and then adding a subsurf modifier at 4 (cringe) that it is easy to see where that confusion comes in.

 

I do now and then use a sub-surf modifier but then after applying I go in and take out a bunch of the edge loops that really aren't needed (usually for me it is the corners and edges that I wan't smooth and I don't need all that extra topology).

 

I just finished (well almost) one of the most complex pieces of furniture that I have made to date. It is 7048 and 2 meters wide by 1.75 meters high and .8 deep. It has tons of details and lots of metal trim, pulls, bolts etc and came in at 3.4 with extrememly long range good LODs. It is even good at 1. It has plenty of details as it is so adding more with extra bevels in thiscase would just be superflous.  Other folks of course might have different ideas .

It is all on one texture too which was SO not easy to accomplish. Even though I love mapping I was VERY happy to get it done.

 

Edit: a PS

I am guessing that your REAL questions is "if we can get the land impact down to 1 should we worry about how dense the mesh is" or something of that sort. I suspect that for some people the land impact count is the bottom line. I am not in that camp. Somewhere between most efficient and prettiest there is a balance point. It is different with each model. I try to find that sweet spot. Again, MY "sweet spot" may not be that of others.

 

[Chic Aeon]

I had an epiphany while washing dished and making lunch (usually it is during tubbing time) so I am going to stick it in this thread as it kinda seems to encompus the ideas here.

 

You, Drongle, have talked about that nasty triangle that you see when people cheat on their LODs. I didn't connect that to the "zeroing out" the lowest LOD on the uploader until you mentioned that specifically. I also didn't understand is why I never see that in my things since I have been zeroing out the lowest LOD on small things forever.

 

I almost never see that triangle as I roam the world (I obviously shop at good places) but I did last night as a smallish decor item disappeared at very close range.Yes, ugly. Agreed.

 

As far as I can tell my things don't have that issue because by the time they disappear the item is VERY small on the screen and if a triangle appears one doesn't notice it. So it isn't JUST using the uploader rather than making custom LODs, it is most likely using the default settings along with the zeroing out on small items (that is where I have seen it). Couple that with creators having their LODs set to 4 one method or another and there is definitely a recipe for disaster.  As I have mentioned before many of the items with insufficiently holding LODs also are VERY low download, so the LODs could be improved without raising the land impact FINAL NUMBER.

 

And still, for me, the biggest issue is people testing their models at a lowish LOD setting.

 

OK. Back to work.

 

[ChinRey]

---

Chic Aeon wrote:

One thing, I think, that is difficult for folks starting with 3D modeling to "get" is that there are MANY purposes and uses for models. On our platform things need to be pretty light in that triangle count area -- not Blockworld, but certainly not like many 3D items that are made for the purpose of RENDERS, not game engines.

---

Yes. One aspect that is usually forgotten in Second Life because the world is so thoroughly based on technology rather than art, is that what we see is not what is actually there. We see the big picture, we may notice some details in the object we're specifically focusing on, we notice very well items that stand out like sore thumbs (such as poor LoD models) and we do notice abrupt movements and changes (like switches between unmatched LoD models) but most of the image we have of our surroundings is interpolated by the brain, not seen by the eyes.

The three main factors that keep Second Life and other virtual ralities of the same kind from becoming more "real" to the users are the interface, lag and - for SL and SL based virtual realities - the camera position bug. The amount of visual details isn't anywhere near as significant as those three and it's a little bit worrying for Sansar that LL doesn't seem to have quite grasped that fact yet.

That being said, visual details do matter of course and in this particular case I might go for the bevelling. It wouldn't cause any significant lag increase sicne a model like that would hardly ever be rendered in f high LoD anyway so why not? The only worry is what happens at the high-medium switch point. If ti causes more problems there - like sudden changes in the shading across the surface, then no.

[Drongle McMahon]

Yes. It's too dark. Here's a lighter closep. Given the effort involved in getting it to show up, I guess the answer should be that it's probably not worth it, at least for daylight. Under local lights, the highlights become more prominent.



[ChinRey]

---

Chic Aeon wrote:

You, Drongle, have talked about that nasty triangle that you see when people cheat on their LODs.

---

I don't really think it's right to hold that specific part of the LoD issue against builders. It's one of the Seven Big Blunders LL's programmers made when they wrote the code for sculpts and for mesh. Us content creators just have to try our best to minimize the problems they create.

(Which reminds me: Patch, if you happen to read this and are serious about improving the content quality in SL: get into a time machine, go back to ... 2006, was it? ... and fix those Blunders. If you do that, there may not even be a need for Sansar since SL should be able to render at 90 fps.)

[Drongle McMahon]

"I almost never see that triangle"

More often the case than not. Here is a set of four table bases. Left is high LOD throughout; then my manual LODs; then one with triangle count settings close to the ones you used (gave 3803, 3808, 476, 3 tris); then default LODs. First two rows either side of mediu->low LOD switch. Bottom row just after low->lowest. All at RVLF=1.125. You can just about see the a single triangle in the third one, but you probably wouldn't notice it if you weren't looking for it. It will depend on what triangles GLOD happens to end up with, and that can vary each time you upload the same file. It might sometimes be bigger. It's really pretty easy to make the single downward-facing polygon for the lowest LOD instead of hoping GLOD will be nice to you. So I would stil suggest that.



It's interesting to note here that even the first model, highest detail at all LODS, looks broken up in the bottom row. This must be simpoly because too many triangloes are smaller than one pixel. It does show why using too detailed models at lowest LODs is always going to be a waste of resource.

 

[Pamela Galli]

Probably worth it, but I might just try doing it w texture.

[Chic Aeon]

So -- can I make a new object that is a triangle facing down rather then delete a lot of loop cuts and such? I seem to remember a message long long ago about not being a part of a material set or something like that.  And does one need a triangle PER material?

 

Done for the day (whew) but will try that next time.

 

I do think your edge effect is very nice. I have done that on wooden boards now and then. IF the "table" would have been less detailed and the pieces a bit thicker then I think it would have been worth it.

[Drongle McMahon]

It needs to have one triangle for each material. However, now that I think about it, it's going to be stretched to fill the bounding box of the high LOD mesh. So that's not going to work the way I was suggesting. Maybe you have to put a very tiny triangle at the top too. There's also a way of fooling the uploader with a vertex not assigned to a triangle. Maybe I can use that, but that might require editing the collada file. I'll have to do some experiments. 

[arton Rotaru]

I go with the lowpoly, but would have the edges baked down into a normal map. Since I can't stand content without specular maps anymore, I will use a gloss map as well. Since these come in with the normal map, the normal map has to be there anyway. :matte-motes-smitten:

 

Drongle McMahon wrote:

This must be simpoly because too many triangloes are smaller than one pixel. It does show why using too detailed models at lowest LODs is always going to be a waste of resource.

Yeah, I had this problem a while ago when making this trash bin:



It had twice as many vertical bars of half the width. It had ugly edge flickering though, when moving the cam. So I made them twice as wide, and half the number of bars. Works way better!

And since I can't stand single triangle LODs as well, here is what it's LOD models look like:



Yes, unfortunately it has a second material for the 17 tris lowest LOD with a 128² diffuse, no normal, blank spec. But like I said, I can't stand single triangle LODs. :matte-motes-whistle:

Since the number came up a couple of times already, it also has a DW of 1.2.:matte-motes-little-laugh:

 

[Drongle McMahon]

I did the experiments...

As I suspected, if you make a completely flat downward facing triangle, it get placed at half way up the bounding box. So that's no good. Adding a micro-triangle method works ok, as long as you make the tiny triangle at the top small enough that it's less than one pixel when the LOD switches to it. It can be anywhere as long as it's above the downward triangle, because the uploader will stretch the whole thing so that it's at the top and the downward triangle is at the bottom.

The other methods depend on a quirk of the viewer code that I reported as a bug some time ago. It's still working in the latest viewer. So I doubt that it's going to be changed, but it can't be guaranteed to keep working. However, if it is changed that will not affect meshes that have already been uploaded, as the uploader has already been fooled for those.

It works because the uploader initialises the bounding box limits with the first value it finds in the list of vertex positions in the collada file. Then it changes them as it goes through vertices referenced in the triangle list. So if that first vertex is never referenced in a triangle, and any of its coordinates is outside the range of the vertices used for triangles, it will remain there as the bounding box limit. So all we have to do is put a suitable vertex as the first in the position list (this can also be used to offset the pivot for doors, which is also the centre of the bounding box, albeit at a cost of increasing the size and therefore the LI).

Method 1 is to edit the collada file directly. The result is shown below for a single flat triangle (one material) file. The position count (blue) has been increased by three to account for the three inserted numbers (green) whichdefine a vertex higher up, Z being greater than for the vertices of the triangle. As with the micro triangle, it doesn't matter how high, as the bounding box will be stretched. We also have to increment by one (red) the count in <accessor>, and all the indices in the polylist (<p> tag) that refer to the position source, because we have shifted all the vertices by adding the special one.

<library_geometries>    <geometry id="Cube_001-mesh" name="Cube.001">      <mesh>        <source id="Cube_001-mesh-positions">          <float_array id="Cube_001-mesh-positions-array" count=""> 0.2 0.4 -1 0.4 0.2 -1 0.4 0.4 -1</float_array>          <technique_common>            <accessor source="#Cube_001-mesh-positions-array" count="" stride="3">  .....        <polylist material="Material-material" count="1">          <input semantic="VERTEX" source="#Cube_001-mesh-vertices" offset="0"/>          <input semantic="NORMAL" source="#Cube_001-mesh-normals" offset="1"/>          <vcount>3 </vcount>          <p> 0  0  0</p>        </polylist>      </mesh>    </geometry>  </library_geometries>

Fortunately, there is a much easier way to do this in Blender. The picture shows two versions of the flat triangle with an extra vertex added at the end of an edge attached to one of its vertices (the edge makes it easier to see). To make sure this extra vertex appears first in the exported collada, simply select it and then snap the cursor to it (Mesh->Snap->Cursor to Selected). Then select all the vertices and sort elements by closeness to the cursor (Mesh->Sort Elements->Cursor Distance).

Now when the file is exported, the extra vertex will appear first, followed by the more distant triangle vertices. In the left hand version, the extra vertex is directly above the triangle, made by simply extruding one of the triangle vertices. In this case, the triangle will be stretched in the horizontal plane to the extents of the bottom of the bounding box. If you want the triangle remain small, you can move the extra vertex to the opposite corner of the bounding box, as shown to the right.



You can check that these have worked by dialing RenderVolumeLODFactor down to zero, which will always render the lowest LOD, even when you are on top of the object. To see whether a micro-triangle is small enough not to render, you should test by zooming out with RenderVolumeLODFactor set to 1. The flat downward triangle of any size is alright for things on the ground, but for things that might be seen from below, you should be able either to use two micro-triangles, or to use a single micro-triangle with an extra vertex.

ETA: Note that, because of the bounding box stretch/squeeze, one dae file can be used for any model with the same number of materials, as long as the material numbers are the same. So if you adopt a convention for naming you materials (e.g. mat1, mat2, ....) then you won't have to keep making new lowest LOD files.

ETA: Just to recap thecontext here - This is about methods to use a one-triangle-per-meterial flat polygon lowest LOD that will make the object disappear completely at the lowest LOD, thus avoiding ugly triangles sometimes produced by the automatic LOD generator when the triuangle count is set to zero. It deals initially with a downward facing polygon, which will be invisible for objects on the ground. Extension to ungrounded objects is then mentioned. All this does not imply a recommendation fo the use of minimal geometry lowest LODs. It is simply to help avoid aesthetically unpleasant results from those who choose to use them.

[Chic Aeon]

Thanks for all that testing. Have a snippet so I don't lose the info.

 

I DID finally (FINALLY) get the linkset (multiple meshes in one file on upload) physics thing. Sometimes it just takes me awhile.

 

Poco a poco.

[Aquila Kytori]

 

Showing what is possible when using hand made lower Lod models is good but if you really want to encourage people new to mesh to do the same then it would be even better to include the wire frames.

At the moment i’m putting together a sim size speedway stadium where most of the objects are very large so I only have to worry about the Medium Lod model for most of the parts.

But today I needed some sets of tyre stacks to protect the ends of the walls that separate the race track from the pit lanes:

 

   ( and the download weight was again the magical 1.2   The Med and Low were having some effect on the LI cost but by far the biggest effect for an model this size, (3 x 2 x 1.5m) was the Lowest lod model ).

If you follow the workflow of :

Create high Lod mesh.

Uv Unwrap.

Create texture.

Create lower Lod mesh models (in a way that the lower Lods can use the same UV/texture without additional editing )

      then from the above example you can see that often, making the lower Lods is very little extra work .

If you are posting images of the end result please consider also adding wireframes of how you got there.

 

A method to remove edge loops without destrying UV's see message number 8 here :

  https://community.secondlife.com/t5/Mesh/Any-advice-on-ways-to-line-up-UV-islands-for-the-different-LODs/m-p/2936244#M31636 

[IvanBenjammin]

---

Drongle McMahon wrote:

While I had the table, I tried one more thing that demonstrates how little effect the high LOD complexity has on the LI for something this size. I made a single segment bevel on all the sharp edges (made with edge split modifier in the original high LOD model) and then transferred the normals from the previous high LOD version. This has the effect of adding edge highlights under advanced lighting, as you can see in the left panel of the picture, comapred with the righ panel. Of course, these are only visible when you are this close. This raised the high LOD triangle count to 9136, nearly two and a half times as many as in the original. So that's two and a half times the work for the renderer (is it?). The download weigh and LI were still 1. I would be interested to know people's views about whether all that extra goemetry is worthwhile for this improvement. Doing something similar with much bigger objects, like a house, would not be so cheap, as the high LOD has increasing effect on the LI.



(9 am default sunlight, with shadows.)

---

Can I ask what the difference is in vertex count between bevelled and non bevelled versions? Vertex count is just as important (if not moreso) to the renderer as triangles, and in theory there's no difference between a hard edge and a bevelled one (as a hard edge has to be split into at least two vertices by the renderer).

IMO its worth it. I try to bevel outer edges wherever possible - it looks so much nicer, especially with normal mapping.

[Drongle McMahon]

"Can I ask what the difference is in vertex count"

Good question. The answer is: Edge-split 4568 vertices, bevelled 10240 vertices. More than twice as many! As you will no doubt be, I was surprised by this. In case others don't see why, I show the vertex normals of a typical corner of the mesh in the two cases, edge split above and bevelled below. Althought the edfge split version has only two vertex positions, these are split into three because the SL format vertex list includes the normals at each vertex. So it has to list them each time they appear with a different normal, even though the positions are the same. So that's six vertices for SL. Now the bevelled version actually has six vertex positions, but each has only one normal. So that should still be six vertices in SL.



Indeed, in Blender, both versions have the same vertex count, 4320. My initial thought was that the differences were the result of the UV mapping. There were a lot of seams, and these cause duplication of vertices along them in much the same way as do different normals, more in the bevelled version. However, removing the UV maps only changed the couints to 4320 (the same as in Blender) for the edge-spli version, and 7050 for the bevelled version. This must mean something peculiar is goiung on in the bevelled version that is causing tiny differences between what should be identical normals in the exported file, or that the uploader code that is supposed to avoid duplication of identical vertices is not working quite as intended. It's also possible that removing the UVs is not giving the same data as not having them in the first place. I will have to do some more experiments to find out.

[IvanBenjammin]

I would be very interested to see what you discover through testing, because that makes no sense.

Is it just me, or does understanding SL tech feel like archaeology, piecing together explanations out of clues?

[ChinRey]

---

IvanBenjammin wrote:

Is it just me, or does understanding SL tech feel like archaeology, piecing together explanations out of clues?

---

It's not just you, that's exactly what it is.

[ChinRey]

---

Aquila Kytori wrote:

 

Showing what is possible when using hand made lower Lod models is good but if you really want to encourage people new to mesh to do the same then it would be even better to include the wire frames.

---

Good point. These examples shouldn't really need them though.

I suppose I shouldn't really reveal all my LoD secrets since one of my selling points is that I can make models with lower LI than anybody else.

But here are a few tricks that may or may not improve the lowest LoD model of Aquila's tyre stack:

No. 4 is the one that will give the lowest download weight but the difference betwen the last three is so minute it may not even show in the three decimal figure the uploader gives.



 

The first model is the old crossed sheet trick, very useful for smaller plants (and also larger background plants) and sometimes used for other objects too. For some reason it's rarely seen as a lower LoD impostor solution though. It increases the triangle count a little bit but it may or may not give a better visual representation of the model - have to actually test it to know.

The other are different variants on the crossed sheet and on Aquila's LoD model taking advantage of the fact that the lower part of the model is less noticeable than the upper part to cut the triangle count in half.

[Drongle McMahon]

It turns out to be more complicated than I had imagined. First, I was forgetting the effect I have commented on before, a long time ago. If you don't have a UV map in the dae file, the uploader uses uninitialised data, effectively random UV mapping. That usually leads to a lot of separated islands. The seams between these split the vertex list just as different normals do. Furthermore, it's can be different each time you upload, so that the vertex count varies. The way round this is to make a UV map, but to collapse it all to one point. Then all the UV coordinates are identical and no splitting can be induced on that account. That reduced the vertex count considerably, but only down to 6500 or so.

So I looked at the dae files in detail. When you use data transfer to modify the normals in Blender, you have to turn Auto-smooth on (set to 180 deg, so that it has no effect), or the unmodified normals get used instead*. However, any time you turn auto smooth on, some "wobble" gets introduced into the exported normal data values, and that affects the transferred normals. If that wobble is sufficient, it can split vertices because the normals are detected as different. In the case of the problem model, rounding the normals to four decimal places eliminated the wobble and produced an uploaded model with the expected 4320 vertices. The number increased as the rounding was made less stringent. Here is a section of the normal data before and after rounding...

 

> nmlsq[101:160] [1]  9.945234e-01 -1.323220e-05 -3.090524e-01  9.510451e-01 -4.528400e-06 -3.090322e-01 [7]  9.510517e-01  9.924170e-06 -3.089848e-01  9.510670e-01  6.020850e-06 -1.045139e-01[13]  9.945235e-01 -1.913310e-05  3.090501e-01  9.510459e-01 -5.126000e-06  3.090020e-01[19]  9.510614e-01  1.814960e-05  6.691052e-01  7.431678e-01  2.948870e-06  6.691429e-01[25]  7.431339e-01 -1.642110e-05 -6.691060e-01  7.431671e-01 -2.892380e-06 -6.691432e-01[31]  7.431335e-01  1.680850e-05  8.089966e-01  5.878134e-01  3.188850e-06  8.090273e-01[37]  5.877711e-01 -1.564620e-05 -8.089970e-01  5.878129e-01 -4.617800e-06 -8.090271e-01[43]  5.877715e-01  1.776220e-05  9.135313e-01  4.067686e-01  3.395910e-06  9.135525e-01[49]  4.067209e-01 -1.585480e-05 -9.135320e-01  4.067672e-01 -4.293090e-06 -9.135530e-01[55]  4.067196e-01  1.671910e-05  9.781405e-01  2.079452e-01  2.592020e-06  9.781511e-01

> nmlsqr[101:160] [1]  0.9945  0.0000 -0.3091  0.9510  0.0000 -0.3090 [7]  0.9511  0.0000 -0.3090  0.9511  0.0000 -0.1045[13]  0.9945  0.0000  0.3091  0.9510  0.0000  0.3090[19]  0.9511  0.0000  0.6691  0.7432  0.0000  0.6691[25]  0.7431  0.0000 -0.6691  0.7432  0.0000 -0.6691[31]  0.7431  0.0000  0.8090  0.5878  0.0000  0.8090[37]  0.5878  0.0000 -0.8090  0.5878  0.0000 -0.8090[43]  0.5878  0.0000  0.9135  0.4068  0.0000  0.9136[49]  0.4067  0.0000 -0.9135  0.4068  0.0000 -0.9136[55]  0.4067  0.0000  0.9781  0.2079  0.0000  0.9782

This is from R, which I used to do the rounding.

However, having discovered this, I proceeded to try to reproduce the effect, starting with a new copy of the mesh. This time it imported straight away with 4320 vertices. There was wobble in the normal data again, but apparently not enough to show up (I haven't checked explicitly). So I am still confused. I need to try to repoduce the model with the excessive wobble. 

Anyway, it does appear that the auto-smooth function in Blender, which has to be applied to export transferred normals, introduces "wobble" in the values for the custom normals that can be sufficient to cause artefactual splitting of vertices. I would have to regard this as a bug (or feature) in Blender (although the uploader could be modified to work around it by doing less stringent matching in the code that eliminates duplicates). I suspect the wobble must be there in the internal Blender data, rather than being introduced by the exporter. Whether there is a sensible reason for the wobble, I will not speculate, as I don't know enough about the code and/or its motivating priciples.

*That's very strange, because smooth shaded mesh without data transfer behave the opposite way round. If you turn auto smooth on for these, they get exported as flat shaded although they look smooth shaded in Blender. You have to turn it off to get the smooth shaded normals exported. When it's on, the normals, specifying the unwanted flat shading, still have the wobble.