objects degrading over distance

[ChinRey]

---

Drongle McMahon wrote:

Instead, I am pretty sure you mean it introduces the resource consumption effects that would have caused increased LI and render cost if the calculation didn't ignore it. Just trying to resolve this slight ambiguity.

---

Yes, of course. Sorry if that wasn't clear.

 

---

Drongle McMahon wrote:

*ETA Yes CTS-631, but that's an old mesh beta one, in discontinued jira section, June 2011. I don't suppose many will be able to see it, and I can't see a way to change it's visibility.

---

Can you tell us why it was rejected? Didn't they see the need for it or was it too difficult to implement?

[Drongle McMahon]

Quite reasonably, there is never enough time to implement all possible nice features, and bugs have to have much higher priority. Then, once the system is released, there has to be overwhelming benefit of any changes that will affect existing content. It's just the necessary and inevitable winnowing process, I guess. I never moved it into the new jira, which means it's not possible to consder now. I suppose someone else do a ne equivalent one. I wouldn't be optimistic though. In some ways, it would just make things even more complicated!

[ChinRey]

---

Drongle McMahon wrote:

and bugs have to have much higher priority.

---

Of course! It wouldn't really be SL without the bugs, would it?

[Codex Alpha]

Thanks for the info and reminders. I will go over your replies in depth more when I get the chance.

I do prefer manual decimation over automated, because it is easy if I keep my meshes clean from the beginning - decimation is clean from that. Sometimes I'm not in the mood to work on hi-poly to low its the boring part of design, but I get there eventually

Yes, the 3 names including Drongle, Arton and the other were very helpful in this department, we dont hear enough from them really. I wish they'd have a blog because then my skills might develop faster with some oversight and easier reference than digging out old replies on a forum.

[Penny Patton]

---

ChinRey wrote:

Contrary to what Immy said early in this thread, LoD models aren't that common in 3D design and when they are used, LoD factor is set individually for each object.

---

I'm not sure what you mean. LOD is commonly used in videogames and you have to think of SL as a videogame with regards to 3D design or you're going to create a lot of problems for yourself and everyone else.

[ChinRey]

---

Penny Patton wrote:

I'm not sure what you mean. LOD is commonly used in videogames and you have to think of SL as a videogame with regards to 3D design or you're going to create a lot of problems for yourself and everyone else.

---

We may be discussing whether a glass is half full or half empty here.

Except, keep in mind that I was talking about fixed, pre-made LoD models, not LoD in general. I think it's quite telling that wikipedia's article on Level of detail doesn't even mention LoD models but only talks about various LoD algorithms. Of course, LoD models isn't always used in SL either. It's just for  meshes; prims and sculpts use very basic decimation algorithms instead.

There's a quite interesting article at the Valve Developer wiki for those who want to learn more about how LoD models may be used outside Second Life.

[Penny Patton]

---

ChinRey wrote:

Except, keep in mind that I was talking about fixed, pre-made LoD models, not LoD in general.

---

Sure, ok, fair enough. If we're talking about how LL screwed the pooch with LoD then I'm inclined to agree.

 

If we're talking about how best to approach the system we have, which isn't great but isn't as bad as people who don't utilize LoD models make it out to be, content creators should be creating reasonable LoD models so that their content looks better over greater distances, without also carrying unreasonable Land Impact costs.

 

 (Also people shouldn't be double scaling content which effectively halves all distances in SL.)

[Imnotgoing Sideways]

---

ChinRey wrote:

Contrary to what Immy said early in this thread, LoD models aren't that common in 3D design and when they are used, LoD factor is set individually for each object.

---

Contrary to what?  I'd risk to say it's non-existent in 3D design.  The closest thing we get to LOD in Blender is multires modifiers and it's all but missing from Solidworks and Fusion360.

On the other hand, LoD modelling is an absolute unavoidable necessity in 3D rendering.  (>_<)

 But, in rendering environments like games, it's an absolute necessity.  There's often no predicting where a viewer's/player's camera will be at any moment.  The core method to control visuals to avoid overwhelming a system's resources in a dynamic environment is LoD reduction.  Without it, 3D rendered gaming simply wouldn't exist.

LoD falloff still tends to be simplified by single measurements.  They're usually defined more by screen space usage than virtualized distance measurements.  It would be too labourous to define LoD for every single object.  Looking into the configuration files of games like Skyrim and Fallout, you'll see LoD values set for objects, lights, shadows, characters, and the one near individual of trees.  Categorically defining visual ranges for knowingly optimized models.

SL doesn't have the luxury of knowingly optimized models, so, they had to settle for something.  When the grid was all prims, it was relatively easy to maintain simplified forms of each.  Come sculpts and mesh, the potential complexity of any solution grew exponentially.  The Lab had to pick a balance between unrestrictive support for careful creators and reasonable limitations for the careless.

[ChinRey]

---

Imnotgoing Sideways wrote:

But, in rendering environments like games, it's an absolute necessity.  There's often no predicting where a viewer's/player's camera will be at any moment.

---

I may have misunderstood you there. But as I already clarified in my reply to Penny Patton, I was talking about LoD the way it's done with mesh in SL. Other 3D environment have far better way of dealing with LoD, usually a gradual algorithmic decimation, sometimes perhaps a single LoD model and/or an impostor.

 

---

Imnotgoing Sideways wrote:

Come sculpts and mesh, the potential complexity of any solution grew exponentially.  The Lab had to pick a balance between unrestrictive support for careful creators and reasonable limitations for the careless.

---

No, sorry, I don't buy that. To borrow Penny's very precise words: LL screwed the pooch with LoD.

Two quite telling facts: it took several years and several JIRAs before they finally noticed that they had got the LoD formula for three and four face meshes wrong (and by then it was apparently too late to fix that bug). Also, it took several years before LL's own content creators, the Moles, even started experimenting with mesh and it's only very recently they've started to get it right. Clearly they were not involved in the development, that was all left to programmers with no real understanding of practical 3D design.

Nyx Linden once told me that GLOD, that pitiful excuse for a decimator they included in the uploader, was the best on the market and he clearly sincerely believed it. That shows how ignorant the LL developers were about practical mesh building.

[Whirly Fizzle]

---

ChinRey wrote:

---

Two quite telling facts: it took several years and several JIRAs before they finally noticed that they had got the LoD formula for three and four face meshes wrong (and by then it was apparently too late to fix that bug).

It's not too late -

that bug

is fixed in the Maint-RC viewer.

[ChinRey]

---

Whirly Fizzle wrote:

It's not too late -

that bug

is fixed in the Maint-RC viewer.

---

Oh, that's good news. Last I heard from Beq there were some server side issues that caused conflicts with her patch.

Even so, it took five years, several bug reports, a new management and an unpaid volunteer to fix a blunder that never ever should have been allowed past the early beta stage.

Now, imagine if LL released a new set of beginner avatars and they forgot to set the elevation height so the avis were sunk waist deep into the ground. That's the LoM (Level of Mistakes) they made with mesh LoD.

[Polymath Snuggler]

Beq and AndryK seem to have ironed out the problems with the fix, which is awesome news, and the fix itself was actually fairly simple~

I feel compelled to mention however, that the bug itself was incredibly bizarre.  As it was rooted in the methodology of the piggybacking of mesh display behavior on top of prim base types.  Bugs that are simple to locate don't last 5 years~ nor do the bugs that are simple to solve.  This particular one was insanely difficult to locate, but simple to solve.  The vast majority of the rest of the LOD problems sadly fall under the "simple to locate, but nearly impossible to solve." umbrella.  That being said, while there are a LOT of bugs with the LOD system, it's still 'passibly functional' as it presently stands.  Remember: The Lindens operate as a business should. Cost benefit analysis.  Which means solving really convoluted pain-in-the-ass problems that have no drastic impact on the world really isn't high on their to-do list.

 

The majority of the problems come from the way the upload system presently is incentiveizing uneducated creators to create content with single-triangle Low LOD's.  And while I do hold the Lindens partially accountable for not doing more to at least clarify in the uploader what was "good" and "bad" for SL.  At the end of the day, there's no amount of enforcement that can stop a unskilled creator from creating bad content, without limiting the creative freedom of a good content creator to create something impressive.  That being said~ SL documentation, especially on mesh has been abysmally lacking.

 

As for actually fixing things ~ I've actually submitted a number of random LOD related bug reports to LL ~ and they've seemed very receptive to at least trying to figure out a solution.  After looking through the JIRAs of the last 5-7 years, I can say with reasonable confidence, a lot of longstanding bugs of SL predominantly exist because no one has filed a report that reliably points to "this specific thing is broke."  ~  Most of it is "when I go here, and do this thing, half the time this other strange thing happens that I didn't expect."  While that's helpful ~ as someone who's recently taken up trying to write code junk~ I can tell you it's not always quite good enough.  Things seem to be heading in the right direction though!  Even if it's a bit painfully on the slow side.