Particle Demo

[Bill]

particleDemoPreview.png (95.31 KiB) Viewed 7321 times

ParticleDemo_v3b.zip

(14.79 KiB) Downloaded 218 times

Hrmm Didn't know where else to stick this, but I guess it's 'animation'?
Found a very cool particle demo on another forum, converted the code to Livecode pretty easy, converting the floats to meaningful integers and matching the cool effects was a rough ride though.
So basically it's some particles and they attach lines to nearest neighbor or are supposed to.
Original demo was very 'webby' I can't seem to get the same effect exactly.

Ah well, here it is.

hit any key to start/stop it.

UPDATED: Still not "Webby" but definately more "Spidery"
Happy Halloween.

[bn]

Thank Bill,

very fascinating

Kind regards
Bernd

[stam]

Thanks Bill - quite mesmerising
Happy Halloween


I found this fascinating so tinkered a bit - making the stack dimensions large has significant impact on frame rate...
I found the animation most fluid on my system (macOS 11.6, MBP 2015 15' Touch Bar) if reducing the size of the stack to 400 x 300 and reducing the particle count to 10 - very fluid (visually the frame rate is > 40 FPS).
At this stack size increasing the particle count to 30 gives slightly choppy animation (visually ~10-15 FPS) and if increasing the stack dimensions to say 800x600 or more the frame rate drops to 1-2 FPS or less. I tried changing the outerGlow filter to box1pass but that perhaps surprisingly was almost worse than setting it to gaussian - i presume there is some hardware acceleration at play here.

Do you have any suggestions for improving animation speed? or is this a hard limit by the LC engine?

[bn]

Here is a stack I made for someone in the forum (SJAT) who wanted particles like sand in a random movement.
I could not resist to add features...
The animation is one graphic "gSand" then you can choose different "particles" and set some things like "antialiased, drop shadow, outerGlow and markers filled" and see the slowdown for each. You can change the markers (that is what is visible) on the fly. Most things can be changed while the animation is running. Clicking in the graphic and holding the mouse down either attracts the "particles" or moves them away from the mouse. Releasing the mouse releases the particles.

I sum I think that the graphic effects and the number of graphics slow the "ParticleDemo" down. It is a lot to render for LC. One could try to reduce the number of graphics by drawing e.g. lines with a certain "glow" in 1 graphic (separating the point list with an empty line for the differnt lines. That would be about 4 plus the points. Just an estimate, did not try to do it on Bill's stack.

Here is the stack I mentioned above where you can modify quite some parameters and see the load on animation. (slow-down)

Kind regards
Bernd

[stam]

Here is the stack I mentioned above where you can modify quite some parameters and see the load on animation. (slow-down)

Thanks Bernd, that is a really interesting stack - and kind of mesmerising to see the particles chasing the mouse clicks

As expected, antialiasing, drop shadow and inner glow visually have the biggest impact (actually still fairly impressive speed with those switched off given the number of particles - up to about 20 FPS with 500 points (i had to start/stop the animation a couple times to get the frame rate accurately reflecting what i was seeing with each change). I didn't see any differences with the [filter] setting when tinkering with Bill's stack, i presume the same holds true here but didn't test.

What i found more telling was that with all graphic quality settings turned off and using 500 points, the frame rate was 19-20 FPS; but reducing the number of points down to 50 produced a maximum frame rate of 21 Hz (range 17-21 Hz), and even just using 1 point produced a max frame rate of 24 Hz (range 19 - 24 FPS). In other words whether rendering 1 or 500 points didn't really yield a substantial change in frame rate.

Am i right in thinking that's a hard limit in LC animations?
Some years ago i compiled an app with XOJO working with tri-meshes with about 800 points per frame using openGL and was able to animate at about 60 FPS - I'm guessing that won't really be feasible at present with LC? - Not that i've found a satisfactory way to work with tri-meshes in LC yet... as far as i know openGL or similar can't be used with LC and with that speed optimisations (like not rendering the vertices that aren't visible etc) and shaders aren't available either

[bn]

Hi Stam,

In other words whether rendering 1 or 500 points didn't really yield a substantial change in frame rate.

I use a send in time handler that tries to fire every 40 milliseonds which translates to 25 frames per seconds.
I figured more than 25 frames per seconds is just a waste because that is the frame rate you get on TV (PAL).
The frame rate is indicated in the field at the top when you stop the animation.

So here the interesting part is the drop in frame rate. Below 18 or so is noticeable depending on the marker in use. (I like the 16th note and the ship and and...)

Try to use a small marker and increase the particle count to to 1500.

I also forgot to mention that there is a very crude collision testing and change in direction and speed of the colliding particles.

But certainly you are right that LC is not the fastest architecture to animate complex graphics. This was a test to push the limit a bit.

Kind regards
Bernd

[xAction]

Neat demo, I like the flocking. Changing the send in 40 milliseconds to 2 milliseconds gets 80FPS.

[bn]

I forgot to mention that setting the lineSize of graphic "gSand" to greater than 0 gives a nice effect. I would start with a few particles (10-12) and set the marker to 16th note.

Play that with your violine...

Kind regards
Bernd

[stam]

Neat demo, I like the flocking. Changing the send in 40 milliseconds to 2 milliseconds gets 80FPS.

Thanks @xAction - been meaning to rest that but have been travelling across 3 countries and immediately back at work today, so hadn’t had a chance.

That’s actually pretty cool…

Now if there was a way to use OpenGL or similar….

[RogGuay]

Bill and Bernd, I haven’t had time yet to study these inspiring stacks of yours, but I certainly will take a closer look. Some time ago I experimented with simulating the Flocking phenomenon with a stack I called FlockOBoids. I found that about 50 was pretty much an upper limit to the number of Boids that LC could handle. I’m hoping that the technique(s) used in your stacks, particularly SandStackSjatplat, will be applicable.

I love your work. It is truly inspiring!

Roger

[bn]

Thanks Roger,

Here is a stack that animates along a given path, in this case a lemniscate which looks like the eternity symbol or a ∞.
This is based on an idea by Hermann Hoch [-HH], the animation was done by me.

Kind regards
Bernd

[stam]

That is really pretty cool, thank you Bernd!
Will have to find some time to digest the code!

[RogGuay]

This is absolutely gorgeous in so many ways!

Roger

[RogGuay]

Bernd, may I ask, how did you generate the polygon "lemniskate"? I have a stack that plots equations into polygons but the equation for Lemniscates involves the SqRt of negative numbers which LC cannot handle, and I haven't figured out a work-around.

Thanks,
Roger

[bn]

Roger, that was Hermann who provided that graphic, I would not know how to do that.
I only did the animation. But when I looked up "lemniscate" (Wikipedia) then there were different formulas which I of course did not understand. Some seemed to be manageable, but who knows; not me.

Kind regards
Bernd