Primitives building vs. vertex building....

Hi all,

I wanted to sound out an idea for the feature request. The Lindens have come up with a really great building system that gives us so much freedom, yet simplicity. Er… yes, it’s very simple…believe me, it could be much more complex!!!

However, this comes at a cost of extra vertices and faces that are never seen by the naked eye. I’m not sure what the percentage is, but I wouldn’t be surprised to find out that 50% of the faces and vertices are not necessary and yet causing our video cards that much more work or (as in my case) that much more information that needs to be downloaded from the internet.

Now, if we could simplify and trim up our objects and double the number of objects we can build on our land by removing this unnecessary information, wouldn’t that be a good thing? What if we could do this by:

1. instead of “charging” our land for number of primitives, you charge for number of Vertices.
2. give us a new function that “fuses” unseen vertices and faces. This would remove redundant vertices, hidden faces and provides new vertices where needed at intersections.

This could save 4 vertices and 2 faces per intersecting wall. Also, unless there is another reason for it, you could remove the size limit for walls. Once upon a time, in beta, LL wanted to “control” building via taxes on how many objects you had plus how large those objects were. This system proved to be too constraining. But my point here is that , I think this was the main reason for prim count. If that reason no longer exists, How about we get more efficient with our prims / vertices so we can get more out of our builds? More bang for the byte?

Shall I add this to the “wish list”?

Ingie

Hi Ingie. Good points you made there. There is a lot of unnecessary data downloaded and processed. And given that SL renders using the painters algorithm, all those hidden faces can put a real load on the client. I sometimes use a pure alpha texture on hidden faces to avoid rendering artifacts (like visible seams in a 50% transparent wall) - perhaps a "Don't Render" checkbox on a face could mark it as invisible and not to be rendered. No need to download a texture or have the GPU chew on it. It would be nice if that could be automated, but that might be difficult as sometimes you want those internal faces for whatever reason.

As for prim size, I'm told that the max 10m size has to do more with overlaps between sims. Each sim has to know about prims in the overlap zone, for interactions with avs and physics. If you made prims larger, the overlap size would have to be larger too, which would put a heavier load on the sim.

I wonder how the new render engine will change all this.

I ain't no Linden programmer, but I am guessing that the system they chosen is because of the nature of prims and the generic way they might be used. ie: Yes, you could go with a less generalized rendering method, but then that would require you to be mindful of how prims were assembled. Worse, an optimized renderer would likely make it that easier for a newbie to overload a sim by creating unoptimized prims. (Personally, while there might be some optimization that could be done automatically, I don't see it happening unless we had more elaborate build tools. ie: A "snap to object" rule that would make flat boxes merge their edges together. Only for rendering though, they would still need to be treated seperately for physics and sim splits.)

Pre-sorting back-to-front also makes things simpler when it comes to rendering mixed transparent/opaque prims, even though most 3D renderers don't bother with pre-sorting nontransparent geometry these days. (Faster to let Zbuffer sort it out!) But then again, SL's renderer can't be optimized for specific geometry cases as can be done with %90 of the game graphics engines out there...

So, while they are very good ideas, but I don't see 'em being implemented in SL.

I wouldn't.

You're thinking of prims in terms of how they are rendered, which is purely a client side thing. The data that is streamed from the server is a trivial number of parameters that fully describe the prim's shape and orientation. Therefore, a cube or torus or any other prim probably only takes 10-20 bytes of data to stream from the server.

The client has a lot of work to do to render the primitives, but the bottleneck with SL is the server->client bandwidth.

- Jon

I welcome Ingie's innovative idea. We need more ideas like that to reduce lag.

I think you don't solve a problem by tossing it off to the "client-side" pile (as I've said elsewhere about spinning scripts, etc.).

LL needs to be considering about the effect some customers have on the client side for other customers, too. They need to secure a common space where performance is optimal and where there are various deterrents on people's piggish nature to affect the enjoyment of others of their game.

Tortured prims can slow down, hoochie hair can slow down, etc.

So this represents a suggestion that might work. I've seen it in other games. It means you won't have that much fun doing the 360 degree camera pans and getting the awesome screenshots (I'm thinking). But it could be worth it if it speeds up the world.

Conceptually, I agree with what you're saying. The point I'm making is the implementation doesn't allow for it, in the way Ingie suggested.

SL servers don't send prim vertex data to the client, so there isn't anything to eliminate.

Reducing load on the client is a good idea, and we should probably talk about that, but its a different issue.

- Jon

Thank you Jon, I didn't realize it worked like that, but I see now why it won't help. I'm going to have to have my phone lines re-wired in my house anyway (hee hee, they're so messed up!!) I might get the bandwidth I need once we do that.

Ingie

If you want to learn more about how it works, the link below is a paper written by Philip and Cory that describe in detail some of the hardware and software technologies used, and the tradeoffs required.

http://www.cs.ubc.ca/~krasic/cpsc538a/papers/rosedale.pdf

- Jon

Thank you! This looks like good reading! Wow, and look at the map of the world! That's how I remember it. Everytime, I open the map, I'm... shocked doesn't quite do it for me, more freaked out and lost!!! The world is HUGE OMG!

I have so much to see, and so much goes away before I ever get to see it.... Life, Secondlife is passing me by........ 8:

Thanks again, didn't ever see that before! Love Ingie

BTW, the real number is probably substantially larger than this -- you also have the keys of the textures (16 bytes each), and the keys of any scripts in the prim, and any sound clips associated with it, etc.

But, all in all, its still a much smaller number than it would be if you sent actual polygons down, at least WRT curved-surface prims.

- Jon