Two Tri Trick?

[Macrocosm Draegonne]

I searched for quite a while, and found the old post eventually, but the pictures are all missing now lol, and those that discussed it were a bit vague on account of the excellent tutorial images, which I only partly remember.  Im optimizing a mesh items lowest LOD, and I need to remove one more tri to be golden at 14 tri, of course that one tri is being used to hide a material area no longer visible at that distance.  I know there was a way to do some *****ery and end up with two verts and one less tri. right?  Does anyone remember the trick?  I've tried a bunch of things to no avail yet. ?

Edited September 25, 2018 by Macrocosm Draegonne

[Macrocosm Draegonne]

I think I figured it out, to collapse two of the three vertices to the same location gave me the result I wanted it seems.

Edit: Nope that gave MAV_TOO_FEW_UNIQUE_VERTICES error, hmm.  Well I guess I shouldnt complain, ive got this mesh down to half an li already.

Edited September 25, 2018 by Macrocosm Draegonne

[Macrocosm Draegonne]

.

Edited September 27, 2018 by Macrocosm Draegonne

[Macrocosm Draegonne]

I suppose my memory is a bit fuzzy on that old post, but I could have sworn there was a trick to make those remaining single tri's hidden in the LOD model (for a texture not used in the LOD of the mesh), wasn't there a way to be lighter on LI and further out of the way?

I have uploaded the same asset dozens of times in beta grid, trying for the best li score and lod effect, im finally getting somewhat better, especially with the blender to SL workflows.

This is the excellent post now missing all the images, I remember all the great examples people spent a lot of time giving good visuals.  I looked in the wayback website and the forums are not cached, so I guess all thats gone?

 

Edited September 27, 2018 by Macrocosm Draegonne

[Macrocosm Draegonne]

Ok I finally figured out my confusion, its still disappointing how that page lost all its images.  However, I was mixing up two things, it was a suggestion for making the flip side of plane visible using one extra tri, and it does contain another material slot if you want since it has a face and can be uv mapped on both sides.  Works great, but the problem is it doesnt work on a tri, must be a plane   so using it to hide unused texture slots wont gain any benefits. 

It is a cool trick for a visible other side though, in my testing the viewer still counted the additional two tri's for the flip side of the plane, but it only charged two extra vertices, thats half the verts for a visible other side, pretty neat in and of itself.

I am still wondering what other ways we can further optimize the LOD objects, especially in regard to the unused texture slots that the uploader wants there anyway.

[ChinRey]

1 hour ago, Macrocosm Draegonne said:

Ok I finally figured out my confusion, its still disappointing how that page lost all its images.

Yes, unfortunately it was not possible to transfer the images from the old to the new forum. Lots of good info got lost that way.

 

1 hour ago, Macrocosm Draegonne said:

I am still wondering what other ways we can further optimize the LOD objects,

Oh, there are so many ways, I could write a book!

But when it comes to those "face placeholder" triangles, see if they can do double duty and be put to other uses too. Sometimes they can be used to fill out a shape where the texture doesn't matter, sometimes they can be used to define the outer dimensions of the model.

[Macrocosm Draegonne]

1 minute ago, ChinRey said:

Oh, there are so many ways, I could write a book!

But when it comes to those "face placeholder" triangles, see if they can do double duty and be put to other uses too. Sometimes they can be used to fill out a shape where the texture doesn't matter, sometimes they can be used to define the outer dimensions of the model.

Ok I think I get what you're saying, so dont hide them, put them right out front and make use of them somehow, thats a good idea to use sometimes!

its only in the lowest LOD that I end up with these extra tri's, so I could dump the tri in one of the primary areas, if there be any good spots not culled when optimizing, and texture permitting. 

I still wish I could eek out those last tri's tho! or at least some of the verts, ive tried a bunch of tricks so far lol 

I have connected it to existing mesh to save on verts & edges, only one tri for each unused material, done end to end to form quads with two materials each quad, and keep them all at the same z, y and x coordinates proportionally.

[ChinRey]

5 minutes ago, Macrocosm Draegonne said:

I have connected it to existing mesh to save on verts & edges, only one tri for each unused material, done end to end to form quads with two materials each quad, and keep them all at the same z, y and x coordinates proportionally.

That helps although it doesn't work the way you think. Each face has its own set of vertices in SL so a vertice that is shared is split into two. It still helps a bit though because those two copies of the same original vertice still have the same coordinates and normals data and shared data means a smaller compressed file and that reduces the download weight.

[Macrocosm Draegonne]

41 minutes ago, ChinRey said:

That helps although it doesn't work the way you think. Each face has its own set of vertices in SL so a vertice that is shared is split into two. It still helps a bit though because those two copies of the same original vertice still have the same coordinates and normals data and shared data means a smaller compressed file and that reduces the download weight.

Oh, is that why its adding some vertices on import?   my lowest LOD was 12 tri's 20 verts, but in the uploader shows at 26, although the tri's did not go up, the .500 score is the Server number, Download is below 500.  Im trying to be as efficient as I can manage and those extra verts were really worring me, like seriously, I looked for them... and now i know why I couldn't find them. lol ?

I had an idea for its lowest lod that would be even lower tri, by making a small lowfi baked texture spot of the whole thing on the main diffuse to smear over the lod, its from very far away so it should be fine.  But of course ill still have to hide those unused textures, so its only useful in some situations to reduce tri's in the lod, if all materials use the same diffuse there should be no trouble at all, but that is not always possible for every situation, especially when using tiling textures as I am in this current build.

Edited September 27, 2018 by Macrocosm Draegonne

[ChinRey]

Just now, Macrocosm Draegonne said:

Oh, is that why its adding some vertices on import?

Yes, and normals too. An SL mesh vertice can only have one set of normals data so if two triangles are at an angle and don't have smooth normals, any vertice they share will be split.

I think it's important to know that SL's implementation of mesh is what's technically known as a "crude hack" and much of what you may know about mesh from other environment don't apply here.

[Macrocosm Draegonne]

22 minutes ago, ChinRey said:

Yes, and normals too. An SL mesh vertice can only have one set of normals data so if two triangles are at an angle and don't have smooth normals, any vertice they share will be split.

I think it's important to know that SL's implementation of mesh is what's technically known as a "crude hack" and much of what you may know about mesh from other environment don't apply here.

Well, I dont know much about the mesh in other environments, other than Skyrim SE and Citites Skylines to a small degree, both have their own hacks and particularities lol  SL is the first one im actually making some mesh for though, didnt get around to it much in the others yet.

I had noticed mucking around with my Normals tweaked the li, this current thing is all set to smooth, though maybe not entirely.  Hmm another few dozen uploads and ill have it down, its faster and better with each attempt lol.

[Macrocosm Draegonne]

I really hope what I've seen suggested is true about texture dimensions being increased, creating a large atlas with relevant textures would make a more "instant-rez" feeling since a great many more objects will come into view once those textures load.  I am going to do this anyway (as much as is workable) even with the 1024x2 limit, but when that can be 4096 x 8192, or other variations, etc, things will both be less expensive on the draw calls and rendering, and feel better to the user as more comes into view in logical amounts.  Not to mention the greater level of detail can be provided in the case someone is up close.  And, a whole lot less files being served from the server too, though about the same file size generally speaking.

Also, while we're at it, why not a new compression mechanism that both encrypts everything and reduces file size by 85%?? ?

Edited September 28, 2018 by Macrocosm Draegonne

[ChinRey]

4 hours ago, Macrocosm Draegonne said:

but when that can be 4096 x 8192, or other variations, etc, things will both be less expensive on the draw calls and rendering

No it wouldn't for three or possibly four reasons.

Think about it. Ten 4096x8192 textures is enough to overload many people's VRAM. 50 of them will cause serious problems for most computers. Make it 50 8192x8192s and everybody will struggle. Large texture atlases work very well in carefully optimized 3D environments with relatively few objects and where everything is made to work together and using the same atlas. A Second Life scene is made from hundreds, even thousands, of unmatched items that can't all use the same texture atlas - they are not even made by the same creator.

SL scenes also have a much higher total pixel density than a typical computer game because they tend to be more complex. Even a fairly simple scene will need hundreds of textures. A more elaborate scene with a dozen avatars in it may well require several thousand textures. With that amount, even a consistent use of 512s is pushing the limits.

Then there is the SL mentality. One of the most prestigious SL designers uses 1024s for the shadow prims underneath his builds. I have seen houses where each identical window is a separate upload using a separate copy of the same texture. Idiocy like those examples are not at all unusual, they represent the typical level of efficiency consciousness we have to struggle with in SL. As the old saying goes: don't give the monkey the key to the banana plantation.

The fourth reason is the one I'm not sure of but as far as I know, SL doesn't have consolidated draw calls. It certainly doesn't have it across linksets, which is abd enough for the texture atlas concept, but I don't believe it even consolidates on object level, each face one ach mesh is a separate draw call even if the texture is the same.

 

[Macrocosm Draegonne]

17 minutes ago, ChinRey said:

No it wouldn't for three or possibly four reasons.

Think about it. Ten 4096x8192 textures is enough to overload many people's VRAM. 50 of them will cause serious problems for most computers. Make it 50 8192x8192s and everybody will struggle. Large texture atlases work very well in carefully optimized 3D environments with relatively few objects and where everything is made to work together and using the same atlas. A Second Life scene is made from hundreds, even thousands, of unmatched items that can't all use the same texture atlas - they are not even made by the same creator.

SL scenes also have a much higher total pixel density than a typical computer game because they tend to be more complex. Even a fairly simple scene will need hundreds of textures. A more elaborate scene with a dozen avatars in it may well require several thousand textures. With that amount, even a consistent use of 512s is pushing the limits.

Then there is the SL mentality. One of the most prestigious SL designers uses 1024s for the shadow prims underneath his builds. I have seen houses where each identical window is a separate upload using a separate copy of the same texture. Idiocy like those examples are not at all unusual, they represent the typical level of efficiency consciousness we have to struggle with in SL. As the old saying goes: don't give the monkey the key to the banana plantation.

The fourth reason is the one I'm not sure of but as far as I know, SL doesn't have consolidated draw calls. It certainly doesn't have it across linksets, which is abd enough for the texture atlas concept, but I don't believe it even consolidates on object level, each face one ach mesh is a separate draw call even if the texture is the same.

 

Yes I agree, but in this case its still only loading the images that will load anyway, the only difference is they're in one file, when it makes sense, atlas has to be somewhat better right performing right?  I was thinking more for texture sets which will be everywhere in a sim, the ground textures, or building sets, things an atlas does well. 

I still think we will have larger textures eventually, if what you're saying is true, and what others are saying, the full rez texture hardly every loads for anyone, unless they're zoomed way in, or at least that is the goal of some tweaks coming right?

Edited September 28, 2018 by Macrocosm Draegonne

[Kyrah Abattoir]

Another thing about large atlases, games like rage use a gigantic texture atlas that range in the gigabits of texture data, however they aren't loaded in vram as is, there is a complex system in the background that loads and unloads chunks of it in and out of ram/vram, at varying resolution, depend what the player is looking at and how far he is from it.

Recycling from a common pool of textures is the next best thing when it comes to secondlife (and less 'cutting edge' engines), and the smaller the better.

Games like minecraft atlas all their textures in a handful of texture sheets but that's also because they use such a low resolution to begin with that atlasing them has next to no cost (they can cram 4096 tiles in a single 1024x1024)

Oh yeah i forgot, when atlassing textures you will encounter issues with edge seams because texture filtering will blend the edges of your tiles with the next one.

[ChinRey]

On 9/28/2018 at 12:12 PM, Macrocosm Draegonne said:

Yes I agree, but in this case its still only loading the images that will load anyway, the only difference is they're in one file, when it makes sense, atlas has to be somewhat better right performing right?

Yes but it doesn't make much sense in Sl becuase it is impossible to predict which textures go together in the same scene.

 

On 9/28/2018 at 12:12 PM, Macrocosm Draegonne said:

I was thinking more for texture sets which will be everywhere in a sim, the ground textures, or building sets, things an atlas does well.

A 4096x4096 equals 16 1024s. If you use that many 1024s for the ground or for a single build in SL, you're doing something wrong.

 

On 9/28/2018 at 12:12 PM, Macrocosm Draegonne said:

I still think we will have larger textures eventually,

SL had 2048 and 4096 textures for a while but LL had to give it up because it was turning into a lag disaster. There are still a few of them around and you really, really do not want to use them. Take my word for it, I've tried.

 

On 9/28/2018 at 12:12 PM, Macrocosm Draegonne said:

if what you're saying is true, and what others are saying, the full rez texture hardly every loads for anyone, unless they're zoomed way in, or at least that is the goal of some tweaks coming right?

SL already has mip-mapping, with the extensive baking abuse we see today I doubt it would function at all without. That reduces render load but does nothing to download time and it actually increases the load on the VRAM since it has to store several copies of each texture with diferent resolutions.

[Macrocosm Draegonne]

2 minutes ago, ChinRey said:

A 4096x4096 equals 16 1024s. If you use that many 1024s for the ground or for a single build in SL, you're doing something wrong. 

16?  Wouldn't that be four?  Yes im a noob if it werent already apparent lol

4 minutes ago, ChinRey said:

SL already has mip-mapping, with the extensive baking abuse we see today I doubt it would function at all without. That reduces render load but does nothing to download time and it actually increases the load on the VRAM since it has to store several copies of each texture with diferent resolutions.

Yes, I was just reading up on that, very cool system, perhaps that is what will play a role in the new cache system they've hinted at for better performance?  I have to believe that bigger textures are coming some day, tech is not stationary, it evolves, compression becomes better, io gets improved, LOD and mipmapping can make sure the load is handled well. 1024 is an old limit from a world that no longer exists, eventually that limit will fall like any other.  This is hypothetical of course lol.  I have to have optimism, otherwise the future seems boring.

[ChinRey]

1 minute ago, Macrocosm Draegonne said:

16?  Wouldn't that be four?  Yes im a noob if it werent already apparent lol

No, it would be 4x4 which equals 16.

 

5 minutes ago, Macrocosm Draegonne said:

I have to believe that bigger textures are coming some day, tech is not stationary,

I hope so too but that is far into the future. Let's see how things are ten years from now.

[Macrocosm Draegonne]

4 hours ago, Kyrah Abattoir said:

Another thing about large atlases, games like rage use a gigantic texture atlas that range in the gigabits of texture data, however they aren't loaded in vram as is, there is a complex system in the background that loads and unloads chunks of it in and out of ram/vram, at varying resolution, depend what the player is looking at and how far he is from it.

Recycling from a common pool of textures is the next best thing when it comes to secondlife (and less 'cutting edge' engines), and the smaller the better.

Games like minecraft atlas all their textures in a handful of texture sheets but that's also because they use such a low resolution to begin with that atlasing them has next to no cost (they can cram 4096 tiles in a single 1024x1024)

Oh yeah i forgot, when atlassing textures you will encounter issues with edge seams because texture filtering will blend the edges of your tiles with the next one.

I am going to reuse textures and normals as much as possible, to try and eeek out every bit of optimizing I can hehe. 

Yeah it would be interesting tho!  An atlas if ever allowed in SL would be best limited to particular things, perhaps usable by Estate/SIM owner only.  Could make a few categories like terrain/flora/structures, or simply limit the quantity of them per sim or whatever limits seem smart.  I figured it would need an abstraction to for instance be able to tile a square image out of a larger image those.

But I suppose the mipmaping and such make atlases unnecessary, the trouble is the 1024 size limit severely punishes large objects as they end up having a ton of textures or end up a blurry mess.  I am going to use tiling textures as much as I can, and layers, to try and combat the issue.

 

 

[Macrocosm Draegonne]

11 minutes ago, ChinRey said:

20 minutes ago, Macrocosm Draegonne said:

16?  Wouldn't that be four?  Yes im a noob if it werent already apparent lol

No, it would be 4x4 which equals 16.

You're counting all sides?  I was just thinking as far as texture space, only four  eight 1024's would fit in that area right?

lmfao nevermind, my coffee is kicking in now! ?

Edited September 30, 2018 by Macrocosm Draegonne

[ChinRey]

11 minutes ago, Macrocosm Draegonne said:

You're counting all sides?  I was just thinking as far as texture space, only four  eight 1024's would fit in that area right?

lmfao nevermind, my coffee is kicking in now! ?

But I had already started making this illustration, I can't let it go to waste!

It is an important point anyway, and one many don't seem to grasp even with a healthy dose of coffee: doubling the resolution doesn't double the number of pixels - and thus the worklaod and memory use - it quadruples it.

[Macrocosm Draegonne]

12 minutes ago, ChinRey said:

But I had already started making this illustration, I can't let it go to waste!

It is an important point anyway, and one many don't seem to grasp even with a healthy dose of coffee: doubling the resolution doesn't double the number of pixels - and thus the worklaod and memory use - it quadruples it.

Great point, it really illustrates what an atlas could do though, thats 15 less calls to a texture potentially.

The higher resolution is nicer though for certain things, especially mountains and terrain, but also skin or any other texture really.  The issue is viewer optimization more than texture size at this point, computers are a lot more capable these days on average, compression could get faster too right?  SL barely uses any resources on my machine, usually way less than max 30% of processor and gpu, and a tiny itty bit part of my ram lol.

For larger textures i wouldnt want them all just downloading, the mipmapping could control so those are only seen when up really close, and/or  are massive huge objects and are LOD controlled. 

EDIT: But I guess thats not how it works, you say it downloads the full image regardless? So it chooses to use the mip maps for LOD to save viewer stress?

I have over 70gigs of mods and textures in my Skyrim build lol lots of 4k textures, but thats an instanced game and a whole different setup of course.

Edited September 30, 2018 by Macrocosm Draegonne

[Kyrah Abattoir]

I don't think what SL does is what you'd consider "true" mipmapping. And regardless, mipmapping reduces the render load, but all the mips are usually loaded in vram together.

[Beq Janus]

On 9/30/2018 at 8:15 AM, Macrocosm Draegonne said:

Great point, it really illustrates what an atlas could do though, thats 15 less calls to a texture potentially.

The higher resolution is nicer though for certain things, especially mountains and terrain, but also skin or any other texture really.  The issue is viewer optimization more than texture size at this point, computers are a lot more capable these days on average, compression could get faster too right?  SL barely uses any resources on my machine, usually way less than max 30% of processor and gpu, and a tiny itty bit part of my ram lol.

For larger textures i wouldnt want them all just downloading, the mipmapping could control so those are only seen when up really close, and/or  are massive huge objects and are LOD controlled. 

EDIT: But I guess thats not how it works, you say it downloads the full image regardless? So it chooses to use the mip maps for LOD to save viewer stress?

I have over 70gigs of mods and textures in my Skyrim build lol lots of 4k textures, but thats an instanced game and a whole different setup of course.

That's arguably 15 fewer calls to a texture, but 16 times the data to transfer, which in a non-curated environment like SL is the real problem. As soon as you allow 4096x4096 everyone starts slapping them on their shoelaces and nipple rings. Inside the viewer not only do we then have to transfer 16 times the amount of data, we then have to purge it more regularly to replace it with the next set of fancy shoe laces that need to be rendered. The only way larger textures make any sense is if a means of enforcing their use as atlases could be defined and adequately enforced. You also have to consider that while many of us may have stonking great video cards the majority of SL users are lagging behind us, with many on smaller laptops without a dedicated graphics card and so we also need to deal with managing their quality.

As for "mipmaps", true mipmaps are a GPU thing, in SL we have discard levels, these are effectively an analogue of mipmaps and the viewer will request the discard level most appropriate to the size (on screen) of the object being viewed. This is why in fact you get the progressive rendering of textures as the discards are loaded. This adds a 33% overhead to the texture sizes and this does have to be carried in RAM of course ultimately. while the following page is quite old it is not fundamentally out of date http://wiki.secondlife.com/wiki/Image_System#Discard_Level_and_Mip_Mapping

People often poke SL as being behind the curve relative to "other games", but it is always best to bear in mind that "other games" have content that is professionally designed and curated and often gives the finger to low-end users too. It's a sensitive juggling act and while there is undoubtedly a lot that could be done to make things better, the limits we have are often there to protect us from wholesale abuse.

Beq

 

[Kyrah Abattoir]

I agree, and unfortunately those limits are nowhere near what they should be for a good overall SL experience.