Liquidfun JavaScript - LFJS - [behavior]

Post reply
5 favourites

  • Hello;

    Does anyone have any suggestions about an effect I can use to make the collection of particles blend to a liquid look? I think I have seen effects that give a blob of particles more of an edge and smooth out the small gaps in the liquid.

    thanks

    yours

    winkr7

  • Mosenrat

    Thanks for the fix!

    Love it!! Thank you for your thank you!

  • winkr7 - I am glad the bugs are fixed.

    I think that the effect you are looking for is Alpha Clamp. It is most efficient to apply it to a layer instead of to each object/particle.

  • The Scirra version is a bit weird.

    drive.google.com/open

  • Hello Collodium;

    I was using your elastic particle demo (see below for exact code) and I thought I would see what happens when the elastic particle group loses elasticity and melts and then regains it. This works fine for one group (just "tag" or "tag2") and its fun to watch it jump back together.

    However when I do both at once it freezes and sends this message (see below) to the console.

    thanks for your time.

    yours

    winkr7

    + System: On start of layout

    -> ctrl: LFJS World: fixed step rate

    -> ctrl: LFJS Set World Step 30 steps/sec FPS

    -> ctrl: LFJS Set particle as the particle object

    // The Elastic or Spring flags needs to be set before spawn otherwise they cannot be set later.

    When the particles are created they are bound to their neighbors.

    // This is all the Liquidfun documentation says about Elastic particles:

    Elastic particles deform and may also bounce when they collide with rigid bodies.

    From the cpp code, Elastic particles are connected in triads, or 3s.

    -> ctrl: LFJS Turn Spring behavior OFF for spawning

    -> ctrl: LFJS Turn Elastic behavior ON for spawning

    -> ctrl: LFJS Particle group "tag" Rigid: ON

    -> ctrl: LFJS Particle system elastic strength: 100

    -> ctrl: LFJS Particle system spring strength: 100

    -> ctrl: LFJS Set spawn color to rgba(250,140,30,255)

    -> ctrl: LFJS Create particle "tag", shape box at 160, 300, width 200, height 200, angle 0

    // This is what the documentation says about Spring particles:

    Spring particles produce the effect of being attached to one another, as by a

    spring. Particles are "connected" in pairs. Each particle is connected to the

    one that was closest to it at time of creation. Once paired, particles do not

    change "partners." The farther an external force pulls them from one another,

    the greater the power with which they collide when that external force is

    removed. No matter how far particles get from one another, the connection

    between them does not "snap."

    -> ctrl: LFJS Turn Spring behavior ON for spawning

    -> ctrl: LFJS Turn Elastic behavior OFF for spawning

    -> ctrl: LFJS Set spawn color to rgba(100,220,60,255)

    -> ctrl: LFJS Create particle "tag2", shape box at 440, 300, width 200, height 200, angle 0

    ----+ (no conditions)

    -----> System: Wait 4 seconds

    --------+ (no conditions)

    ---------> ctrl: LFJS Group "tag" all particles set Elastic behavior OFF

    ---------> ctrl: LFJS Group "tag2" all particles set Spring behavior OFF

    ---------> System: Wait 4 seconds

    ---------> ctrl: LFJS Group "tag" all particles set Elastic behavior ON

    ---------> ctrl: LFJS Group "tag2" all particles set Spring behavior ON

    // here is the freeze this is the console text :

    dd5c0979-a104-4195-9e94-a6b37ce18f4c:1 Uncaught (in promise) RuntimeError: float unrepresentable in integer range

    at wasm-function[475]:0x239ac

    at wasm-function[514]:0x2b3cd

    at wasm-function[559]:0x36193

    at wasm-function[445]:0x20694

    at wasm-function[94]:0x54b3

    at _0x5bebeb.<computed> (blob:https://preview.construct.net/dd5c0979-a104-4195-9e94-a6b37ce18f4c:1:75982)

    at _0x49a3a9.<computed>.Step (blob:https://preview.construct.net/dd5c0979-a104-4195-9e94-a6b37ce18f4c:1:131885)

    at LFJSInstance.Tick (blob:https://preview.construct.net/7381ba8a-306d-4a33-abc7-1ceb43f5b5d1:2360:26)

    at C3.Runtime._BehaviorTick (https://editor.construct.net/r171-3/preview/c3/runtime.js:1:25340)

    at C3.Runtime.Step (https://editor.construct.net/r171-3/preview/c3/runtime.js:1:26912)

  • Thanks for that bug report winkr7

    Update to v1.0.0.7

    Bugfix - indexing error in c++ library sometimes called particles out of buffer range.

  • Colludium

    Thanks for the quick fix. You might want to consider the elastic reconstitution as part of the demo--it is really impressive to watch shapes rising up out of the sea.

    yours

    winkr7

  • Colludium;

    Hello, I found another problem.

    I am still using the elastic example. If I adjust the particle system damping parameter it runs fine with a value of 6 and bellow with interesting effects at 6. If I set it to 7 or above I get this error on the console:

    Uncaught (in promise) RuntimeError: float unrepresentable in integer range

    at wasm-function[513]:0x2aa3e

    at wasm-function[559]:0x3605e

    at wasm-function[445]:0x20694

    at wasm-function[94]:0x54b3

    at _0x3c5115.<computed> (blob:https://preview.construct.net/062ea27e-a403-4169-a558-2188caa1a6ee:1:76825)

    at _0x3442af.<computed>.<computed> [as Step] (blob:https://preview.construct.net/062ea27e-a403-4169-a558-2188caa1a6ee:1:132909)

    at LFJSInstance.Tick (blob:https://preview.construct.net/af3aadf6-b18d-4ea5-913e-69960c163866:2360:26)

    at C3.Runtime._BehaviorTick (https://editor.construct.net/r171-3/preview/c3/runtime.js:1:25340)

    at C3.Runtime.Step (https://editor.construct.net/r171-3/preview/c3/runtime.js:1:26912)

    at async C3.Runtime.Tick (https://editor.construct.net/r171-3/preview/c3/runtime.js:1:25977)

    ==================================================================================================

    Here is the exact code I am running--I am only changing line 4.

    + System: On start of layout

    -> ctrl: LFJS World: fixed step rate

    -> ctrl: LFJS Set World Step 30 steps/sec FPS

    -> ctrl: LFJS Particle system damping: 7

    -> ctrl: LFJS Set particle as the particle object

    // The Elastic or Spring flags needs to be set before spawn otherwise they cannot be set later.

    When the particles are created they are bound to their neighbors.

    // This is all the Liquidfun documentation says about Elastic particles:

    Elastic particles deform and may also bounce when they collide with rigid bodies.

    From the cpp code, Elastic particles are connected in triads, or 3s.

    -> ctrl: LFJS Turn Elastic behavior ON for spawning

    -> ctrl: LFJS Set spawn color to rgba(250,140,30,255)

    -> ctrl: LFJS Create particle "tag", shape box at 160, 300, width 200, height 200, angle 0

    // This is what the documentation says about Spring particles:

    Spring particles produce the effect of being attached to one another, as by a

    spring. Particles are "connected" in pairs. Each particle is connected to the

    one that was closest to it at time of creation. Once paired, particles do not

    change "partners." The farther an external force pulls them from one another,

    the greater the power with which they collide when that external force is

    removed. No matter how far particles get from one another, the connection

    between them does not "snap."

    -> ctrl: LFJS Turn Spring behavior ON for spawning

    -> ctrl: LFJS Set spawn color to rgba(100,220,60,255)

    -> ctrl: LFJS Create particle "tag2", shape box at 440, 300, width 200, height 200, angle 0

    thanks for your time.

    winkr7

  • Thanks winkr7 - this should now be fixed.

    Update: v.0.0.8

    Bugfix. Particle system setting actions are all now clamped to value ranges iaw the Liquidfun c++ files and/or have been tested to not produce odd results.

  • Colludium;

    Thanks for the quick response. It doesn't crash now, but the parameter doesn't seem to do anything. I assume it is clamped between 0 and 1.

    Still, it is best not to crash. I have the feeling they left out the division by zero checks and reasonable value checks in the interest of speed. Do I get the clamp values from the google site?

    thanks again.

    yours

    winkr7

  • Um can this be timescaled?

  • winkr7 - I've frigged most of the particle system parameters so that they are input in the range 0 to 100 (the max values can be rather arbitrary), so the max values from the b2ParticleSystem.h b2ParticleSystemDef struct equate to an action input of 100. Actually, it's a little more complicated. Some of the value ranges can be bigger and I've broadened the range slightly where I thought it ok. Like you, I saw that changing some of the values didn't make a big difference (I was in 2 minds as to include them or not). Particle system damping is indeed clamped between 0 and 1. Values greater than 1.2 caused chaos in my tests. Part of the particle system def struct is copied below to show you what I mean by the values being somewhat arbitrary: 

    b2ParticleSystemDef()
{
	strictContactCheck = false;
	density = 1.0f;
	gravityScale = 1.0f;
	radius = 1.0f;
	maxCount = 0;
	
	// Initialize physical coefficients to the maximum values that
	// maintain numerical stability.
	pressureStrength = 0.05f;
	dampingStrength = 1.0f;
	elasticStrength = 0.25f;
	springStrength = 0.25f;
	viscousStrength = 0.25f;
	surfaceTensionPressureStrength = 0.2f;
	surfaceTensionNormalStrength = 0.2f;
	repulsiveStrength = 1.0f;
	powderStrength = 0.5f;
	ejectionStrength = 0.5f;
	staticPressureStrength = 0.2f;
	staticPressureRelaxation = 0.2f;
	staticPressureIterations = 8;
	colorMixingStrength = 1.0f / 128.0f; 
	destroyByAge = true;
	lifetimeGranularity = 1.0f / 60.0f;
}

    The lifetimeGranularity is not accessible and is set inside the plugin depending on the framerate (fixed = 1/30 or 1/60; variable = 1/60 is assumed). For particle systems it is recommended to use fixed framerate because of a known bug where particles gain energy with variable dt values.

    newt - good question. If you use a variable framerate then the world steps are all smooth at lower timescale values (but very small values of dt can cause this bug: link). If you use a fixed framerate then the world step value remains as 1/30 or 1/60, so at lower timescale values there is a longer delay before each world step (the size equating to dt at 1/30 or 1/60). I guess that if there was a slo-mo phase then it would be best to set variable framerate for the duration, then go back to fixed.

  • Update: v1.0.0.9

    Fixed some spelling and description errors. Mostly incorrect references to buffer index which should have been particle UID.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • Hello Colludium;

    The viscous behavior is supposed to clipped to 100 is that correct? If I set it to 590 it crashes the elastic demo.

    -> ctrl: LFJS Turn Elastic behavior ON for spawning

    // only added these two lines

    -> ctrl: LFJS Turn Viscous behavior ON for spawning

    -> ctrl: LFJS Particle system viscous strength: 590

    // end addition

    the console value is:

    ncaught (in promise) RuntimeError: float unrepresentable in integer range

    at wasm-function[513]:0x2aa3e

    at wasm-function[559]:0x3605e

    at wasm-function[445]:0x20694

    at wasm-function[94]:0x54b3

    You could set up a test program that walks through all the possible (and some not possible) values for all the variables and see what crashes it.

    thanks for your time

    yours

    winrk7

  • Thanks winkr7 - the viscous is indeed clamped. However, the value was too much when the viscous behaviour flag was set at the same time as the elastic flag (weirdly, when elastic was enabled when it was already enabled). I have reduced the maximum value to account for this - it appears to be a Liquidfun limitation. The editor input range is still 0 to 100.

    Update: v1.0.0.10

    Bugfix - Out of range error when elastic behaviour set with the viscous behaviour flag.

    Note: Most of the system settings are input in the range 0 - 100. Inside the plugin the input value is factored for the range of values that haven't produced bugs in my testing. Some of these ratios mean that the max values in my post above can be exceeded. My reasoning is that higher values can cause even better effects (like the viscous max value in the Liqudfun b2ParticleSystemDef is 0.25 whereas in LFJS it can be 1.0 - because 0.25 isn't as striking). This means that there may be other quirks or bugs where combined behaviours might cause problems. I hope that the likely options have now been covered - but with over 32000 combinations I am not able to test them all to be sure.

Post reply
Return to board index
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)