[sldev] A patch to allow creation of megaprims from
within theviewer
Tateru Nino
tateru.nino at gmail.com
Wed May 14 10:17:21 PDT 2008
The environmental experience isn't uniform, though. I can tell you right
now that compared to my old graphic settings, the grid looks and feels
VASTLY different to how it used to with my new machine. Being able to
run a higher draw distance than 64 has changed my whole experience of
SL. When you add in shaders, lighting settings, and detail sliders,
(also dropped packets and ruthing) the view of the virtual world is
really quite inconsistent from user-to-user.
Dale Mahalko wrote:
> The main issue I see with megaprims is making the environmental
> experience uniform for all users. This means that the environment
> should perform reasonably similar for people who run with the minimum
> viewer settings of a 64 meter view distance. I have been on sims that
> use 200+ meter prims across the entire sim, and with a view distance
> of 64 meters this huge prim is frequently invisible to me because its
> centerpoint is over 64 meters away.
>
> People designing for large spaces need to take this into
> consideration, and need to either:
> 1. Use prims that fit within the 64 meter view distance, or
> 2. Inform all visitors on arrival that this sim requires a higher
> performance view distance setting to see it correctly.
>
> Note that if a megaprim is centered in the middle of a sim, the
> minimum viewing distance to see it from a sim corner is 182 meters.
>
> I do not know how sloping affects the view distance, but if a megaprim
> is up in the air, this adds a third dimension to the view distance and
> may require a higher yet minimum view distance of perhaps 200 to 256
> meters.
>
> An alternate way to deal with this so that say a 65536^3 sky megaprim
> is visible even with a view of 64 meters, is to add a flag that makes
> a prim always visible within a sim regardless of viewer distance. But
> this would require changes to all prim data structures, the UI to
> permit this setting, changing the way the sim determines what objects
> the client should be sent, and the client itself.
>
> - Scalar Tardis / Dale Mahalko
>
>
> On Wed, May 14, 2008 at 11:00 AM, Matthew Dowd
> <matthew.dowd at hotmail.co.uk> wrote:
>
>> This approach sounds "right" in that it captures the policy which was (at
>> some point, possibly still is), that megaprims were allowed on private
>> estates but not on mainland.
>>
>> The implementations suggested sounds a little complex, I'd propose something
>> simpler:
>>
>> An estate owner has an additional option in the estate tools "Allow
>> Megaprims".
>>
>> If you are on a sim with that option checked, then you can rez megaprims
>> (there probably should be some maximum to the dimensions, but this has been
>> discussed elsewhere), and the restrictions in the build tools is relaxed.
>>
>> If you are on a sim with that option unchecked, then megaprims fail to rez
>> (and no copy ones remain in inventory) with a suitable "prim too large" type
>> message, and the restrictions in the build tool are enforced.
>>
>> The assumption is that mainland would have this option unchecked.
>>
>> A slightly more versatile (and IMHO preferable) variant would be to instead
>> of a checkbox, have a sim-wide maximum prim dimension which the sim owner
>> can adjust (in the same way they can adjust sea level).
>>
>> So the default (and value for mainland) would be 10m, but an estate owner
>> could set this to 100m, or larger.
>>
>> Again the same rules as above apply - the build dialog restricts to the
>> value of the sim, and prims sized above this limit fail to rez.
>>
>> Matthew
>>
>>
>>
>>
>>
>>
>>
>> ________________________________
>> Date: Wed, 14 May 2008 16:33:05 +0100
>> From: talinsands at googlemail.com
>> To: sldev at lists.secondlife.com
>> Subject: Re: [sldev] A patch to allow creation of megaprims from within
>> theviewer
>>
>> Mega-prim proposal:
>> SOs = Sim Owners
>> There are many SOs who believe mega prims are bad for performance and
>> degrade revenue streams...some SOs use mega prims to in order to solve
>> problems which can not be solved with regular prims. We are not here to
>> argue the rights and wrongs but to offer a solutions to Linden Labs which
>> will work for all.
>> I propose giving SOs the ability either to allow or deny the use of
>> mega-prims on their Sims. This will simply be a process where only
>> mega-prims created by the Sim Owner will be allowed on the Sim ( this will
>> require a new prim type I beleive ). This discourages the creation of items
>> for sale which include megas, and also removes the ability of griefers to
>> utilize mega-prims in their attacks. The Sim Owner can then make a set of
>> full perm megas and give them to staff/residents for use on their Sims only,
>> as they will not rez on other Sims. If the Sim Owner chooses not to allow
>> mega-prims then it is simply a case of not creating them.
>>
>> On application of this new treatment of megas I suggest a 3 month period
>> of adjustment before the older megas which do not conform are removed from
>> the asset system, and this change should be well publicized.
>> I believe the problem with megas and prims overlapping other Sims is being
>> addressed by the Lindens. Ref.."Megaprim Liberation" project.
>> http://www.massively.com/2007/12/22/megaprims-to-stay-andrew-linden/
>> http://wiki.secondlife.com/wiki/User:Andrew_Linden/Office_Hours/2008_05_10
>> However, I would like to read what other plans Linden Labs has in regard to
>> mega-prims well in advance of any action, in order that SOs may have enough
>> time to adjust any plans, both past and current, which may be impacted by
>> any change.
>>
>>
>> On 14/05/2008, Felix Duesenburg <kfa at gmx.net> wrote:
>>
>> I took the liberty to put this on the agenda for the open source meeting,
>> which I hope meets with approval. Although not aware of every previous
>> discussion on this, it seems far from finalized and maybe we need some fresh
>> arguments to reach a conclusion on a workable policy.
>>
>> Felix
>>
>>
>> Sylvio Deutsch wrote:
>>
>>> Oh no, sad news... I´m one of the very happy with the mega prims
>>> hability...
>>>
>>>
>>> {}Overtake
>>>
>>>
>>>
>>> ----- Original Message -----
>>> *From:* Able Whitman <mailto:able.whitman at gmail.com>
>>> *To:* sldev at lists.secondlife.com <mailto:sldev at lists.secondlife.com>
>>> *Sent:* Wednesday, May 14, 2008 12:38 AM
>>> *Subject:* [sldev] Re: A patch to allow creation of megaprims from
>>> within theviewer
>>>
>>> Unfortunately, Andrew Linden confirmed today in his Havok4 office
>>> hours that the ability to create megaprims was unintentional and
>>> that the fix to disable it "should go out in the next server update"
>>> (see:
>>>
>>> http://wiki.secondlife.com/wiki/User:Andrew_Linden/Office_Hours/2008_05_10).
>>>
>>> I'm disappointed. I've gotten nothing but positive feedback about
>>> the ability to create large prims and their usefulness in
>>> streamlining builds and reducing prim counts. Andrew mentions that
>>> "Qarl Linden is working on the true beginning of 'Megaprim
>>> Liberation' -- being able to return objects that overlap onto your
>>> land." I'm hopeful that we'll be able to see this liberation sooner
>>> rather than later.
>>>
>>> For people who are using my patch against other grids that already
>>> support large prims, I'll keep fixing bugs that are found and
>>> posting updates on my site (ablewhitman.org
>>> <http://ablewhitman.org>) instead of in JIRA.
>>>
>>> Cheers,
>>> --Able
>>>
>>> On Mon, May 12, 2008 at 5:36 PM, Able Whitman
>>> <able.whitman at gmail.com <mailto:able.whitman at gmail.com>> wrote:
>>>
>>> I've posted an updated version of my patch on JIRA. It's a small
>>> fix to lltoolplacer.cpp which will clamp the scale values in the
>>> new stored settings against MIN_OBJECT_SCALE and
>>> MAX_OBJECT_SCALE before sending the ObjectAdd packet. This way
>>> invalid (negative, too small, too large) values won't be passed
>>> along in the ObjectAdd request.
>>>
>>> The practical effect is small, since these values are still
>>> validated by the sim, but it's an extra precautionary measure.
>>>
>>> Cheers,
>>> --Able
>>>
>>>
>>>
>>> On Sun, May 11, 2008 at 4:37 PM, Able Whitman
>>> <able.whitman at gmail.com <mailto:able.whitman at gmail.com>> wrote:
>>>
>>> Howdy,
>>>
>>> This is the second small feature I've been working on
>>> lately. Apparently at some time in the recent past, an LL
>>> server update re-enabled the ability to create prims with
>>> dimensions larger than 10m on a side. There are already lots
>>> of new megaprims available, mostly for free (like here on
>>> SLExchange:
>>>
>>> http://slexchange.com/modules.php?name=Marketplace&file=item&ItemID=685589
>>>
>>> <http://slexchange.com/modules.php?name=Marketplace&file=item&ItemID=685589>).
>>> I'm pretty sure most of these prims have been created using
>>> LibSL-derived tools.
>>>
>>> I don't know if this new-again ability is intentional or
>>> not, although I certainly hope it is because megaprims are
>>> incredibly useful. Either way, I wanted to be able to create
>>> large prims directly in the viewer. My biggest reason for
>>> wanting this ability is so that any builds I produce using
>>> these prims will then list me as the creator, instead of the
>>> creator of the prims that come from megaprim collections.
>>> Being able to create them myself also gives me the
>>> flexibility to have large prims in whatever size I need,
>>> regardless of whether someone thought to create one in
>>> advance or not.
>>>
>>> For the moment, I haven't posted this patch in JIRA, for a
>>> few reasons.
>>> 1. As above, I'm not sure if the ability to create these
>>> large prims is intentional or not
>>> 2. The patch, as it stands, isn't as good or as polished as
>>> I'd like for a JIRA submission
>>> 3. The creation and handling of large prims in the viewer is
>>> quirky
>>> 4. The use of megaprims always seems to be somewhat
>>> controversial
>>>
>>> With regards to "quirky", these large prims are subject to a
>>> couple of constraints:
>>> a. Prims with dimensions greater than 10m can only be
>>> *created*, they cannot be resized again later
>>> b. Attempts to resize any dimension of a large prim results
>>> in all dimensions of the prim being re-clamped to a 10m
>>> maximum
>>>
>>> With regards to controversy over the use of megaprims, I
>>> certainly understand that they can be used as a greifing
>>> tool (and I myself have been on the grief-receiving end of
>>> this). However, I feel that the incredible usefulness of
>>> such large prims greatly overweighs the detriments. Some
>>> people seem to disagree vehemently, though, so I thought a
>>> discussion here might be fruitful.
>>>
>>> That said, the patch itself is actually fairly
>>> straightforward. Part of the patch simply enables the Build
>>> tools to display and edit scale values larger than 10.0.
>>>
>>> Since large prims can only be oversized on creation, I've
>>> replaced the viewer's hard-coded new prim size of <0.5, 0.5,
>>> 0.5> with configurable settings. Then I've exposed these
>>> settings on the Create tool panel of the Build tools floater.
>>>
>>> Put together, these changes make it pretty simple to create
>>> prims of whatever dimensions you'd like.
>>>
>>> I've attached my patch (which is against 1.19.1.4
>>> <http://1.19.1.4>, the most recent official release viewer),
>>> as well as a screenshot demonstrating the patch in action.
>>>
>>> Please let me know if you have any questions, thoughts, or
>>> concerns.
>>>
>>> Cheers,
>>> --Able
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Click here to unsubscribe or manage your list subscription:
>>> /index.html
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Click here to unsubscribe or manage your list subscription:
>>> /index.html
>>>
>> _______________________________________________
>> Click here to unsubscribe or manage your list subscription:
>> /index.html
>>
>>
>> ________________________________
>> Get fish-slapping on Messenger! Play Now
>> _______________________________________________
>> Click here to unsubscribe or manage your list subscription:
>> /index.html
>>
>>
>>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>
>
--
Tateru Nino
http://www.massively.com/
More information about the SLDev
mailing list