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

Dzonatas dzonatas at dzonux.net
Wed Oct 17 07:15:00 PDT 2007


What to do with the megaprims?

I've read a lot of the suggestions, and most of them make me want to go 
"Hmmmmmm...." Very good ideas with a lot of thought, and there is one I 
thought came close to the solution.

Aimee Webber had blogged about the idea, but she was very close to what 
Philip Rosedale suggested in his keynote speech at OSCON.

Here is Aimee's blog:  
http://www.secondlifeinsider.com/2007/10/12/what-to-do-with-megaprims

Consider her suggestion about the "Arbitrarily Large Radii" and 
"Built-in tools for large shape creation" for a moment.

Then, consider what Philip Rosedale suggested about optimization in the 
keynote speech!

*BAM*

Add an option to optimize prims!!!!!!!!!!11!!!!111!!111!

For example, take 2 ordinary 10x10x10 box prims and connect them 
together so the faces line up on one side.  When the optimize-prim tool 
is activated, the server would create one 20x10x10 prim. The server 
essentially combines the two.

Want a different prim shape?  Take the post optimized-prim and just 
change the shape.  This is how we can still create the big sphere (as in 
Aimee's blog) with box prims and no special scripts. Just put 4-10x10x10 
prims together in one larger square face to face and all selected for 
edit, select optimize, and change to sphere.

Simple.

Why do it on the server? Because that is where we still limit prims to 
10x10x10 only to be rezzed/created  as it is now. Other sanity checks 
can be added if we limit creation of a larger prim to be done piece by 
piece. I won't go into all possible checks, but one would be that the 
creator would have to have enough land space in order to create prims, 
optimize, and end with the larger prim.

I'm still question if we should allow larger prims to be stored in 
inventory directly or make the larger prim break down to the smaller 
prims first before it goes to inventory. There are other ideas like 
allow it to be stored to inventory as a huge prim but then the server 
decides if it has to be rezzed in smaller prims and re-optimized 
automatically to re-rez the larger prim.  Either way could solve some of 
the encroachment pains.  (for example, someone tries to rez a 256x256x1 
prim on a 16sqm parcel -- can't be done with this scheme as the smaller 
prims tries to rez on someone else's parcel)

This scheme also solves one of the physics problem, the prim being known 
to made with smaller prims, already has the footprint to use for the 
physics engine. I'd imagine some extra parametric offsets may be needed 
(if now possible with Havok4) to (for example) offset the origin of an 
spherical section.

Should we max the size of the prims?  If we stick to this rez scheme, 
piece by piece (10x10x10 prim by 10x10x10x prim) then one starts to be 
limited by how much land they have permission on to create such a prim. 
Perhaps, for now, we could limit the max optimized size to a 64m length 
in any dimension to work with the minimal view distance.  That 64m 
length would also mean a change that distance is calculated from either 
the larger optimized prim edge instead of its center or from each center 
of the pre-optimized prims. There could be an advantage either way upon 
final implementation.

(I thought we should call this option "transform" but the image of the 
Allspark scene with Bumblebee came to mind lol -- but then Philip would 
earn the avi name of Allrez)

-- 
Power to Change the Void


More information about the SLDev mailing list