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

[Erik Anderson]

You know, the fact that megaprims are limited to only 10 or so shapes may be
making things easier.  *Can* you make a truncated skewed twisted profile-cut
torus from the current options available?  Limiting us to a menu may prevent
some of the more nasty shapes that might otherwise be created in the build
menu.

And I do recognize that nonphys prims are not invisible to the physics
engine, which needs to calculate collision targets for phys as well as
nonphys objects.  It would be a lot harder to create the skyboxes that I
have if I had to tile 10x10 prims instead of the six megaprims I'm using now
though...

On 10/17/07, Dzonatas <dzonatas at dzonux.net> 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.
>
>
> > When you rez a prim larger than 10 meters, it gets ignored by the
> > physics engine.
>
> That would break content. 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.
>
> > The whole business of automatically generating sets of new prims that
> > behave like a single prim seems unworkable to me. The shape of a
> > component prim that results from resizing a truncated skewed twisted
> > profile-cut torus is just too complex to describe compactly... the
> > server and the client both will have to completely ignore the
> > component prims, and perform all the same calculations for rendering
> > and physics as if it was a single megaprim, and in addition generate
> > magic linksets. Where are the savings?
>
> 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.
>
> > 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. The entire object
> does not need to be seen by each process, but each process decides on
> which parts of the object it retrieves and computes.
>
> --
> Power to Change the Void
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071017/048eff8f/attachment-0001.htm