Each LOD must have the same number of faces as the highest LOD

[Gaia Clary]

Found in : http://wiki.secondlife.com/wiki/Mesh/Mesh_Streaming_Cost (see in the last section "issues" ...)

...

...

???

...

 

hmmm.....

I proposed to name them "surfaces" a while ago. There was no big welcome for that proposal ... 

What about naming them "texture faces" ?

 

[Drongle McMahon]

That would be a good change. That wiki page is quite out-of-date now. Most importanrly, it still uses the wrong LOD switch distances; they should be radius/0.24, radius/0.06 and radius/0.03. This was corrected in the real source code a long time ago. (I think the cost comes from the server now, although the code is still there, maybe just for Show Render Info. So strictly speaking, we can't see the actual code now. However, It seems to behave the same as the function in the viewer source code.)

[Gaia Clary]

---

Drongle McMahon wrote:

That would be a good change. That wiki page is quite out-of-date now. Most importanrly, it still uses the wrong LOD switch distances; they should be radius/0.24, radius/0.06 and radius/0.03.

---

heh! While making the LOD switch animation in Blender for the last tutorial i thought something must be wrong. It felt like it does not behave like that in the SL viewer... So after reading what you wrote, i now understand what was wrong and i will redo the animation now ;-)

So for an object with BBox radius = 1 meter and with renderVolumeLODFactor=1.0

 

from	to	at distance from Object Center
High	Medium	4.166 Meter
Medium	Low	16.66 Meter
Low	Lowest	33.33 Meter

Is it like that ?

[Drongle McMahon]

It was last time I checked. I usually say 4, 16 and 32, which are easier to remember. It's quite difficult to measure exactly because there is some "lazy" updating. You sometimes have to do multiple zoom-ins or zoom-outs to get the LOD to update. There's also this interesting line that suggests some sort of fudge factor...

"    F32    LLVOVolume::sLODSlopDistanceFactor = 0.5f;  // Changing this to zero, effectively disables the LOD transition slop "

...but I couldn't find anywhere where that factor is actually used. So I don't know what "LOD transition slop" is.

 

[Rusalka Writer]

I've gotten hung up on the "number of texture faces" thing a time or two. I've filed it under "mesh *$*@ I don't understand."

[York Jessop]

Me too sort of, I'm guessing that if you have 8 'textures' or 'uvmaps' each LOD needs to have the same number? Im not sure if they need to be relatively in the same place tho?

[Drongle McMahon]

The ambiguity is between "face" in a 3D program, which usually means the area defined by a ring of vertices with no other vertices inside (usually triangles or quad(rilateral)s), and the "face" in-world, which is the patch of surface area you can colour and texture independently. In traditional prims, the in-world faces are always a collection of contiguous  triangles. With meshes, they do not have to be contiguous, so you can have islands of surface area that receive the same texture.(You can see an example in my Mesh City gallery where the 12 rotating centers of the dodecahedron are all the same face.)

The way the texture is stretched across the triangles making up one in-world face is defined by the UV map coordinates of the vertices involved, but the face exists, and ca be coloured but not textured*, even without a UV map. It is these in-world faces that are rtestricted to 8 per model, and which must be the same in number between LOD meshes of the same model. There is no requirement that they have any geometrical similarity in the LOD meshes, either in number, size or locations of the constituent triangles.Thus, for example, a "billboard" alpha texture for use at the lowest LOD can be kept on a small hidden triangle at the higher LODs.

In the Collada file, the in-world-faces are defined by separate triangle (or poly) lists (<triangles> tag) in a single geometry (<geometry> tag) that defines a model. For now (though changes have been requested), the order of the triangle lists determines the face number. That means the order determines which faces receive the same texture at different LODs. The order depends on your Collada exporter. (For Blender, fortunately, it is the order of the Blender material indices.).

3D program .....                 Collada ..........      SL

(collection of faces) -> <triangle> tag       -> face

(object)                      -> <geometry> tag     -> prim (mesh) = collection of the above.

*bugs apart.

[York Jessop]

Thanks

Could you translate Gaia? Google Translate failed.

[Ashasekayi Ra]

Drongle, how does the renderVolumeLODFactor amount affect the LOD switch distances? 

[DanielRavenNest Noe]

On an ordinary prim, with the Edit window open, you have a "Select Face" button, which lets you choose which part to apply a texture and other settings to. For prims, the part of the prim covered by one "Face" texture is pre-defined.  With a mesh, the part covered is whatever you choose when creating it.  The "Select Face" button still works for meshes, and highlights your chosen area with the target circles, same as with prims.

Since the Edit window has no way to specify which LOD level to apply things to, all the LOD levels need the same number of faces as the highest level.  In your 3D program, that means having the same number of texture IDs for each LOD model, in the same order, and at least one triangle in each model assigned to each ID.  Otherwise the parts covered can vary in the different levels.

[Drongle McMahon]

"how does the renderVolumeLODFactor amount affect the LOD switch distances? "

Just multiply the numbers Gaia gave by renderVolumeLODFactor (RVLF).

You can also multiply by the object  "radius". As Gaiai said before somewhere, the "radius"  is half the square root of (x*x + y*y + z*z) where x, y and z are the dimensions in the edit box. It's the distance from the center of the bounding box (the translucent box you see when you stretch the object) to one of its corners.

High -> Medium @ 4.166 * RVLF * 0.5 * sqrt(x*x + y*y + z*z)

Medium -> Low @  16.66 * RVLF * 0.5 * sqrt(x*x + y*y + z*z) 

Low -> Lowest  @   33.33 * RVLF * 0.5 * sqrt(x*x + y*y + z*z) 

This applies individually to each prim in a linkset. So they will switch at different distances if they are different sizes.

I don't know if this applies to attachments. Iguess it would because they are still a type of object called "Volume", but there is a separate renderAvatarLODFactor wich might apply to attachments too. (There is alkso a renderTreeLODFactor and a renderTerrainLODFactor).

PS. If anyone wants to make a test object with radius = 1.0, just set the dimensions x = y = z = 1.155



[Gaia Clary]

---

York Jessop wrote:

Thanks

Could you translate Gaia? Google Translate failed.

---

This object has 6 texture faces :

but 54 model faces:

and as you can see, the model faces which share the same texture face do not need to be adjacent.

Is that enough of translation ;-) ?

[Drongle McMahon]

Could you translate Gaia? Google Translate failed.

Sorry. I don't think Google has hyperconvoluted prose on its language list. I tried converting to Telegu (because it is pretty) and back, but it wasn't much better. Tell me if this is better. I do need to learn to be more comprehensible....

_________________________________________________________________________________

In a 3D program, face usually means the area enclosed by a ring of vertices with no other vertices inside it. These are usually triangles. If they have more than three vertices, they are divided into triangles when meshes are uploaded. So I will call them triangles in the following.

In-world, and in LSL, a face is a part of the surface of a prim that you can colour and texture independently. These faces can be made up of many triangles in the underlying mesh that defines the structure of the prim. In traditional prims, all the triangles making a face are joined together. In meshes they don't have to be joined. One face can be made up of separate pieces that are not connected (like the twelve circles with rotating textures on the ball in the middle of my gallery in Mesh City).

The way the texture is stretched across the triangles making up one in-world face is defined by the UV map. The face exists even if there is no UV Map. In that case it can be coloured but not textured.

It is these in-world faces that are rtestricted to 8 per model. There must be the same number in LOD meshes of the same model, but they don't have to be similar, either in number of triangles, size or location.Thus a texture for use only at the lowest LOD can be kept on a single small hidden triangle in the higher LODs.

In the Collada file, the in-world-faces are represented triangle lists in the section defining the geometry a model. The LSL face numbers are just the order of the triangle lists in the file. Faces with the same number will get the same texture at every LOD. To make sure the right faces get the same texture at different LODs, you have to make sure the face numbers, and thus the triangle lists, are in the right order. In Blender that simply means using the same material index for the parts that are supposed to get the same texture.



[Madeliefste Oh]

---

Gaia Clary wrote:...what about naming them "texture faces" ?

 

---

Or "texture areas"...

[Rage Riptide]

That message has haunted many I guess. It's a reminder that "You're doing it wrong"! But the message is wrong too.

While in this phase there has to be more error info. I just keep trying till something works and then I'm usually not happy a 2,300 PE

Texturable surfaces.

[TANAKAAKIO Inshan]

If polygon faces of meshes are so, lod levels are not making any sense.
I didn't know the meaning at first .
I knew what you're saying soon.
Meshes have up to 8 faces of surface texture.
The number sholud be same in every LODs to keep painting area as far as possible.

[Ashasekayi Ra]

Thanks Drongle.

[York Jessop]

Thanks Gaia, I understand the part about them not needing to be next to each other (Thanks too Drongle I understood most of your post, I just had to read it about 8 times )

I guess what I'm not sure about is how it relates to the same number of texture faces per lod.

Say I have 6 materials/textures on my high LOD model, Do I need to have the exact same materials textures on each lod, for example

 

 

[Gaia Clary]

yes, unfortunately that is the case at the moment. There was a discussion about if this constraint can be removed later. But i don't know if that will happen.

[edit]: wrong additional statement about physics shape and texture faces removed (see my post below).

[Drongle McMahon]

"Do I need to have the exact samematerials textures on each lod?"

No, you don't have to, but you might as well. If you provide different textures for the lower LODs, they will be ignored and the set provided for the high LOD will be used for all the other LODs.

1. The uploader forces you to have the same number of "texture-faces" in each LOD.

2. The different LODs don't have separate textures - there is only one set which is used for all the LODs.

3. If you do specify different textures for the different LODs, the ones for the lower three LODs will be ignored*.

4. The order of  the "texture faces" in the Collada file decides which texture is applied to which "texture face".

*(unless they have made that an error now)

PS I am not disagreeing with Gaia ... at first I said "Yes and no", but I thought that might be annoying.

[Drongle McMahon]

"also the physics shape needs the same amount of (texture-) faces"

That's interesting. I didn't encounter a problem like that (yet?). Can you give more details? I would like to try it out.

[York Jessop]

Ugh physics shape too, thats abit silly, you cant even see the physics shape.

[Gaia Clary]

now you confuse me ;-)

Isn't that what you write exactly the same as "The set of textures provided for the High LOD will be reused for all lower LOD's" ?

I mean, surely you can actually use different textures in your lower LOD files. But when they get ignored anyways, then what benefit would i have from doing that ?

[Gaia Clary]

[edit] Oups you are right, it works even without any material settings. I think i also found why it did not work for me the other day. It looks like i unintentionally saved the entire scene as physics shape instead of just the selection. This error happens to me all the time since i work with Blender 2.58 ;-( and i forget to set the checkmark too often.

With that export the importer goes wild problably because now the number of objects in the physics file is different from the other shape files.

So: I was wrong, the physics file does not need any material settings at all. good ;-)

[arton Rotaru]

---

Gaia Clary wrote:

i think a got a viewer crash when i used a physics shape without any (or with just one) material settings. However this issue appeared to me some weeks ago and it might have been solved by now... So i need to recheck this.

---

That was a bug a while ago, which was around only a couple of days, where the viewer crashed uploading a mesh (incl. physics) without UVs.