Building and texturing for reduced lag - a request for info

Does anyone have a link to building techniques with reduced lag in mind?


For examples of what I mean, when mapping for Half-Life and Half-Life2,
one has to be constantly keeping in mind the accepted limits for how many
polygons should be rendered in your view at any point in the environment.

So, using for example, the equivalent of a cube prim in that engine, if you
had a texture tiled once on each face (U 1.0 v 1.0) then each face is
counted as 2 polys. But, if you tile a texture on that face 10 times in each
direction, that same face is now counted as 200 polys. If all six faces are
textured like that it starts to add up fast.

Mappers have to use every trick they can think of to keep the poly count
as low as possible (while still making things look good) so you only repeat
tiling textures on faces that really matter.

Also, there is a texture that is used called "null" that looks the same as the
SL texture "totallyclear". If you apply it to faces that are never seen
(for example in between pieces of floor and walls that butt together) it
effectively strips away those polys from being rendered and frees up
polys for more important faces.

It's also taboo in that engine to intersect brushes (prims) as the intersection
point creates many unnecessary polygons (If you've ever seen a bad boolean
you'll get what I mean.)

I realize that this is a totally different engine, with it's own strengths/weaknesses,
but coming from that school of content creation, these issues are in my mind
when I'm building here and looking at other builds. I can't help but think
that there must be simple things we could be teaching all builders that
would help everyone's computers run faster.

So, if you can link me to this sort of info I'd appreciate it.

I'd love to know if using totallyclear on inner faces would help,
if texture scaling affects us all (as well as texture resolution),
if avoiding prim intersection would be well advised (or doesn't
matter).

Another thing I've been thinking about is that we need a function in the
build tools that allows us to do a texture replace. Imagine if you have
a prim you have selected and applied a texture to on all sides at once.
Later you change your mind and decide to retexture one or more of the
faces you can see, but forget the ones underneath, behind or in between.
Imagine this happens more than once on the same build, because I'm
sure it does.
Now when anyone approaches that build, their client is streaming in an
extra texture (or 2 or 6 etc) you can't even see.
It'd be nice to be able to seek out these textures that have become
obsolete to the build and do a replacement on the entire link set,
say, replace them all with totallyclear.
Not to mention, this would be a great help just for changing your mind
about a texture you are building with.

Does this function exist already? or is there a script that does this?
If not, where should I go to request a feature?


Thanks for reading. And thanks in advance for any links.

Interesting. I've always thought building should be more like this.

Purely out of a desire to be ordered and tidy, I make a point of laying textures only on visible faces but I sometimes find I have to overlay some colour on adjoining faces to disguise a 'keyline' the camera will insist on rendering where two prims are supposed to meet flush with each other.

I never overlap prims if I can help it.

My build renders pretty quickly in comparison to many I've visited but I put that down to the private estate where I live: the landlord, Dirk Talamasca, is very good about running it smoothly. I can't say that any of the steps I take in building contribute directly to a fast render but they do help me keep better track of what I'm doing.

Nevertheless, it would be good to have a more comprehensive texture editing feature that would work on a find/replace basis. For the time being, I make occasional use of the much maligned GLIntercept to check texture usage although that is a very heavy-handed way of finding more or less identical versions of the same thing.

I'd like to see an intermediate/advanced class that demonstrates these concepts.

One thing I can mention tho, while I'm very familiar with the texture "totally clear" I've never seen "null" that being said, since a third texture "default transparent" is now a part of the library, it should probably be used instead, since everyone has it already.

My 2 L$ on this, in random order, and unsupported by facts:

* SL doesn't have a "no render" texture, unfortunately.
* Fully transparent textures ARE rendered.
* Any texture with an alpha channel (whether it's fully transparent, or appears fully opaque) will slow down the viewer framerate, especially when there are several of them overlapping in your view.
* Texturing doesn't affect the polygon count, but having repeats higher than 1.0 is rumored to have a (small) cpu overhead.
* A large number of unique textures is bad.
* High resolution textures are detrimental to high performance, but I think one 512x512 texture is better than four 256x256 textures, if you can manage that (atlasing.)


I obviously have no numbers to back this up, but in my opinion, the factors you should keep in mind when building are, in this order:

1. As few alpha textures as possible.
2. As few unique textures as possible.
3. Textures as small as you can make them.

three small clarifications,

there is a transparent texture that produces object occlusion (two in fact, know as the invisiprim textures) it itself is rendered, but can occlude other textures to prevent them from being rendered if it's on a large enough object (used for megaprim clutter screens)

any change in a textures repeats (including fractional) will increase overhead slightly, as will differences between image aspect ratio vs prim face aspect ratio / curvature, but those difference are negligible in light of render distance changes.

the differences between load for 4@256^2 vs 1@512^2 (loaded with the previous) image sizes are actually negligible it terms of raw size, but the latter allows for simultaneous rendering of all four, and only references one call to the asset server. there is a small savings in request time, and header overhead, but mostly it's the aesthetic difference that is appealing here... the rest is just gravy.

I don't know of any single doc that lays out all the details. however, if you search these forums (forii?) and the Wiki, you will find lots of scattered information. There are several Gurus, but Ceera Murakami and Chosen Few come to mind. If they speak, EF Hutton listens.

There are built in consoles to watch textures download, look at the polygons with no textures, and so on, but none of them are really good at making all the important issues obvious.

Also keep in mind that by the time you figure this out (give it a year or two) all the users' computers and networks will be twice as good as they are now, so it won't matter half as much

lee

From a viewer framerate point of view, it's my understanding that the main limiting factor is the number of "render batches". Modern cards are able to render a lot more polygons per batch than what the SL viewer is able to feed them. I think that means that if more polygons are using the same texture, less batches are needed, and the framerate is faster. You can see a visualization of this in Advanced >> Rendering >> Info Displays >> Render Batches

(That being said, I know very little about OpenGL, so I might be wrong)

From a "how long before everything is loaded" point of view, there is also a difference: Because the viewer is only downloading a limited amount of textures at a time from the sim, it tries to juggle the different texture fetches into this limitation. So a single large texture will download faster in most cases than the same amount of pixels (or bytes) spread over several smaller textures.

I'd think that would affect lower end cards more than upper (and I probably should have mentioned it) but I could fill a thimble with what I know about openGL myself. I would at least expect some minor savings in texture fetching, but I'm not sure if it would actually reduce the number of batches (as all polygons still need rendering)... a little past my knowledge base though.


I know order is affected, but I'm not sure about amounts... but the psychological effect of the order can have a huge impact, with entire objects being rendered at once, rather than a piece from this one and part from that one, creating a perception of speed (similar in a way to how progressive vs linear rendering affects perception of speed)

I really have no understanding of the logic (or lack of) that tells the SL client how to render polygons.

There are still items I find get rendered very late in the process despite me standing directly in front of them, and despite me seeing other items BEHIND the item that's not rezzed yet, being rezzed and those other items only having been placed there a day before, whilst the item that's not rezzed had been there almost a year!

At time it seems a total random choise by the viewer.

It's like if I have cammed away from my avatar then make my avatar teleport away a little most of my house vanishes, but some furniture remains floating in the air.

I can't see any rational as to what does and what does not render.

And to that point what does and what does not get cached.

Eg at home, all cached, tp away to a small area, TP back and some items need to re re-rezzed again in your home.

Do you know which those are and where I could find them?

One of them is written up here: http://wiki.secondlife.com/wiki/Invisiprim.

the other is "e97cf410-8e61-7005-ec06-629eba4cd1fb"

Just because objects and textures are not being rendered in the view doesn't mean they have not been loaded into memory. Is there any evidence that invisiprims prevent this from happening? I guess I am saying 'citation needed' but I mean it in the most polite way possible.

As a follow up/clarification to my own post - when I look at 'invisiprim' hidden objects in wireframe mode I can see them. I have no skills to definitively check my video card memory to see if the textures on the occluded objects are in memory, but I am assuming they are if the mesh data is showing up.

Wireframe mode could be a poor way to test this theory (SL could switch to a different rendering mode since it doesn't have to account for textures) so I am interested in hearing any information one way or the other.

to my knowledge there is no occlusion in wireframe mode. I can only give anecdotal evidence for occlusion reducing rendered textures, and the basic behavior of occlusion. this only counts for sure though, if the occluded texture is entirely blocked.

Wow, thanks everyone for the replies.
It was nice to come back here and have
some info to read.

I do wish there was more citation for
all of this sort of thing. I can't
seem to find much either, that's why
I posted this thread.

Ok, a few directed comments and then
another question:


@Ephraim Kappler-
I too am using these techniques
already for years, out of habit.
They make things look good.
Regarding the keyline issue you
mentioned, I do find that with a
couple of exceptions, (to do with
hollowed prims meeting cubes)
it is almost always possible to get
a clean seam.

Sometimes the issue is as simple as
aligning textures exactly. This is
most easily done with the test pattern texture
that Chosen Few posted in this thread
a couple of years ago. (Anyone who
doesn't have this, grab it and try it.
It makes for perfect texturing.)


Other times that thin seam is caused by
an SL bug that takes prims that are set
to round number rotations like 90° and
randomly changes them minute amounts
to something like 90.005 or similar.
These can be reset by manually inputting
the correct rotation again, but often
change again later, or another prim
nearby does.

@all-
This ongoing bug just mentioned is
one that needs LL's attention, so anyone
who has noticed it please take the time
to vote on Jira to have it fixed.
There are at least three related Jira issues
about it, and I linked them in this thread:




@DancesWithRobots Soyer-
Just so there's no confusion, the "null"
texture and all of the techniques I mentioned
in the original post are from my content creation
in the Half-Life and Half-Life2 Source engines.
Also, thanks! for pointing out about the
"default transparent" texture added to SL,
it must have happened while I was on a break
from building here. I will switch to it.


@Thickbrick Sleaford-
All good tips, thanks!
I was hoping there was a "no render" texture
so that's a bummer. I did notice that
"default transparent" has the same dimensions
as totallyclear (which I got from a Torley pack)
they are both 32x32 pixels.

I might keep using that small alpha texture on
hidden faces as it requires no specific scale
and is so small. With cams going through floors
and walls it helps to keep things sleek and tidy.


@Void Singer- Interesting posts! Thanks
for the info on invisiprims and the
debate with Thickbrick Sleaford on
texture size.


@Piggie Paule- I am confused by these
things also.

@Pygora Acronym- Would you update in this
thread if you find out more? I'm
interested. (Even a link later would be great.)


Geez, I'm long winded. I'll keep the question short.

What do you know about shaders and their
effect on performance? I like to use medium
and high shiny on many faces in a build.

Thanks all.

PS- Does linking URLs not work here?

/109/45/214824/1.html

use tags and a ? at the end

Thanks