Jump to content

chrixbed

Resident
  • Posts

    54
  • Joined

  • Last visited

Posts posted by chrixbed

  1. Looking for feedback about this project:

    Semence

    This video is a preview made in Second Life about our new show "Semence," an exploration of life's origins, progression, and the cycle of death.  We are using a custom Particle System I built called the Bloom. 

    In French, "semence" refers to the seed from which all sorts of life emerge.

    Note: The show will be performed at SLEA6

    A live Particle Show in sync with the audio stream playing 24/7 now.

    tp: http://maps.secondlife.com/secondlife/SLEA6/91/143/1003

     

  2. I like the idea of having an animation that offsets the Animesh. The only issue I have with that is it seems to be limited to 10 meters by axes as far as I know. Also in my case, I made a giant Animesh and the 10 meters is not visible. Anywhoe as try to use llSetKeyframedMotion() or some Pathfinding LSL functions with success to simulate a rotation ? Or maybe I should just llSetPos() the prim using a circle equation or some sort?

  3. I made an animesh and I would like to make it spin around a cube with an offset from the center. If I apply a llTargetOmega() that will make the Animesh spin but without any distance from the center. Normally if I just link 2 prims together and distance them apart they will spin around the linkset center. Unfortunately, the Animesh only spins on itself, it can't be offset.

    I would like to make the Animesh spin around an offset center, is there a way to do that?

    Detail video: https://gyazo.com/8eb7bf82052c9c10468c245c8abece1c

    6f0bcafb026b0fed5369819c2f0361e2.png

  4. I'm making a particle show and I want to have my guess to pre-load the texture I'm using in their viewer cache. So I made a simple cube that flips all the textures used with my particles so the viewer has it in memory at the time to play the particle and avoid the big white square.

    Question: If I set my alpha to 0, is it still gone a work to load the texture in viewer memory?

    here is my code:

    string TEXTURE;
    integer INDEX;
    integer TOTAL;
    integer toggle;
    float gap = 0.2;
    default
    {
        touch_start(integer total_number)
        {
            toggle = !toggle;
            if(toggle){
    		llSetAlpha(0, ALL_SIDES); // Where I set the Alpha
    		TOTAL = llGetInventoryNumber( INVENTORY_TEXTURE );
               	INDEX = 0;
             	llSetTimerEvent(gap);
            }
            else
                llSetTimerEvent(0.0);
        }
        
        timer()
        {
            TEXTURE = llGetInventoryName(INVENTORY_TEXTURE, INDEX );
            llSetTexture(TEXTURE, ALL_SIDES);
            if (INDEX >= TOTAL-1)
            {    INDEX = 0;
                return;
            }
            INDEX ++;
        }
        
        changed(integer change)
        {
            if (change & CHANGED_INVENTORY)         
            {
                llSetTimerEvent(0.0);
                TOTAL = llGetInventoryNumber( INVENTORY_TEXTURE );
                INDEX = 0;
                llSetTimerEvent(gap);
            }
        }
    }

     

    • Like 1
  5. 3 hours ago, Bleuhazenfurfle said:

    Just as another idea, I once used a triangular prim with the top clipped off (because I couldn't be bothered with doing any fancy textures for it anyhow), which gave me a square "knob" and two tracks (the angled sides — which look flat because HUD), and then moved the "knob" my messing with the skew.

    The shape math, and handling click position on the steeply angled faces, got slightly gnarly…  but not too bad, and neither was the result.  It also doesn't have the issue of sliding off the knob (except for sideways), and you could still just click the track to set a specific position.  All with one prim and no textures, because I've got the graphic artist skills of a turnip.  (You could probably handle a little sideways slip too, with a suitably distorted track texture.)

    I use a few of them for things like the adjustable speed position joggers on a camera save and restore HUD I tossed together because sometimes you have just the right scenic view (honest!) in a club, but then you wanna have a quick look around the room…

    Seem to be interesting but I have a hard time to visualized it; are you suggesting adjusting the size of a triangle prim to make a slider effect when you touch it?

  6. Your comments make me think and I realize that I was stressing the timer to close to the edge. I when for an easy way by simply changing the numbers of update which gives more time and now it's working.

    Ex for a song of 121BPM:

    -Before with 10 scales updates timer = (60/121)/10 = 0.04958

    -Now with only 5 scales updates, timer = (60/121)/5 = 0.09917

    The new one can handle both sim. I will try to round it to 1/45th second to make it more compatible with the timer as suggested.

    • Like 1
  7. 2 hours ago, Wulfie Reanimator said:

    The biggest problem with the actual implementation is that you're seemingly doing fixed steps per timer event, instead of calculating what the scale should be whenever the timer is triggered. This causes the problem of having the effect change pace as the rate of events fluctuates.

    Since you're going for a smooth in-out motion, you could give llGetTime (multiplied by BPM) to llSin or llCos, since sine/cosine are wave-functions. This would allow you to use much fewer updates while preserving that consistent rate.

    That a very good idea, actually I did calculate a list with llCos() for the sizes of the object to create a sense of oscillation but using it to spread the call to the timer is a very interesting way to do that as well. I will try to comeback with a updated code version to see if I can make it works.

  8. 3 hours ago, Qie Niangao said:

    Well, the problem isn't time dilation, its the Scripts Run percentage. Malibu Dream is a (lightly loaded) "Full Region" whereas Black Art Sands is just a Homestead, so there's only a quarter as much time available for processing each simulation frame, which is why it only gets to process about half the scripts on the scheduler queue each timeslice. 

    Regardless, that's a very tight timer for what this script is trying to do. Even if it works running on a lightly loaded sim, it's generating a huge volume of object updates for each viewer in sight of the scripted object. Also, just in passing, the simulators run at 45 frames a second, so timers tend to be most reliable when they're approximately integer multiples of 1/45th second (or 0.0222.. seconds).

    (Actually, I would have expected that llSetScale would be throttled with a 0.2 second delay, as is llSetPos and etc., thus requiring use of llSetLinkPrimitiveParamsFast -- but apparently I would have been wrong, judging by the wiki.)

    I guess my advice would be to settle on a different effect that can be performed purely viewer-side, instead of in the script itself.

    You are right, I notice that the timer are slower on Black Art Sand indeed:

     

    timer.jpg

  9. I'm working on a mesh that a rescale (llScale()) to follow a beat on a timer. I use the script on a SIM where everything seem to work fine but when I change to a other SIM the timer get lost. I try to see if there is a time dilatation between the sims but nothing special. My timer speed is around 0.04958.

    In the following video:  Malibu Dream's SIM follow the beat but not Black Art Sand's SIM ?!

    Here is an ex of my code:

    integer step = 0;
    integer steps = 5;
    lstSteps = [<1,9,9>,<2,9,9>,<3,9,9>,<4,9,9>,<5,9,9>,<5,9,9>,<4,9,9>,<3,9,9>,<2,9,9>,<1,9,9>]; // Scale the object
    default
    {
        state_entry()
        {
    	BPM = 121;
    		// Calculate the frequency to update the info to sync the beat
          	Beat = (60/BPM)/Steps; // value = 0.04958;
            llSetTimerEvent(Beat);
        }
    
        timer()
        {
    	llSetScale (llList2Vector(lstSteps, step));
            if (step == (2*steps)-1) step = -1;
            step++;
        }
    }

    How can I handle that better and know when a SIM perform well or not ?

    Thanks !

  10. 1 hour ago, Ghost Warblood said:

    Nope, such a feature has not been released nor do I see linden labs releasing something like this, only way for particles to change, is by uploading the other frames of the gif as separate textures then inputting multiple uuid's and have the script alternate between them (which could cause lag). Also, this topic doesn't belong in "LSL library"

    That sad, it will has been a nice feature but I appreciate you take the time to answer.

    Note: I'm sorry that I post a unrelated content, I should have post that in LSL Scripting. 

    Thank you Ghost Warblood!

    • Like 1
  11. I found that old footage about a proposal to add animated texture (gif?) feature for particles. A Jira was proposed about it and it's seem to has been release but I'm not sure... Is there anyone knows more about that feature and if there is an actual possible way to use or create the effect of animated texture or gif in a llParticleSystem() ?

    Note: I know llSetTextureAnim() but I don't think is possible to mix those, right ?

    • Like 1
  12. 41 minutes ago, Fenix Eldritch said:

    The trick in this scenario is to grant PERMISSION_ATTACH to the attachment object before you place it into the rezzer's inventory. That way, each new instance will be a copy of the object who already has the permission given. The state_entry event won't trigger when the object is rezzed from the rezzer, only the on_rez event.

    A simple proof of concept for the attachment script:

    Thanks Fenix, that exactly what I was trying to do and work perfectly !

  13. Hi, 

    How to workaround that:

    image.png.9b283979fa9334e600522d263d3be738.png

     

    Context:

    I'm building a rezzer for my avatar which attach and detach multiple objects from llRegionSay() calls. I get the authorisation windows every times and I try to find a workaround to automatically authorise my avatar to accept the Request for PERMISSION_ATTACH. Any ugly hardcoding in FireStorm or other way are welcome !

    Note: I know "Experiences" are the way to go to have this done automatically but I want a temporary workaround to test my stuff first.

    Here is the code in my Rezzer:

    integer listen_handle;
    default
    {
        state_entry()
        {
            listen_handle = llListen(-12, "", NULL_KEY, "");
        }
     
        listen( integer channel, string name, key id, string message )
        {
    	// Example of call llRegionSay(-12, "ObjectName");
        	if(llGetInventoryType(message)==INVENTORY_OBJECT)
            	llRezObject(strObject, llGetPos() + <0.0,0.0,1.0>, <0.0,0.0,0.0>, <0.0,0.0,0.0,1.0>, 0);
        }
    }

    Here is the code in my objects:

    integer listen_handle;
    integer DETACH_Flag = FALSE;
    default
    {
        state_entry()
        {
            listen_handle = llListen(-11, "", NULL_KEY, "");
        }
     
        run_time_permissions( integer vBitPermissions )
        {
            if ( vBitPermissions & PERMISSION_ATTACH ){
                if (DETACH_Flag){
                    llDetachFromAvatar( );
                    llListenRemove(listen_handle);
                    llDie();
                }
                else  llAttachToAvatarTemp( ATTACH_LHAND );     
            }
            else     
                llOwnerSay( "Permission to attach denied" );
        }
     
        on_rez(integer rez)
        {
            llRequestPermissions( llGetOwner(), PERMISSION_ATTACH );
        }
        
        listen( integer channel, string name, key id, string message )
        {
    	// Call to detach ex: llRegionSay(-11, "Detach");
        	if (message == "Detach") {
    	      	DETACH_Flag = TRUE ;
          		llRequestPermissions(llGetOwner(), PERMISSION_ATTACH );
            }
        }
    }

    Thanks !

  14. I'm working on a set of prim that each of them have a llParticleSystem() and I try to evaluate the limit of it.

    I know that there is a limit of 8192 particle count for the viewer to a max distance of 50m.

    My guess was to use the Particle Flow parameters to calculate the limit of particle to not overflow the viewer. For example if I have 10 particles emitter, I will do a setup like that:

    PSYS_PART_MAX_AGE = 15, // 15 sec 
    PSYS_SRC_BURST_RATE = 1, // every sec
    PSYS_SRC_BURST_PART_COUNT = 10 / create 10 particle every burst
    

    So each emitter will generate a max of 15X10 = 150 particles. Since I have 10 emitter that will use1500 out of the max 8192.

    Is my maths right ?

    Is there another way to calculated that or a tools that inform us about the number of emitted particles ?

    Thanks !

     

  15. As a geek moment, I did a test using a Gömböc mesh shape. A Gömböc is a fascinating mathematical object that is a convex three-dimensional homogeneous body that when resting on a flat surface has just one stable and one unstable point of equilibrium. 

    I did this object out of curiosity to see how Second Life Game Engine can handle that type of physique. 

    You can try it too if you want: https://marketplace.secondlife.com/p/Gomboc/20643635

    Important: This is not my creation, you can find the original 3D STL file source at this link:
    https://www.thingiverse.com/thing:523643

    • Like 3
×
×
  • Create New...