Cube as 1/2 a prim

Lets say I fit 100 twisted torii onto my plot - This takes up 100 prims but they have very high tri-counts, they're very complex, lower people's FPS, ect... On the other hand, lets say I rez 100 boxes... They cost the same amount of prims, but are less complex and easier to render.

Basically, what I'm getting at here; I'm realising more and more that I think we should have "tri limits" instead of prim-limits... But that would be a pretty radical change, so...

What are the pros and cons of say a system where if you have a box and it A. isn't hollow, B. Isn't twisted at all, C. Has no advanced-cut... then that simple box counts as 1/2 a prim? If I'm understanding correctly, there would be little to no noticible negative effect (I can already fill a parcel up with twisted pieces &/or torii and get some nasty video lag) Someone who has a house made entirely of 100 boxes would suddenly be taking up 50 prims and have an extra 50 to play with... Just an idea I'd throw out there, hopefully some more technical people can look at this and tell me why it wouldn't work.

This is a "Good Idea" (TM), unfortunately totaly impracticle and impossible. Calling llSetPrimitiveParams could result in objects being returned.

Similar suggestions have already been made several times.... and sadly ignored.

I find prim limitation very frustrating when I am trying to create any items, and something like this which encourages builders to be more considerate when building would be a great help.

Lewis

Wondering how you could have a 'similar suggestion'. I've never heard this suggested before.

I don't have the inclination to search through for the post but I know it was made - whereas instead of prims per parcel, it was more like a score... a basic cube was 1, right up to a torus being something like 5. It was sort of based on a principle that Sims Online uses.

In TSO, you can have 984 "squares" per property, and each item takes up a certain amount of squares.

One large table, for example, takes up 6 squares, and 10 chairs will fit around it, meaning you can sit 10 people in 16 squares.

However, individual one square tables will sit 4 - so to sit 12 you need 3 one square tables and 12 chairs - meaning 15 squares in total - one less than a big table, and you can seat 2 more people.

Such techniques allow creative designers to fit far more in their plot of land. A similar technique, where designers use simpler shapes instead of multiple small prims with detail you can hardly see, would allow people more prims on their land, and of course potentially reduce the amount of work the client has to do to render anything.

Lewis

It takes pretty much the same amount of server resources to save, serve, and possibly do physics on a super complex twisted torus as it does on a plain ol' box.

The server resources are what you're buying when you buy the land, not the client side display.

By analogy: If I make a website that's all straight HTML and images and a few Quicktime movies, it renders much faster on the user's machine than if I make one that's entirely Flash with embedded video and heavy transparency and scripting. But I pay the same amount for bandwidth and space, because all the server has to do is respond to the visitor's requests for files.

Fundamentally, you want simple prims to cost less than complex ones. Truth is the information streamed to the client about the properties of a prim are probably the same (bandwidth wise) no-matter how the prim is contorted.

The only real gain outside of your wish for upping prim limits is that it would persuade a sort of "build friendly" rule thus helping the FPS of only those people with poor graphics cards. That doesn't seem like much of an incentive to me. Especially since graphics cards will continue to improve over time anyway.

I have a 128mb graphics card but often the fps is slow because of lag caused by trying to render so much information.

The simple solution of "just upgrade your computer or don't play" will, sadly, drive more people away than cause them to spend lots of money upgrading a computer that they only need for perhaps one game - SL.

Lewis

Is there any reason the function couldn't just fail if it'd exceed the prim limit?

I've been in at least 2 threads where this has been discussed, as well as different costs for phantom and physical prims.

Is there really so little difference in the amount of physics processing though? I'd always imagined it would be quite noticable (at least when they're in places close enough to places avatars go to cause regular deep thinks).

I suggested having it related to the number of faces, with curved faces counting as six (random number pulled out of my hat) faces, and concave curved faces even more, then scale up the quota 6 times so a cube or a sphere remained the same.

Strife: you could have llSetPrimitiveParameters fail or return just that object. You'd have to grandfather in old objects anyway to keep from having a Great Culling, so scripts could adapt.

True, true, and false. Complex objects are a bugger for the physics engine. Even a hollow cube can be nasty.

Well, it strikes me as a good idea.

It seems that everyone and their grandmother has been suggesting this. Somehow I managed to miss them all!

Anyway, I think it's a good idea.

Thats not true at all. LL's streaming format uses default values and bit masks. The more non default a shape is, the more bandwidth it requires. A plain ol' box has a very small foot print. While a "super complex twisted torus" takes up more bandwidth because of it's "super complex" nature ie, attributes that are not default. The physics stain for a torus is much greater then that of a cube, LL has acknowlaged this. As to saving the asset, i cannot say, LL has given close to no information about how objects are stored.

Bump to add this thread which followed some ideas around the same path..

It would be great as a furniture maker to be able to let invisable poseballs (lag friendly) take up less or no space at all..

I may be looking at this the wrong way - but surely a cube that has been cut, twisted and advanced cut has the same 'tri-count' as one that is default? The fact that the values are set to 0 shouldn't change the fact that the polygons that make up a cube (with allowances for being cut, twisted etc.) still have to be rendered. There should be no difference in rendering times between a default cube and one that has been tortured, should there? There should, however, be marked differences in polygon count (and therefore render time) between the prim types.

At least, that's what I would have thought...

Remember that the default cube has 6 faces, each with for 4 vertices. Even after skewing, top-sizing and dimpling I wouldn't expect it to exceed 12 triangles.

BUT... If you cut a box, you add two more 4-point faces (another 4 tris), but the top and bottom faces become concave, requiring at least 1 more tri each.

If you hollow it, not only do you introduce 4 more faces (another 8 tris), but the top and bottom faces become more complex shapes, requiring at least 6 more tris each. Of course cut and hollow complicates this even more.

Twist needs to add tris to the side faces as they are no longer planar, and their curve needs to be approximated my more and more tris as the twist increases.

The number of triangles for any shape tries to be as few as possible for that shape, so a cube that hasn't been modified is only 12 triangles, whereas one that's been modified will be more.

Do demonstrate, here's a picture of the (camera facing) triangles used for a basic cube and one that's been twisted 90 degrees:



EDIT: Why won't the forum show that as an image rather than a link?!?

Ok, so I was!

Thanks for the quick re-education Ben and AJ

YW, Sable.
the forum only displays image "attachments" in-line (and then only if there are 2 or less, IIRC). It doesn't display images urls posted as "hyperlinks".

Unfortuanately, according to the posting rules at the bottom of the page "Feature Suggestions" currently doesn't allow attachments.

In another thread, Jeff Linden says

Nope, it's definately shown images I've added with the [IMG]tag inline before. Just not this one. Maybe it's because it's a gif, I've only done it with jpegs previously.