Jump to content

Helium Loon

Resident
  • Posts

    309
  • Joined

  • Last visited

Posts posted by Helium Loon


  1. Madelaine McMasters wrote:

    I agree about the ambivalence of units, which is why I described the architecture as a ratio to my height. SL's architecture is simply proportionally much larger than RL architecture. Nevertheless, we seem to enjoy it just fine.

    I just popped in world to probe my avatar bounding box with a tiny sphere. I get the impression it's actually a bounding ovoid. I moved the sphere near my head until it started to push me, then lowered it towards the ground. It continue to push me until around pelvis height, then stopped. At ground level I moved the sphere towards me again until it pushed, then raised it. Again, it continued to push me until reaching pelvis height. The top of the ovoid was about at the top of my head, well under 2.95meters. So Abigail's claim that the box started scaling in 2005 seems true. Making the box an ovoid also makes sense as that maps better to the head, though it's a bit more difficult computationally.

     

    That actually isn't surprising it's an ovoid shape....specifically, probably a scaled sphere......which is actually computationally easier than a box shape to calculate intersection tests with (which is what the physics engine has to do), since it can simply be represented as a set of radii and a central point.  And ray-sphere and object-sphere intersection tests are highly optimized and computationally much simpler than just about any other shape.

     

    And while the bounding box scales to the 'height' of the avatar (based on the shape worn) to some degree, it doesn't handle a lot of deformations done with odd shapes (llike Tinys) so the actual max and min size of the bounding shape's extents is pretty fixed.  Even designing architecturally for the 80% median range sizes, means scale is still skewed a LOT.......human height ranges for that 80% median scale only cover a range of about 18 inches (5 foot 6 inches, +/- 9 inches) but in SL that range goes a LOT further.  The median height in SL runs at 2.1 meters, or around 6 foot 11 inches, with a variance (at 80% median range) of +/- 68cm, or about 27 inches!  That's TRIPLE the potential difference compared to reality.  That means scaling up of architectural details is correspondingly larger.

     

    Furthermore, as has been mentioned already, camera position is offset above the avatar....resulting in even MORE height adjustment for architecture, since we have to accomodate the camera position as well.  Fortunately, if you are already scaling based on the avatar size ranges, you are pretty safe, except for the very tallest avatars.  The very smallest avatars (not counting tinys) will seem to be dwarfed by comparison to the architecture, though.

     

     

  2. Charlar,

     

    I tried to download the viewer-development-shining-fixes build to see if the issue persists in it.....but the last good build (284404) under cygwin gets an access denied XML page for me.  But I can download the mac and linux clients for that build without problem.  Current bulid failed for cygwin, so can't try to DL that one.  Unfortunately, I'm a windows user, so the mac & linux builds won't help.

     

  3. There are two major things to remember here....

     

    First, since the collision model (aka, bounding box), does not animate.  It does not bend or deform.  So in order for architecture to allow for those avatars which are set at maximum height (2.95 meters!), the doorway HAS to be big enough for that bounding volume to pass through.  While those who set their height that large are relatively few, there is the potential, and if the doorway is NOT large enough, it becomes a blockage to them.  The bounding box can't 'stoop down' or 'crawl' through a doorway that is too short/narrow.  So, in addition to the cam problem, there is an accessibility problem.  Thus if the doors are scaled up, the floors themselves have to scale up as well.  Which means windows and most everything has to scale up proportionately.

     

    Second, in a virtual space, units are just that.  Units.  They are arbitrary.  In SL, we use meters, and we assume they correspond with RL meters.  But they could just as easily be inches, angstroms, furlongs.......anything.  Everything is relative to the base units chosen.  In the real world, we have concrete points of reference that we use to define our systems of measurement (aka, units).  We agree with others to use them for our calculations and measurements, so that we can agree on quantities and dimensions.  But in a virtual world, there IS no concrete point of reference, only numbers.  So, everything is relative to whatever units they chose to use.

     

    So if your avatar is 2.3 meters tall in SL, that's fine.  Those meters may not be the same as RL meters.  We build and design based on that, but it would be more appropriate to measure things based on a standard default avatar size......so if the average avatar was 2.3 former meters in height, They would now be 1 'height unit' tall.  And a standard cube would rez at 0.21739 'height units' tall.  It's all relative.

     

  4. Just verified in-world with others who are using other viewers (one of which was on a new dev build (Second Life 3.2.8 (248008)), so the mesh render code should be up-to-date) and they all saw the issue.

     

    While this is a rather specialized case (mesh with mulitple materials, some faces set with transparency) it isn't THAT unusal......I'm thinking this is buggy behavior.  It also masked-out hovertexts, even the name/displayname/viewer blocks, water, and anything with a non-zero transparency setting.

     

     

     

     

  5. Okay.  I updated my drivers.....even went up to the current beta geforce drivers (290.53)

     

    I'm still seeing the issue in firestorm-release.  Checked my other machine (with the 560GT Ti), same thing.

     

    I should probably note something.  The mesh with transparency that is demonstrating the issue is an rigged avatar attachment, and has different materials (some of which are transparent, some aren't) and that's what's creating the issue.  The mesh has three 'layers' that are turned on and off via script by changing the tranparency of two of the layers (either both 100% transparent, or one or the other 100% transparent.)

     

    I'm including a pic to show it:

    (The red object in front of the mesh figure is actually a spherical red glass xmas ornament.....)

     

    GFX-Bug-Mesh-001

     

     I'll have to try the current LL viewer to see if it also happens there, or if it's just Firestorm.

     

  6. That is very possible.  I had to back up to a pretty old driver to avoid a nasty bug on this older machine......OpenGL kept crashing with the newer drivers at the time.  I'll update again and see if it's improved any......the card is a 7950 GTKO, so while performance isn't bad, it had some issues with the newer drivers.

     

    If that doesn't help, I may have to upgrade my card......if I can afford to.  (my other comp has a 560 GT Ti......and runs much more current drivers.  I'll see if it happens on that machine too, and will report back here.

     

  7. *laughs*

     

    Sorry, Chosen.....I know that particular terminology is incorrect in reference to 2D graphics and 3D meshes.....I was referring (as I think you know) to the Alpha Masks.  But you are correct.....in this forum, considering how layer, channel, and mask are all applicable, I should be more careful to refer to the right one.

     

  8. No.  Take a normal prim, set it to 100% transparent.  Take another prim, make it 50% transparent.  Put the first in front of part of the second.  You'll see right though the 100%, and see the 50% just fine.

     

    Now, take a mesh, set it to 100% transparent, and move it in front of the 50% transparent prim.  It will completely 'cut away' the 50% transparent prim as if it weren't there.  Those areas not viewed 'through' the 100% transparent mesh will look normal (i.e., a 50% transparent prim) but the part viewed through it will simply vanish.

     

    That's invisiprim behavior......invisiprims were a special texture, applied to regular prims, to 'cut away' the avatar mesh and hide it (since we didn't have alpha layers back then.)  They caused a lot of visual problems when they were used too much, or made larger than needed.

     

    Seeing this behavior on a mesh set to 100% transparent seems both odd and unintended.

     

  9. Wearing a mesh item with 100% transparency (to hide it at times) results in the hidden mesh acting like an invisiprim, causing all non-opaque prims and meshes behind it to effectively dissappear....

     

    Is this a known issue?  Or expected behavior (I hope not!)  I searched through the JIRA's a bit, but couldn't find anything that matched.

     

  10. You need a loop, like the one in the giveContents() function, inside your touch_start() event, inside the if statement.

     

    I don't believe llRemoveInventory() can remove items from an agent's inventory, only from the prim it resides in.  And since the test in your if block only fires if the number of elements is GREATER than (not 'greater than or equal to'), it won't even try when the number of items is one or zero.

     

     Something more like:

    list inventory;giveContents(){     integer num = llGetInventoryNumber(INVENTORY_ALL);    string script = llGetScriptName();    integer i = 0;    inventory = [];    for(; i < num; ++i)    {        string name = llGetInventoryName(INVENTORY_ALL, i);        if(name != script)        {            if(llGetInventoryPermMask(name, MASK_OWNER) & PERM_COPY)            {                inventory += [name];            }        }    }    if(llGetListLength(inventory) > 0)    {        llGiveInventoryList(llDetectedKey(0), "Contents", inventory);    }}    default{    touch_start(integer n)    {        giveContents();        integer i;        integer numInList = llGetListLength(inventory);        if(numInList > 0)        {            for(i=0; i < numInList; ++i)            {                llRemoveInventory((string)inventory);            }            llOwnerSay("CLEARED!");        }        else        {            llOwnerSay("No items to clear!");        }    }}

     

    Initializing your list with [""] actually put an entry into it.  To clear a list, set it to [], as I showed above.  This will allow you to compare lengths easier.

     

  11. Just another little efficiency thing for loops....

     

    prefix notation is faster and uses less resources than postfix.  This is because the value doesn't have to be held for evaluation before operation.  So when using loops, especially, it's better to use ++i than to use i++ (or use --i rather than i-- if your loop is decrementing.)

     

  12. I can't say for certain, but that looks like 'ringing' caused by DCT compression.  By having a single pixel in the height map being so starkly offset from all those around it, it causes whatever 'interpolation' function being used to convert the map (which is 256x256 data points) to however many are being used to render the terrain, to exhibit such artifacts.

     

    Try setting the closest pixels in the height map to a value closer in magnitude to the high pixel.....it may not reduce the aliasing completely, but will probably drop it's magnitude quite a bit.

     

    Also, it is possible to utilize centroids by offset, to encode the heightfield, and avoid the need for 257 datapoints.  By taking into account the averaging, and weighting it, one can easily still have full height (or very similar) without causing all the adjacent points to be affected.  Or, more simply, they could simply interpolate the last set in each axis.  Or the first.  Or resample the 256x256 image to 257x257, which even with cubic interpoloation functions would rarely produce additonal adjacency changes except for large areas.

     

    Without more info from LL, it's hard to say precisely what is going on.  I'm just guessing here, based on what I've seen.

     

  13. Assuming you know how to accomplish everything but the delay, try looking at the list like this:

     

    1)  Code to play a sound

    2)  Code to rotate a prim in one direction

    3)  Code to start a timer with a 4 second duration (timer code has the code to rotate the prim in the opposite direction)

    4)  Code to continue playing remaining sounds in order.

     

    There will be no (significant) delay between executing step 3 and step 4, but when 4 seconds has passed, the code in the timer will be executed.

     

  14. I'm actually surprised no-one else caught that your child script has the link_message() event handler INSIDE your state_entry().  That won't work.

     

    Your child script should be laid out like so:

     

    default{    state_entry()    {    }    link_message(integer sender_number, integer number, string message, key id)    {	if ( number == 1 ){		fliptexture(AVAILABLE);	}	else if ( number == 0){		fliptexture(UNAVAILABLE);	}				    }}

     

  15. Boolean solid geometry is a WONDERFUL idea....but it will NOT work in SL.  Boolean operations on the meshes (even of internal 'prims') are very complex.  Doing that dynamically every frame while building would be horribly complex, not to mention slow the CPU to a crawl.

    Boolean operations on meshes are fairly well-defined, so doing it as a single-click operation is doable.....but NOT really workable in SL.  The very idea of 'prims' is that the meshes are pre-defined.  Even though we can 'torture' them into funky shapes with twists, bends, and tapers, those are simple operations on the internal mesh of the prim, and do not actually change the structure of it.  Booleans will create NEW vertexes, edges, and faces when the operations are executed.....this changes the topology of the mesh, and its structure, creating a new mesh.  This would have to be downloaded from the server, just like existing meshes.

     

    There are plenty of mesh editing programs that support boolean operations....create your 'prims' in there, do the boolean operations, then save it and upload it to SL.

     

  16. You have it almost right, but your syntax on your IF statement in your listen() is wrong.

     

    Try:

     

    if (message == "hi" || message =="hello" || message == "hey" || message == "hola" || message == "oi")

     

    A better method would be to have a list of the words that match a certain condition, then check if it's in the list.

     

    list hellos = [ "hi", "hello", "hey", "hola", "oi" ];state_entry(){    llListen(3,"", NULL_KEY, "");}listen(integer channel, string name, key id, string message){    if(~llListFindList(hellos, (list)message)    {        llSay(0, "Wasup");    }}

     

  17. If he has, as you say, mega L$ to get it with, it is definitely possible to get custom mesh work done.  And since you can export your avi for doing such custom work, it could be fitted to his existing shape as well.

     

    Have him (or you could for him) contact some of the mesh fashion builders and see what they would charge to do it.  It'll be expensive (custom work usually is) but the results would be worth it!

     

     

×
×
  • Create New...