iliveisl

 

another multi-texture per prim example

16 comments

here is an old trick that many people use and it helps reduce load for visitors

depending on how nice a quality you need your textures, placing several on one image can be a handy trick. it helps you keep your inventory under control (i am really bad at keeping textures organised both in-world and in the real world!) and can reduce the load for your users

texturework_001in Second Life, placing multiple textures on one image is also a way to save a little money with uploads. here’s some trivia about how much those $10 Linden uploads actually affects Linden Lab’s bottom line. back when i was big into SL (well, my avatar is like 5′ 2″ with boots on), Linden Lab published all kings of user data – from user hours to revenues they earned. in early 2008, Linden Lab was bringing in $90,000 USD per month on all the $10 L upload fees! what was chump change to you and me was several people’s salaries at the Lab! o_O

anyway . . . this example is a 512 pixel square image saved as a PNG-8 with transparency and the filesize is 89 kb – that’s not too bad considering i am using it for 6 different graffiti tags in Hax Nuit

i made these tags as gray scale so that i could colour them differently for some variety and thus use each several times. it is hard to see but “is this real” and “i am rezzed therefore i am” have a linear gradient applied. the OpenSim people/hippo logo also has radial gradients. the ideal was to give them a bit more texture. i should have been more extreme in the gray scale gradients but what do expect from an Ener?

after importing the texture, i set it up on a phantom prim, set all the other sides to 100 transparent and then adjust the repeats and offset to show one of the textures. then i shift duplicate it and only need to adjust the offsets for similar sized parts of the texture (the top four were all the same repeats, the bottom two were different)

once i am happy with the repeats, i then duplicated them and coloured the front faces. then i name each and take a copy into inventory for archiving. i then shift duplicate the ones in-world and spend a few minutes randomly placing them and that’s all there is to it =)

texturework_002

texturework_003

texturework_004

Twitter Tumblr Digg Reddit Stumbleupon Delicious Facebook Plusone Pinterest Linkedin Tumblr Posterous Snailmail

written by Ener Hax

June 14th, 2013 at 5:41 am

posted in OpenSim

tagged with

16 comments to 'another multi-texture per prim example'

subscribe to comments with RSS or trackBack to 'another multi-texture per prim example'.

  1. KUDOS! This is a prime way to Reduce Texture Lag and you made a perfect applicable example of it here Ener. If people used 512×512 or even 1024×1024 textures but set them up as “cells” which can be shifted as you show, you can cover a lot of space with a single texture. When a visitor hits the sim, they only download the one texture with it’s many cells. Certainly a lot better than pulling down 4,6 or 8 separate textures.

    Smart Sim Building means using as few “downloadables” as possible as that is where most of the lag comes from.

    There is a “trick” too for it. If you use a 1024×1024 for example. You can put 2×2 @ 512×512 (2 across, 2 down) or 4×4 @ 256×256 (4 across, 4 down). Always try to stay in “normal sized cells” of 256, 512. Using oddball sizes can come back to haunt you or others depending on the viewer and rendering. It also makes it easier if you are tiling the textures at all.

    There is a CATCH though. If you have texture-A and make copies of it, the texture is the same but the UUID is changed, therefore the viewer cannot differentiate that it is a same or different texture so it will download each UUID (texture). To test this, depending on your viewer, you can sometimes see in the prim properties, textures the actual UUID for the texture and compare it to your master one.

    Depending on how the texture is applied & used it could be the same UUID (reducing lag) or a different UUID (creating lag). If the texture is applied when building and you use the texture picker in the build tools and select a texture from inventory, that will always reference back to “that” texture UUID.

    If you shift copy a prim that is textured (pending on viewer & OpenSim version) it may create another texture entry (therefore a new UUID) although I believe that has been mostly resolved as that was an older problem issue.

    IF the Texture (or anything else) is located inside a prim and you shift copy that prim, then everything inside that prim will receive a new UUID.

    WhiteStar

    14 Jun 13 at 7:27 pm

  2. [...] See on iliveisl.com [...]

  3. that trick was also a good practice a few years back in Second Life for people doing business presentation and loading textures up on cubes that were already rezzed out

    the tip about the UUID is a really important one and i can terll from exporting objects that often what should be one texture is indeed several with diff UUIDs

    i did not realise that shift duplicating could lead to duplicate textures, but that certainly makes sense

    i wish there was an easy way to get texture properties from a prim. i have replaced textures a few times on the multi-year build of Enclave Harbour. i am certain that texture loading is obscene for it!

    thanks WhiteStar for being the consummate teacher – i do learn quite a bit from you =)

    Ener Hax

    15 Jun 13 at 5:18 pm

  4. I could provide a script to reference the texture info but you would have to be owner / creator of prim & texture. Yes, that trick does harken back to the old days of SL when of course performance & texture loading was always a massive issue. Since OpenSim frees people of many of the SL constraints, people have gotten “lazy” or even “apathetic” towards these issues and then they wonder why loading is so slow. It also has a deleterious effect on asset servers in a grid having to pull from the DB and push out all those extras when it can be avoided.

    You also made a good point that many educators or SOAS users who use it for presentations… Using a gridded large texture is also much faster for flipping back & forth through… it does however need a script that can deal with it… no I am not going to write one for it and I don’t think I have one in my extensive lib’s because I handle presentation panels and slides in a somewhat different way with pre-caching <> textures to make things snappy.

    WS

    WhiteStar

    15 Jun 13 at 7:01 pm

  5. The “many textures in ONE texture” is always a neat trick! It’s also quite handy for square objects such as chests, boxes, or cargo containers… but can work just as well for barrels or many simple objects.

    http://pontusb.com/images/work_04/flats.jpg

    http://d1ij7zv8zivhs3.cloudfront.net/assets/829673/lightbox/7f1eb8cb4f6d421c58bc389a29db8cdf.jpg

    It reminds me of the “XyText 1.5″ scripts that lets you put 10 characters (letters/numbers/symbols) on ONE prim. Very useful for signage.

    The original method (SL) is free
    http://wiki.secondlife.com/wiki/XyText_1.5
    (and there are several variations)

    It also should be doable in (most?) OpenSim worlds, but you’ll need to get the correct texture UUIDs for your world.

    I know it works in InWorldz, cuz I made a version there, using texture UUIds provided in their Wiki pages, but I altered the original script to use easy notecard setup for the text.

    http://img96.imageshack.us/img96/6673/niy4.jpg

    Thanks as always for all your resource-saving tips!

    PS: You said “i wish there was an easy way to get texture properties from a prim…” There are ways to do that easily with scripts, let me know what you need (texture UUIDs? other?). A simple one to start with is

    http://wiki.secondlife.com/wiki/LlGetTexture

    once you know the UUId(s), you can use

    llSetTexture()
    or
    llSetPrimitiveParams()
    or
    llSetLinkPrimitiveParams()

    to set textures on any object, using the UUIDs of textures already in your Inventory. I use this method to make prims with changing textures (textures are set via script; no actual textures need to be in Prim’s inventory).

    And of course you can right click on most textures in your Inventory, then select “copy asset UUID”, then paste the UUID where you need it (script, etc.)

    DreamWalker

    19 Jun 13 at 2:41 am

  6. I love this thread! I’ve been doing stuff like this for quite a while, and it’s always great to have a little show on a prim.

    Dana Paxson

    12 Jul 13 at 10:59 am

  7. It is a good method for making HUDs, boxes, and animations. This is cost efficient as well as client load efficient. I try to use no larger than 512×512 for png as it affects my meager hardware, but that is also the point for me using a netbook or 1 core laptop. My theory is that if I can make something have low lag using a slower and older 1 core laptop, than it should be ridiculously fast to load and use for those using faster and more modern hardware. Think of it as strapping weights to the viewer to help train building skills. I also prefer using prim twisting to reduce prim count, as well as using Blender mesh uploads for prim reduction. Everything always affects me lag-wise, so I am always conscious of the little details that can reduce system loads.

    I also like using:

    llSetPrimitiveParamsFast()
    llSetLinkPrimitiveParamsFast()

    instead of:

    llSetPrimitiveParams()
    llSetLinkPrimitiveParams()

    because it gets rid of the delay in the script.

    UUID keys are very efficient and useful for setting or swapping textures on something, from a specific face on a specific link of a linkset, to all faces and links of the entire object.

    http://wiki.secondlife.com/wiki/LlGetTexture

    The script there should report to you the texture UUID keys on the 6 sides of a cube.

    As an example, my TrippehBox uses 1 script to swap textures on one link while rotating the texture as to create a very abinormal visual effect. Check it out at:

    http://i1295.photobucket.com/albums/b636/jkygbsutyc/sl_iw_os/trippehbox0_zps9d98acd8.png~original

    I made this as a more efficient alternative to those party ball objects people like to wear at clubs and other places. This is a 1 script object using UUID keys to switch textures on-demand, and it is a single, non moving object that many people can equally enjoy in a large area at the same time. Animating a texture on the inner surface of a negative sculptie was fun. My strategy for efficiency looks pretty cool imo.

    I agree that instance UUID keys will differ each time you rez a copy of the same object. This is why derendering an annoying spam object does not get rid of the rest of them.

    For greater efficiency, I use an alt account to store my texture library as this frees up excess inventory from my main account and the UUID keys still work no matter who uses them.

    Hope this can inspire a few new ideas out there.

    Sincerely,
    Mick Scarbridge (SL).

    Mick Scarbridge

    17 Jul 13 at 10:19 pm

  8. Forgot to mention that a light flasher is more efficient to the server if you use a single texture with multiple cells and texture animation script instead of changing the object in a way that refreshes it frequently.

    Sincerely,
    Mick Scarbridge (SL).

    Mick Scarbridge

    17 Jul 13 at 10:27 pm

  9. that does look very cool and would mess with you (i’ve seen objects like you describe, the negative inside dealio and it is a very different affect)

    “if I can make something have low lag using a slower and older 1 core laptop, than it should be ridiculously fast to load and use”

    ditto, ditto, ditto! your philosophy is excellent because many people “push” the limits because they are only focused on their own experience (or lack of as it probably is when it comes to good scripting or even good texture practices) rather than realising everyone will be adding overhead and those objects/scripts that can do so without resulting in crazy lag (like <10 frames per second)

    your approach not only leads to lower client overhead, it leads to real originality! =)

    Ener Hax

    18 Jul 13 at 8:19 am

  10. Was playing with a mesh hover platform I made in blender today. I need to learn more with uv mapping, but I discovered that you can use a double gradient texture that fades from one color to many others then back to the first color again on the opposite side to make the object fade like a fiber lamp, and all done by dropping in a texture rotation script then deleting the script afterwards. This does not refresh the object repeatedly like using a script to blink it on and off with rapid glowy color changing effects, so it uses less resources while making some good eye candy. This also seems to work in mesh objects, but some of the polys are a little off so I must do a little research and figure out how to either blend them into the surface, or at least manipulate where the oddball pixels are positioned (like a pattern made intentionally). I like using scriptless goodies and this adds yet another to my toybox. I alsl tried driving my hover platform using the npv script, but with a few lines commented out to prevent the platform from turning transparent when sitting or from going ker-poof when I stand. Here is a pic of my mesh HoverPlat using the scriptless color fading technique:

    http://i1295.photobucket.com/albums/b636/jkygbsutyc/hoverplatfadingcolorgradient_zps91c1b06d.jpg~original

    Sincerely,
    Mick Scarbridge (SL).

    Mick Scarbridge

    8 Aug 13 at 7:48 am

  11. holy cow! you are like Neo times 10!!!

    for things like your HoverPlat, how can you measure the usage hit it has?

    is it less than making a prim version of it (understanding that prims will never have the detail)

    the rotating texture script is all user side but what about the object itself?

    (this is actually more of a question: how can i see the overhead on an object?)

    btw, i like the HoverPlat! (it did take me a minute to figure out it was short for platform!) =D

    Ener Hax

    8 Aug 13 at 8:32 am

  12. I think the prim count was 3 links total, but the land impact was around 45 prims worth when I expanded the object. Mesh can be funny like that as the prim cost varies with size of the same object. Check land impact when the object is rezzed, then shrink it tiny and check land impact again to notice a change. Do the same while expanding it to preposterous proportions as well. Edit a mesh object you rezzed then look for the prim count as per usual.

    Firestorm, Singularity, and Phoenix had land impact in the edit menu. The land impact of a mesh object also is synonymous with the number of polygons in the mesh object. Less than 4000 seems to visually implode or crumple, while more than 4800 polys seems to crash me on my meager 32 bit Sempron laptop when I attempt to upload to SL. Something to remember when adding mesh to prim or prim to mesh; this usually increases land impact considerably. I learned this when adding my mesh drones to a prim sphere for allowing proper XYZ rotational orientation. Also, level of detail (LOD) for uploading makes a huge impact (no pun intended thar).

    The land impact of an object increases when you add a script if the land impact was determined by server weight. This happens only when the server weight is higher than either the streaming or physics weights of the object. Making an object dynamic (physical or scripted) increases the amount of work the server has to do to track that object. Most often, objects have a higher streaming or physics weight than server weight, so this only affects certain server-intensive pieces of content.

    Here are a few links to browse for mesh thingz:

    http://wiki.secondlife.com/wiki/Mesh/FAQ

    http://wiki.secondlife.com/wiki/Mesh/Mesh_Server_Weight

    http://community.secondlife.com/t5/English-Knowledge-Base/Calculating-land-impact/ta-p/974163

    http://blog.machinimatrix.org/optimizing-meshes/

    I chose to use mesh to reduce the total number of textures used versus total number of textures used for a prim version. To me, mesh is superior in most cases due to the way they use land impact. As an example, with my low poly mesh window bars I would have used over 120 prims to create it while it only had a land impact of 4 prims for mesh. It really depends on the shape and complexity. I recently attempted to upload a stupid-complex, high poly mesh I made of a custom gaming PC with four graphics cards stuffed into it, using riser cables for each card to allow for greater cooling and more overclocking. The model had over 60,000 polys total, which UberCrashed me before I could finish the upload. I recently made an animated gif of the HoverPlats moving around while changing colors, and all with zero scripts in them. I made the HoverPlat have flat sides instead of making it smoothly round on purpose for that “high tech” style. I used a prim cylinder as the main clear glass floor, which i should upload a mesh one to replace it as this may reduce total land impact. I am trying to discover more things I can do scriptless. ^,..,^

    Sincerely,
    Mick Scarbridge (SL).

    Mick Scarbridge

    4 Sep 13 at 5:48 am

  13. wow! thanks on the great and in-depth education! another reason for me to switch viewers, i had no idea you could see land impact but that totally makes sense

    clearly, mesh can make more realistic things (i used to use Blender daily for my day job) but it sounds like my “prim-only” approach is still a good way to go resource wise

    your explanation (and links) was really great – thank you Mick! =)

    Ener Hax

    5 Sep 13 at 7:26 am

  14. You’re welcome! I use different viewers for different purposes, much like some people drive a car for carpooling to work with friends and a truck for hauling lumber from the lumber yard. Each viewer is both general purpose and specialized in a few areas.

    I used to use Restrained Love viewer in Windows 7 for a dedicated viewer used for RLV testing as well as for uploading objects to my SL store. The other viewers at the time did not perform as good for those two tasks.

    I like Firestorm for SL as my primary viewer mostly because of the non pie chart interface and the landmark favorites bar across the top of the screen. I do not like the lag associated with Firestorm, however I love the viewer-based AO that can be configured in about 10 minutes to eliminate a common AO HUD and script (scriptless AO, yaayy!).

    Before Phoenix was dropped off the support wagon, I dedicated it as my building viewer for building things. Phoenix was also the most stable viewer I have used for everything. I will miss it.

    I used Ragegast for developing AI bots and running multiple viewers from a 1 core netbook.

    I used Singularity for combat and sim security jobs because it had lightweight code and ran very fast on older hardware plus it had a few neat tools that only Singularity had.

    I also used Imprudence as my viewer dedicated for backing up my builds from SL to hard drive, which worked quite well.

    Teapot was the opposite of other viewer layouts and was a bit lacking for my needs, however it was quite fast.

    I experiment with everything and discover a lot of neat tricks over time.

    Sincerely,
    Mick Scarbridge (SL).

    Mick Scarbridge

    28 Sep 13 at 10:42 pm

  15. Anyone interested in grabbing a copy of Gimp Magazine in PDF form for free, head on over to http://gimpmagazine.org/ and scroll down a bit to grab a copy. As a Gimp artist myself, I like to find new tricks and styles to help me expand my own. I hope this could help a few Gimp artists that frequent SL, IW, and OpenSim to discover new things and inspiration.

    Sincerely,
    Mick Scarbridge (SL).

    Mick Scarbridge

    29 Sep 13 at 1:04 am

  16. holy cow Mick! you sure are the opposite of me on viewers! only Imprudence 1.3.2 for me! =p

    cool on the Gimp link – thanks! =)

    Ener Hax

    2 Oct 13 at 2:30 pm

leave a reply - add your thoughts

you can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>