Optimisation: Tris vs Vram

[Ana Stubbs]

I admit I'm in the exact opposite situation to the majority of SL creators, but due to the audience my work caters to, I have to severely optimise, for both complexity and texture size. My target av has a computer which barely runs SL at all, and potentially uses an expensive, metered connection.

With that in mind, how do I find the balance between adding geometry to a build or faking it via a normal map?

I'm leaning towards the latter, because the extra textures don't download for people not using ALM, and because even normal textures can be reused, but is there any point at which the overhead of the extra texture becomes more of a problem than extra geometry?

ii

This is a slightly ludicrous example, because I didn't properly optimise either the geometry or texture size, and one is a sculptie I used for comparison, but the columns in this image are as follows

	Triangles	Vram
Left	64	516 KB
Middle	576	4 KB
Right	2048	20 KB

I'd really appreciate some expert advice, because I'm a novice modeler, and most of what's been written on the subject seems to be about the evils of using twenty 1024x1024 textures on an earring with 50k tris - an important subject, but it seems a little hard to apply down here at the other end of the telescope!

[Coffee Pancake]

Textures are cheap to render & shade in real time (compared to lighting more complicated geometry) and while the viewer doesn't handle loading and degrading them as well as it could, it is a very safe option as the situation can only ever improve. 

The basic rules of good modelling still stand. Never model anything you can't see, don't use geometry when a texture will do and when possible, reuse the texture as much as you can in the same scene.

 

[Ana Stubbs]

Thank you for such a clear and concise answer!

[Chic Aeon]

I would suggest better textures and less geometry. A typical "trick" is to bake your texture (I use Blender Cycles but not sure what you have )using a high poly model but UPLOAD an equivalent but low poly version. I don't often need to do this with the things that I make, but I have -- and it works well.

Normal maps are fine for some things BUT not everyone sees them AND they can look really horrible under some lighting conditions. Since we have no control over the lighting in Second Life and we have no way of knowing what folks are using for their Windlights, I try and make the texture contain as much information as it can. I very seldom use normal maps and then mostly on organic things like rocks. Rocks can look VERY bumpy and still be believable. Other surfaces? Not so much.

So far as your examples go, does the low poly model have smooth shading? Hard to tell. That would likely help. OR you could try putting a bevel on the edges that protrude and also making smooth shading. That an a high poly (high resolution) bake would likely get you something as good as your high poly model.

 

Your pillar example should look fine with a well-baked 1024 texture.  

Good luck.

 

[Ana Stubbs]

Yes, it uses smooth shading, but I wasn't intending to bake a 1024 texture - it seemed better to take a long thin seamless texture and tile it down vertically. The actual model I made in Blender is very short and squat (a bit like an elephant stood on it), then stretched out inworld.

The low poly model is a plain cylinder with a normal map baked from the high poly model.

I know how to make textures seamless, and I know how to do a simple bake in Cycles, but wouldn't have a clue where to start with baking a seamless texture, if it's possible.

EDIT: Not everyone seeing normal maps is a positive in this case - anyone who doesn't will just see a cylindrical column, without knowing that anything was amiss. I've always felt that a graceful degradation of the experience is best.

Edited July 24, 2018 by Ana Stubbs

[ChinRey]

7 hours ago, Ana Stubbs said:

but is there any point at which the overhead of the extra texture becomes more of a problem than extra geometry?

CoffeeDujour gave you a very good answer but there's one thing to add: yes, there is such a point. It's when you run out of VRAM and the computer has to start swapping textures in and out of it. The moment you reach that point, textures become a much bigger cause for lag than geometry and unfortunately that happens far too often in SL.

As a rule, keep the total VRAM usage for the entire scene below 1 GB and you'll be fine. (1 GB equals about 250 1024x1024 textures or 1000 512x512s or 4000 256x256.)

[Wulfie Reanimator]

And to make things even more complicated, since this thread seems to be focusing on memory, the mesh itself has a very small memory footprint because it's just vector data which is very efficient to compress.

So if your concern is memory, go for extra tris because they're cheaper. If your concern is rendering performance, go for textures (not even 1024, it's way overkill). But realistically, you'll have to do the balancing dance. 

[Kyrah Abattoir]

• Use and abuse texture repeats whenever you can, if a part is present multiple times in a single object, figure out if you can get away with using the same piece of texture for it on all the identical subparts.
• Pack your UVs to maximize texture area, you can also save on texture size by using non square textures (they still have to fit the 'power of two' rule tho).
• Use the viewer built-in textures when you can and if you can (default white as a specular map is useful in a lot of cases instead of making a custom one)
• Recycle textures across multiple objects if they share simmilar details.
• Once you are happy with all your textures, try to scale them down, uniformly and non uniformly. Sometimes the loss in resolution won't be noticeable and you just saved some memory for very little effort. Non uniform scaling can also create some interesting illusions of detail when pixels are halved in only one direction.
• For the point above, be mindful of how much space you leave between UV islands, if it's already too tight, reducing the texture will create seams.
• While a constant pixel size feels nice and homogenous, drop down resolution on small and/or unimportant parts.
• Remember that a lot of details are essentially "greeble" they exist only to be conciously ignored.
• Remember that there is no such thing as a free lunch. No matter how you do it, adding detail will effectively raise the cost to render that object, the real question is "by how much?".

[Coffee Pancake]

1 hour ago, Kyrah Abattoir said:

• Once you are happy with all your textures, try to scale them down, uniformly and non uniformly. Sometimes the loss in resolution won't be noticeable and you just saved some memory for very little effort. Non uniform scaling can also create some interesting illusions of detail when pixels are halved in only one direction.

Rather than simply doing this to reduce texture size, better to scale the UVs and use the left over space on the texture for something else. 1x 1024x1024 is better than 2x 512x1024

[Chic Aeon]

2 hours ago, Kyrah Abattoir said:

• Use and abuse texture repeats whenever you can, if a part is present multiple times in a single object, figure out if you can get away with using the same piece of texture for it on all the identical subparts.
• Pack your UVs to maximize texture area, you can also save on texture size by using non square textures (they still have to fit the 'power of two' rule tho).
• Use the viewer built-in textures when you can and if you can (default white as a specular map is useful in a lot of cases instead of making a custom one)
• Recycle textures across multiple objects if they share simmilar details.
• Once you are happy with all your textures, try to scale them down, uniformly and non uniformly. Sometimes the loss in resolution won't be noticeable and you just saved some memory for very little effort. Non uniform scaling can also create some interesting illusions of detail when pixels are halved in only one direction.
• For the point above, be mindful of how much space you leave between UV islands, if it's already too tight, reducing the texture will create seams.
• While a constant pixel size feels nice and homogenous, drop down resolution on small and/or unimportant parts.
• Remember that a lot of details are essentially "greeble" they exist only to be conciously ignored.
• Remember that there is no such thing as a free lunch. No matter how you do it, adding detail will effectively raise the cost to render that object, the real question is "by how much?".

Just wanted to note that many of these bullet points do NOT work well with baked textures -- and even with non-baked textures reusing, inconsistency in scaling differently and using textures too small to make a realistic look when scaled will severely damage the look of the finished product. 

The whole point of baking textures, shine, ambient shadows (and cast shadows if you like that) is REALISM.  Throwing all that away for the sake of efficiency pretty much makes all that learning useless. Might as well just slap on some tilling textures from the library :D.   

There is a SANE way to make things pretty and still be efficient. 

[Ana Stubbs]

My focus on memory is partly a proxy for download size, which I haven't found a good way of measuring. I'm hoping that by optimising for texture size, I'm also indirectly optimising for download size. I know that in an ideal world we'd all have caches the size of Mars, but I can't realistically enforce that on everyone else.

[ChinRey]

1 hour ago, Ana Stubbs said:

My focus on memory is partly a proxy for download size, which I haven't found a good way of measuring.

No matter what file format you upload as, SL uses jpeg2000 (which is not in any way the same format as jpeg btw) internally. With lossless compression the format typically gives a size reduction around 85%. So expect about 50-70 Kb for a 1024 and 10-20 for a 512. But remember that bandwidth is measured in bits, not bytes. So multiply by eight to get the number of kilobytes and then add a little bit of overhead.

There are lots of other factors than the file size that affect how fast textures load though.

 

[Ana Stubbs]

Thanks, I guess I could have found that out myself.

Download size does directly affect users on metered or capped connections. I've known avs who ration their use of voice, and plan visits to new sims depending on how much data they have left this month. It seems alien to me on my 80/20 VDSL connection, but I do admire their persistence and dedication.

[Coffee Pancake]

3 hours ago, Ana Stubbs said:

My focus on memory is partly a proxy for download size, which I haven't found a good way of measuring. I'm hoping that by optimising for texture size, I'm also indirectly optimising for download size. I know that in an ideal world we'd all have caches the size of Mars, but I can't realistically enforce that on everyone else.

You're fighting a losing quest with that on SL. The individual file downloads are not what gobbles up your data (and I'm not including voice).

[Ana Stubbs]

37 minutes ago, CoffeeDujour said:

You're fighting a losing quest with that on SL. The individual file downloads are not what gobbles up your data (and I'm not including voice).

What does? (I assume you're not counting music or media either).

I'd always assumed downloads accounted for at least some of it. The textures don't magically appear, they have to be downloaded from the CDN.

[Coffee Pancake]

Textures (in an ideal world with a functioning cache) are one time downloads. If you purposefully don't roam much then most textures will come from local storage.

The viewer is constantly streaming data from SL. 8KB per sec on an empty region ranging up to a couple of hundred KB/s on a busier one with people moving about (or people on neighboring regions), object updates etc. That racks up fast.

[ChinRey]

2 hours ago, CoffeeDujour said:

You're fighting a losing quest with that on SL.

Yes but to quote Norwegian poet Jan Erik Vold: "It's hopeless and we never give up!"

[Ana Stubbs]

17 minutes ago, CoffeeDujour said:

Textures (in an ideal world with a functioning cache) are one time downloads. If you purposefully don't roam much then most textures will come from local storage.

When you find the ideal world, sign me up

17 minutes ago, CoffeeDujour said:

Textures (in an ideal world with a functioning cache) are one time downloads. If you purposefully don't roam much then most textures will come from local storage.

The viewer is constantly streaming data from SL. 8KB per sec on an empty region ranging up to a couple of hundred KB/s on a busier one with people moving about (or people on neighboring regions), object updates etc. That racks up fast.

Ouch, that would indeed do it. I think I'd still like to keep them reasonably low though - you still have that initial download, and it will give me more confidence when assuring people that their busted internet cap is not my fault, no matter how much they want to believe that it is.

[Coffee Pancake]

6 minutes ago, Ana Stubbs said:

and it will give me more confidence when assuring people that their busted internet cap is not my fault, no matter how much they want to believe that it is.

If someone on Second Life accuses you of busting their internet data cap then the only correct response is double spaced, excessively verbose and written entirely in unicode characters that happen to look like letters.

[Kyrah Abattoir]

On 7/24/2018 at 5:02 PM, Chic Aeon said:

Just wanted to note that many of these bullet points do NOT work well with baked textures -- and even with non-baked textures reusing, inconsistency in scaling differently and using textures too small to make a realistic look when scaled will severely damage the look of the finished product. 

The whole point of baking textures, shine, ambient shadows (and cast shadows if you like that) is REALISM.  Throwing all that away for the sake of efficiency pretty much makes all that learning useless. Might as well just slap on some tilling textures from the library :D.   

There is a SANE way to make things pretty and still be efficient. 

Baked textures doesn't mean you have to do it blind and without consideration, come on, you're better than that.

Building creators tend to be major offenders in this department. They aparently didn't get the memo that we aren't in 2008 anymore.

Scaling inconsistencies typically do not matter when we are talking about  50 - 150% difference between maps. Most people won't notice, I usually reduce texture resolution for things like underside, hole caps and lining on my items because it's not important, it only exist to be ignored. Likewise, If i can get away with it i'll slightly enlarge the areas that contain important elements that can benefit from a little more texture area.

The whole point of normal maps, realtime ambient occlusion and realtime shadows is so you're not loading the vram with huge, heavily pre-lit textures (since that's the only way you'll be able to achieve an acceptable look without lightmapping).

If you want to throw the realism argument, don't use ambient occlusion at all, because the point of AO has never been that it was realistic, it's just eye pleasing.

 

The PROPER way is to use every trick in the book to get a similar (or better) result at a lower cost, not just the ones that are easy or convenient.

Edited July 25, 2018 by Kyrah Abattoir

[Chic Aeon]

You can do a perfectly great job with baked textures and still keep your texture use low. Not all creators that are making baked texture goods are sloppy. 

I pretty much disagree with pretty much all you have said Kyrah but you have you point of view and I have mine.