Prim Bonuses and LODs

[ChinRey]

---

Aquila Kytori wrote:

I was curious about what you meant about not using modifiers because of “vertex drift”...

---

Yes, I suppose I didn't explain that properly.

Say your mesh has to vertices, one with the coordinates <50.000,50.000,50.000>, the other <50.000,50.000,10.000>.

Move the second vertice to <50.001,50.000,10.000> and you get a significant increase in download weight. Significant on this scale of course. Two vertices don't cause any download weight worth mentioning anyway and won't even make a mesh but apply the principle of precision vertice alignment whenever possible and you can save an amazing amount of LI. The almost 90% reduction me and Arton managed to demonstrate with our hexagons is a bit extreme but 10-20% is not at all unusual.

 

Here's a very simple example, a torus with 24-12 resolution (576 tris):



If I use the decimate modifier to reduce the triangle count to 144 for the mid LoD model, I get this shape:



Download weight 0.402 with auto generated low and lowest LoD models:



If I decimate manually to 144 tris, the model looks like this:



A visually better solution but right now it's the download weight that counts. It's 0.379



 

---

Aquila Kytori wrote:

Accurate to 7 decimal places, I repeated for moving  0.2, 0.3, 0.4, 0.5 etc up to 1.0 along x axis. The 0.5 was exactly 0.5 in the print out but all the rest had a similar deviation as the first. Was this the kind of “drift" that you were referring to ? If so does the collada exporter export to 7 or 8 decimal places ? surely not .

---

I don't know about 7 or 8 decimal places but remember it can add up.

Dodecagon freshly created in Blender, except it's UV mapped:



Same with vertices lined up as well as they can be in Blender:



With the top face shifted 0.0001 mm on the y axis:



 

[Drongle McMahon]

5.960464477539063e-08 is 2^-24. It is the smallest denormalized number that can be represented in the 16 bit IEE floating point format. Denormalised numbers* are numbers smaller than the minimum representable with full precision, at the cost of reduced precision. They are used (unless excluded by a compiler directive) because they can avoid divison-by zero errors produced by rounding of intermediate vales produced by subtraction of two floating point numbers that differ by less than the minimum normal number. So this number is as close as the format can go to 0 without actually being 0. Why they are generated by your particular manipulations, I don't know.

*A link with some explanations, albeit for 32 bit numbers.

The Blender collada exporter does use seven decimal digitd of precision for export, which is consistent with the use of 32 bit floats (single precision) for internal data, which I have read elsewhere is the case. So there doesn't seem to be any reason for a number whch is the natural consequence of using 16 bit (half precision) floats.So I am rather confused about that. I suppose it could be using SSE/SIMD instructions** which can do parallel calculations on registers carrying multiple lower-precision numbers, making it faster. If that used 16 bit segmentation of the registers, that could account for this effect. Maybe someone with knowledge of Blender internals can enlighten us?

The SL uploader converts the floating point data to 16 bit integers, with a scaling factor calculated so that the whole range (-32768..32767) is used over the size of the bounding box in each dimension. This gives even precison over the whole range, unlike floating point numbers. 6*10^-8 would almost always become zero in that conversion (i.e. unless the mesh was extremely small!).

I have to suspect that the other small, but larger numbers, and the differences that creep in, are the results of similar precision errors.

**ETA: Or maybe using 16 bit calculations on graphics processor? Surely not worth the loss of precision for either?

ETA: Or maybe it's the Python that's doing it?

[Drongle McMahon]

That was all probably rubbish. :matte-motes-sick:

Found a detailed source for all this. It seems 2^-24 is also the minimum rounding error for a 32 bit floating point value that is supposed to be 1. That is, it is half the value of the least significant digit in the significand (mantissa), referred to as 0.5ulp. Of course, it's much more complicated than that. having read about 1/4of the indicated document, it appears that 0.5 ulp is the target for error in much more complicated calculations than addition and subtraction, which are achieved by using extra bits in intermediate values. So that remains the expected minimum rounding error.

What happens if you scale the plane up by 100? Does the funny number scale up too?

The 7 significant decimal didgits used by the Blender exporter is more than enough for the 16 bit integer representations used by the SL uploader, but that document mentions that nine decimal digits are required for the originating 32 bit (single precision) binary number to be recovered when it is read back in.

 

[Aquila Kytori]

Hi Drongle

---

Drongle McMahon wrote:

That was all probably rubbish. :matte-motes-sick:

 

---

And unfortunately all way above my head. Now I understand that number to be the computer language equivalent of being as close to being zero without actually being zero. Could make a good password for my online bank account.

---

Drongle McMahon wrote:

What happens if you scale the plane up by 100? Does the funny number scale up too?

---



Shouldn't the -99.00 be -100.0 and the 101.0 be 100.0 ?

 



That did change the number to ................e-06

 

and finally:



[Drongle McMahon]

Not sure what you did here ... ie what step you scaled at. Meanwhile, I can confirm that 1.100000023841858 is exactly what you get when you convert the nearest possible 32 bit binary representation of 1.1 to decimal. It's not exact because dividing by 10 (multiplying by 0.1) gives a recurring binary fraction. That gets rounded up to the value we see. In binary, the significand should be 1.000110011001100110011001,1001100110011.... where the comma is the last available digit. So that gets rounded up to 1.000110011001100110011010. So that is the predictable rounding error. If you move the point by an amount that is exactly representable in a 32 bit float, such as 0.5 or 0.25, there will be no error. I imagine rotations are done my matrix multiplication, which is again subject to rounding errors, and that's where the other errors come from. Of course, as these all accumulate on top of each other, the effects can get larger. That may account for the "wobble" we are seeing.

ETA: in the case of 1.100000023841858, the error is too small to show up in the 7 significant digitd produced by the collada exporter. So this particulat vertex shows up as 1.1

[Aquila Kytori]

Drongle, the starting point each time I scaled was this one from the earlier post :

---

Aquila Kytori wrote:

Lastly I added a plane in top view, then in:

     Edit mode, rotated it about the x axis 90°

     Front view,   G X 1   followed by   G Z 1, so that one corner of the plane was at x0 y0 z0.

Ran the script and got the following :

 

 

 

---

and can also confirm you are perfectly correct, no deviation what so ever when moving a vertices 0.25, 0.5 or 0.75 along the x axis.

 

[ChinRey]

---

Aquila Kytori wrote:

and can also confirm you are perfectly correct, no deviation what so ever when moving a vertices 0.25, 0.5 or 0.75 along the x axis.

---

This is way above my head, I'm just a simple builder.

All I know is that you get higher LI if you don't keep your vertices straight.

[Drongle McMahon]

"you get higher LI if you don't keep your vertices straight"

Yes. I guess we were just thinking about how they annoyingly get unstraight in the first place. I suppose the reason the strightness helps is because it improves the compressibility of the uploaded data. Is that your impression too?

[ChinRey]

---

Drongle McMahon wrote:

"you get higher LI if you don't keep your vertices straight"

Yes. I guess we were just thinking about how they annoyingly get unstraight in the first place.

---

Yes and joke aside, it is both interesting and quite useful to understand that better.

 

---

Drongle McMahon wrote:

I suppose the reason the strightness helps is because it improves the compressibility of the uploaded data. Is that your impression too?

---

I can't think of any other explanation. As far as I know, the formula for calculating download weight only contains two variables, the item's dimensions and the size of the compressed file.

It is worth noticing that sometimes you can actually get lower download weight with slightly offset vertices. That's conistent with the compressability explanation since perfectly aligned vertices isn't necessarily what gives compressor the easiest bytes to handle. I can't see how a human can reliably find those other sweet - and even sweeter - spots but it should actually be possible to write a computer program for it.

[shaniqua Sahara]

my two cents. most people who upload a lot of meshes have to take Lindens into account. it is often ten times more costly uploading meshes with lower LODs than not. less prim count, cheaper price = a must do for most.

 

while i'm here i'd like to also mention that most "content creators" are people trying to have fun making things, their not trying to be artists or have the know how to make everything as otptimal as it could be. they just want to have fun and be like "oh wow look what i just did". to try to attemp somethings they never thought they could, push themselves to the edge of their abilites and stuff like that. i'm almost always working on things that are just over my head because that's where i find excitement, so for sure a lot of the things i do could be better done, but that's not the point.

we have to accept poorly optimized things because it's part of the average.

i say turn up your LOD settings to where you can, make what you like how you like and go to town. eventually some will get better at it and others won't. that's sLife. we're all different sorts and stripes in it together whether we like it or not.

[ChinRey]

---

shaniqua Sahara wrote:

my two cents. most people who upload a lot of meshes have to take Lindens into account. it is often ten times more costly uploading meshes with lower LODs than not. less prim count, cheaper price = a must do for most.

---

No, it isn't. Good LoD models do not increase the upload cost.

 

---

shaniqua Sahara wrote:

while i'm here i'd like to also mention that most "content creators" are people trying to have fun making things, their not trying to be artists or have the know how to make everything as otptimal as it could be.

---

Yes, and as I said earlier in this thread, we have to distinguish between the people who create just for their own enjoyment and those who expect to get paid for their work here.

 

---

shaniqua Sahara wrote:

i say turn up your LOD settings to where you can, make what you like how you like and go to town. eventually some will get better at it and others won't. that's sLife. we're all different sorts and stripes in it together whether we like it or not.

---

I may be a blue eyed idealist but to me this is very much about making Second Life accessable to more people. Higher LoD setting means higher hardware requirements and not everybody who might enjoy Second Life are willing and able to pay for that.

Just one quick and random comparasion: I haven't tried either of them but judging by the stats a Nvidia GeForce GT 740 should be able to perform about the same at LoD setting 1 as a GeForce GTX 980 at LoD setting 4. The price difference is about 320 dollars. That is the actual cost we all have to pay for poorly optimized cotnent in Second Life (actually it's even more since the 980 also needs a bigger and more expensive power supply - not sure how much that adds to the price). A few extra cents in upload charges is nothing by comparasion.

[Medhue Simoni]

I just want to mention to everyone that Troy Linden was at the last Bento meeting, and brought up the topic of best practices. It seems the Lab is thinking about the topic and how to better cover it. Troy mentioned possibly doing some videos around the topic. I've suggested that LL have a few of us in videos talking about specific creation topics. So, kind of like this forum thread in a video, but maybe not as detailed. I'm bringing it up here to see what you all think, and who might be willing to be involved in such things. I'm not pointing any fingers, cough Drongle and ChinRey, or any others, but it would be nice to get many perspectives. Contact Troy@lindenlab.com if you have any thoughts on this, or want to be involved.

[IvanBenjammin]

Why does that give me the impression that the Lindens are as in the dark as we are? Community engagement is always a positive thing, as is information about best practices, but their silence on most things mesh makes me feel that they don't understand their own system, and that's disheartening.

Maybe I'm just tired after wrestling with the uploader for an entire day (I hate you so much, physics...).

[ChinRey]

---

IvanBenjammin wrote:

but their silence on most things mesh makes me feel that they don't understand their own system, and that's disheartening.

---

Oh yes, Oz has actually more or less confirmed that. But to be fair, we shouldn't really blame the current SL team for the sins of the past. Linden Lab's development work is far better organized and much better focused than ever before. (That's why I suggested a time machine earlier in this thread. Problems should always be handled by their roots and in this case we need one of those for that. )

The Lindens who developed SL mesh didn't document what they did properly neither internally nor for us users. Key people in that project don't work here anymore and even if they did, they probably wouldn't remember in detail all the cool (presumably) and unusual (definitely) shortcuts they took more than five years ago. That's the situation and we just have to deal with it the best we can.

 

---

IvanBenjammin wrote:

Maybe I'm just tired after wrestling with the uploader for an entire day (I hate you so much, physics...).

---

Oh, the physics. That's a different can of worms.

This probably isn' very useful :

http://anarchy.cn/manual/12/HavokSdk_ProgrammersManual/bk03.html

 

LL did actually publish a simplified end user's manual for Havok. It is a pdf file somewhere in the wiki (Aquila, do you remember where?) and if I remember correctly, it seems to contradict Havok's own manual in at least one crucial detail. Beq once suggested to me that SL is using a simplified rather than a full version of Havok, not sure if that's the case.

[arton Rotaru]

ArtistDoc.pdf

[ChinRey]

---

arton Rotaru wrote:

ArtistDoc.pdf

---

Wow, thank you Arton! That's actually not the document I had in mind. Somebody (I think it was Aquila) once showed me a pdf file with an introduction to Havok written by LL. Unfortunately the computer I had a copy of it on is long dead and I don't have the URL either. Among other things, I seem to remember it said that a pyramid was the second most efficient and that's not a Havok shape at all.

Anyway, a brief look at these two docs suggests that SL isn't utilizing Havok very well, at least not for static objects. Paragraph 1.12.2.5 in the ArtistDoc is perhaps the clearest:

• The sphere and the capsule are the two most efficient shapes - we do not have access to either at all
• A cube is more efficient than a triangle yet we can often have farily complex unanalyzed physics with dozens of triangles and still get a lower physics weight than a two cube analyzed physics shape
• A convex hull (other than a cube) is the second most expensive shape yet we can have quite complex hulls as part of an analyzed physics with little or no increase in physics weight.
• The weight of a physics model made from a single triangle is 0.200, a cube is 0.360 but according to the documentation, the cube is the lightest
• The physics weight of a prim cube is 0.060, a mesh cube 0.360
• The physics weight of a prim cylinder is lower than that of a mesh triangle
• The documentation suggests we should minimize the number of triangles but we can often reduce physics weight by adding triangles in strategic places (even when those added triangles don't seem to help define any of the lighter Havok shapes)
• I'm not sure if Havok treats the physics of a sculpt as 36 triangles or a single 14 sides convex hull (the calculated physics weight suggests triangles) but in either case it seems to be an unneccessarily complex shape
• I can't find any explanation why size matters to triangle physics
• Nor can I find any explanation why long and narrow triangles are such a bad thing...
• or why some twisted prim shapes end up with those astronomical physics weight figures

It seems the mesh uploader only uses two shapes, the triangle and the convex hull. So a sphere is represented by a list of triangles or a very complex convex hull and a cube is defined as a convex hull even though exactly the same shape can bne handled better when defined as a cube. That's clearly not the best way to do it.

[ChinRey]

---

Medhue Simoni wrote:

Contact Troy@lindenlab.com if you have any thoughts on this, or want to be involved.

---

Want to is one thing. Question is if I have the time. I'll think about it.

[Drongle McMahon]

The sphere and the capsule are the two most efficient shapes - we do not have access to either at all

True for uploaded mesh, but these havok primitives do get used elsewhere, if I remember correctly. I think the avatar collision shape uses a capsule. Also, the primitives are used for the physics shape of legacy prims, spheres, cylinders and boxes, as long as they are not distorted and scaled only so that they are still the primitive shape. The primitives have a constant physics weight of 0.1. That means you can make very cheap physics by using only linked undistorted prims.

You can see the switch from primitive to triangle-based physics in the physics shape view. If you make sets of ten linked objects, you can see the differences in physics weight using the More Info link. These don't get used as they are in the LI though. Here are some examples, all a .05x0.5 cube, Prim/CH physics weights for ten linked....

Plain cube 1.0/1.0; Hollow 50% 27.0/3.6; Twist 180 32.9/6.8; taper 0.1,0 3.6/3.6

The Blender physics system includes all the havok physics primitives, but I don't think the exporter exports them. Unfortunately, the mesh uploader can't recognise the perfect havok primitives if you put the in you mesh. So you can't take advantage of them in uploaded physics shapes. Collada actually has capsules, spheres, cylinders and boxes in its physics section, as does Blender, which would provide possibility of using them, but I don't think the Blender Collada exported knows about them, and neither does the SL uploader.

 ETA: There's another interesting thing that happens when you increase the size of the twisted cube. Up to 5x5x5, it's behaviour is as expected: the CH weight stays at 0.7, while th Prim weight decreases to 0.5, from 3.3 at 0.5x0.5x0.5. Then the complexity of the underlying geometry increases, affecting both weights, So a 10x10x10 version has CH weight of 1.3 and Prim weight of 2.1.

 

[Drongle McMahon]

...yet we can have quite complex hulls as part of an analyzed physics with little or no increase in physics weight.

Are you sure you aren't thinking of the physics weight the uploader displays, which is the default Convex Hull for the whole mesh. If you have an "Analyzed" physics shape, this will be the single complex hull containing of the whole collection of hull generated. It's weight will depend on the number of vertices, and thus on the complexity only of the outer surfaces of the collection. The phsyics weight of the analsis result will only be applied when you switch it to 2Prim" inworld.

The weight of a physics model made from a single triangle is 0.200

Yes, I never tried a single triangle before. Very odd. The 0.2 is the (size-invariant) default CH weight, the same whether you analyze or not. Switching to Prim, the triangle-based weight is 0.5, strangely not varying with size, while the analyzed weight stays at 0.2. However, there is another very odd thing that has to be called a bug. The default CH are not where they shoud be. The visible mesh is in the middle of the bounding box in the direction perpendicular to the flat plane, and the phsyics shape view shows the physics there too. But it isn't. If you reveal the actual physics shapes by making them static pathfinding obstacles, then rebake the region, you can see the actial phsyics, as shown in the red triangles. The left pair is the default CH setting, while the right is the, correct, Prim setting. Both these are analyzed, but the behaviour is the same for triangle-based shapes. The nearer one is a triangle in the YZ plane, while the further away is a triangle in the XY plane. If you try walking over/through them, you see that the red triangles are indeed the actual physics shapes.

Ugh!

 

[Drongle McMahon]

 

• The physics weight of a prim cube is 0.060, a mesh cube 0.360
• The physics weight of a prim cylinder is lower than that of a mesh triangle

Because these are using the havok primitives - apply some torture to the prims and see what happens to the weights.

I'm not sure if Havok treats the physics of a sculpt as 36 triangles or a single 14 sides convex hull (the calculated physics weight suggests triangles) but in either case it seems to be an unneccessarily complex shape

The physics shape of all sculpts is the same - the convex hull of a torus with equal major and minor radii, fitted into the bounding box. The flat ends are in the YZ plane. Here is a picture. Two each of a prim torus, at the back, and a spiral stairs sculpty, at the front, all 2x2x2m. The ones to the right have been made into static obstacles to reveal the phsyics in pathfinding view. These are the Prim type shapes, but I suspect the sculpty is really always convex hull, because its physics weight (1.8) doesn't change with size. It is actually the low LOD of the torus, which has 162 triangles (9x9x2). It's a bit odd because the two ends are different. One has the flat faces you can see, while at the other they are angled. Consequently, the diameter of the flat face of the convex hull is different at either end!



 

 

[Drongle McMahon]

 I can't find any explanation why size matters to triangle physics

Not sure about that, but if you think of your avatar, or a flying prim, colliding with a small triangulated surface, you will be near enough to many triangles to require collision calculations for each. If the same triangles are made much bigger by stretching the surface, so you only get near one at a time, then there are that many less calculations to do.

Nor can I find any explanation why long and narrow triangles are such a bad thing...

No idea. Probably something to do with the details of how the collision detection calculations work.

or why some twisted prim shapes end up with those astronomical physics weight figures

That is certainly a bug. A jira on it was accepted, but then resolved as "Trivial" and "Unactionable" because changes to the calculations could affect existing content (also considered. I don't know whether the bug is in the Havok code or the SL code (on the server). If it's the Havok code, there must be a risk that weights could change if/;when a library update is adopted.

 

[arton Rotaru]

---

Drongle McMahon wrote:

True for uploaded mesh, but these havok primitives do get used elsewhere, if I remember correctly. I think the avatar collision shape uses a capsule.

---

Objects declared as pathfinding characters will use the capsule shape as well. :matte-motes-smile:

Haven't read your posts yet, will do later tonight.

[IvanBenjammin]

---

ChinRey wrote:

---

IvanBenjammin wrote:

but their silence on most things mesh makes me feel that they don't understand their own system, and that's disheartening.

---

Oh yes, Oz has actually more or less confirmed that. But to be fair, we shouldn't really blame the current SL team for the sins of the past. Linden Lab's development work is far better organized and much better focused than ever before. (That's why I suggested a time machine earlier in this thread. Problems should always be handled by their roots and in this case we need one of those for that.

)

The Lindens who developed SL mesh didn't document what they did properly neither internally nor for us users. Key people in that project don't work here anymore and even if they did, they probably wouldn't remember in detail all the cool (presumably) and unusual (definitely) shortcuts they took more than five years ago. That's the situation and we just have to deal with it the best we can.

 

---

IvanBenjammin wrote:

Maybe I'm just tired after wrestling with the uploader for an entire day (I hate you so much, physics...).

---

Oh, the physics. That's a different can of worms.

This probably isn' very useful

:

http://anarchy.cn/manual/12/HavokSdk_ProgrammersManual/bk03.html

 

LL did actually publish a simplified end user's manual for Havok. It is a pdf file somewhere in the wiki (Aquila, do you remember where?) and if I remember correctly, it seems to contradict Havok's own manual in at least one crucial detail. Beq once suggested to me that SL is using a simplified rather than a full version of Havok, not sure if that's the case.

---

Huh. Well, that explains a lot. I don't blame anyone, its just frustrating to not have clear answers on certain questions.

Thanks for the link. I think I understand how the physics works for the most part. My issue with it is that its just not consistent or particularly predictable when you're working with a certain level of complexity. But you're right - we just have to deal with it.

[ChinRey]

---

Drongle McMahon wrote:

or why some twisted prim shapes end up with those astronomical physics weight figures

That is certainly a bug.

A jira on it

was accepted, but then resolved as "Trivial"

...

---

Hmmmm...

I'm sure we all know that are some people who always get hung up on tiny details and fail to see the big picture... and I wouldn't be entirely surprised if some of them might ask how a bug that has caused inexperienced builders more headache and gray hairs than anything else in SL and also is the reason why we have to keep this awkward double LI accounting system could be described as "trivial". But then again, some people just never get it.

 

---

Drongle McMahon wrote:

 

I'm not sure if Havok treats the physics of a sculpt as 36 triangles or a single 14 sides convex hull (the calculated physics weight suggests triangles)

...

It is actually the low LOD of the torus, which has 162 triangles (9x9x2). It's a bit odd because the two ends are different. One has the flat faces you can see, while at the other they are angled.

---

Woops, sorry I got the poly count wrong. But you gave the answer, with one side angled inwards it isn't a convex hull at all so it has to be handled as a triangle list. Makes you wonder: since the goal obviously was to maximize the sculpt's physics weight, why didn't they use a full resolution torus? or - even better - a twisted one?

Just like Arton I need a bit of time to reply to everything you posted here, Drongle. It was quite a load of info!

(Edit: about sculpt physics, before I re-read Drongle's post I completely forgot the fact that the physics weight is independent of size. But the physics shape can't possibly be a single convex hull since it isn't actually convex and even though I have very little, if any, respect left for LL's original sculpt/mesh software developer team at this stage, I find it very hard to believe they made it from multiple hulls.)

[Drongle McMahon]

with one side angled inwards it isn't a convex hull

I guess I wasn't clear enough. The sculpty physics shape is the convex hull of the low LOD torus, not the torus itself. Here is another picture. Torus on left, sculpty on right, top ones rotated 180 degrees, so that you can seeboth ends. So the top left is what I meant by angled instead of flat. Both ends of the sculty have flat ends because they are the convex hulls of the shapes to their left. As you can see, the diameters of the flat faces (nonagons) is different at each end. That's all an inevitable consequence of having nine segments.*



Concerning the astronomical physics weights - I suppose it's just possible that whatever causes the weight calculation to be so high might actually also make a huge amount of work for the physics engine. In that case, it would be better it was left until the cauise was removed by updating the havok engine. It might be possible to determine this by looking at the effect on the region phsyics time after setting up collisions of similar objects with and without the excessive weights.

*ETA That was wrong! In fact it depends on which axis you spin the minor circle in. If it's perpendicular to one edge, then you get a symetrical torus with the same structure at each end. If it's at 90 degrees to that, you get the SL version, with one flat annular end face. Same thing if you consider the axis fixed. Then it depends how you arient the minor circle before spinning it.