Scripting/Graphics Speed Optimization question

Hi,

I'm not sure if this is the 'right' place to post this question or not...this question deals with efficiency for something I'm scripting and good habits for scripting...so I thought the best place to get answers like that would be here.

My question is with regards to 'textures' and 'objects'. I see that when you open up the texture window for an object in SL..an object 'defaults' to the wood texture. You may also click the 'blank' button and choose a 'blank' texture, or you can choose the 'default media texture'. I can set these same textures with the script using the key as well.

I'll just make up an example here and hopefully that'll help someone answer me best. Lets say you are building a HUD attachment....maybe like a little control panel on your HUD or what not so that only ONE surface is visible (The surface facing the user).

You have a custom-built texture that will get painted onto that face of the prim. Yet...the prim still has 'other' faces that the user will never see. If its a cube...even if you've made it as 'thin' as possible...there is still a top face, a bottom face, a left face, a right face, and a back face. The only 'face' you need your custom texture on is the 'front' (user-facing) face.

Now, lets say that under certain conditions...that user-facing texture will change. Under one circumstance its one texture and under another set of circumstances it changes to a different texture.

So what is the best and most efficient way to handle the 'other' faces of this object? Should I use a 'blank' texture? Should I use the 'default media texture'? Should I use the 'wood' texture? Should I set the other faces to 100% transparent? Should I set them to a color? Is it actually faster just to set the texture to ALL_SIDES anyway?

I'm guessing that certain textures and things take longer and chew up more horsepower to draw than other things and I have no idea what that precedence is.

Someone 'else' makes my textures for me so they know all the tips and tricks of the trade with regards to building more 'efficient' textures and such. They can handle their end just fine. However, on my end....I don't understand what to make the other faces faces.

I hope all of this makes sense

Thanks!!!!!!!!!!!!

--
Cy

any of the above choices would be good, blank and plywood are good bets becuse they are everywhere.

here is a discussion about textures given to you by LL
/8/57/84600/1.html

i personally use my own white texture, its 16x16 pixels, and TINY both before and after SL gets done with it... yes everyone has to DL a new white texture, but its really quick, and uses up alot less video ram (versus the blank texture, which i think is a 256x256 hog)


white 16x16 65fe9f1f-f5ab-814e-6898-2d934989abf6
black 16x16 ad955c3f-0435-071f-e438-0dfe97672203

oh and dont make it 100% transparent on all the other sides, the edges are fine for alpha signs ect.. (makes a nice fake 2d plane) but i found when editing (or other ppl scaling it to their screen size) it can be lost really ez if your not facing the direction of the non transparent side ... you cant see the edges of a hud, i wouldnt waste the time and im pretty shure that adds alittle more stress to the client using the device

also secondlife mainly deals with pixel count the smaller the faster, 16x16 = 256 pixels, 256x256 = 65536 pixels, this all depends on how much detail you need... 16x16 is fine for a solid color, 256x256 would be fine for a billboard. course you can mix and match to your needs, ie a 128x512 image = 65536 pixels, and should act like a 256x256 image. Unique color count plays a role in it also, an image with 2 colors (black and white) will rez faster and use less memory than an image in 256 shades of grey... this has to be colors neccacary in making the image, you cant reduce color depth to 32k colors (which is 24 bit) and expect faster load times (sometimes it does, but mostly not)

ps i just looked at the filesizes for the above textures, on MY computer they are 822 bytes in bitmap format, by the time SL adds jpeg 2k compression ... well lets just say that 822 bytes would take only a few seconds even with a 2400 baud modem

Thanks for the info Osgeld!!! Great stuff!

So let me ask you a specific question and see how YOU would do it...

Just elaborating further on my initial example...

Say you have a control panel to be attached to a user's HUD. Thus....they only 'see' the front of it. The texture for the 'front' face gives the appearance of shiny gray metal.

There are actually 3 control panel 'textures'. One that has a bunch of red indicators, #2 has a bunch of green indicators, #3 has a bunch of yellow indicators.

If the user is in the presence of 'friend' avatars (dictated by an friend's list) then texture #1 loads. If they are 'enemy', texture #2 loads. If they are listed as neither friend nor enemy, texture #3 loads.

The objective here is to reduce that texture 'load time' as low as possible so that it appears the indicators on the panel are 'lighting' up.....and you want to minimize the chances of the user actually seeing the texture 'load'. You want it as smooth as possible.

Assuming that with 'buttons' and such on your control panel as well....the gadget has enough physical 'bulk' to not easily be lost on accident if things were alpha. What would you do with the 'sides', 'top', 'bottom', and 'back' of the control panel? Would you use your 16x16 white texture? Or would you set the other prim faces to be transparent? OR is there another way you'd handle this?

--
Cy

Hmm - if you have three small textures you want to load quickly, put them side-by-side in one texture and use llOffsetTexture to "change" textures. Even though this slightly larger 3-in-1 texture takes longer to initially load, changing texture to texture incurs almost no loading penalty.

Also - Im pretty sure SL discards faces who's alpha is 0. In order to set this property, you must use llSetAlpha, as a transparent texture also incurs loading time.
==Chris

i agree, but i would make a 4 in texture, yellow green red and white, set the unseen parts to the same texture (offset them so they are the same color if you must) but then you have 1 texture and 4 areas covered ...

size does matter you could make this texture 16x16 with the 4 parts inside, its small and quick but well ... for example here it is streched on a 10x10m plane in open gl
http://cheesefactory.us/example.bmp
so if you dont mind doing the math to offset the fuzzys this is the way, if not 64x64 or 128x128 textures start to "crisp" up ...

detail vs pixels


and also why deal with the transparency, you cant see it while you wear it

Thanks alot Chris! To the rescue once again! As usual, you're help and advice is greatly appreciated.

Thats a brilliant idea! I never even thought of just 'sliding' a texture like that instead of loading new ones. That is just...well...really slick!

Thanks for the info on Alpha as well...that adds to what I was 'assuming' but I really wasn't sure. I was guessing that 100% transparent would be 'less' horsepower required, and mid-ranges of transparency would be the 'most' horsepower required.



Thanks again Osgeld! Thats also a really slick idea! and thankyou kindly for the example. I'm sure I follow what you've been explaining now...between you and Chris...I think I've got a better idea of how to plan for these things now.

Thanks!!!!!

--
Cy

Another possibility would be to just use a monochrome button image and change the color.