What size are prims?

I'm wondering if anyone knows how big a prim is in terms of file size? I'm trying to optimise my sim build and am looking for that info to assist.

I've never heard anyone ask this question. You mean file size as downloaded for viewing on your computer, or as stored on the server? A single prim is a combination of different assets all stored as records in a GIANT relational database on the so-called asset server. Individual prims do not exist as single files anywhere. Many assets do get downloaded and cached on your system for quicker access, but prims are not among them that I am aware, although the textures on prim surfaces certainly are.

There are MANY things to consider when optimizing a sim for performance, both in terms of client and server load.

normal prims can be enlarged up to 10 meters by 10 meters. If you purchase premade mega prims you can have a flat prim (say for a floor) that is 20 meters by 20 meters by 0.050. they(mega prims) can be resized in the aspect that their shape can be changed (not their size) You can also cut them hollow them taper them etc. however..say if you take 40 by 40 by 40 mega cylinder and turn that into cube and then cut that in half the part that you cut will still be on the collision plane. ((you have to make them phantom for the cut piece not to be in your way when walking or flying.))

~Lana

oh file size hahaha...oops

Thanks for the replies. Perhaps I should have asked my question better. To rephrase: does anyone how much bandwdith a prim costs to download and rez? Does a prim have a set (or general range) bandwidth cost?

AFAIK file sizes vary by their special features, there really isn't a reference to what the sim holds vs what gets transfered to the client, but the more complex (cuts, twists, tapers, textures for each side, etc) the more that gets trasfered. that means each file has some amount of variable information. also AFAIK contents do NOT get transfered to the client (except on request, which explains the lag seeing them sometimes)

I believe polygon information is built locally (but done't quote me on it) so a sim full of toruses really doesn't affect the sim so much as it does your vid card... at least untill you get into physical(moving) objects.

info for anything rezzed on a sim IS kept on the sim (not just the asset servers), including av's and their attachments (to track physics and running scripts).

That's not a meaningful question. Prims don't have a file size, and while people will informally talk about optimizing a build or a sim, you can't really do that. You can only optimize specific measurable factors, e.g., optimize the drawing of an object on typical graphics configurations, or optimize the texture downloads.

The raw download data for the prim is negligible. It's just the geometric description.

It's the textures that create the bandwidth load. In general, keep textures as small as possible. If I recall correctly, 512x512 is considered the max for most uses, 256x256 is better. There are specific cases where larger textures can be justified, but also clever ways to exploit tiling of smaller textures.

In terms of data sent from the SL server to the viewer, the data sent for each prim is essentially the data points you can manipulate in the edit window for that prim. For downloading, the data sent for each prim is insignificant compared to the texture data transfered. Rendering once the data is transfered to the viewer client is another issue altogether.

I think that http://svn.secondlife.com/trac/linden/browser/release/indra/llmath/llvolume.h?rev=66
would be a good place to start for figuring out "how big a prim is". Assuming you speak C++, that is.

It's neat seeing the properties in the inworld build editor in their C++ incarnation.

Just because I remember seeing this information and it was easily to find... (from )

Others have already pointed out this doesn't relate to bandwidth or rendering or whatever I guess but it tickles me nonetheless?

I can't remember the reference, but I have read that using highly tortured torii can create a performance hit. Something about the increasing number of angles.

But your time would probably be better spent optimizing textures, which are a much more common source of issues. Using 256x256 and 512x512 textures instead of 1024x1024, avoiding odd size (512x1024), and controlling the number of different textures.

For instance, I've learned to make much better use of textures in my store design by ganging together graphics into one texture. Typically, I'll have 3 or 4 different store signs on one 512x512 texture and then offset the texture display to reveal the portion I want for a particular sign.

Keeping a defined set of textures for styling builds creates a better aesthetic experience anyway. Too many textures usually is a result of a sloppy and/or overwrought design.

Guys, as far as bandwidth goes, every prim is the same "size". What's transmitted from SL to your computer is simply a list of parameters. Since all prims have the same variables, the list is always one size.

This is the crux of what makes SL Internet-efficient. Every client is pre-programmed with the knowledge of how to create a cube, a cylinder, a sphere, etc. So there's never any need to stream that information over the Internet. All that does stream is a few lines of text, listing the values for each of the various parameters.

Bascially, the information says "Put a cube at ____ location. Make that cube _____ big. Roate it by _____ amount. Cut it by _____ amount." Etc. All together, the total list, according to Crystal's quote from Kelly, is about 1K when compressed. That's all that gets streamed to you to describe each prim, 1 kilobyte.

The exception to this would be sculpties. Sculpties have a both parametric data set, just like regular prims, and a vertex displacement map, which we call the sculpt map texture. In most cases, sculpt maps when viewed uncompressed are either 12 or 16 kilobytes each (64x64 pixels, times either 24 or 32 bits). But that's not a hard rule. Technically, people can make sculpt maps any size they want, up to 1024x1024, for a maximum possible of 3MB at 24-bits per channel, or 4MB at 32 bits per channel. Most people aren't stupid enough to do that, but some are.

90% of the time, it's a pretty safe bet that any given sculpty is 12K or 16K, minus whatever savings you get from the fact that stored images are compressed, plus whatever miniscule amount of bytes are necessary for the parameter list. If I had to guess, I'd say most sculoties are probably somewhere around 10K or so, but don't quote me on that. As I said, it's just a guess.



OK, so if all that's true, how come, as Beebo points out items like twisted toruses cause more lag than do cubes? Well, the answer is when you get into that discussion, you're no longer talking about downloads, but about rendering, and that's a very different thing. As far as the streamed information goes, the parameter list that says "create a torus" is the same size as the list that says "create a cube". However, once the instructions from the list are executed by your computer (which happens AFTER the download, so has nothing to do with bandwidth), it's a whole different ballgame. A torus has 2048 polygons in it, while a cube has just 108. So it takes 20 cubes on-screen to equal the rendering performance hit of one torus, or put another way, a torus causes 20 times more "lag" than a cube. But that has nothing do with Internet bandwidth; it's all local processing on your own video card.

Once again, the streamed information is just a list of parameters; the stuff that shows up on your screen is actual polygons. Don't confuse the two.




So where's the real bandwidth hog? As others have stated, where your bandwidth really gets eaten up is by textures. When viewed uncompressed, textures in SL range from 192 bytes (8x8 pixels times 24 bits per channel) all the way up to 4 MB (1024x1024 pixels times 32 bits per channel). But of course the uncompressed versions are not what are being streamed. SL stores textures server-side in JPEG2000 format, which has a highly variable compression ratio, depending on quality settings, and upon the degree of contrast from pixel to pixel in the image.

From experience saving JPEG2000's in Photoshop, I can say generally, you'll get anywhere from 10:1 at medium quality, to about 3:1 at highest quality. I have no idea what settings SL uses, though, or even if Photoshop's results are a good comparison. All I can say for certain is that the bandwidth cost of every texture in SL is going to be some fraction of 192 bytes to 4MB, depending on the size of the texture.

And that's before you even get into the fact that there's simply no way to predict how many textures will be in any given scene, or what the average size of those textures will be. One hollowed and cut cube can have anywhere from one to nine separate textures on it. Some people do stupid things like put a 1024x1024 on a little 2-foot sign, while others are much more conscientious, and would put a 64x64 or 128x128 on the same sized object.




LV, If I were you I would forget all about this idea of bandwidth per prim. There are just too many variables involved from the textures to make that question answerable. If you want to "optimize" your build, don't do it with bandwidth in mind. Do it with rendering in mind. That means keep texture sizes small, and keep poly counts low. Here are some tips for how to do that:

The way "lag" is usually defined is not Internet latency, but a drop in local FPS. And 9 times out of 10, that drop is because of poor texture management. SL would run pobably 20-30 times faster than it currently does if everyone using it were to optimize textures the way professional video game artists do. (For more information on texture optimization, see the sticky entitled Texture Size, Pixel Counts, Video Memory, and File Formats at the top of the Texturing forum.)

As for poly counts, turn on wireframe view (ctrl-shift-r) and you can get a pretty good idea of how many polygons are in each prim type. From there, use good judgment.

Don't use a tube where a cylinder will do, for example. Tubes have 768 polygons in them, while cylinders have just 192.

Avoid using over-revolved or twisted toruses wherever possible. The torus is the most poly-heavy prim there is, weighing in at 2048 polygons. When you twist it all the way, you double that amount. Give it additional revolutions, and you can quadruple it. Do both, and it's freakin' huge.

Don't over-use sculpties. Like toruses, sculpties have 2048 polygons. They can't be over-revolved, or twisted, so that number is fixed. However, people do have a tendency to over-use them, which can make them a bit dangerous. You don't want hundreds of them on the screen at once, or they will bog people down. Keep their number reasonable.

Those are the kinds of things you want to be thinking about. Bandwidth, be damned; that's beyond your control. As with any other real time environment, good performance in SL is all about rendering speed, and that's something that is under your control.

Why do you say this?

I can see avoiding odd non-power-of-2 sizes, just because they don't look good, but why avoid something like 512x1024, if you actually had need of something that big?

Good catch, Sindy. I missed that one.

There's nothing wrong with 512x1024, except that it's fairly large. It's not an "odd" size, though, in any way, just a big one.

what exactly is a "reasonable" amount to use?. Do we start waiting for the simulator to rezz the sculpties slower?..or...for every 100 normal prims we are allowed 1 sculpty?..Or rather one sculpty every 5 meters radius? Can you clarify?

~Lana

After all that I think I feel a bit woosy. Actually, more like dizzy.

Welcome to MY world

~Lana

`

I count 576 triangles on an untortured tube and 1152 on an untortured torus. Sculpties do have at worst 2048 triangles.

Ctl-shift-1 turns on that little meter window thingie (technical term). I think under advanced, there is a meter for Texture Memory. I assume that is how full your graphics card is with textures.

Hmm, you're right. I stand corrected.

At one time, I went through and made a list of the poly counts for each prim type. My count then showed the torus having 64x32 tris (2048 total), and the tube having 24x32 (768 total). Now it seems it's 48x24 and 24x24, respectively.

While it's certainly possible I could have miscounted then, I have a hard time believing I was off by such a huge amount. Did they change it, perhaps?

I seem to remember there was some effort a while back to make tubes and cut toruses more easily mate with cylinders and spheres. Perhaps this is the result of that? Cylinders and spheres have both always had 24 sections, as far as I know. If tubes and toruses were changed from 32 to 24, it would explain why they didn't quite mate back then, but they do now. I'm just guessing, though. Anyone have any concrete info on this?

I have been tracking the issue of the number of sides on circles for a long time. I think there was a first look viewer that appeared very briefly sometime in 2006, which had 32 sided "circles" on at least tori, and maybe cylinders and spheres as well. I'm pretty sure that it didn't last longer than a month or so (someone complained about their chair I think?). Otherwise as far as I know, the highest LOD for all circles has always been 24 sides.

Thanks, Seifert. If you're right, then maybe that was the time when I counted.

Or maybe I just picked the wrong week to quit sniffing glue that day or something.