How Do You Make a Leaf Waft?

[Prokofy Neva]

Just so you know -- yes, I already hired a scripter. I always hire scripters. Multiple scripters. But not all of them know how to do a specific thing.

Yes, I went to Jopsy's Particle Laboratory and that was helpful in reaffirming what I had gathered from what one scripter and from testing -- the higher the "burst" number, the slower it actually goes. But there is so much information about the history of the watch there that you can't find what time it is. 

Yes, I bought full prim scripts and examined them to see how they might work but couldn't figure it out.

Yes, I read the SL wiki but couldn't find specifically what I need.

Maybe it's too complex.

So all I want to do is make a leaf waft.

Yes, I know about "drop" -- I have that.

Yes, I know about the burst rate as I mentioned. But what one particle expert told me is that particles don't always change just because you change one number on one parameter -- sometimes multiple changes have to be made in sync, which is why I'm asking this question.

PS I've also bought multiple emitter and particle scripts, most with no off switch. Honestly, there should be an AR category for not putting off switches on particles. It's like some scripters or copiers of the classic Omega particle script want to stay in the eternal trance rave of 2008. But the rest of us want to be able to turn them off. And the "off" switch isn't something you can just copy and paste from one to put on another, they differ.

I just want to make the leaf emerge SLOWLY, fall, and waft on the wind and be able to TURN IT OFF. That shouldn't be too hard, no?

BTW I'm puzzled why certain dandelion emitters I've purchased have the image emerging so far away from the small prim -- obviously flowers can't be that way. If the particle emerges from the center of the prim, what's up? Maybe they didn't test it on an actual flower, but only the big box they made as a sample? But the images emerge quite far from the box, too.,

Yes, I realize that because of some *thing* about SL, the particles don't come from where they should, and you have to make an invisible prim to link to another prim, like the Moles' incense. But what if that still doesn't work?

 

 

[Qie Niangao]

Lots of questions. Let's start with "waft." Some trees emit actual textured temporary prims that slowly fall to the ground in patterns determined by the physics that's applied to them as they're rezzed by script. That can be very laggy so I don't recommend it, but it's something you may have seen that can't be perfectly imitated by particles.

Focusing on "waft on the wind", particles have a PSYS_PART_FLAGS bit identified as the PSYS_PART_WIND_MASK that determines whether they float on the "wind" that moves through the sim. The good part of using that "Linden wind" is that everything that's wind-dependent can move together. The bad part is that it can be more (or less) "gusty" than ideal for the mood you want to set, and there's no practical way to reduce or augment it. One alternative is to make your own "wind" effect in how you set PSYS_SRC_ACCEL.

It may be a challenge "to make the leaf emerge SLOWLY", depending what you mean by that. It might be enough to apply the right value to the aforementioned PSYS_SRC_ACCEL to make it move slowly and gradually accelerate, but to make them form slowly (to avoid them flashing into view) you'd use a near-zero PSYS_PART_START_ALPHA.

That _START_ALPHA "form slowly" thing may be what you're seeing with "certain dandelion emitters [that] have the image emerging so far away from the small prim" -- if they gradually emerge from nothing as they move away from the emitter; if instead they pop into full view some distance from the emitter, that's PSYS_SRC_BURST_RADIUS.

It's easy for a script to stop emitting particles -- they only need to call the particle system with an empty parameter list ([]), but it's impossible to stop already-emitted particles from running their course to completion.

As to "particles don't come from where they should", scripts are constrained in the axis on which particles are emitted, which is one reason why it's sometimes necessary to link-in a dedicated emitter prim. They are, however, always emitted in a pattern around the center of the emitter prim. Even with custom mesh there may be other, overriding reasons for the center of the visual object to be somewhere other than the center of the particle pattern, or for the item's axes to be oriented differently than is needed for the desired particle pattern.

[Prokofy Neva]

I didn't realize the trees were actually putting out temp-rez prims, I thought they were all particles. So no, I don't want to do it that way as it can be laggy as you say.

I'm going to try tweaking PSYS_SRC_ACCEL I hadn't noticed that.

I thought it was all about the "burst" number.

The number for "nothing" is "0", right? And then if burst radius is *higher* they should move *closer*?

I don't care about stopping already emitted particles, I care about stopping new ones. And so few creators seem to build that in. So I had a scripter add it in. 

Thanks, I will try to work with this.

[Rolig Loon]

4 hours ago, Prokofy Neva said:

And then if burst radius is *higher* they should move *closer*?

No, just the opposite.  The burst radius is defining the distance between the emitter and the point when particles appear to be created.  If I define Burst Radius to be 1.0, I am telling the script to make particles appear 1.0m from the emitter. That can be very useful if I want to make, say, a shower of sparks appear from the end of a steel rod instead of somewhere farther back along  its length.  Or if I want dandelion seeds disperse in a spherical pattern around the flower rather than popping out of its center.

And yes, turning particles on and off is no more difficult than turning a light on and off.  Basically,

touch_start (integer num)
{
    iSwitch = !iSwitch ;   // Makes the value of the global integer variable iSwitch change from TRUE to FALSE or vice-versa
    if ( iSwitch == TRUE)
    {
        // Create particles by calling your llParticleSystem function here
    }
    else
    {
        llParticleSystem([ ]);    // Turn all particles off
    }
}

As long as you have created a global integer variable like iSwitch to act as a toggle switch, you can turn anything on/off.

[Kyrah Abattoir]

PSYS_SRC_ACCEL will be... interesting. If you don't mind leaves that go faster and faster.

[Rolig Loon]

Hmmm... I changed my mind. 

Edited May 12, 2019 by Rolig Loon

[Madelaine McMasters]

Give up on particles. Real leaves tumble and oscillate during their fall due to aerodynamic instabilities. Particles can be programmed to have trajectories based on initial velocity, acceleration, gravity and wind, but those affect only trajectory, not orientation. The only available particle orientation control is PSYS_SRC_OMEGA and that imparts only simple spin, which won't look at all natural, and will always have the leaf texture pointing straight at the viewer.

A lifelike falling leaf simulation will require you to temp-rez leaf objects that contain scripts to effect both realistic trajectory and orientation.

[Coffee Pancake]

No .. stop ... 

Go look at those rotating butterfly rings.

 

Make a curve in blender that fits the path you want to leaf to fall.

Make a shallow V shape and extrude that along the track.

Make a texture that's 1024 x 32 .. place a 32 pixel square leaf at one end, the rest should be an alpha mask.

Upload your texture & mesh, use texture animation to slide your texture along your path. The leaf will appear to follow your path.

You may have to tinker with the script or uv mapping to get it right, trial and error here.

 

 

 

 

[Prokofy Neva]

On 5/12/2019 at 12:01 PM, Rolig Loon said:

No, just the opposite.  The burst radius is defining the distance between the emitter and the point when particles appear to be created.  If I define Burst Radius to be 1.0, I am telling the script to make particles appear 1.0m from the emitter. That can be very useful if I want to make, say, a shower of sparks appear from the end of a steel rod instead of somewhere farther back along  its length.  Or if I want dandelion seeds disperse in a spherical pattern around the flower rather than popping out of its center.

And yes, turning particles on and off is no more difficult than turning a light on and off.  Basically,

touch_start (integer num)
{
    iSwitch = !iSwitch ;   // Makes the value of the global integer variable iSwitch change from TRUE to FALSE or vice-versa
    if ( iSwitch == TRUE)
    {
        // Create particles by calling your llParticleSystem function here
    }
    else
    {
        llParticleSystem([ ]);    // Turn all particles off
    }
}

As long as you have created a global integer variable like iSwitch to act as a toggle switch, you can turn anything on/off.

I realize I am about 15 years late to the party here, but I found out that at Jopsy's Particle Station, an old famous SL build, there are a lot of useful tutorials.

You can pick up a template switch that will turn off any particle, or at least *his* particles and Omega's. Yes, it would be better to build the shut- off order into the script itself. One thing that has baffled me is why copying and pasting what seem to be the obvious on/off switch code lines (that I commissioned a scripter to do) don't work on every script. In fact, the lines are different than yours, I don't know why, I just live here. In fact, changing burst radius to higher *does* slow things down on *some* things, but maybe it depends on the texture or other parameters?

Another thing I was trying to do was make a dripping spigot. One sold on the MP just shot out too fast, and while the creator was apparently willing to adjust it, it still didn't look great. I noticed a really good-looking dripping faucet I have in the form of a maple syrup bucked (my goal is to make a pine tar bucket) had Jopsy's drip particle and Andrew Linden's water drop texture. Sadly, I can't find Andrew Linden's texture anywhere -- and the Lindens have now for some reason put all their content in the Library on no-transfer (I suppose their glory days of open source mania are over now that they rely on top content creators for the library who understandably don't want to release their creations into the wild, but it seems crazy to put on no-transfer the water falls and such that were on all perms 10 years ago). So I had to buy such a water drop that I have to say looks an awful lot like Andrew Linden's drop. Oh, well.

I have to say, that with the combination of what Qie explained here, and Rolig, I was able to get a drip going which I made into this dragon medicine drip. You really feel like Helen Keller after Annie has signed words to you when the SL darkness is dispelled at these moments.

Yes, I realize the temp-rez mesh object has more capacity as a "wafting leaf," and from examining their contents, I see now the best tree makers have things, not particles.  And it only temporarily uses the sim's prim buffer. But in fact using these things does involve having the server take a beating.

 

RE:

No .. stop ... 

Go look at those rotating butterfly rings.

Make a curve in blender that fits the path you want to leaf to fall.

Make a shallow V shape and extrude that along the track.

Make a texture that's 1024 x 32 .. place a 32 pixel square leaf at one end, the rest should be an alpha mask.

Upload your texture & mesh, use texture animation to slide your texture along your path. The leaf will appear to follow your path.

You may have to tinker with the script or uv mapping to get it right, trial and error here.

So there are a number of problems with this advice. First, there's an assumption that I "know Blender". I know Paint. I'm not likely to get beyond Paint. My daughter and her boyfriend may teach me Blender some weekend but it's unlikely it will "stick".

 I keep making new discoveries in Paint after years of use. For example, that if you can't get "magic wand" to get rid of a background for you, if you shift the number on  "Tolerance" (who knows why it is called that), it will make it possible. I found this on a help forums after searching (still in vain) for advice for how to get the white line off a transparency if you've already used Magic Wand, already erased in "zoom in" etc. A mystery.

Second, I'm quite capable of just buying a nice photo or artwork that does these things on istock, especially from starving Russian artists, and did, to make a sort of feathery V-shaped spray -- by accident. I still don't understand why these things called "Vectors" have checkerboard squares on them and how/if you should get that out.

I don't know what alpha mask is. I do notice that if you try to switch things to that, it turns them from clear to white, despite its being named "alpha" which is usually the thing that makes your body disappear so it doesn't stick out of your clothes. So I don't use it.

I don't know how you "upload mesh" because I don't know how to "make mesh". I suspect this is going to be beyond me. But  it is on my to-do list for the next 15 years. After all, I have now managed to make a potion bottle with a cork that pops and goes back and has sparkles and liquid that goes up and down, using templates and trial and error, and I'm happy, even if no one will ever buy it.

Texture animation, which slides photos along prims giving you the illusion the prim is moving, is actually something I have gotten to work in making my Narnia quest, but again, only by trial and error.

Another thing I don't understand is why, when you buy a sculpty or even mesh template, these different maps are sometimes in black and white, sometimes all clear, and sometimes already "look like" the thing you want to make. Naturally I opt for that third version and try to cut and paste something into it that will "work". It doesn't, always. It's always a mystery to me why sculpties just don't texture very well unless you go through these gyrations outside of SL in at least Paint if not something better. SL would be a lot better place if you could texture sculpties the way you can prims.

So you see the problem -- levels and skills. Yes, you can read tutorials. I can't learn from watching YouTubes, they go by too fast. My son even makes them for me -- too fast. When I get absolutely desperate, I will even watch a Torley video, which is what sent me to Jopsy's about which I had forgotten. 

Edited May 14, 2019 by Prokofy Neva

[Qie Niangao]

There are sort of three classes of "falling leaf" solutions kicking around here. Let's call them:

1. Particle
2. TextureAnim on static mesh
3. Dynamically-rezzed Object

Just for concreteness, here's a simple example of the Particle approach:

// Public Domain by Qie Niangao, 2019

integer fallingp = TRUE;

emitLeaves (integer onp)
{
    if (fallingp)
        llLinkParticleSystem(LINK_THIS,
            [ PSYS_SRC_TEXTURE, "318274ec-ad58-f9f9-582f-a09fcd62718c"  // Gimped by Qie from Public Domain on Wikimedia Commons
            , PSYS_PART_FLAGS
              , PSYS_PART_WIND_MASK     // usually undetectable though
              | PSYS_PART_INTERP_COLOR_MASK
              | PSYS_PART_INTERP_SCALE_MASK
              | PSYS_PART_EMISSIVE_MASK     // I wouldn't, but most would
            , PSYS_SRC_BURST_RADIUS, 1.0          // no effect w/ DROP
            , PSYS_PART_START_SCALE, <0.05, 0.2, 0.0>
            , PSYS_PART_END_SCALE, <0.2, 0.0, 0.0>
            , PSYS_PART_START_COLOR, <0.2, 0.1, 0.1>    // shaded inside tree
            , PSYS_PART_END_COLOR, <1.0, 1.0, 1.0>
            , PSYS_PART_START_ALPHA, 0.5
            , PSYS_PART_END_ALPHA, 1.0
            , PSYS_PART_START_GLOW, 0.01
            , PSYS_PART_END_GLOW, 0.01
            , PSYS_SRC_PATTERN, PSYS_SRC_PATTERN_ANGLE_CONE
            , PSYS_SRC_ANGLE_BEGIN, PI_BY_TWO
            , PSYS_SRC_ANGLE_END, PI
            , PSYS_PART_MAX_AGE, 3.0
            , PSYS_SRC_BURST_RATE, 1.5
            , PSYS_SRC_BURST_PART_COUNT, 1
            , PSYS_SRC_ACCEL, <0, 0, -0.75>
            ]);
    else
        llLinkParticleSystem(LINK_THIS, []);
}

default
{
    state_entry() 
    { 
        emitLeaves(fallingp);
    }
    touch_start(integer num_detected)
    {
        emitLeaves(fallingp = !fallingp);
    }
}

The rationale for dynamic START/END parameters and the CONE emission pattern is to give some variability in how the individual leaves appear as they move through space, even though they're all emitted by the same, unchanging particle system and they're all "sprites" unaffected by camera position. Especially the changing SCALE aspect ratios give some illusion of twirling as the leaves fall, particularly at much shorter BURST_RATEs when there are lots of them on the screen at the same time with different changing shapes.

It's a pretty lame "twirl" though, nothing like the "fluttering" effect achievable with the TextureAnim-on-mesh approach. Both approaches are predominantly viewer-side effects, triggered by a server-side script that doesn't need to do anything more once it's run. (In fact, if the effects never need to be switched off, the scripts can be removed completely, minimizing server load.) TextureAnim-on-mesh does however involve some extra server-side geometry (the mesh on which the texture is animated) with a (minimal) additional Land Impact.

That dynamic leaf shape "fluttering" effect is cool but the mesh is static, soon evident in the constant leaf path, as with the butterflies, etc, that use this same effect. In contrast, the particles have varied -- but much simpler -- paths.

In passing, it's hardly worth firing up Blender to make a mesh for this; it's not as if you'd be inventing a new product category, which is the only way I can be bothered to model anything these days. Instead you can just buy an assortment of sculptmaps for L$300 or equivalent meshes for L$450 (or very possibly less or better from some other source; these just surfaced easily in search). Or you may already have a modifiable copy but the one gathering dust in my inventory was no-mod -- hence gathering dust.

That third, Dynamically rezzed object approach is, in contrast, a server-side effect. Each leaf is formed on the server and the corresponding object info sent to every viewer of the scene -- along with a steady stream of object update messages as the leaf falls and is eventually deleted. Added to this is the cost of loading and running a script in each leaf that moves it around and/or instantiating a physical object for Havok to move in the sim. Either way, it's extra work for the sim, but the physical object approach has the added risk of lagging the whole sim, whereas non-physical scripted motion will only lag other scripts. On the other hand, (non-phantom) physical objects can realistically bump into other objects, so the leaves may pile up on the ground and collect along walls and fences (rather than passing through buildings).

 

Edited May 14, 2019 by Qie Niangao
use Marketplace links, cuz secondlife:// viewer URIs for the in-world objects only work in chat

[Coffee Pancake]

7 hours ago, Prokofy Neva said:

So there are a number of problems with this advice. First, there's an assumption that I "know Blender". I know Paint. I'm not likely to get beyond Paint. My daughter and her boyfriend may teach me Blender some weekend but it's unlikely it will "stick".

Blender is not that hard for the simple kind of modelling this would require, you're seriously one download and three youtube tutorials away from success.

The new 2.8 is MUCH better than previous versions, they have reworked a lot of the UI with the focus on accessibility and ease of workflow.

Versions prior to 2.8 were still half clinging to the legacy UI and workflow,  the early days had a rather unhelpful business model,  literally "this awesome software is free!" (but super confusing) "you can buy the manual in the store!"

7 hours ago, Prokofy Neva said:

So you see the problem -- levels and skills. Yes, you can read tutorials. I can't learn from watching YouTubes, they go by too fast.

You can pause with SPACE. Move forward and back a frame with  ,   and   .

Do a bit, pause, do a bit, pause, do a bit, rewind a bit, pause. 

If you're determined to stick with one application for everything for ever then you can't do a lot worse than picking blender.

1 hour ago, Qie Niangao said:

In passing, it's hardly worth firing up Blender to make a mesh for this; it's not as if you'd be inventing a new product category, which is the only way I can be bothered to model anything these days.

It's especially worth a bit of blender for simple stuff that already exists. People have to learn somehow, and making your own version of something someone else did before you is kinda how education works.

The entire history of art can be summed up as "that looks cool, let me have a go, hey look, I did it a bit different'", followed by "for some unknown people liked this, I'm hungry, maybe I should make more". 

It's about the journey as much as the end result.

[Qie Niangao]

10 hours ago, Prokofy Neva said:

Sadly, I can't find Andrew Linden's texture anywhere -- and the Lindens have now for some reason put all their content in the Library on no-transfer (I suppose their glory days of open source mania are over now that they rely on top content creators for the library who understandably don't want to release their creations into the wild, but it seems crazy to put on no-transfer the water falls and such that were on all perms 10 years ago). So I had to buy such a water drop that I have to say looks an awful lot like Andrew Linden's drop. Oh, well.

When I first encountered it I was confused, but the Library textures are still full perm, they just require an extra (silly) step: You must first Copy and then Paste them into "My Inventory" and then you can do whatever you want with them. I have no idea why this step is necessary; you can make multiple copies and they all end up with the same UUID, so it's a mystery to me what purpose is served by having personal Inventory pointers to those assets.

[Prokofy Neva]

I'm glad you explained them to me so I can use "waterfall" again. But Andrew Linden's droplet actually isn't in there.