About resource usage of the different prim types

From some threads here i learned for instance:



So where does this sort of information come from ? Where can i get a comprehensive information about other prim types ? From the quote above i also learn, that the resources needed by a standard prim can become very high depending on bending/pathcut/hollow/twist ... Is there any sort of tool/algorythm which can tell me how many resources i really occupy with a build ?



How can i determine, whether my sculptie build is starting to make trouble ? For instance if i would make some very high precision construction out of lets say 20 sculpties. Then i would create something equivalent made out of 400 standard prims. How can i judge, which build will be the "better build" regarding resource consumption ? Is there anything else available, except asking others if they "feel" to have some performance problems with my builds ? Maybe the SL-viewer has got some hidden evaluation functions related to builds ?

And finally i am using a graphic card, which allows me to set all graphic parameters to max, which is good for me, but when i reduce my settings i often see, that my builds get bad to some kind. So i started to switch forward and backward my parameters to check how my constructions look alike with lower settings. But can i be sure, that i really see the worst case, when i set my parameters to minimum ? Or could my graphic card still be much better (regarding visualisation quality, not performance) even if the parameters are set to minimum ?

too deep.

SL is not that detailed in that area of resource use.

No one calculates the lag each prim will contribute and i do not think it is even possible.

Well. That particular nugget came from an experiment I did while thinking about it. In fact it surprised me that it was so many! I made a small platform, sat on it and used the editor dialog to raise it to about 1000m, and created a torus on the platform. Then I put the torus in the air, cammed around so It was all I could see, then used the Advanced|Rendering|Types menu to turn everything off except Volumes (which sculpties and toruses belong to), and Advanced|Rendering|Wireframe (not necessary really, but it helps to show what's going on). Finally, View|Statistics bar and opening the Advanced item there gives you a Ktriangle count. This is now about 0 if you can't see the torus and you can see it change as you bring it into view, hollow, cut etc. (This is also a good way to see how the triangle counts of all the objects change with LOD.) So there you are! I had thought that the plain torus was 2048 triangles, like a sculpty, but it's only half that.

By the way, I could never get good counts of small numbers of triangles. So for cubes etc. with less triangles I make a whole array of duplicates and divide by the number.

I went through and counted once, and here's what I came up with, in order from lightest to heaviest:

Prism (default): 4 sides x 1 tri per side = 4 tris

Prism (untapered): 8 sections x 8 tris per section = 64 tris

Cube: 6 sides x 18 tris per side = 108 tris

Cylinder: 24 sections x 8 tris per section = 192 tris

Ring: 24 sections x 9 tris per section = 216 tris

Sphere: 24 sections x 22 tris per section = 528 tris

Tube: 24 sections x 24 tris per section = 576 tris

Torus: 24 sections x 48 tris per section = 1152 tris

Sculpty: 2048 tris

I didn't look into every possible cut and twist permutation because that would take forever, but those are the basic counts.

From loose observation, I've concluded the "average prim" by usage is roughly 190'ish tris. So if poly count is the only factor you're considering 1 sculpty equals about 11 average prims. If a sculpty can replace 11 prims, it's worth using.

Of course, if you're talking just lightweight prims, like cubes, then the numbers get a little more extreme. It takes 19 cubes to equal roughly the poly count of one sculpty. That actually coincides pretty nicely with the numbers in your example. 20 sculpties could replace 400 cubes, and the poly count would be about the same.

For things like asterisk-shaped trees, crisscrossing three or four cubes is going to be MUCH lighter than folding up a sculpty into the same shape.

Leave it to Chosen to break it down and use a new word while at it...."Tris".

Ignorance is oh so bliss...

For the record, "tris" in 3D modeling lingo is short for "triangles". Sorry for any confusion.

Can you explain why? That is to say what is gained, for an undistorted cube, by having 3x3 rectangles on each face instead of just one, since the geometry and texture stretching is surely the same? And if 3x3 is good, why not 4x4 or 5x5 etc? This has always puzzled me.

I've always wondered that myself, Drongle. My assumption is it's just an inefficiency in SL's development that went overlooked. If there's a deliberate reason for it, my best guess would be maybe it's for lighting purposes. I'm totally making that up, though.

My guess is that in order to have a potentially distortable cube, you need to have a target region (a handle, if you like that word better) at the center of each face that can be pulled out or pushed in. To preserve symmetry when you pull/push on that target area, it has to be the same size as surrounding areas, which means there has to be an odd number of areas on the face (3x3, 5x5, 7x7, etc.). Go with 3x3 rather than a higher number in order to reduce the computing power it takes to distort the cube.

Chosen almost certainly has the RIGHT answer, but that's my best guess.

Edit: Or not. It sounded better in my head than it did once I typed it.

I am proud to see, that i do know something better than the experts, hah!



LOD is everywhere ))) The picture shows the same prim cube from different distances. I used the wireframe option to show the mesh and i recolored the background to black, so you can see better on the pic.

Have fun
Gaia

Gaia, don't refer to yourself as "not an expert". Your Blender tutorials have been pretty incredible. Clearly you know what you're doing.

I get your point about LOD, but I'm still not sure why LOD is at all necessary on a cube. It could stay just 12 tris all the time, and it would still be a cube. It's not like, say, a cylinder, which actually does benefit shape-wise from adding more faces as the camera gets closer to it. A cube is a cube is a cube.

One might conclude it's just a simplification, so exceptions or alterations to the basic LOD multiplication don't need to be made for different prim types, except that default prisms are just 1 tri per side at all LOD levels. So clearly at least one exception is being made. If it can be done for the prism, why not for the cube?

A cube needs all those polys for the vertex lighting. Otherwise the light would only effect the corners of the cube.

Thanks, Virtually. I thought it might have to do with lighting.

When the shadow viewer becomes widely used then LL will be able to reduce the number of polys per cube because the shadow viewer uses a more advanced shading model.

I am certainly not an expert. Your picture shows the facts nicely, but does not explain them. Even if more vertices are needed for shading, why isn't it 4x4, 2x2, 1x1 (like the 2-fold reductions for sculpties (except the lowest LOD, which is a mess))? I am sure there will be agood reason.

3x3 probably gave satisfactory lighting results for a 10 meter prim. Pointless using 4x4 when it's not really necessary.

Although for a megaprim a 3x3 surface will be useless with local lights. But those monsters were never supposed to exist anyway.

I have read an article about vertex lighting and i have the feeling, that the effects are irrelevant for SL, because we do not have shadows here. But it is a bit complicated (or the article is a bit complicated) so i did not fully understand it and its implications. I found something about gouraud-shading too. is that the same ? here are 2 links:

http://phalanx.planetunreal.gamespy.com/tut%27s/tutorial_vertex.htm
http://en.wikipedia.org/wiki/Gouraud_shading

So i made some tests in SL but i was not able to see any difference on my 3 cubes (which i posted earlier. Especially the small one with only 2 tris per side does not look the slightest bit different compared to the one rendered with 108 tris... i am puzzled...

ok, what would i have to expect to happen on my LOD1 Object then, regarding vertex lighting ?


While i was at it, I did yet another experiment:

1.) i placed my camera near to a cube, so that it is rendered with 108 tris. (LOD3)
2.) i started twisting it. Up to 44 degrees the number of tris keeps constant.
3.) with a twist of 45 degrees, the cube gets one additional "layer of tris" so that it is now 4*6 = 24 tris n each side, while top and bottom keep as before (18 tris)
4.) twisting further brings more and more additional "layers" to the cube.

Now i moved my camera away, so that the prim is only rendered with LOD1 and twisted again. The object starts looking ugly as soon as i start twisting it.

Can it then be, that cubes have 18 faces per side, so that LOD for all standard prim objects can be calculated in the same way ?

i don't have the feeling, that i have understood this issue here

regards,
Gaia

I don't understand why this is worth worrying about, but if I understand the problem with the vertex lighting I can illustrate it fairly easily.



The door on the left is a sculpty, the one on the right is a copy with regular cubes. You can see how the lighting reacts incorrectly on the sculpty's faces.

Yes Ponk. That's one of my great disappointments with sculpties. It completely ruined my therwise beautiful icosaheron which had the edges formed by diagonals all softened like that. Qarl would say it's as it should be because they were never intended for sharp edges.

It works fine if you swap the edge for the next lesser LOD line, problem is the sculpty suffers for obvious reasons. Baked lighting and fullbright is the only real way to get around it.

There is a quick and dirty way to measure the render cost of a prim type though, just look at your avatar's render cost by enabling it in the advanced menu and attach whichever prim you want to measure the cost of and subtract your original number. Don't forget the prim's texture also counts against the cost, so attach a plywood prim to your left hand when you take the first number and keep it there as you attach the other prim to your right.

I don't know how the render cost is measured, but it'll tell you which prim is the laggier.

Vertex lighting is how SL lights up the world. We would be in the dark without it. Actually, on the 6th day God probably said "Let there be vertices".

It isn't connected with shadows at all. Shadows and shading are handled differently in today's realtime 3D engines. It's only in raytracing where shading and shadows are the same.

and yes, vertex lighting is basically gouraud shading.

If you rez a 10 meter prim/wall and move a light around in front of it then you'll see how it only works on the vertices. The more vertices there are then the more options there are for the lighting to work from.

We could probably get away with not having multiple vertices per cube's surface if 'local lights' were removed, as then SL wouldn't have to reproduce the spotlight effect we expect from small local lights. But this would mean no realistic bedside table lamps etc.

Finally, the twist function of the cube will also need extra vertices to work. Although this doesn't apply to a non twisted cube.


Disclaimer - None of the above applies to the sexy new shadow viewer/client

hah! This is something of which i think, that i can understand now Together with what i have learned so far from the other documents this makes pretty much sense. I have overlooked the local lights...


This is what i was looking at yesterday. I thought, maybe the 18 tris per side are due to optimisation. At the end a cube is just another mesh, it does not know, that it is a cube. So, maybe it is just a coincidence, that LOD calculation is made independent of the object and the 18 tris in LOD 1 make up for better local lighting ? I would really appreciate a programmer's remark on this. The answer should be embedded in the viewer-code somewhere, no ?

Is there something i can download as ready made executable for windows-xp ?

http://my.opera.com/boylane/blog One there =D

I see what you're saying - that the LOD manager expects to reduce a mesh's polys for each LOD. Which would mean that it would be necessary that a cube has lots of vertices at the highest detail level or it would collapse into nothing.

It does make sense.