The importance of LOD

[IvanBenjammin]

Thanks for starting this thread, lots of good points so far.

The triangle soup phenomena seriously bugs me and puts me off visiting a lot of places in SL, despite having high display settings with decent view distance. 

The rezzing process is often overlooked - the fact that as objects load into the scene, regardless of view distance, you will see the lower LODs. So you have a beautiful, high detail mesh creation that's low land impact, but its completely unrecognisable until its fully rezzed. This may not bother some people, but it certainly bothers me. I teleport to a sim, where the landing point is under a nice tree. At least after a minute of rezzing. Until then, I can't see anything except triangle soup.

Awareness of this is growing. I don't want to plug my own work in this thread, but one of the top comments I get from customers is appreciation for decent LODs. Some are always going to care about this more than others, in the same way that some like nice lighting, while others prefer one of those flat-shaded presets that make avatar skin look good at the expense of everything else.

Engines like Unreal or Unity have the ability to directly control where LOD switching occurs on a per object basis. You can make a chair with a single LOD level of a few thousand triangles, and simply make it disappear at distance. Because SL locks LOD switching to object size (with rendervolume acting as a multiplier), creators have developed various tricks, like the single triangle LOD mesh already mentioned.

Unity/Unreal also have proper instancing for mesh objects. In reality, once a mesh object is downloaded, all other copies of it should has a download weight of zero. Physics weight will still be important, but if physics is rarely the highest LI factor anyway. Just this fact alone makes the land impact system inaccurate. Add in textures, which are far more memory intensive than mesh (but have zero land impact...) and the inaccurate system becomes broken.

Obviously some sort of accounting system is needed, but some sort of memory limit per sim would make much more sense. It would arguably mean less freedom for creators, but a better experience for everyone IMO.

 

 

 

[ChinRey]

---

Medhue Simoni wrote

These are all nice examples, but they are the basics that everyone will or should eventually learn.

---

Sadly that turns out not to be the case. Well, those who are willing and able to learn and manage to see through all the myhths and superstition that always spreads wherever cold facts are scarce, will eventually learn but it's a long and tedious road.

Things are getting better though. When I started working with mesh, about a year and a half ago, only a few builders, like Drongle, really knew how to do it efficiently and most of them were so busy experimenting and learning they never had time to make their works available for others. The general level of quality and understanding is much higher today and it keeps getting better all the time.

We still got a long way to go but we're getting there.

---

Medhue Simoni wrote:

Is less prims better than models with LODs you can see from a 500 meters away?

---

Just to make one thing clear here, we're not talking distances of that scale. An object with the dimensions of 1x1x1 m has its first theoretical switch point at 3.6 m (that's about 12' for our American friends) with RenderVolLODFactor at 1. Even with the LOD factor set at 4 it's still only 14.4 m. In theory that is. In reality, the distance will always be less, sometimes a lot less.

(Edit - have to add a bit here: Important to remember that the switch point distance is the one between the center of the object - not the nearest surface - and the camera. That means with LOD Factor 1 and default camera position a few meters behind and above the avatar the 1x1x1 m cube at the avatar's feet will be displayed with the mid rather than the high resolution model. Anotehr example - Even with a LOD factor of 4 a 0.1x0.1x0.1 m object will only use the high resolution model if you cam in on it, never if you have your cam in "avatar position".)

But I agree of course that we can't maximize LOD at any cost. It's always a question of balance, to find out exactly how much and what to sacrifice at each level. That's something a computer program can never ever do for us and probably the most mportant skill for a mesh maker to have.

 

---

Medhue Simoni wrote:

I've made just about every kind of item possible, and I have yet to see the genius of LL's system

---

It's a hack. I don't know if it's because of LL's lack of understanding how building works or because their hands were tied by old code. Probably a combination of both but in any case it's a hack.

The idea of the four LOD models is very much an integrated part of the prim system and made specifically to fit the prims and it works well enough for those. Not without flaws - as Chic Aeon pointed out early in this thread - but it rarely causes any big problems. It is far less suitable for sculpts and by the time we get to mesh, it doesn't really work at all.

 Still, it's what we've got so it's what we work with and what we should make the most out of.

---

Medhue Simoni wrote:

Plus, LL completely ignored the real culprits. It's not really the items on the sims that are going to be problematic, but the avatars that play there. None of LL's system does anything at all to address this.

---

There's no "real" culprit here. Everything in SL add to the overall load and lag. You do have a point though, geometry is very rarely a significant factor. A single avatar fully loaded with high poly couldn't-care-less-about-lag mesh body, mesh clothing and mesh everything covered with high resolution still-don't-care-about-lag textures can easily create far more lag than an entire well built sim. But LL made the decision long ago to put tighter restriction on the environmental builds than on the avatar. (That's why we today have an SL where clothing and avatar shapes are more important than the virtual surroundings.)

Again, not much we can do about it. We just have to make the best of the situation and make sure we make our own works as well as we can.

[ChinRey]

---

IvanBenjammin wrote:

The rezzing process is often overlooked - the fact that as objects load into the scene, regardless of view distance, you will see the lower LODs. So you have a beautiful, high detail mesh creation that's low land impact, but its completely unrecognisable until its fully rezzed

---

Glad you brought that up. Those lower resolution LOD models aren't just for long distance vieweing, they're also used as temporary models during the rendering process. When the viewer renders an object, it starts with the lowest res model to get something out there as quickly as possible. Then it goes up through all the models until it gets to the one apropriate for the viewing distance. If your GPU is busy, it may take quite a while before it has time to switch an object to a different model. This is the reason why actual LOD is always a little bit - sometimes a lot - poorer than the theoretical one.

---

IvanBenjammin wrote:

Add in textures, which are far more memory intensive than mesh (but have zero land impact...) and the inaccurate system becomes broken.

---

To put that into some kind of perspective. A 1024x1024 resolution texture consists of 1 048 576 points (pixels). An SL mesh has a theoretical maximum of 65536 points (vertices) but in reality meshes are far simpler than that. Usually we're talking two- or three digit figures - four digits at most.

You can't really compare texture pixels with mesh vertices directly this way of course but the sheer difference in scale between the two numbers still says a lot.

---

IvanBenjammin wrote:

Unity/Unreal also have proper instancing for mesh objects.

---

A friend of mine said to me that the moment somebody combined OPen sim, Unity and WebGL to create a virtual world, SL would be dead. He was wrong of course, no matter what happens, sheer momentum will keep SL going for a long time. BUt I'm beginning to think he still had a point...

[Drongle McMahon]

In reality, once a mesh object is downloaded, all other copies of it should has a download weight of zero.

That would be right if the downloading burden was the only consideration. It would make a huge difference, and it would encourage mpre efficient re-use of geometry. For example, I once made a tree where all the branches were instances of the same mesh at different scales, but with the LI system it was horribly expensive. However, I think instancing doesn't help (much) with the gpu effort required to render multiple objects. So when they decided that that was the equally or more important target for limitation with LI, the idea of rewarding instancing no longer fitted with the aim.

You're also right about textures. I have no real data, which would be really interesting to see if it exists, but I do get the impression that both downloading and rendering large textures contributes more to the slow rezzing problem than does geometry, especially now that we have normal and specular maps too. On the other hand, I think good textures/materials can contribute much more to visual quality than geometric detail can.

 

[Pamela Galli]

---

Medhue Simoni wrote:

---

Drongle McMahon wrote:

I don't disagree. Poor choices by consumers are as much to blame as the producers who choose to exploit those choices. No difference between RL and SL there, except maybe that RL does have a few laws to eliminate the worst abuses. Still the cynical exploiters can still make the most money (ever heard of

Gerald Ratner

?). Fortunately for me, I'm not trying to sell anything. So I can ignore the destructive realities of commerce.

---

Are they poor choices? Some, most likely are. Others, are making a conscious choice for what they think is better, for them. Just like in real life.

_______________

 

People do make poor choices wrt LI sometimes -- my sculpted stuff still sells regularly, even at almost double the LI of mesh -- but I certainly would not call someone buying mesh that does not hold up well 200m away a poor choice -- for them. Most people don't care what their home looks like to ppl 200 m away. And once their stuff is cached, it usually pops into view pretty quickly -- for them.  

They just dont care much that some visitors have to wait a bit for things to rez, and they dont care that people flying around the sim may not be able to see the whole thing properly rezzed at 200m. And I cant see how this is a bad thing. 

 

 

[leliel Mirihi]

I think a lot of you guys are asking too much from the LI system. One of the design constraints of LI was that it wasn't too radical of a change from the prim system. LI doesn't count textures because the prim system didn't, LI doesn't include avatars because the prim system didn't, LI doesn't account for instancing because the prim system didn't. LL wanted a mesh object to have an LI of roughly the same as an equivalent prim object but that's never going to happen if the LI system is counting all kinds of crazy things the prim system never did.

There's also the issue of user training. It's taken years to get people to understand LI, arguable we're still a long way from it being widely understood. And it's a simple system! If they had added all that stuff people would have just given up and stopped caring, I'd argue it's happening now with the type of objects that started this thread.

If you're saying that LI didn't go far enough to stop the rampant resource abuse that has plagued SL for a decade then you're right. But being bitter about that isn't very helpful.

[Pamela Galli]

---

leliel Mirihi wrote:

I think a lot of you guys are asking too much from the LI system. One of the design constraints of LI was that it wasn't too radical of a change from the prim system. LI doesn't count textures because the prim system didn't, LI doesn't include avatars because the prim system didn't, LI doesn't account for instancing because the prim system didn't. LL wanted a mesh object to have an LI of roughly the same as an equivalent prim object but that's never going to happen if the LI system is counting all kinds of crazy things the prim system never did.

There's also the issue of user training. It's taken years to get people to understand LI, arguable we're still a long way from it being widely understood. And it's a simple system! If they had added all that stuff people would have just given up and stopped caring, I'd argue it's happening now with the type of objects that started this thread.

If you're saying that LI didn't go far enough to stop the rampant resource abuse that has plagued SL for a decade then you're right. But being bitter about that isn't very helpful.

---

I am not bitter about it, quite the contrary. I agree with the above points about LI accounting, but I dont find it that hard to work around.

[IvanBenjammin]

You can't really compare texture pixels with mesh vertices directly this way of course but the sheer difference in scale between the two numbers still says a lot.

Yes, that's part of it. It doesn't tell the whole story because texture and mesh data are treated differently by the GPU, but fundementally they both amount to a list of points with values to define them - RGB values for pixels and XYZ positions for vertices. Its a bit more complicated than that, because textures might have an alpha channel (which means it has 4 values instead of 3), and the mesh has UV (xy coordinates) and normals (XYZ vectors)

Once a texture is cached, it isn't going to be much of a performance drag. Its a quick hop from your cache to VRAM, but the download TO your cache is the bottleneck for textures.

For mesh, its a little different. It too gets cached and loaded into RAM, but the GPU is having to calculate its vertex positions relative to camera position for every frame it renders.

On the face of it, it might sound like mesh is incredibly render intensive if its doing that 30+ times a second, but modern GPUs ('modern' in this instance being anything less than 10 years old) can crunch those numbers blazingly fast. Even onboard graphics setup is very quick at this process, its just using the system resources to do it rather than its own.

That would be right if the downloading burden was the only consideration. It would make a huge difference, and it would encourage mpre efficient re-use of geometry. For example, I once made a tree where all the branches were instances of the same mesh at different scales, but with the LI system it was horribly expensive. However, I think instancing doesn't help (much) with the gpu effort required to render multiple objects.

It doesn't help with the actual drawing of triangles, but this is the quickest part of the process. What happens is (and I'm oversimplifying to a criminal degree here)  the CPU defines a 'drawcall' which tells the GPU what to render. Only one object can be defined in a single drawcall. As I said above, the GPU is blazingly fast at number crunching, and will essentially render faster than drawcalls can be made - it can even end up being idle for a decent chunk of the time taken to render a frame.

What instancing means is that multiple copies of a mesh become a single drawcall. The CPU tells the GPU to 'render this, X times, at these positions.'  By the time its done, the next drawcall is ready. Its for similar reasons that 1 object of 5000 triangles will be more efficient than 100 (non-instanced) objects of 50 triangles - the former is a single drawcall, the latter is 100.

I don't know exactly how the SL engine works, but when I was working with the Unreal engine, an object of 600 triangles or less was essentially free, because those 600 triangles rendered faster than the time it took for the drawcall itself.

That's a pretty simplified explanation of what I understand to be going on 'under the hood', but frankly I can't understand the complexities myself

You're also right about textures. I have no real data, which would be really interesting to see if it exists, but I do get the impression that both downloading and rendering large textures contributes more to the slow rezzing problem than does geometry, especially now that we have normal and specular maps too. On the other hand, I think good textures/materials can contribute much more to visual quality than geometric detail can.

I absolutely agree with you, and its why everything I make is normal mapped - even if lots of people in SL still can't display those. Its worth pointing out that normal mapping is less memory intensive than a diffuse texture (not sure about spec maps) - ultimately the same amount of data, but GPUs have been optimized to handle it more efficiently. This is another point that the technicalities escape me, unfortunately. Probably why I ended up an artist monkey instead of a code monkey

 

[IvanBenjammin]

---

leliel Mirihi wrote:

I think a lot of you guys are asking too much from the LI system. One of the design constraints of LI was that it wasn't too radical of a change from the prim system. LI doesn't count textures because the prim system didn't, LI doesn't include avatars because the prim system didn't, LI doesn't account for instancing because the prim system didn't. LL wanted a mesh object to have an LI of roughly the same as an equivalent prim object but that's never going to happen if the LI system is counting all kinds of crazy things the prim system never did.

There's also the issue of user training. It's taken years to get people to understand LI, arguable we're still a long way from it being widely understood. And it's a simple system! If they had added all that stuff people would have just given up and stopped caring, I'd argue it's happening now with the type of objects that started this thread.

If you're saying that LI didn't go far enough to stop the rampant resource abuse that has plagued SL for a decade then you're right. But being bitter about that isn't very helpful.

---

I'm not bitter at all, in fact incredibly thankful that SL exists as a platform for my creativity. That doesn't mean I can't see flaws in the system, or that I don't want better tools. Perhaps I chose my words poorly when I said I didn't like going places with triangle soup - I spend most of my time in my sandbox so I don't really go anywhere.

[leliel Mirihi]

---

Pamela Galli wrote:

I am not bitter about it, quite the contrary. I agree with the above points about LI accounting, but I dont find it that hard to work around.

---

 Sorry if it seemed like I was calling you out. I was replying to the thread as a whole and your post just happened to be the last one at the time so I clicked reply to it.

[Medhue Simoni]

Don't get me wrong ChinRey. I think the topic is important, and it's great that people are pointing it out.

I think my point is ulitmately not to just blame the creators. Like you said tho, things are getting better. I personally like to make more things for avatars than anything else, as it's kind of easy to make efficient things for avatar, which is why I don't understand why so many go so overboard. They can, which is probably why. The creators I have the most sympathy for, are the home, buildings, and landscape designers, which are the primary creators that do need good LODs to see far away. I've made a few large structures for myself, but I didn't jump through all the hoops to make them the lowest land impact. I'd rather just bite the bullet on the prims and have 1 mesh to deal with. lol

 

[arton Rotaru]

Hehe, cool topic. :matte-motes-sunglasses-3: Though, I have pretty much given up on arguing about LoD. The train has left the station 4 years ago. Though, even LL is aware of the problem, and some(one?) of them doesn't like current LoD behavior.

At least there is consideration to provide a message, during upload, when the clients LOD factor is set to higher numbers than the default, to make the uneducated builders aware of the problems it could cause. Seems like nothing has happened in that regard, though. Not that it would help much anyway. There will be still those who upload highpoly stuff with zeroed out LoD to advertise their stuff with "super detailed, low land impact" phrases.

https://jira.secondlife.com/browse/BUG-6243

I just find it funny, that people go for super low LI with bad LoD, but ultra detail on the high LoD model. Cramming way to many of these objects onto parcels which should hold much less content, to be with good performance. Cranking up the LoD factor to make all that mess even viewable, results in even higher load, with to many objects in close range, with each of them containing even more textures.

And then they wonder why their SL is unusable on their laptop, when their friend with his half a million poly AV enters the scene on top of that. :matte-motes-big-grin:

But hey, that's only human. :matte-motes-silly:

I also agree that the mesh accounting isn't ideal, though I can't blame it too much, since I also have way more stuff rezzed on our homestead than under the old accounting, but with pretty LoDs.:matte-motes-sunglasses-3:

[Medhue Simoni]

While we have so many here that know their LODs, why not have you guys criticize my mesh, and LODs. Just remember that I like to animate more than anything. Modeling and everything else is just my set up to animate something. I do love to learn tho.

When I first learned to model, during SL mesh beta period, I just let the uploader do all the work. Then people like Drongle and Chosen stressed making your own, so I did. Then I started using Blender. I know I'm going to get ripped apart for this, but especially lately, I've been using Blender's decimate modifier alot for my LODs. Generally, I try to reduce the model keeping the geometry symetrical. Originally, I thought it was far to random to reduce a model in good ways, but after playing with it on quite a few models now, I find the results to be pretty good, and in Blender, you can stop at any point and then go in and finish it up by hand. I find that when your geometry is evenly laid out, the decimator can do a decent job. Ultimately tho, it's about saving time. After spending days modeling and texturing a model, the last thing I want to do is spend hours creating LODs. Using the decimate modifier turns that into a half hour of playing around. I'll show an example, and then you all can rip me apart, and tell me to stick to animating.

Triangles -       High 2814,  Mid 1406, Low 350

This model was 1 of my first decent model, but I recently decided to sell it for Unity also.

Basically, I just don't understand why a modeler would not use something like a good decimator, if they can get good results. Please be gentle. lol

[leliel Mirihi]

---

Medhue Simoni wrote:

 I'll show an example, and then you all can rip me apart, and tell me to stick to animating.Triangles -       High 2814,  Mid 1406, Low 350

This model was 1 of my first decent model, but I recently decided to sell it for Unity also.

---

It's a little hard to judge from that one picture so take this with a grain of salt.

High LOD looks fine for the most part. The only problem I see is the receiver, it was literally just a box with stuff bolted on. Yours is too high poly for that.

Mid LOD seems a little higher than it needs to be but I'd have to see how it behaved in SL to properly judge it.

Low LOD is way higher than it needs to be. Nobody is going to see those curves on the hand grips or stock at those distances, the barrel could just be a prism for all anyone cares, etc.

Some artistic criticism if you want as well. The front hand grip is in the right place but the wrong shape and missing some parts. Also the overall gun seems a bit off assuming you're modeling the original Tompson and not the M1928 and variants.

 

[Drongle McMahon]

Medhue, where is lowest LOD?* At this size, the LI is very dominated by the lowest LOD. So, apart from that, your models look ok. I guess I would have had less detail all the way down, and more drastic reductions, but that's a matter of choice - I'm not so interested in guns that I would be looking closely at them. It woud be interesting to know the actual triangle and vertex counts (uploader's version). The default targets for the autoLOD are 1/4 the vertices at each step. Yours looks like a lot less pruning than that, but that doesn't mean much.

I haven't used the Blender decimator for ages. It used to destroy the UV maps. So I only use Dissolve now, which takes longer but keeps the maps intact. Does the decimator preserve UV maps now? Before Dissolve, I used to spend much more time fixing UV maps than reducing the geometry.

*One triangle? Actually, for this case, two triangles (for both sides) with the right shape and suitable texture, might be quite reasonable. Maybe four, so you still have the magazine from head-on.

[Drongle McMahon]

What instancing means .... same drawcall ...

I can't claim to have looked at the code, but I would be surprised if there's any instancing at that level in the standard viewer, even with legacy prims. Others would know better.

There is intancing in the sense of downloading the mesh assets (geometry etc), independently of texturing, provided the only differences between objects are simple transformations (and provided they aren't uploaded together with the different textures, getting different uuids). I'm not even sure whether it even applies to the generation of geometry from sculpt maps for sculpties that share a map. I think that happens per object level, not per map. (You do see coordinated snapping on of objects with shared maps, but I think that's the map download/cache fetch).

[Jake Koronikov]

---

IvanBenjammin wrote:

....

Once a texture is cached, it isn't going to be much of a performance drag. Its a quick hop from your cache to VRAM, but the download TO your cache is the bottleneck for textures.

For mesh, its a little different. It too gets cached and loaded into RAM, but the GPU is having to calculate its vertex positions relative to camera position for every frame it renders.

On the face of it, it might sound like mesh is incredibly render intensive if its doing that 30+ times a second, but modern GPUs ('modern' in this instance being anything less than 10 years old) can crunch those numbers blazingly fast. Even onboard graphics setup is very quick at this process, its just using the system resources to do it rather than its own.

.........

---

Very good explanation. But there is one thing that no-one has been worried about, and what I would say is the most significant singe cause of FPS drop in SL: alpha overdraw.

Even old GPUs can hande amazing number of triangles and still keep the fps at about 50 or above. But even the latest GPUs cannot handle overlayed alpha textures. That is called alpha overdraw. To put it simple, when you render dozen of alpha blended textures over eachother, the GPU has to make "Photoshop level" graphics work with every drawcall...

According to my experience, most of the laggy sims in SL are just filled up with trees and grass that have dozens if not even hundreds of alpha textures showing thru eachother. In different angles and with different semi-transparent textures. The SL shader system does not have any special solution for these kind of objects. Some other game platforms have special shaders to render those. At least those shaders can be coded.

This issue is gonna be one big pain in the butt, when they develop mobile, tablet (plus all sorts of pods and tubes) version of SL2. Because those poor devices can never ever handle the alpha inferno that content creators will create....

[leliel Mirihi]

---

Jake Koronikov wrote:

The SL shader system does not have any special solution for these kind of objects. Some other game platforms have special shaders to render those. At least those shaders can be coded.

---

 Those games use alpha masking instead of alpha blending, SL now has alpha masking as well. Give it a few more years and most well made content will use it making over draw much less of a problem.

[Jake Koronikov]

---

leliel Mirihi wrote:

---

Jake Koronikov wrote:

The SL shader system does not have any special solution for these kind of objects. Some other game platforms have special shaders to render those. At least those shaders can be coded.

---

 Those games use alpha masking instead of alpha blending, SL now has alpha masking as well. Give it a few more years and most well made content will use it making over draw much less of a problem.

---

Both alpha masking and alpha blending have to be maintained in the future SL2. They are two quite different methods. The problem is, that when residents (=content creators) have the freedom...they usually use alpha blending. Alpha blending is just like the old school alpha texture, that we see all over SL. Alpha (amount of see-thru) is coded in alpha channel as 0-255. This is same as alpha blending.

High FPS games also use alpha blending, but they have a possibility to code their custom shaders so, that the expensive light calulations can be reduced in alpha objects. This will help increasing FPS. They give less quality shaders for alpha intensive objects. They can even define that how deep the alpha blending will go (z-rejection), meaning how many layered alpha textures is the maxium the shader will ever calculate.

But if the SL resident chooses the shaders...I am afraid that they will choose the most beautiful and most GPU expensive ones.

[leliel Mirihi]

The problem with this kind of stuff is there's no feed back loop. When people see performance problems there's no obvious cause for them and the community basically indoctrinates people to blame LL for everything. Most people just don't even realized it's their own content that's causing the problems. When you try to bring up the issue many people take it as a personal insult and downplay, brush off, shift blame or just get hostile.

Increasing public awareness through frequent educational campaigns while expanding the performance metric systems in the viewer is the only long term solution I can think of. The performance metrics displays in the viewer were originally made for debugging but they need to be brought to the for front and made easier to use and understand. Content creators and consumers can't make informed decisions without the proper data and they can't get the proper data without the appropriate tools.

[Medhue Simoni]

---

leliel Mirihi wrote:

---

Medhue Simoni wrote:

 I'll show an example, and then you all can rip me apart, and tell me to stick to animating.Triangles -       High 2814,  Mid 1406, Low 350

This model was 1 of my first decent model, but I recently decided to sell it for Unity also.

---

It's a little hard to judge from that one picture so take this with a grain of salt.

High LOD looks fine for the most part. The only problem I see is the receiver, it was literally just a box with stuff bolted on. Yours is too high poly for that.

Mid LOD seems a little higher than it needs to be but I'd have to see how it behaved in SL to properly judge it.

Low LOD is way higher than it needs to be. Nobody is going to see those curves on the hand grips or stock at those distances, the barrel could just be a prism for all anyone cares, etc.

Some artistic criticism if you want as well. The front hand grip is in the right place but the wrong shape and missing some parts. Also the overall gun seems a bit off assuming you're modeling the original Tompson and not the M1928 and variants.

 

---

Thanks for the critique! I can't say I disagree with you.

Originally, when I first created the Tommygun in 3Ds Max, I did not add in the front grip. I wanted it to be 1 handed in SL. When I decided to sell it for Unity, I added the front grip. I probably should throw in some animations to hold it, reload, and shoot.

[Perrie Juran]

---

leliel Mirihi wrote:

---

Jake Koronikov wrote:

The SL shader system does not have any special solution for these kind of objects. Some other game platforms have special shaders to render those. At least those shaders can be coded.

---

 Those games use alpha masking instead of alpha blending, SL now has alpha masking as well. Give it a few more years and most well made content will use it making over draw much less of a problem.

---

Tagging you partly out of convenience.  If SL survives (and I do expect it to continue for a couple of years still) the replacement of 'bad' content with better content will happen by attrition.  But the majority of users will be clueless to the advantage unless someone calls their attention to it.

I've been following this thread out of general interest and thought this exchange between Monty and Torley would be of interest to people because LL practices and the need to educate people have been brought up.

"Monty Linden added a comment - 17/Oct/14 11:32 AM - edited

So, in something like game development where one hierarchical team would make resource decisions, a resource target would be set (say 256MB resident textures) and content would be adapted to fit in it. Doesn't work for us where content is designed without foreknowledge of its target environment. Better tools for the content creators is certainly desperately needed. Has been, is now, will be tomorrow.

But it's not enough. That centralized feedback loop within a design team doesn't have a direct analog in SL. Instead, there are many independent possible feedback loops. Estate owners/managers and event/build organizers might want the resource allocation and enforcement role. Renters, visitors, fabricators, etc. are directly and indirectly consuming it. The piece that is missing is the communication/advice/enforcement/review network so that everything can be brought into balance. Prim/rendering cost doesn't quite cover it.

Recent changes are probably going to aggravate it. Mesh and texture behavior just became a whole lot more permissive. I'm expecting overbuilding to become more common.

 

Torley Linden added a comment - 17/Oct/14 4:07 PM - edited

That's a great way to put it, Monty — the "communication/advice/enforcement/review network" is the social-cultural piece of the puzzle. I have always advocated for this in SL and am more than happy to help if we (Linden Lab) are going to raise awareness, especially at a broad level that sets a good example of content creation practices. It's incredibly important to teach our community how to get the most out of any tools and to be aware that resource usage needs to be balanced for optimized experiences.

I wish the LL Viewer had a better way to selectively block/hide objects during a session. There are times when it's several troublesome objects stuffed with 1024x1024 textures that cause problems for the rest of the scene. This is even more evident when doing video work since the "texture thrashing" is recorded in motion, and really makes the experience look bad. Some 3rd-party viewers have a "Hide Selected" that persists until you either relog or teleport away and back again.

Texture thrashing is even more problematic considering that (1) some of the best-looking scenes in SL are very graphically dense in order to maintain a more modern appearance and (2) sometimes, it's a curated collection of objects built by an assortment of creators, gathered in a cohesive space — so the content curator doesn't have full control over those texture sizes aside from choosing what they include."

https://jira.secondlife.com/browse/BUG-2514

I don't want to start a thread hijack but my personal opinion is that LL has really missed the boat on the value to them in educating people as to best practices, that it would yield a greater ROI than the ROI on all the money they are investing in infrastructure.

[Medhue Simoni]

---

Drongle McMahon wrote:

Medhue, where is lowest LOD?* At this size, the LI is very dominated by the lowest LOD. So, apart from that, your models look ok. I guess I would have had less detail all the way down, and more drastic reductions, but that's a matter of choice - I'm not so interested in guns that I would be looking closely at them. It woud be interesting to know the actual triangle and vertex counts (uploader's version). The default targets for the autoLOD are 1/4 the vertices at each step. Yours looks like a lot less pruning than that, but that doesn't mean much.

I haven't used the Blender decimator for ages. It used to destroy the UV maps. So I only use Dissolve now, which takes longer but keeps the maps intact. Does the decimator preserve UV maps now? Before Dissolve, I used to spend much more time fixing UV maps than reducing the geometry.

*One triangle? Actually, for this case, two triangles (for both sides) with the right shape and suitable texture, might be quite reasonable. Maybe four, so you still have the magazine from head-on.

---

This version is for Unity, not SL. I likely did go a little overboard when I modeled this originally in 3ds Max. I reduced the final for Unity a little in the stock and grips. I wanted it to be highly detailed for FPS games in Unity. Most FPS games today, it's incredible how detailed the weapons are.

This was literally 1 of my first 10 models that I ever created, and when I originally uploaded it to SL, I just use the uploader to create the LODs.

Blender's decimator preserves the UV map now. Like I said, when the model's geometry is evenly laid out, the decimator does a decent job. I'm not sure I'd use it for the Lowest LOD in SL, as I'd likely just reduce the model by hand from the Low LOD. I guess the reason I bring it up is that, if LODs are a problem in SL, and so many creators and just using the uploader, then this would be a much better way, which give much better results. I want to know what people like yourself think about it.

If you want to look at the model, you can goto my website and see the model in a 3D viewer. I think I made the environment for the 3D veiwer a bit dark tho. I'm using Sketchfab for the 3D view.

http://www.medhueanimations.com/collections/3d-models/products/medhue-tommygun

[Medhue Simoni]

---

Perrie Juran wrote:

---

I've been following this thread out of general interest and thought this exchange between Monty and Torley would be of interest to people because LL practices and the need to educate people have been brought up.

 

I don't want to start a thread hijack but my personal opinion is that LL has really missed the boat on the value to them in educating people as to best practices, that it would yield a greater ROI than the ROI on all the money they are investing in infrastructure.

---

That is definitely an interesting exchange. More best practices are definitely needed. That said, I think it is also something the community can do. We've had many discussions about efficiency and things of that sort, but there is no way to highlight those threads.

I'd rather Lindens did actual work on the system to make it better. They created a pretty awesome pathfinding system, which easily rivals any other on any platform. The thing is, we don't have custom skeletons to make those NPCs actually look good using that pathfinding. Of course, I'm more into animating and armatures than most, so I'm highly biased. Give me custom skeletons PLEASE. I want to bring my bat into SL. Although, I will also likely rig him with the SL skeleton, as an avatar.

This is just the flying animation roughed out. It's been changed significantly.

[Perrie Juran]

---

Medhue Simoni wrote:

---

Perrie Juran wrote:

---

I've been following this thread out of general interest and thought this exchange between Monty and Torley would be of interest to people because LL practices and the need to educate people have been brought up.

 

I don't want to start a thread hijack but my personal opinion is that LL has really missed the boat on the value to them in educating people as to best practices, that it would yield a greater ROI than the ROI on all the money they are investing in infrastructure.

---

That is definitely an interesting exchange. More best practices are definitely needed. That said, I think it is also something the community can do. We've had many discussions about efficiency and things of that sort, but there is no way to highlight those threads.

I'd rather Lindens did actual work on the system to make it better....

<Snip>

 

---

Oh, I'd much rather they focus on working on the System.

And I know a lot of users have done a lot of work doing tutorials, etc on best practices.

Maybe they should allow us to post those tutorials in Tips and Tricks which hasn't had any new material added since 2011.