prims vs. textures continued


the other day i explored the impact of textures on the server (specifically RAM) and this becomes critical for two reasons – the more RAM you use the more it uses up your server’s resources and the longer it takes for your work to load for visitors

if you don’t run your own server you probably are not so concerned with that first point because you figure your world provider (vwp? like isp?) is being paid to deal with it. the second point affects everyone if your grid is open to visitors because they will need to download your textures as well as the information about all your prims.  that latter part is also something you should consider that affects lag – the complexity of your prims is data that is sent to visitors. if a prim is twisted, cut, hollowed, has texture repeats and offsets – all of that info takes up bytes (an important consideration for meshes also) – the more bytes, the more lag

when i saw the significant reduction in one region’s OAR file after removing some textures, my OCD side kicked in and i decided to see what would happen if i swapped prims for textures. i already started doing this with the roads, thanks to subQuark’s help, where we went from 2 and 3 prims with textures to 5 prims without textures (that post)

my first “test” for seeing what the effect of removing additional textures is on a building that is the place of a toilet flushing science activity (warning: math content). it’s a building meant to be one metre taller than the current tallest building in the world and it only uses 5 textures, all of which are 512 png-8s . removing textures would reduce the amount of data in that region but i still want to maintain a level of “visual interest” so i added prims to the building, a lot of prims - 286 additional prims! o_O

at first it might seem that adding prims is a crazy idea because, for many of us, Second Life imposed a mentality that prims are the big deal because that’s what the limiting factor is on a sim. you don’t get a report on how much RAM you use, only on the number of prims and scripts. so the thought of adding 286 prims in the place of 5 textures seems ludicrous (at least to me)

but simple prims might have a small footprint and i base that thought on this from the SimHost website: “A simple ‘box’ primitive (or things derived from boxes) use a tiny amount of resources (max: 50MB per 1,000). ”

so what was the end result of this?

well, it completely shocked me. i thought that 286 additional prims would take up a lot more space than 5 fairly well made textures but was i wrong! i swear that i am not making up these numbers and what i looked at was the OAR file size before i removed the five textures and then after i added the 286 new prims (all hollowed cylinders) and the results were 18,388 KB before and 18,387 KB after!!!

this has turned my virtual world upside down and the image below shows the two “looks” – i think i’m going to continue on this crazy rampage! =)


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

written by Ener Hax

October 28th, 2011 at 11:34 pm

posted in OpenSim

tagged with ,

7 comments to 'prims vs. textures continued'

subscribe to comments with RSS or trackBack to 'prims vs. textures continued'.

  1. There isn’t much to a prim. Just a few small rows in a couple of database tables, at least for OS. Who knows about SL but it must be about the same. But, there’s several differences between how prims and textures are handled in the server and the client.

    I think this is how it basically works…

    - Prims are small. The server has to figure out which ones apply to your scene and then send your client all of them.
    - Textures are big. The client figures out which ones it wants and then asks for them.
    - The client decides how to render both prims and textures.
    - The server keeps track of how things in the sim interact with each other and sends the client updates for changes. Things like prim location changes or your AV running into a prim would be sent.
    -Textures never get sent again unless the client drops one from cache and asks for it again.

    So, thinking about both the client and server, I don’t know what is best. But, to make a small sim-on-a-stick, the prim approach is probably best. With sim-on-a-stick, it’s probably just your AV so your whole PC can dedicate itself to running one sim with one AV and only deal with one client.

    Micheil Merlin

    29 Oct 11 at 8:41 am

  2. “removing textures would reduce the amount of data in that region but i still want to maintain a level of “visual interest” so i added prims to the building, a lot of prims – 286 additional prims!”
    And data for all 286 got added to the file, too. Basically, you traded one set of texture data for a new set of prim data.

    Sarge Misfit

    29 Oct 11 at 10:43 am

  3. ahh, thanks for the explanation Micheil! i did not think about the physics except to make all the additional 286 prims Phantom =)

    pretty neat though Sarge how 5 “normal” textures equals 286 prims! i would have never thought that was true

    Ener Hax

    29 Oct 11 at 11:45 am

  4. One thing I like with using prims is that you can make them into rooms, thereby turning your building into a functional structure rather than it being a prop :-)

    How big is Enclave Harbour’s OAR file, btw? Excelsior Stations is 471Mb. Seems to be about 1Mb per 100 prims.

    Sarge Misfit

    29 Oct 11 at 3:15 pm

  5. well gee Sarge, where were you last night??? you are correct, now i can make those all floors . . . hmm, but then i’d need to unPhantom them? dang, what to do?

    conundrums are enigmatic

    Ener Hax

    29 Oct 11 at 3:45 pm

  6. The impact different prims will have on a running scene depends mostly on the complexity of their physical meshes. When the physics normals are calculated for a primitive, they are stored as a large array of points. This collection of points can be very small or very large depending on the shape of the primitive.

    Another important fact is that the same prim repeated many many times will use up less RAM vs using many differently shaped prims.

    None of this would make much of a difference in an OAR file though, just when rezzed. The OAR representation for prims is a collection of XML files that has to encode all the properties of the prim. XML can be bulky, but usually compresses pretty well when zipped.


    29 Oct 11 at 7:05 pm

  7. [...] a very interesting piece on the relative lag of prims and textures.. if you missed it it’s here. I guess my idea for 2024 tex is out the window for a few [...]

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>