Weird download impact calculations on mesh upload

[JackTheOtterFox]

All right, so I have discovered a behaviour I can't quite understand when uploading mesh models.
First off, I created two models for testing, one is basically a smaller version of the other, made with the same tools and workflow.
Here is what I get for trying to upload the small model:

Looks about right, 0.649 Download impact for 1501 Vertices, I can live with that. (I've turned down LODs for this example to make sure they don't influence the calculation)
Next off, here is the bigger version...

Woops, now that can't be right. I've gone up from 1501 Vertices to 7239, so the model increased in complexity by ~4.82 times.
The download impact however seems to have increased from 0.649 to 18.579, so by ~28.63 times (!).

I don't know the exact formular of how SL calculates this number, however this seems too extreme of a difference to be correct.
For another example, the source .dae file of the small model is 219.616 Bytes in size (measured from windows properties panel), the file of the big model is 1.053.387 Bytes, which is an increase of ~4.8 times, roughly matching the increase of vertices between the models. Since downloading a file is literally just pushing the bytes of the model over the network I can not understand this unreasonable increase in Download Impact, but then again this is my first upload where I actually pay attention to these numbers, so maybe I'm just missing something obvious here.

I hope someone can help me clear this up, thanks in advance for that!

Best regards
Jack

[ChinRey]

Here's your answer:

21 minutes ago, Toastfan123 said:

 one is basically a smaller version of the other, made with the same tools and workflow.

Download weight is based on the fie size of all four LoD models, each of them weighed towards the others based on how large an area it is supposed to be viewed across. When you increase the size, the high model will be given more significance since it wil be visible at a wider distance in-world.

[JackTheOtterFox]

8 hours ago, ChinRey said:

Here's your answer:

Download weight is based on the fie size of all four LoD models, each of them weighed towards the others based on how large an area it is supposed to be viewed across. When you increase the size, the high model will be given more significance since it wil be visible at a wider distance in-world.

All right, that kind of doesn't make much sense though, does it? I mean, it's not like the actual space the object takes up is in any way influencing the download impact on the server, thats impacting how the object is rendered by the individual viewers, at least I would think that...
Anyway, is there a formular of how to calculate the optimal size for the object so that it takes up the least amount of download impact? 18 LI is way too much for what the model is supposed to resemble, but I could easily split it up into multiple objects. (Even though at least the way I see it that would actually increase the stress on the server because there are multiple individual objects, but whatever :P)

[ChinRey]

37 minutes ago, Toastfan123 said:

All right, that kind of doesn't make much sense though, does it? I mean, it's not like the actual space the object takes up is in any way influencing the download impact on the server, thats impacting how the object is rendered by the individual viewers, at least I would think that...

I can't write a long explanation right now. I've injured an arm so I'm typing with only one hand and that's sooo slow.

Maybe @arton Rotaru or @Aquila Kytori can help?

 

37 minutes ago, Toastfan123 said:

Anyway, is there a formular of how to calculate the optimal size for the object so that it takes up the least amount of download impact?

There are dozens of ways to reduce land impact but the only way to learn them all, is to browse through all the old posts here. But three ways that seem espescially relevant here:

• When you split a mesh, keep the average download weight for the parts at c. 0.5
• Try to avoid combining large and small triangles in the same mesh
• Never, never, ever use LoD models generated by the uploader

Edited February 26, 2019 by ChinRey

[JackTheOtterFox]

20 minutes ago, ChinRey said:

I can't write a long explanation right now. I've injured an arm so I'm typing with only one hand. Maybe @arton Rotaru or @Aquila Kytori can help?

 

There are dozens of ways to reduce land impact but the only way to learn them all, is to browse through all the old posts here. But three ways that seem espescially relevant here:

• When you split a mesh, keep the average download weight for the parts at c. 0.5
• Try to avoid combining large and small triangles in the same mesh
• Never, never, ever use LoD models generated by the uploader

All right, I suppose I will experiment around with it a bit more, one last question though:
The uploader shows you a very specific compesition of the land impact, however when I inspect an element in world it always displays the land impact as an integer. Does that mean that it always caps the number? So for example if I had an object with 1.49 (or 1.99 depending on if it rounds or caps), it should show up as "1 Land Impact" in the game, right? And since 1 is the minium achivable LI value, shouldn't I always try to split a larger object into smaller objects that come as close to "2" as possible?

[ChinRey]

25 minutes ago, Toastfan123 said:

So for example if I had an object with 1.49 (or 1.99 depending on if it rounds or caps), it should show up as "1 Land Impact" in the game, right? And since 1 is the minium achivable LI value, shouldn't I always try to split a larger object into smaller objects that come as close to "2" as possible?

First the weights of all parts in the linkset is summed up, then the result is rounded off to the nearest integer. So:

• 1.499 becomes 1
• 1.500 becomes 2
• 1.900+0.599 becomes 2
• 1.901+0.599 becomes 3

And so on.

Pushing those decimals right to the limit is another (slightly dubious) way to shave off a little bit of LI.

Keep in mind that download weight is only one of the three weights that may determine the LI.

Edited February 26, 2019 by ChinRey

[JackTheOtterFox]

Thank you, and yes, I had that in mind. Speaking of the other two weights, I'm having a problem with the physics part of it as well.

First you can see the collission in-game, second you can see the collision plane I provided. It seems like the game just completely ignores my physics object and replaces it with it's own, even though it showed up correctly in the upload window. Any idea what could cause this?

[Kyrah Abattoir]

Make sure the collisions are set to "prim" and that you didn't do the whole analyze/simplify thing.

Edited February 26, 2019 by Kyrah Abattoir

[JackTheOtterFox]

The colisions are set to prim, and I did not to the analyze thing. It seems like it's still wrong though.
I'll also probably postpone this whole thing until I get access to the beta grid (just submitted a ticket), because I'm paying waaay too many upload fees for these failed attempts.

[ChinRey]

36 minutes ago, Toastfan123 said:

The colisions are set to prim, and I did not to the analyze thing. It seems like it's still wrong though.

Is your mesh 0.5 m or less tall? If it is, it will automatically and silentyl be switched to convex hull even if you set it to prim.

 

36 minutes ago, Toastfan123 said:

I'll also probably postpone this whole thing until I get access to the beta grid (just submitted a ticket), because I'm paying waaay too many upload fees for these failed attempts.

Oh yes! You definitely need the beta grid if you want to make good mesh without going bankrupt!

Edited February 26, 2019 by ChinRey

[JackTheOtterFox]

12 minutes ago, ChinRey said:

Is your mesh 0.5 m or less tall? If it is, it will automatically and silentyl be switched to convex hull even if you set it to prim.

Yes, it is, and I would really prefer not to change that fact because that would mean having to re-bake all textures once again...
Is there a way of disabling this? It's really stupid, especially because the game doesn't tell you about it (which in my case cost me actual money without even understanding why...)

 

[ChinRey]

48 minutes ago, Toastfan123 said:

It's really stupid, especially because the game doesn't tell you about it (which in my case cost me actual money without even understanding why...)

The mesh documentation leaves a bit to be desired, yes. But you have to keep in mind that Linden Lab doesn't have anybody who really understands the practical side og mesh making. They may be good programmers and developers but that doesn't necessarily mean they know how to use the software well. To use a music analogy, some of the best violins in the world were made by people who couldn't play Mary Had A Little Lamb in tune.

In this particular case it's a workaround for a genuine flaw in the physics engine though and since they didn't make that themselves, it's not really their fault.

A thorough explanation is way too much for me to write at the moment but the problem may solve itself when you split the mesh since covex hull may work well enough for each part separately.

 

48 minutes ago, Toastfan123 said:

Yes, it is, and I would really prefer not to change that fact because that would mean having to re-bake all textures once again...

Great to hear you are putting some effort into the texturing. You won't believe how many people just use Blender's "auto bakefail", ending up with horrendous AO and even worse UV.

Even so, are you sure you want to use baked textures for this at all? Compared to a low res repeating texture, there's a lot to loose both in performance and flexibility and little to gain in looks.

Here's one I made:

This uses a standard seamless 512x512 - it's a library texture even. Compared to a baked 1024x1024 this gives me twice the resolution with a quarter of the lag.

And it laso allows me to switch to any one of thosands of textures with just a few mouse clicks so it can fit any surrounding. Here's a mossy deep forest/jungle version. Another library texture and this one isn't even seamless:

Edited February 26, 2019 by ChinRey

[arton Rotaru]

51 minutes ago, Toastfan123 said:

Yes, it is, and I would really prefer not to change that fact because that would mean having to re-bake all textures once again...
Is there a way of disabling this? It's really stupid, especially because the game doesn't tell you about it (which in my case cost me actual money without even understanding why...)

Try the Analyze thing during upload.

@ChinRey I hope your injury isn't too bad. Get well soon!

[JackTheOtterFox]

4 minutes ago, ChinRey said:

Great to hear you are putting some effort into the texturing. You won't believe how many people just use Blender's "auto bakefail", ending up with horrendous AO and even worse UV.

Even so, are you sure you want to use baked textures for this at all?

Short answer: Yes, I'm sure.

Longer answer: I'm creating my textures using substance designer, I want to get more familiar both with the software as well as with the workflow of creating 3D objects, preferably for other platforms as well (Thinking about Sansar and Unity, possibily others).

What I did was that I created a set of 9 stones which are spread over the 8 allowed materials (the two small rocks use the same material because they are so small). Then I took each individual stone into SP and created a material for them. What I like more about it this way as opposed to just using tileable textures is that you have a lot more control over the appearance, you can add things like cracks and geometry dependant effects. It might be utter overkill for the overall simplicity of SL, but it helps me understand these processed tremendously, and I also really, enjoy it, which is why I'll stick to it for the time being.

[arton Rotaru]

4 hours ago, Toastfan123 said:

All right, that kind of doesn't make much sense though, does it? I mean, it's not like the actual space the object takes up is in any way influencing the download impact on the server,

The idea is that a larger object is rendered more often at it's higher LOD models, even at a distance, as a smaller one. Hence, the server has to send more data to the viewer than just the data for the lowest LOD of a smaller object in the same distance.

[JackTheOtterFox]

15 minutes ago, arton Rotaru said:

The idea is that a larger object is rendered more often at it's higher LOD models, even at a distance, as a smaller one. Hence, the server has to send more data to the viewer than just the data for the lowest LOD of a smaller object in the same distance.

Okay, I can kind of see where that is coming from, but the viewer still caches the model, so the server really only has to send it every once in a while and when they first join...

Even with that reasoning though, it feels like the increase in download impact is not justified, at least not to the extend it it is currently implemented.

[Kyrah Abattoir]

9 minutes ago, Toastfan123 said:

Okay, I can kind of see where that is coming from, but the viewer still caches the model, so the server really only has to send it every once in a while and when they first join...

Even with that reasoning though, it feels like the increase in download impact is not justified, at least not to the extend it it is currently implemented.

The clientside rendering load is also a concern.

Edited February 26, 2019 by Kyrah Abattoir

[ChinRey]

3 minutes ago, Toastfan123 said:

..

but it helps me understand these processed tremendously, and I also really, enjoy it

Those are very good reasons when you build for your own pleasure.

 

10 minutes ago, Toastfan123 said:

..

for the overall simplicity of SL

A typical SL scene is actually far more complex than what you're likely to ever see elsewhere. That's why people keep complaining about lag and even leave because of it. But it's a different kind of complexity. A typical game scene consists of a few carefully selected feautre objects on a very simple low lag background. An SL scene is typically made from lots and lots and lots of objects. Each take a little bit of resources and unless you're careful, you can run out of computing powers fast.

 

4 minutes ago, Toastfan123 said:

Even with that reasoning though, it feels like the increase in download impact is not justified, at least not to the extend it it is currently implemented.

It does seem a bit exaggerated, yes, and it's one of the reasons why we have so many neshes with poor LoD in SL. Since the LoD models tend to be so important for LI, it's very tempting to unskilled mesh makers who don't know how to optimize to compenaste by butchering the LoD models.

LLis working on a new LI calculation system at the moment, and from what I understand, this is one of the problems they are trying to fix.

 

10 minutes ago, arton Rotaru said:

 

@ChinRey I hope your injury isn't too bad. Get well soon!

Thank you.

 

[JackTheOtterFox]

1 hour ago, Kyrah Abattoir said:

The clientside rendering load is also a concern.

Yes, however it shouldn't be a concern to the server, and we are talking about the download impact here.

[JackTheOtterFox]

3 hours ago, ChinRey said:

It does seem a bit exaggerated, yes, and it's one of the reasons why we have so many neshes with poor LoD in SL. Since the LoD models tend to be so important for LI, it's very tempting to unskilled mesh makers who don't know how to optimize to compenaste by butchering the LoD models.

LLis working on a new LI calculation system at the moment, and from what I understand, this is one of the problems they are trying to fix.

That sounds great, hopefully they will be able to come up with a decent solution. I find it pretty interesting that there is still so much work put into this game from LL's side.

[ChinRey]

25 minutes ago, Toastfan123 said:

I find it pretty interesting that there is still so much work put into this game from LL's side.

A brief history of Second Life development:

• c. 2002-2007: Boldly venture into places where no avatar had ever gone (including quite a few places where no avatar should ever go).
• 2008-2013 (The Six Dark Years): No coherent strategy, quick and dirty patches and hastily launched new shinies intended to maximize short term profit.
• 2014-c. 2016: Maintenance and damage control to keep SL running until Sansar was ready to take over.
• c. 2016 and onwards (after it became obvious SL'ers weren't going to flock over to Sansar): Maintenance and damage control continue. Also some development of new shinies to keep old jaded users' interest (generally more solid work this time) but still no overall strategy or attempt to upgrade the software as a whole.

 

25 minutes ago, Toastfan123 said:

That sounds great, hopefully they will be able to come up with a decent solution.

I hope so too and I know the developers are doing their best. But this is actually very difficult. We'll see.

Edited February 26, 2019 by ChinRey

[JackTheOtterFox]

All right, so, a few hours later.
I made the segment even smaller (I was slightly over 1.5 on the upload impact before), so that's good now.
I made the mesh a bit higher artificially (I added a single triangle a few centimeters below the mesh to make it's bounding box higher so that the physics mesh actually gets used, which it does, so that works).
I updated my LOD object and want to finally upload the first finalized piece (Still not on the beta grid, but whatever).
I've run into a problem AGAIN:

Screenshot of the mesh preview in the uploader window.
The in blender perfectly aligned collision pane is just, well, not aligned correctly.
I've double checked that all objects (Mesh, LOD Mesh and collision pane) have the same origin point and applied transformation in blender, and as I said, there they line up perfectly.

I'm actually starting to slowly get frustrated, I can understand that there are a few things you need to learn before you can upload things to SL, but the problems I'm encountering for the most part just seem so unnecessary and honestly partially kind of stupid that my initial inspiration and fun has kind of shifted to annoyance and sadness.

Anyway, has anyone encountered something like this before? If so, is there an obvious reason I'm once again missing here?

Thanks in advance, and sorry for just dragging this thread on and on, but I feel like I at least should be close by now >.<

[Chic Aeon]

Just read through quickly but looking at your OP, is there a reason why you have zeroed out ALL THREE LOWER LODs? 

Have you looked at your build in anything other than LOD4 to test what people see?

So you know in case you don't. LOD2 is standard for Firestorm viewer (most folks I believe) and 1.25 for the Linden viewer. A whole lot of folks do not use LOD4 as it really slows down computers (even hefty ones). 

So if you plan on anyone else seeing your path (or have hopes for that anyway) you might want to take a look.

And I heartily agree that the beta grid is your mesh making friend. 

[JackTheOtterFox]

3 minutes ago, Chic Aeon said:

Just read through quickly but looking at your OP, is there a reason why you have zeroed out ALL THREE LOWER LODs? 

Have you looked at your build in anything other than LOD4 to test what people see?

So you know in case you don't. LOD2 is standard for Firestorm viewer (most folks I believe) and 1.25 for the Linden viewer. A whole lot of folks do not use LOD4 as it really slows down computers (even hefty ones). 

So if you plan on anyone else seeing your path (or have hopes for that anyway) you might want to take a look.

And I heartily agree that the beta grid is your mesh making friend. 

I have a model for the second LOD, but it's actually literally already the lowest I can go in vertex count while still maintaining some level of shape, I kind of don't care. It's a path, if you are further away it should be fine not even rendering at all (which for me just starts to de-render after a very considerable distance, so I think that's fine.)

I highly doubt that people disable the highest level of detail, because it's the original mesh. LOD is a performance method, it's supposed to reduce complexity if the object is far away from the camera, in the most optimal case you wouldn't even see the transision. Nothing other than the highest quality mesh is supposed to be viewed from close up, so if someone actually disables the high quality mesh, well, without being rude, that's not my problem. That's not how LOD is supposed to be used, and I can't adjust for every misuse of technology ^^

(I btw stated in the original post that I nulled out the LODs for showcase purpouses, because I didn't want them weighing into the calculations I was presenting)

[Ana Stubbs]

Just now, Toastfan123 said:

I have a model for the second LOD, but it's actually literally already the lowest I can go in vertex count while still maintaining some level of shape, I kind of don't care. It's a path, if you are further away it should be fine not even rendering at all (which for me just starts to de-render after a very considerable distance, so I think that's fine.)

I highly doubt that people disable the highest level of detail, because it's the original mesh. LOD is a performance method, it's supposed to reduce complexity if the object is far away from the camera, in the most optimal case you wouldn't even see the transision. Nothing other than the highest quality mesh is supposed to be viewed from close up, so if someone actually disables the high quality mesh, well, without being rude, that's not my problem. That's not how LOD is supposed to be used, and I can't adjust for every misuse of technology ^^

(I btw stated in the original post that I nulled out the LODs for showcase purpouses, because I didn't want them weighing into the calculations I was presenting)

She (er, I hope? i never asked...) 's talking about the LOD Factor viewer setting, not the individual LOD levels.