Federico-AmazingMaxStuff

it is still unclear to me exactly how the @initcount attribute works. 

If we take the code from the "tf.particles.simple" patch, we can see that the initcount attr. is set to 5.

What is exactly the relation between the number of particles that we set as the matrices dimension, and the initcount? 

Every GS instance will emit 3 particles per frame, is this going to sum up until we reach the same number as the dimension of the input matrices to the buffers (1M)? 

Also, is the "initcount" attribute only relevant when using a GS? Or can this be used also when modifying the output buffers in the Vertex Shader?

Hi all, 
it is still unclear to me exactly how the @initcount attribute works. 
If we take the code from the "tf.particles.simple" patch, we can see that the initcount attr. is set to 5.
And we can have 1M particles.

What is exactly the relation between the number of particles that we set as the matrices dimension, and the initcount? 
Every GS instance will emit 3 particles per frame, is this going to sum up until we reach the same number as the dimension of the input matrices to the buffers (1M)? 
Also, is the "initcount" attribute only relevant when using a GS? Or can this be used also when modifying the output buffers in the Vertex Shader?

Thank you for any help with this!

Hi all, 
it is still unclear to me exactly how the @initcount attribute works. 
If we take the code from the "tf.particles.simple" patch, we

gl3-"initcount"-attribute-for-tf-how-does-it-work

i think the initcount specifies how many particle emitters there are. It looks like their position and velocity is set by a noise texture, which might explain why some emitters finish before others.

i think the initcount specifies how many particle emitters there are.  It looks like their position and velocity is set by a noise texture, which might explain why some emitters finish before others. 

I replied to this on the slack channel, but for completeness: 

init count is simply the number of particles “active” when the tf-process initiates. tf-processes that use geometry shaders are able to add new primitives to the simulation in the geometry program, so there is no concept of primitive count in this case. there is only initial primitive count (ie initcount) and total particle count (ie buffer dim).

in the case of the “Simple Particles” launcher patch, initcount corresponds to the number of particle “emitters”. each draw pass can emit up to “max_vertices” number of vertices (defined in the the geometry shader, line 53: layout(max_vertices = 30) out;) 

hitting the maximum number of vertices has different behavior depending on your particular shader

essentially yes, if you aren’t using a GS, then you can’t add any vertices to the simulation, so you will only ever have “initcount” number in the sim.

another caveat is that if initcount is 0 then all vertices are processed initially.

I replied to this on the slack channel, but for completeness: 

init count is simply the number of particles “active” when the tf-process initiates. tf-processes that use geometry shaders are able to add new primitives to the simulation in the geometry program, so there is no concept of primitive count in this case. there is only initial primitive count (ie initcount) and total particle count (ie buffer dim).

in the case of the “Simple Particles” launcher patch, initcount corresponds to the number of particle “emitters”. each draw pass can emit up to “max_vertices” number of vertices (defined in the the geometry shader, line 53: layout(max_vertices = 30) out;) 

is the “initcount” attribute only relevant when using a GS?

essentially yes, if you aren’t using a GS, then you can’t add any vertices to the simulation, so you will only ever have “initcount” number in the sim.

another caveat is that if initcount is 0 then all vertices are processed initially.

Dante's statement above is also true.

Thanks for the thorough explanation Rob. 

GL3 "initcount" attribute for TF, how does it work?