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

[Dzonatas]

The question if we can make such a truncated skewed twisted profile-cut 
torus now or in the future should not limit us now to what we can shape. 
The server and viewer decides what can and can not do. If the physics 
engine can do it, then it allows it. If it can't do it, then it takes 
some corrective action, like make it non-physical or phantom.

The point being there is that we should not limit the prims to current 
implementation. That, however, I did suggest the protoforms, like the to 
10 or so shapes that now exist.

It would be harder, as you suggested likewise, to manually embed prims. 
The process would be to create one wall by the tile method and then 
select optimize to transform it into the megaprim. Then, you can 
duplicate that 5 more times to create each side of the skybox. Then, 
select all sides and select optimize one more time to create a giant 
hollowed skybox megaprim.

There is actually a whole idea about being able to store these kind of 
megaprims in some archive format under a single optimal object 
reference. I haven't got into the details about that on this list, however.

Erik Anderson wrote:
> 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 
> <mailto: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
>     </index.html>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>   

-- 
Power to Change the Void
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071017/428b88be/attachment.htm