[sldev] Optimus Prim vs. Megatrim: "The Big Prim Problem"

[Argent Stonecutter]

On 17-Oct-2007, at 11:31, Dzonatas wrote:
> Argent Stonecutter wrote:
>> On 17-Oct-2007, at 09:15, Dzonatas wrote:
>>> What to do with the megaprims?

>> Keep them, let people create and rez new megaprims up to 256  
>> meters, don't make it a complex operation to do so, don't  
>> magically convert prims into linksets, just ignore them in the  
>> physics engine.

> My post was not about to create linksets, but that would be a  
> similar idea if the basic prims did not *transform* or *optimize*  
> as suggested in my post. Linksets, therefore, would be a different  
> topic.

Whatever you call them, the magical optimization step is a lot of  
added complexity. I honestly don't see what it buys you.

>> When you rez a prim larger than 10 meters, it gets ignored by the  
>> physics engine.

> That would break content.

Only if it was applied to existing megaprims. They obviously should  
be grandfathered in for some period.

> On the rez event, instead, is where parts of the system can use the  
> original untranformed/unoptimized version (hence "protoform") and  
> decide if it can work well with the physics at that point or if it  
> has to force phantom.

So you'd have the same prim sometimes being treated as multiple prims  
and sometimes not? Sometimes phantom or sometimes not?

The thing is, as far as the physics engine is concerned, a linkset  
40m across is just as hard to deal with as a single prim 40m across.  
A linkset with a hollow is just as bad as a hollow prim. If the prims  
are unlinked and magic, what happens if some of them are deleted? It  
seems a lot of complexity that will violate the principle of least  
astonishment.

> Given both versions of transformed and protoforms, each process  
> (client or server) can decide what is the best version to use. All  
> the calculations to render either version can be done ahead of time  
> instead of on each event.

I don't see how exposing the complexity to the end user provides any  
benefit. As something that the server could to to simplify the  
calculations for concave objects under the hood, sure... but the  
client doesn't care, it only wants the graphically simplest form.

>> For structural pieces? Just embed transparent non-phantom prims  
>> inside the megaprim.

> You asked "where are the savings?" Here is one answer. That  
> embedded suggestion is very similar to have the protoform and the  
> optimized/transformed version stored as one object.

Except there's a benefit for the user seeing it - the user gets to  
control what the physics engine has to deal with.