Some questions and things I have discovered :
I started by instancing a single point created with an add (and dat to sop to make it a point sprite), but I was stuck at about 40 000 instances, and then discovered I had no fps hit if I instanced several points. Is there a way to know the perfect balance between the number of instances vs number of points in one instance ?
I thought it would be nice if the GLSL multi top could output different buffers, gl_FragData[0…3], as the GLSL mat top, since I wanted to store both particle positions and velocity. I handed up using a quad with a render and render select.
Sadly I’m limited by Touch FTE resolution limitation, I can have 1280*1280 particles max in one texture, but I guess I’ll have to get a paying license to get around that!
One more question for those who have build their particle sys, is there a way to have a constant emission of particles ? Right now I give them a random birth frame before which they’re invisible and they get regenerated to their start position when they have no more life.
Maybe with geometry shaders to create and destroy them on the fly, but I read it wasn’t possible to create many vertices with a geometry shader.
There isn’t any way of knowing the trade-offs between instancing and creating the points directly without trying, there are too many factors that come into play with rendering to know which is best. It may change depending on what you are doing.
I agree having multiple outputs from a GLSL TOP would be good, I expect that will get added early next year.
your particle system looks awsome! I’m a big fan of particles. Can you share this to look how it’s made because i’ve never write glsl shaders. It would be much easier to get into this
@Sheff : Thanks! I’ve attached the file if you want to have a look at it.
@Malcom : Thanks for the answer, waiting for the multi output GLSL top then
On a side note, is there a way to use sampler2DRect and texture2DRect() in Touch ?
I get a “requires version 140 or later” error, even with #extension GL_EXT_gpu_shader4 : enable
and another error with #extension GL_ARB_texture_rectangle : enable
By the way, is there a list of openGL extensions supported by Touch ?
Texture rectangles aren’t supported by Touch, it seemed like it would just confuse things by having two different types of 2D textures. With non-power of two regular 2D textures they seem redundant.
There isn’t really a list of supported extensions, we implement parts or all of lots of different ones. Ones that give you extra functions in GLSL like gpu_shader4 will work except for parts that require extra inputs from Touch (that we don’t support).
Well since texture lookups with texture2DRect are expecting values between 0 and width and 0 and height, instead of 0…1, it seems more convenient when working with pixels.
There would be no need for the input1Offset function from the wiki page.
I was trying to port the gpu gems fluid example (http.developer.nvidia.com/GPUGem … _ch38.html), and I was having a hard time accessing the boundary pixels, resorting to stuff like
bool leftcolumn() {
bool result = false;
if (floor(gl_TexCoord[0].s*1000000+0.5) == floor(1.0/uInputRes1.z*0.5*1000000+0.5)){
res = true;
}
return result;
}
because of rounding errors.
Still about the gpu gems fluid example, it seems I’m about to be stuck, because a part requires looping about 2 fragment shaders (pressure solve followed by applying boundary conditions needs to be done 20-40 times).
I know how to loop over the whole thing with a feedback TOP, or loop over one GLSL top with the number of passes, but I’m stuck there, except trying to combine both fragment shaders in one (which I will try!)
Maybe you have a better idea ?
Thanks a lot.
Great piece of software anyway
Vincent
To test for edge pixels just check if it’s less than the texture coordinate of the right edge of the pixel. The texture coordinate you get in gl_TexCoord is always in the middle of the dest pixel.
So for example if you are drawing to an image with a width of 2. You’ll get a s Tex coord of 0.25 and 0.75, while the edge of the pixels lay at 0, 0.5 and 1.0.
Thanks, you’re right.
and gl_TexCoord.s >(1- uInputRes1.s) fir the right edge.
I remember having tried something like that but it must have been too late in the night
trying to understand the particles system, but there’s one part that seems to have an error (or more likely I just don’t understand it correctly). When Vince does the texture lookup into the pointPos TOP, he does this
