in-world versus external sculp and mesh makers?

[Kwakkelde Kwak]

---

Perrie Juran wrote:

 

Don't you begin to get into a quantity versus quality issue here?

---

By no means. When done right, it's a quantity AND quality thing.

Without going into detail, I think the example I gave speaks for itself. 108 triangles vs 4 triangles on the highest LoD (up close), 48 vs 4 for medium and 12 vs 4 for low and lowest, without any loss of shape. This means a lower impact on the user's end, plain and simple.

The meshes that cause issues are the ones that take advantage of the way LI is calculated. So over-use of geometry on the highest LoD and more or less no geometry for the other LoD models. You can see this with the two rooftops that are posted, viewer lag when you are close and the degeneration when far away. A good example of how to use mesh properly is the jerrycan, although I bet the medium LoD could be even lower.

[arton Rotaru]

---

Kwakkelde Kwak wrote:

---

---

 A good example of how to use mesh properly is the jerrycan, although

I bet the medium LoD could be even lower.

---

INDEED. The whole can could be way lower. My old version of it has only about 300 Tris in highest LOD. However it's not as detailed as this new one. The main reason why the medium LOD isn't even less in polycount, is to keep the shading of the baked normals map consistant.

[Perrie Juran]

It is a beautiful can and yes I understand that with Mesh things can be built that otherwise could be next to impossible to do efficiently with Prims.

But what I am also seeing here is if you aren't extremely exact in what you do things can begin to downgrade very fast. 

I hate to sound discouraged but I am still dealing with the fact that my overall experience has been negatively impacted. 

Like most users I began counting prims the day I got my first place to live.  I know how many prims (land impact) my land supports.  But it's starting to get onerous keeping track of all this stuff.

[Kwakkelde Kwak]

---

arton Rotaru wrote:

---

Kwakkelde Kwak wrote:

---

---

 A good example of how to use mesh properly is the jerrycan, although

I bet the medium LoD could be even lower.

---

INDEED. The whole can could be way lower. My old version of it has only about 300 Tris in highest LOD. However it's not as detailed as this new one. The main reason why the medium LOD isn't even less in polycount, is to keep the shading of the baked normals map consistant.

---

I just meant the way the numbers go down with the LoD models, no insane drop between high and medium. (in some specific cases that can actually work, but not in general). For a game even 300 would be on the high side I think, for SL where people like to zoom in on individual items, the 1000 orwhatwasit is pretty decent I think.

[arton Rotaru]

First of all thanks for the compliment. :matte-motes-grin:

 

With all the changes that came with mesh, we are actually able to rez even more geometry on our land as we could in the past. if you set each prim box to convex hull, you can rez 30000 prims on a fullsim these days.
 That's way to many on a tiny space of 256x256m. The 15000 were way too many already.

However, it's all up to the creators. Lets say you own a fullsim. Now with mesh you are able to build the entire region with reasonable weighted mesh, but still good looking, with little to no lag. With prims, something like this turned out to be a polygon/texture mess, due to the limited building possibilities.

The reality in SL is pretty much not like that, certainly.

Edit: Typos

[Rolig Loon]

Perrie --

I agree about the onerous part, but I'm not sure that much has changed in the 7 years I have been here, nor am I sure that "onerous" is a bad thing, if you take the long view.  We have always had talented builders who use as few prims as possible and yet create beautiful objects by careful texturing.  We have also had hoardes of less experienced builders who use prims wantonly and slap low-quality textures on their work.  The same is true of mesh creators (although I might argue that we have more professional talent in the mix than we used to).  The burden is still on the final consumer to judge which products look best and are most environmentally friendly.  For those who take the responsibility seriously, it can be onerous because there can be so much chaff to sort for so little wheat.  IMO, however, we need more SL residents who, like you, take the time to understand how to evaluate quality.  You not only set a higher standard for creators, but you gradually improve the overall visual quality of SL.  Don't get discouraged.

[arton Rotaru]

---

Kwakkelde Kwak wrote:

---

---

I just meant the way the numbers go down with the LoD models, no insane drop between high and medium. (in some specific cases that can actually work, but not in general). For a game even 300 would be on the high side I think, for SL where people like to zoom in on individual items, the 1000 orwhatwasit is pretty descent I think.

---

Yeah right, if you want to compete on the marketplace, it has to be more detailed as it could be probably.

[Perrie Juran]

---

Rolig Loon wrote:

Perrie --

I agree about the onerous part, but I'm not sure that much has changed in the 7 years I have been here, nor am I sure that "onerous" is a bad thing, if you take the long view.  We have always had talented builders who use as few prims as possible and yet create beautiful objects by careful texturing.  We have also had hoardes of less experienced builders who use prims wantonly and slap low-quality textures on their work.  The same is true of mesh creators (although I might argue that we have more professional talent in the mix than we used to).  The burden is still on the final consumer to judge which products look best and are most environmentally friendly.  For those who take the responsibility seriously, it can be onerous because there can be so much chaff to sort for so little wheat.  IMO, however, we need more SL residents who, like you, take the time to understand how to evaluate quality.  You not only set a higher standard for creators, but you gradually improve the overall visual quality of SL.  Don't get discouraged.

---

Thanks Rolig.  I do appreciate that.

 

[Perrie Juran]

 

---

Kwakkelde Kwak wrote:

---

<snip>

for SL where people like to zoom in on individual items,

</snip>

---

That is so the truth.  And that was some of the beauty of places like Nemo, Alpha & Omega or like in the video of Black Swan above.  The closer you looked, the more detail you saw.  As I recall some of the statues at Black Swan stood over 100 meters tall. 

Another place and I am guessing from his profile RL has kept him from maintaining it was Amael Juran's art store.  He did these incredibly intricate kinetic mandala displays.....the closer you looked the more detail you saw.  They were true works of art.  His Zensual Sculptures which you can still see are also beautiful works of art.

Maybe if and when I start seeing works like this being done with Mesh I will start to get more enthusiastic about it.

[Kwakkelde Kwak]

I wouldn't neccesarily say that. SL is just a different environment than your average computergame, where you run past most of the objects without looking at them.

In a racing game you will find the cars looking extremely detailed and the characters and surroundings very basic for example. In most games, you will find primary and secondary characters, the first being a lot more detailed than the second.

In SL, an object can be primary or secondary. So if you are building a city, the cars should be of medium detail, but if you're building a racing sim, they should have more detail. Afterall, you want the things you actually have on screen most of the time looking as good as they can. When you build "just a car", you don't know how it will be used, so it makes sense to treat it as primary. It would be best if all objects on sale would have at least two versions, low and high detail, but since most people don't even take the time to build separate LoD models for one object, I don't see that happenenig, ever.

[Kwakkelde Kwak]

First of all, that is a great looking sim.

However, you are talking about two entirely different things: performance and looks. The sim in the video looks so good because the builder obviously has talent, not because prims or sculpties are so wonderful. Apart from the flexible cape and hair, I don't see anything that couldn't be built (more efficiently) in mesh. For example, the pyramids use 12 triangles from any distance, a pyramid in mesh would only use half of that, reducing the load on the end user by a staggering 50%.

The giant statue would probably cost a fortune in LI if built in mesh, but it would still be at least as efficient and probably slightly better looking.

One thing I unfortunately cannot answer is how sculpts, prims and mesh compare in network lag. A prim is probably less than 100 bytes. A 64x64 sculpt map in uncompressed jp2 format (used internally in SL) only takes 3kB. Most data of a sculpt is shared and stored locally. A dae file of a a sculpt (I figure the internal SL format is similair) object takes 300kB, or 30 kB when compressed. The uncompressing could result in some lag as well. So if you have a lot of unique mesh objects, things could get laggy I suppose.

[arton Rotaru]

---

Kwakkelde Kwak wrote:

I wouldn't neccesarily say that. SL is just a different environment than your average computergame, where you run past most of the objects without looking at them.

In a racing game you will find the cars looking extremely detailed and the characters and surroundings very basic for example. In most games, you will find primary and secondary characters, the first being a lot more detailed than the second.

In SL, an object can be primary or secondary. So if you are building a city, the cars should be of medium detail, but if you're building a racing sim, they should have more detail. Afterall, you want the things you actually have on screen most of the time looking as good as they can. When you build "just a car", you don't know how it will be used, so it makes sense to treat it as primary. It would be best if all objects on sale would have at least two versions, low and high detail, but since most people don't even take the time to build separate LoD models for one object, I don't see that happenenig, ever.

---

Right! Also, an object one visitor treats as a secondary object, could be treated as a primary object by the next visitor. You never know.

Same with furniture and skipped LODs. I always hear these things don't need lowest LODs. Actually, you never know if people want to put that couch inside the basement, or on the rooftop deck, or wherever.

[Perrie Juran]

---

Kwakkelde Kwak wrote:

First of all, that is a great looking sim.

However, you are talking about two entirely different things: performance and looks. The sim in the video looks so good because the builder obviously has talent, not because prims or sculpties are so wonderful. Apart from the flexible cape and hair, I don't see anything that couldn't be built (more efficiently) in mesh. For example, the pyramids use 12 triangles from any distance, a pyramid in mesh would only use half of that, reducing the load on the end user by a staggering 50%.

The giant statue would probably cost a fortune in LI if built in mesh, but it would still be at least as efficient and probably slightly better looking.

One thing I unfortunately cannot answer is how sculpts, prims and mesh compare in network lag. A prim is probably less than 100 bytes. A 64x64 sculpt map in uncompressed jp2 format (used internally in SL) only takes 3kB. Most data of a sculpt is shared and stored locally. A dae file of a a sculpt (I figure the internal SL format is similair) object takes 300kB, or 30 kB when compressed. The uncompressing could result in some lag as well. So if you have a lot of unique mesh objects, things could get laggy I suppose.

---

It is sad the Rezzables left SL.  I see you have been in SL since 2006 so you probably also remember Greenies, another one of his works.  I think he really pushed the limits of what could be done with "Your World, Your Imagination"  at that time.

The lag issues are real but figuring out the answers can drive you crazy.   I have some specific case incidents I have been looking at while trying to help some friends.  When I get a little time I will private message you about it.

Performance versus Looks is always going to be an issue.  The more detail you add the more information there will be to process.  So I do understand the problem.  I would consider something that turned into a blob like in Optimums picture (message 20) totally unacceptable.

[Optimum Actor]

Example of a mesh model with hand made Level of Detail models:

This Jerry Can has a download weight of 0.4. So there isn't really any reason to not provide decent LOD models.

---

This and other examples give me a very good reason to learn to build mesh properly for myself and the group, rather than rely on pre-made mesh objects in the Marketplace. With my aircon unit example, it's hard to tell what they'll look like from the marketplace description, even with a sample image. The Prim version was part of a set and only $L 10. The Mesh version was also part of a set costing $L 99. Both look good on those pages but it's not until you rezz them that you find out how they really look in use. I had a similar problem with stairs. Lots of cheap mesh stairs that look good up close, but on the sets I've been building they deform, presumably because they use the lowest LOD. Not that such purchases are total waste, as they can still be used in close up shots, but it's annoying because it means they weren't fully tested before put on sale.

Likewise the examples of display weights also support the idea for using Mesh over straight Prims and Sculpties - 15 more display weight units than a simple prim but lots more detail. This has answered an indirect question I had about the worth of building Mesh in the first place. Obviously though the workflow may be different because of my projects - prototypes have to get built first for feedback - and whether or not in-world tools are used Blender most certainly will. Also, I suspect I will be spending much more time in the Beta Grid testing mesh for free when I come back to this properly!

This information's been extremely helpful 

[arton Rotaru]

Yep, it's hard to tell just from MP images. Most of my SL buddies build properly LOD meshes though, and they put some wording like "hand made LOD's" or something like that into the listing description. If such wording is not in the listings, it would be best to ask the creator to show the object in-world, which can be inconvenient and time consuming, of course.

Best would be people would offer "complete" mesh assets, with proper LOD models, or they would state in the description that the object has auto generated LOD's. Or that they have set the lower LOD(s) to just a triangle to keep land impact low, or whatever. Unlikely to happen, I know.

So yeah, to come back on topic actually. I would strongly recommend to take the Blender route. There's much to learn, indeed, but learning all this stuff can be satisfying, and can be great fun, too. And yes, the Preview Grid will be your best friend. :matte-motes-smitten:

[BlackMagi Darkwatch]

Not sure if this will be of much help but when I create my LOD models I use the following script to give me an idea on when the LOD switches will happen.  There are way better scripters (at least one goddess & god on this forum thread) who could probably make it better (to work in a linkset for instance) but as mentioned I use it to give me an idea.

 

Script

//Reference sources://http://wiki.secondlife.com/wiki/User:LindaB_Helendale/meshLODanalyzer//http://wiki.secondlife.com/wiki/Mesh/Mesh_Streaming_Cost float getRadius() {     return llVecMag(llGetScale())/2.0 ;}string float2Integer(float f){    integer v = (integer) f;    return (string)v;} float dLowest = 0.03;float dLow = 0.06;float dMid = 0.24;float dHigh = 0.0;string getMid(float radius){    string s = float2Integer(radius / dMid);    return s + "m's";    }string getLow(float radius){    string s = float2Integer(radius / dLow);    return s + "m's";}string getLowest(float radius){    string s = float2Integer(radius / dLowest);    return s + "m's";} default{    state_entry(){        float r = getRadius();        llOwnerSay("\nApproximate LOD switch distances of: '"+llGetObjectName()+"'"            + "\nMedium LOD distance:  "+getMid®+"\n"            + "Low LOD distance: "      +getLow® +"\n"            + "Lowest LOD distance:  "  +getLowest®);                        llRemoveInventory(llGetScriptName());    }}

 

 

Black

[Rolig Loon]

default{    state_entry(){        float r = llVecMag(llGetScale())/2.0;        llOwnerSay("\nApproximate LOD switch distances of: '"+llGetObjectName()+"'"            + "\nMedium LOD distance:  "+(string)((integer)(r/0.24))+ "m"+"\n"            + "Low LOD distance: "      +(string)((integer)(r/0.06))+ "m" +"\n"            + "Lowest LOD distance:  "  +(string)((integer)(r/0.03)) + "m");                        llRemoveInventory(llGetScriptName());    }}

 EDIT:  Ack!  I posted the wrong copy.  This one works.  Sorry about that.

 

[Drongle McMahon]

I think you need to check that.

A 0.5m cube gives...

Approximate LOD switch distances of: 'Object'
Medium LOD distance:  112m
Low LOD distance: 28m
Lowest LOD distance:  14m

How about this...

string fmtf1 ( float num) { 
    return (string)((integer)(num*10)/10) + "." + llGetSubString((string)llRound(num*10), -1, -1);
}default{    state_entry(){        integer i;        list rvlf = [1.125, 2.0, 4.0];        float r = llVecMag(llGetScale())/2;        llOwnerSay(llGetObjectName()+": radius "+fmtf1®+"\n");        for (i=0;i<3;++i){            float f = llList2Float(rvlf,i);            llOwnerSay("\nRenderVolumeLODFactor:   "+ llGetSubString((string)f,0,4)+"\n"            + "      Medium LOD distance:  "+fmtf1(f*r/0.24)+ "m"+"\n"            + "      Low LOD distance:        "         +fmtf1(f*r/0.06)+ "m" +"\n"            + "      Lowest LOD distance:   "  +fmtf1(f*r/0.03) + "m"+"\n\n");        }        llRemoveInventory(llGetScriptName());    }}

 ETA - cleaned mine a bit too.

[Rolig Loon]

Ooops!  I cleaned up the OP's script, made errors from working too fast, and then posted the bad version instead of the one I repaired.  Dumb, dumb, dumb ..... :smileyembarrassed:

Fixed above.

[Optimum Actor]

Am impressed with these scripts. Not only making stuff an art, but tit's also clearly a science as well!

[BlackMagi Darkwatch]

Thank you Rolig, have updated the script to reflect your much better looking version with an addition in the float r declaration.

 

default{    state_entry(){        float r = llVecMag(llGetScale()/2);        llOwnerSay("\nApproximate LOD switch distances of: '"+llGetObjectName()+"'"            + "\nMedium LOD distance:  "+(string)((integer)(r/0.24))+ "m"+"\n"            + "Low LOD distance: "      +(string)((integer)(r/0.06))+ "m" +"\n"            + "Lowest LOD distance:  "  +(string)((integer)(r/0.03)) + "m");                        llRemoveInventory(llGetScriptName());    }}

 

 

@Drongle.  I assume the RenderVolumeLODFactor is the sldier or debug setting that can be changed through the viewer interface?  I use the default setting in Firestorm which I guess is 2 so that would explain the difference in the switch.  I only use the script to get an idea but your version of it rocks

Black

[Drongle McMahon]

RenderVolumeLODFactor (rvlf) can be set in Advanced->Show debug settings. It is also changed by the object detail slider. The default is 1.125, except for Ultra quality where it is 2.0. Many people now set it to 4.0, to avoid seeing ugly LODs of many sculpts. So that's why I chose those values.

[Rolig Loon]

Oh, there's a 2.0 in there? Missed that.  I'll go back and add it in mine.  Sheesh, can't even write a simple script today.

[steph Arnott]

The so called leap forward in visual quality and lower prim count. I stick with prims and adjust the bounding physics unless as I said I have no choice. Mesh just looks flat and fake to me. Also since mesh tp into a sim and the rendering takes so long, never mind. 

ADDED: Mesh takes longer to render, one of my prim builds takes 0.5 to 1.0 sec, a mesh build of a similar theme takes 15.0 secs and looks flat and blurry. I not no the tech stuff, but 1.0 as opposed to 15.0 somthings working a lot harder. eh?

 

[arton Rotaru]

Every prim be it a legacy prim or sculpted prim is nothing else but mesh. So I dunno why one would look flat and blurry and the other not. If you make it look flat and blurry, it certainly will look flat and blurry, no matter of what it is.

The only difference I see between lowpoly mesh and prims is with deferred rendering turned off. The reason why a prim cube has 108 triangles is probably because of the per face lighting, with deferred off. A mesh cube with just 12 triangles will be poorly lit with local lights. The Prim cube will look a bit better lit, but still not really nice.

With deferred rendering that's not an issue at all though. And with normal/specular mapping even more so not.

However, if you are happy with prims, that's fine. I'm very happy with mesh, because of I'm tired of building a sandcastle with wooden bricks.

I have also never seen a mesh taking 15 seconds to load. I dunno if you are referring to just the mesh data, or it's textures as well? If it's only the mesh data, this would be a very high poly/vertices count mesh. Mesh will take a bit more time to download, because the viewer has all the prim parameters built in already. However, sculpted prims are usually the last thing to be fully loaded, because they are just a texture, which has to be downloaded first.