Is SPE.Group.tick experiencing issues with a faulty delta argument in Three.js / ShaderParticleEngine?

Question

Is SPE.Group.tick experiencing issues with a faulty delta argument in Three.js / ShaderParticleEngine?

I recently started using the ShaderParticleEngine library in Three.js to set up particle emitters.

After browsing through various code snippets online, I managed to get an emitter up and running. Initially, I thought it wasn't working as I could only see a single stationary particle on the screen.

Upon closer inspection, I realized that the particle was indeed moving, but at an extremely slow rate. It was only when I used tick(delta * 1000) that the emitter started showing some action. However, the outcome was far from ideal, with gaps and isolated particles.

Despite not having any issues with low FPS, I decided to remove the delta argument in the tick function call: particleGroup.tick().

Although the result improved slightly, it was still disappointing. See for yourself:

Online Emitter Editor:

My Result:

I'm puzzled by this inconsistency. I've utilized the same code provided in the library examples and exported the settings from the emitter editor. However, any minor tweaks I make, like adjusting particle life or velocity, yield drastically different outcomes in my game. Could it be that the particle life calculation is affected by the absence of the delta argument?

Here's a snippet from my game loop:

var animate = function () {

    requestAnimationFrame( animate );

    render();

    stats.update();

};

var render = function() {

    time = ctx3d.clock.getElapsedTime();
    delta = ctx3d.clock.getDelta();

    particleGroup.tick(delta);

    if(ctx3d.move)
    {
        ctx3d.ship.position.z += delta * 500 * 3000;
        //ctx3d.camera.position.x = ctx3d.ship.position.x;
        //ctx3d.camera.position.z = ctx3d.ship.position.z;
    }

    ctx3d.renderer.render(ctx3d.scene, ctx3d.camera);

}

Delta values per loop:

30.0000010000003385357559 9.999985195463523e-7 30.0000020000006770715117 0.0000010000003385357559 30.0000020000006770715117 0.0000010000003385357559 0.0000020000006770715117 30.0000010000003385357559 0.000002999999196617864 0.0000010000003385357559 9.999985195463523e-7 0.000002999999196617864 0.0000010000003385357559 0.000001999998858082108 0.0000010000003385357559 20.0000020000006770715117 9.999985195463523e-7 0.0000010000003385357559

javascript three.js particle-system

Answer 1

Answer №1

If you're looking to improve the smoothness of your code, consider implementing the following solution:

function adjustSmoothness(sim, timeDelta, maxStep){
  var substeps = Math.floor(timeDelta/maxStep);
  var remainingTime = timeDelta % maxStep;
  while(substeps-->0){
      sim.tick(maxStep);
  }
  if(remainingTime > 0){
      //handle the remaining time
      sim.tick(remainingTime);
  }
}

By incorporating this function into your code, you can effectively break down large steps into smaller, more manageable ones. For instance, if you are targeting 60 frames per second with a 16ms interval, you can use the function as follows:

var runSimulation = function() {

    currentTime = gameClock.getTime();
    timeElapsed = gameClock.getDeltaTime();

    adjustSmoothness(mySimulation, timeElapsed, 0.016);

    if(userInput.isActive)
    {
        player.position.x += timeElapsed * 100 * 200;
        //player.position.y = player.position.x;
        //player.position.z = player.position.x; 
    }

    renderer.drawScene();

}

By following this approach, you should observe visual outcomes that align with a smooth 60fps experience. However, it's essential to bear in mind that if the hardware struggles with these substeps, you may need to refine your solver algorithm. One suggestion is to track data from the last 100 frames and utilize it to determine the appropriate subdivision for your step size.

UPDATE: To ensure accurate timing in your implementation, consider the following:

var previousTime = Date.now()/1000;
var runAnimation = function () {

    requestAnimationFrame(runAnimation);

    runSimulation();

    performanceStats.update();

};

var runSimulation = function() {

    currentTime = Date.now()/1000; 
    timeElapsed = currentTime - previousTime;
    previousTime = currentTime;

    mySimulation.update(timeElapsed);

    if(userInput.isActive)
    {
        player.position.x += timeElapsed * 100 * 200;
        //player.position.y = player.position.x;
        //player.position.z = player.position.x;
    }

    renderer.drawScene();

}

Answer 2

If you're looking to improve the smoothness of your code, consider implementing the following solution:

function adjustSmoothness(sim, timeDelta, maxStep){
  var substeps = Math.floor(timeDelta/maxStep);
  var remainingTime = timeDelta % maxStep;
  while(substeps-->0){
      sim.tick(maxStep);
  }
  if(remainingTime > 0){
      //handle the remaining time
      sim.tick(remainingTime);
  }
}

By incorporating this function into your code, you can effectively break down large steps into smaller, more manageable ones. For instance, if you are targeting 60 frames per second with a 16ms interval, you can use the function as follows:

var runSimulation = function() {

    currentTime = gameClock.getTime();
    timeElapsed = gameClock.getDeltaTime();

    adjustSmoothness(mySimulation, timeElapsed, 0.016);

    if(userInput.isActive)
    {
        player.position.x += timeElapsed * 100 * 200;
        //player.position.y = player.position.x;
        //player.position.z = player.position.x; 
    }

    renderer.drawScene();

}

By following this approach, you should observe visual outcomes that align with a smooth 60fps experience. However, it's essential to bear in mind that if the hardware struggles with these substeps, you may need to refine your solver algorithm. One suggestion is to track data from the last 100 frames and utilize it to determine the appropriate subdivision for your step size.

UPDATE: To ensure accurate timing in your implementation, consider the following:

var previousTime = Date.now()/1000;
var runAnimation = function () {

    requestAnimationFrame(runAnimation);

    runSimulation();

    performanceStats.update();

};

var runSimulation = function() {

    currentTime = Date.now()/1000; 
    timeElapsed = currentTime - previousTime;
    previousTime = currentTime;

    mySimulation.update(timeElapsed);

    if(userInput.isActive)
    {
        player.position.x += timeElapsed * 100 * 200;
        //player.position.y = player.position.x;
        //player.position.z = player.position.x;
    }

    renderer.drawScene();

}

Answer 3

Answer №2

Sharing this as a response, hope it's okay...

I've made some adjustments to the particle engine, upgrading it to version 0.7.7, to address the issue of "not-very-smooth-looking" emitters.

Previously, the particle engine function SPE.Emitter.tick() would determine the number of particles to be activated based on the time step dt. This led to all particles starting at the same position each frame, causing the observed "clumping" effect.

Now, with the updated version:

SPE.Emitter.tick() still uses dt to determine particle activation.
Each particle's age is calculated as a fraction of dt during activation, preventing them from starting at the same position.

For example, if 100 particles are emitted per frame with a dt of 0.016, each particle's age will be calculated as (0.016 / 100) * i, where i is the particle index.

For detailed changes, see: https://github.com/squarefeet/ShaderParticleEngine/blob/master/src/ShaderParticleEmitter.js#L240-L246

Updates have been pushed to the master branch.

Answer 4

Sharing this as a response, hope it's okay...

I've made some adjustments to the particle engine, upgrading it to version 0.7.7, to address the issue of "not-very-smooth-looking" emitters.

Previously, the particle engine function SPE.Emitter.tick() would determine the number of particles to be activated based on the time step dt. This led to all particles starting at the same position each frame, causing the observed "clumping" effect.

Now, with the updated version:

SPE.Emitter.tick() still uses dt to determine particle activation.
Each particle's age is calculated as a fraction of dt during activation, preventing them from starting at the same position.

For example, if 100 particles are emitted per frame with a dt of 0.016, each particle's age will be calculated as (0.016 / 100) * i, where i is the particle index.

For detailed changes, see: https://github.com/squarefeet/ShaderParticleEngine/blob/master/src/ShaderParticleEmitter.js#L240-L246

Updates have been pushed to the master branch.

Is SPE.Group.tick experiencing issues with a faulty delta argument in Three.js / ShaderParticleEngine?

Answer №1

Answer №2

Similar questions

Verify the presence of a specific value within an array of objects in JavaScript that was retrieved from an AJAX response, and then

Executing <script> tags inside <template> on vue js

The component encounters a transformation in which prop values shift to undefined

Update Material-ui to include an inclusive Datepicker widget

Need help triggering Ajax code upon clicking a link?

What is the best way to create router links on the fly in Vue.js?

Only the initial value is being processed in the for loop using Javascript

Else statement malfunctioning with Alert() function

Create a customizable table without relying on external jQuery plugins

extracting an attribute from a class's search functionality

Modules failing to load in the System JS framework

VS code is showing the directory listing instead of serving the HTML file

Is it advisable to consider yarn.lock as a binary file when using git?

The CSS3 slideshow is displaying distorted and unfocused images

Ways to store a filestream coming from Node.js into AngularJS

Jumbling a word by shuffling its letters into a random order

Update the text input field from a different webpage

What is the best way to trigger a child function from the parent component in React?

Is there a way to restrict the amount of user input that is allowed?

What is the best way to retrieve IMDB movie data using AJAX?