Good mesh objects with proper low LOD?

[animats]

I'm over at the Summer Full Perm Fair, looking at objects at various levels of detail. I have yet to find one single mesh object that looks even halfway reasonable at lowest LOD.

The reddish thing on the right is supposed to look like the yellow lounger on the left, but in red.

All this object needed was two triangles which covered the same area as the original. But no. The uploader's triangle decimator is too dumb to do that, and the user didn't do anything manually.

Almost everything here has a low-LOD model which is just what you get from the uploader's triangle decimator. I've seen one object, a big lawn swing, where someone seems to have created a low-LOD model by some means other than letting the uploader do its thing. Even there, most of the parts disappear. Almost always, the low-LOD model covers much less area than the real model. That looks awful.

Yes, I realize that the full perm show is where you dump stuff that's not selling well. But I've been to other shows, and it's about the same. Find me a show or store in SL where at least a quarter of the mesh has a halfway decent lowest-LOD model. If you can.

Doing low-LOD models by hand is just not happening.

 

 

[Klytyna]

2 hours ago, animats said:

Doing low-LOD models by hand is just not happening.

Yes, we know...

We've known for years...

It's the amateur Blunder 3D users who just crank out a hi poly mesh, stick it in the uploader, and hope for the best.

But that doesn't mean that we should encourage a switch to a system where Microbloat rips the IP of every mesh processed AND fubars the LoDs with iffy decimation routines.

Pushing for BAD automation instead of teaching GOOD practice and ACTUAL skills, is NOT the answer, as many people who are 3D modelers, have already told you.

...

The crappy auto-lod uploader you complain about so much is EXACTLY what happens when you offer "let the machine do the job badly rather than you learning to do it right" options as a default.

So the new "bad auto mesh lodders" are slightly better than the old ones, big deal, they still suck.

So called "AAA Title UE 4" games use them, but thats because UE 4 games are "low cost short dev time fill in the blanks in an off the self kit" projects, and hiring some hack modeler and running stuff through an auto-lod, is CHEAPER than doing it properly.

Moving on...

 

[Fionalein]

2 hours ago, animats said:

Yes, I realize that the full perm show is where you dump stuff that's not selling well.

Wasn't that the job of gachas?

[animats]

9 hours ago, Klytyna said:

So called "AAA Title UE 4" games use them, but thats because UE 4 games are "low cost short dev time fill in the blanks in an off the self kit" projects, and hiring some hack modeler and running stuff through an auto-lod, is CHEAPER than doing it properly.

Huh? Please engage brain before putting mouth in gear.

[OptimoMaximo]

12 hours ago, animats said:

Doing low-LOD models by hand is just not happening.

The problem in place as it currently stands, is the costs calculation involving the low LoD triangle count. When the cost skyrockets for the low LoD in any case involving more than, say, 16 triangles, having an automated LoD creator won't serve any purpose. First and foremost, the uploader decimator should line up with the general standards used for LoDs: 50% of the previous LoD; currently it is way harsher, along with the brutality it does its reduction. Re-formulating costs lining up with a 50% reduction base would definitely encourage better LoDs, even if automated. Impostors are a good option for certain types of content, but it certainly is a no go for avatar uploads (or any organic model, even worse if skinned). The main problem sits in the weight mapping: an impostor will never have a sufficient number of vertices to accommodate all the skin data contained in the higher LoDs also respecting the max 4 joints influence per vertex at the same time, making it literally explode in a mess of vertex spikes at render time.

Therefore, as long as the current system is in place, making low LoD models is just not happening as much as it won't happen, unless and until the costs calculations and the GLOD thing stop claiming a ridiculously low number of vertices on the 2 low models.

58 minutes ago, animats said:

10 hours ago, Klytyna said:

So called "AAA Title UE 4" games use them, but thats because UE 4 games are "low cost short dev time fill in the blanks in an off the self kit" projects, and hiring some hack modeler and running stuff through an auto-lod, is CHEAPER than doing it properly.

Huh? Please engage brain before putting mouth in gear.

Please, it's not a matter of engaging brains. You often compare tools for different softwares/engines that have nothing, NOTHING to do with SL and its architecture. Before you try again to convince all of us about the need of a new automated LoD creator, take a look at how meshes get stored and the rules that govern that routine. Then learn to model something complex like an avatar, skin weight it and make matching skinned LoDs for it. Those models need to comply to a couple of rules: same number of joints being used (weight maps) and max 4 influences per vertex on each single LoD. As soon as you try uploading mismatching weight mapped meshes, everything blows up and the same goes when reducing vertex number too harshly: there's no room for the same number of joints if the max 4 influences rule has to be respected, and to get the same number of joints the max 4 influences per vertex rule is extremely hard to achieve. All this to try and comply to what the uploader expects the reduction to be performed (which i believe is 1/4th of the previous LoD, if not a lot more when the high LoD is quite highpoly). Performing tests on cubes or models that are just a bit more than cubes doesn't deliver any valuable knowledge or case proof, making impostors and the likes for such models doesn't require rocket science. That's why the low-LoD problem can't be fixed changing algorithms, but rather changing the threshold for a reasonably degrading model at a reasonable cost (LI or render weight)

[Chic Aeon]

There is STILL the issue of the second lowest LOD though which some (many - sigh) creators are zeroing out by habit. There are times when that makes sense as you really don't need to see a large building two sims away (at least not often) but in general that is just as much of a problem as the lowest LOD issue. 

Again, as I always say -- TESTING is the key. If you have a small item with the lowest LOD zeroed out and can still see it from half a sim away at LOD2 -- that's good enough for me. We all make our choices of course.

 

 

[ChinRey]

On 10.8.2018 at 9:03 PM, Chic Aeon said:

There are times when that makes sense as you really don't need to see a large building two sims away (at least not often) but in general that is just as much of a problem as the lowest LOD issue.

No, there arenn't.

The LoD calculation takes the default 128 m draw distance into account and simply ignores any LoD models that are only supposed to be used beyond that distance. When people try to reduce land impact by reducing the lower LoD models on large objects, it's out of sheer ignorance.

As for actual render cost, if people choose to increase their draw distance beyond the default (which I often do myself), it's their responsibility to ensure their computers can handle it.

Here is a table of the approximate sizes where one of the LoD models no longer adds to the LI:

LoD Level	nx0x0 m	nxnxn m
Lowest	11x0x0 m	6.5x6.5x6.5 m
Low	22x0x0 m	13x13x13 m
Mid	88x0x0 m	52x52x52 m

Edit: I should add that a model's significance to the land impact starts to decrease long before it reaches the no-significance-at-all point. For example, the lowest LoD model for a 4x4x4m size object will add very little to the land impact but if it's only 0.1x0.1x0.1 m, the lowest LoD is practically the only one that matters for LI. The "old established rule" that the lowest LoD model is the one that is most important for LI is if not a myth, at least a truth with modifications. How much each LoD model matters to the land impact, depends on the object's size.

In addition to that, there is also a limit to how much you can simplify before it doesn't make sense to go further (at least not when it comes to LI). That limit varies a bit but generally you won't save any land impact by reducing a model down below ten triangles. If you know what you're doing, you can sometimes get away with 20 or more triangles for a model and still achieve the lowest possible LI.

Edit 2:

Corrected the numebrs in the table. See explanation below.

Edited August 12, 2018 by ChinRey

[OptimoMaximo]

12 hours ago, ChinRey said:

Here is a table of the approximate sizes where one of the LoD models no longer adds to the LI:

indeed, this is where no-level-ground comes into play. This table clearly shows that sizes like a human avatar can NOT fall within these ranges. Granted, a huge minotaur or a giant dragon could benefit from it, but let's be be honest: the average size of a rigged item can't take advantage of these measures. That's why poly count should be more relevant than size, and therefore the cost calculation is currently biased towards buildings rather than an actual rendering/land allotment cost.

[Coffee Pancake]

On 10/08/2018 at 3:50 AM, Klytyna said:

It's the amateur Blunder 3D users who just crank out a hi poly mesh, stick it in the uploader, and hope for the best.

No, it's the "I got this mesh from some place on the inter-tubes, played with in blender for 4 seconds and then stuffed it into SL to sell."

On 10/08/2018 at 3:50 AM, Klytyna said:

But that doesn't mean that we should encourage a switch to a system where Microbloat rips the IP of every mesh processed AND fubars the LoDs with iffy decimation routines. .............. .............. ............ ......... 

You've lost me here .. fewer werds more words?

On 10/08/2018 at 3:50 AM, Klytyna said:

So called "AAA Title UE 4" games use them, but thats because UE 4 games are "low cost short dev time fill in the blanks in an off the self kit" projects, and hiring some hack modeler and running stuff through an auto-lod, is CHEAPER than doing it properly.

Other auto decimators require some weighting input from the user so as to keep the model looking solid,.

[Chic Aeon]

15 hours ago, ChinRey said:

No, there arenn't.

The LoD calculation takes the default 128 m draw distance into account and simply ignores any LoD models that are only supposed to be used beyond that distance. When people try to reduce land impact by reducing the lower LoD models on large objects, it's out of sheer ignorance.

As for actual render cost, if people choose to increase their draw distance beyond the default (which I often do myself), it's their responsibility to ensure their computers can handle it.

Here is a table of the approximate sizes where one of the LoD models no longer adds to the LI:

LoD Level	nx0x0 m	nxnxn m
Lowest	8x0x0 m	5x5x5 m
Low	16x0x0 m	10x10x10 m
Mid	64x0x0 m	40x40x40 m

Edit: I should add that a model's significance to the land impact starts to decrease long before it reaches the no-significance-at-all point. For example, the lowest LoD model for a 4x4x4m size object will add very little to the land impact but if it's only 0.1x0.1x0.1 m, the lowest LoD is practically the only one that matters for LI. The "old established rule" that the lowest LoD model is the one that is most important for LI is if not a myth, at least a truth with modifications. How much each LoD model matters to the land impact, depends on the object's size.

In addition to that, there is also a limit to how much you can simplify before it doesn't make sense to go further (at least not when it comes to LI). That limit varies a bit but generally you won't save any land impact by reducing a model down below ten triangles. If you know what you're doing, you can sometimes get away with 20 or more triangles for a model and still achieve the lowest possible LI.

Just wanted to note that this has been discussed here before and many of the devs who work in the field apparently don't agree. I am not going to argue. Case in point was a very large and simple building where the lowest LODs were from 578 meters away.  That is what I was trying to point out. 

[arton Rotaru]

On 10.8.2018 at 7:09 AM, animats said:

Doing low-LOD models by hand is just not happening.

That's totally not true. It might be a minority of the creators, but there are certainly some who do proper LODs by hand. Speaking just for myself, all my mesh models have handmade LODs down to the lowest level.

[ChinRey]

2 hours ago, Chic Aeon said:

Just wanted to note that this has been discussed here before and many of the devs who work in the field apparently don't agree.

 

If so, it can only mean those "devs" have no idea whatsoever what they are talking about. This is not up to discussion, Chic, this is one of the very few parts of the whole SL mesh mess that is actually well documented and proven by now. Anybody who still doesn't know this and claims to be an expert is, lying,

The principle that is. I did get the distances a little bit wrong, I have to admit that.

Or rather, Linden Lab did. The original numbers in the the table were according to Linden Lab's official description how download weight is calculated which clearly states that the distances for a LoD model's weight calculation is "clamped to a 256m circle". Turns out it's actually more like 356 m. i suppose the programmer who wrote the download weight calculation code accidentally typed a "3" rather than a "2". Easy to do - those keys are close to each other on the keyboard after all. Oh well. I really ought to know better than to trust official Linden Lab documentation.

Anyway, typo in the code or not, the limit is certainly there, even though it's higher than what it was supposed to be.

Here are two uploads of a bar counter (it just happened to be the frst dae file I found on my hard disk), resized to 12 m length.

The lower one is uploaded with the full LoD model. At 12 m length, the download weight is 3.2 and the land impact 3:

The upper one is uploaded with the full LoD model for high, mid and low and with the lowest model zeroed out. At 12 m length, the download weight is 3.2 and the land impact 3:

 

Edited August 12, 2018 by ChinRey

[Klytyna]

9 hours ago, CoffeeDujour said:

You've lost me here ..

That's pretty easy to do in a technical discussion of 3D modeling and texturing it seems...

On 10 August 2018 at 8:50 AM, Klytyna said:

But that doesn't mean that we should encourage a switch to a system where Microbloat rips the IP of every mesh processed AND fubars the LoDs with iffy decimation routines.

The self  admitted NON-3D-Moddeler,  the Messiah Noob of Kama City, stated in a previous "Why don't we get hack devs from a UE4 based FPS game to rewrite SL" post that there's this brilliant auto LoD generator from the Microbloat Corporation, and it's sooooooo easy to use and better then the SL LoD system, and the fact that Microbloat KEEP copies of every mesh processed by the system for their own use, hardly matters at all, no really...

And the reality is... It's STILL a manky Auto-LoD butcher.

He even provided screenshots of some meshes he'd lod-butchered (not his own meshes obviously) with auto routines he'd found on the web.

He also boasted that one of his "found" Auto-LoD butchery apps, "preserved the edges of UV islands" which is pretty damn dumb, as UV islands are NOT the most important part of reducing a mesh without it looking like a twisted mess.

 

[ChinRey]

5 hours ago, Klytyna said:

the Messiah Noob of Kama City, stated in a previous "Why don't we get hack devs from a UE4 based FPS game to rewrite SL" post that there's this brilliant auto LoD generator from the Microbloat Corporation, and it's sooooooo easy to use and better then the SL LoD system, and the fact that Microbloat KEEP copies of every mesh processed by the system for their own use, hardly matters at all, no really...

 

And the reality is... It's STILL a manky Auto-LoD butcher.

I don't disagree with what you say there Klytyna (although you might have put it a bit nicer )

But you forget two things.

One is that a negative result is also a result. This doesn't work? Well, that means we've eliminated one solution and narrowed down the field. If you read the posts hare and comments elsewhere where mesh makers and wanna-be mesh makers meet, it's easy to see why this apparent option has to be brought into light and well and truly eliminated. It's only yesterday that somebody in another thread suggested that an automatic decimator would work well if it was a part of an in-world mesh building tool (as if that would have made any difference). That kind of flawed logic is so common among SL content creators, SL consumers and the Lindens, we need to spend time discussing it.

The other is that even a flawed idea may have some good points. And it's often a good idea to see how others do it even if we can't do it exactly the same way ourselves. There may be a lot to learn there, a lot of things that even they can't be ported directly, can be adapted.

---

Speaking of logic...

I wasn't going to say anything - hoping somebody else would spot it too. (I even considered a prize for the first one to get it.) But I'm feeling particularly impatient today.

Can anybody figure out what that typo in the code I mentioned in my previous post means to the land impact calculation and LoD butchery?

I'll give you one hint: It's really big.

Edited August 12, 2018 by ChinRey

[animats]

5 hours ago, ChinRey said:

One is that a negative result is also a result. This doesn't work? Well, that means we've eliminated one solution and narrowed down the field.

Yes. For a while, I was downloading academic mesh reduction code and trying it. Some does OK on clean geometry. Much of it blows up on flawed geometry. Some of it has trouble when many edges meet at one vertex, as with the end of a capsule shape. Edge angle based reduction tries too hard to follow fine detail. Quadric mesh reduction tries too hard to follow convexity.  Much of the work is for making good looking models that resemble the original in closeup, not for distant models.

Models for distant viewing could be done somewhat differently. Maybe something like quadric mesh reduction, but with the simplified mesh outside the original being weighted much less than being inside. Think of it as "filling in the dents". Like a convex hull, but not going that far. At distant range, you can't see small depth variations, so they can be reduced out. But you can see changes in the outline. An extreme mesh reducer for generating low-LOD models needs to make that distinction. That approach would probably work well for animal shapes.

Then there's deciding when to fill in a hole. Worst case is a spoked wheel, where the spokes are objects of the mesh. All that spoke detail has to go, preferably replaced by a flat impostor. The medium level of detail for a wheel should be a torus with a flat textured insert. You don't want to go all the way to one flat impostor for the entire wheel, or the wheel disappears on-edge. Convex hulling the wheel, then dent reducing the convex hull to a cylinder, then pasting an impostor on the result would work. But that's a special case. Something more general is needed. As a motorcycle builder I struggle with this. Motorcycles are open frames with lots of holes, difficult to reduce effectively.

Detecting a framed hole would help. If a hole is entirely surrounded by a solid, it's a good candidate to be filled in with an impostor face with an alpha channel. That would handle windows in buildings, too. Then you run dent reduction again, which merges wall, window frame, and window, and end up with entire walls becoming one flat face with a generated texture.

Somebody must have been down this road. Much work has been done on mesh reduction. These can't be new ideas. But I haven't found any references yet.

Useful paper: http://graphics.stanford.edu/courses/cs468-10-fall/LectureSlides/08_Simplification.pdf

[arton Rotaru]

15 hours ago, ChinRey said:

Or rather, Linden Lab did. The original numbers in the the table were according to Linden Lab's official description how download weight is calculated which clearly states that the distances for a LoD model's weight calculation is "clamped to a 256m circle". Turns out it's actually more like 356 m. i suppose the programmer who wrote the download weight calculation code accidentally typed a "3" rather than a "2". Easy to do - those keys are close to each other on the keyboard after all. Oh well. I really ought to know better than to trust official Linden Lab documentation.

I think the 256m circle is just a leftover from the very early days of the Mesh import development. The Calculation is based on a circle which encompasses a region of 256x256 meters. That is a radius of 181 meters. A circle with a diameter of 362 meters.

[ChinRey]

1 hour ago, arton Rotaru said:

I think the 256m circle is just a leftover from the very early days of the Mesh import development. The Calculation is based on a circle which encompasses a region of 256x256 meters. That is a radius of 181 meters. A circle with a diameter of 362 meters.

You think it was a deliberate change and it's the documentation that is wrong? Maybe but if they wanted to cover the area to cover a whole sim, the diameter should have been set to 289 m to correspond to the actual area of a region. Also, if it was deliberate it shouldn't have affected the render weight, which it does.

There is one way to find out, if anybody can check the uploader code in the viewer. If the "clamp" diameter is 356 m as I suspected, it's a bug in the software and what the documentation says, is what it was supposed to be. If it is 362 m, it's a deliberate change and the documentation is wrong.

But in either case I think it was a bad mistake. Here's an example why. This is a pile of rocks (in case somebody doesn't notice ):

Uploaded with 101 triangles in the lowest LoD model (the lowest GLOD can manage with anything even remotely resembling a decent model), the land impact is 7. If the clamp diameter had been 256 m as the documentation claims, it would have been 4 or 5 (not sure about the exact numnber 4.5 plus/minus 0.1 is all I can say).

Uploaded with a butchered lowest LoD model, the land impact is 2. If the clamp diameter had been 256 m as the documentation claims, it would have been 2.

So the effect of the change in clamp distance was to increase the land impact of meshes with good LoD but not meshes with butchered LoD models. Now that LL finally has started to recognise the LoD butchery problem, maybe they should take a look at this before they try the bandaid solution they've been talking about.

 

 

 

Edited August 12, 2018 by ChinRey

[arton Rotaru]

45 minutes ago, ChinRey said:

You think it was a deliberate change and it's the documentation that is wrong?

That's what I think, yep.

 

47 minutes ago, ChinRey said:

So the effect of the change in clamp distance was to increase the land impact of meshes with good LoD but not meshes with butchered LoD models. Now that LL finally has started to recognise the LoD butchery problem, maybe they should take a look at this before they try the bandaid solution they've been talking about.

At that time, the focus was to create some other accounting than just having "a prim". Which counts 1 no matter how hard, or easy it actually is. So having fewer triangles gives lower weights, was an understandable approach. There was not much (if at all) thinking about LOD butchering. Fewer triangles = less bytes = lower cost. What those triangles represent, or look like, or whatever, was none of LL's business. Remember, "Your World, Your Imagination". If such imagination is butchered LODs, that be it then.

Now that LL is working on Project ArcTan, which (I guess) will be a whole new calculation formula, rather than a bandaid solution, I think the chances are rather low that there will be inhertited bugs from the current formula.