I am rendering a large number of curves(partcile paths), about 16k. the curves are 300 points long.
Now i want to use a color array of 300 rgba values to color code these curves(all in the same way).
Is there a possibility to use an array of 300 values (well, 300 times 4 float values), for each curve?
I can only get it to work to hava a color array the same size as the vertex array - 300 * 16k(number of curves). The curves already take a lot of data in the vertex buffer, so I want to keep the color array as small as possible.
the is a simple linear relation between the curve positions in the array.
The vertex array consists of all the curves, in curve order: so first all the 300 positions of the first curve, then the next etc, so 16k times 300 positions. I hope it is possible to use one color coding for the one curve and reuse it for the other curves.
Unless you can programatically map the color using the position of the curve coordinates, you either need to have that 300*16K color array, or a texcoord array(of the same size) and then map the color using a 1D texture.
If you could use a geometry shader then it would be a lot easier, just put the curve coordinates in one or more textures (you could even generate them with a custom fragment shader) and then just generate the curve in the geo program along with colors or texture coordinates.
Maybe, to save in on space a little you can use a 1D texcoord for each vertex and then use a texture lookup.
There is also the possibility to use textures to store coordinate information on, if so you would only need a slightly more manageable number of vertics in the VBO, though you will still need to store and send all that data.
something like 3 2048*2048 textures (it would be smoother if you could use 256 points instead of 300) should work.
Another idea is to have limited number of colors allowed, and sort particles by color (bucketsort).
You can then use one draw call for every set of curves - simply use glColor before such draw call.
Using glColor for every curve would work slow since you would have to make separate draw call for every of 16k curves, but it should work fine with 30-50 groups.
Of course it won’t work if you have to do z-sorting for some reason.
If you need something really dynamic then using additional coordinate to lookup in 1D texture would probably be the best solution. Still, you would have to split your geometry to 4-8 parts due to maximum texture size limit.
so for every timestep t I render “particle” times gl_lines.
And I want every gl_line to have the same color coding every timestep. It is working right now with another VBO filled with color info as I told before.
I am not sure if it will work with your methods?
Yes, you can use that additional texcoord freely with glMultiDrawArrays - this will work fastest, but will limit number of different colors you can use to the maximum texture size. It will also cost you one float per vertex.
What I described in my previous post does not require any extra memory, but will certainly cost some performance if there are many different colors. So use this approach if you want to save memory at cost of some performance.
Originally posted by k_szczech: [quote]I am not sure if it will work with your methods?
Yes, you can use that additional texcoord freely with glMultiDrawArrays - this will work fastest, but will limit number of different colors you can use to the maximum texture size. It will also cost you one float per vertex.
What I described in my previous post does not require any extra memory, but will certainly cost some performance if there are many different colors. So use this approach if you want to save memory at cost of some performance. [/QUOTE]I solved this by putting the time for each particle in each w-component. I color according to the difference between particle time and global time.
