Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 2 of 2

Thread: Offset bug in a compute shader for particle system.

  1. #1
    Newbie Newbie mustbe6char's Avatar
    Join Date
    Dec 2017
    Posts
    2

    Offset bug in a compute shader for particle system.

    I am trying to make a particle system using compute shader. My code is heavily inspired by this repo : https://github.com/MauriceGit/Partik...eration_on_GPU

    My bug is that some of my particles don't seem to be properly updated: They start at position (0, 0.5, 0) with a time to live of 2.5 and when their ttl reach 0, the compute shader should reset them at (0, 0, 0) with a ttl of 2.5 and the same velocity/direction vector. But, I have some of the particles who stay at (0, 0.5, 0) and even more strangely, seem to take into account only the X and Z component of the velocity vector (they don't move up or down). Here is a recording of the bug: https://gfycat.com/ForkedBadCurlew
    My complete code is available here : https://github.com/maeln/particles (look at src/particle_handler.cc to see everything related to the particle and data/particle.cs to see the compute shader).

    I tried to dig a bit to find where the bug was coming from so I tried aligning the particle on the X axis by putting this in the compute shader
    Code :
    positions[id] = vec3(float(id)/128.0, 0, 0);
    and I ended up with this : https://gfycat.com/ComplicatedPrecio...stedkookaburra
    (particles aligned on X, Y and Z axis for those who can't open the link).
    So it definitely seems like the data is written with an offset every 32 particles.
    By going a bit further, I outputted the data in the VBO after a single pass from the compute shader to see what was happening with the positions and I obtained this: https://pastebin.com/pkFZz5fk (for each particle the format is (x, y, z; id))
    So it definitely seem like the compute shader is reading or writing the data with an offset, but I cannot figure out why.

    I have been struggling with this bug for 2 days, so any help is appreciated !

    EDIT: Here is a paste with better indentation : https://pastebin.com/PsEi1AF3
    You can clearly see whats happening: every time the compute shader run, it gain an offset of one and skip the fourth run. So you the pattern is : write X in X, X in Y, X in Z, Skip, Repeat.
    Last edited by mustbe6char; 12-17-2017 at 12:50 PM.

  2. #2
    Newbie Newbie mustbe6char's Avatar
    Join Date
    Dec 2017
    Posts
    2
    I finnally found the bug: https://www.khronos.org/opengl/wiki/...#Memory_layout

    I was using the STD430 memory layout in my compute shader, which inherit the property of STD140. There is a warning that some implementation get padding wrong when using vec3 (which I was) to the point where using vec3 with std430/std140 is not advised. Using the memory layout "shared" or "packed" didn't solve the problem but using
    Code :
    glVertexAttribPointer(0, 4, GL_FLOAT, GL_FALSE, 4 * sizeof(float), 0);
    for the position VBO seem to fix the issue, but I will try to find a better way to handle this.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •