[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