Hi again, Wrote it wrong with sizes actually, uniform arrays in general goes in range of 512 - 4k floats max, and these limits counts towards size of all uniforms used in program summed, not each one of them individually. And uniform buffers should be at least 16k floats max if supported.
Cheers, Sergey. 18.02.2011, 01:28, "Sergey Polischuk" <[email protected]>: > Hi, J-S > Uniform arrays maximum size is implementation dependent and about 4k-16k(+) > floats in general. I personally used plain 1D\2D textures to store data for > instancing. Another options as you mentioned is uniform buffers, textures and > texture buffer objects. Uniform buffers max size is quite small - about same > 16k(+) floats as uniform arrays, difference only in usage (you dont need to > transfer uniforms values to gpu, you just switch buffer). Uniform buffers > works faster than textures esp. with consecutive access pattern (as it will > be with instancing) so if you can fit your data in those i think it's best > option, if it just doesnt fit - use plain textures for static data, and > texture buffers for dynamic data. > > Cheers, > Sergey. > > 17.02.2011, 22:52, "Jean-Sébastien Guay" <[email protected]>;: > >> Hi all, >> >> I'm trying to draw some instanced geometry, passing a transform per >> instance. I've set up a uniform array for each node I'm instancing, >> which has a fixed number of values (I'm using 128 now) and that works well. >> >> The problem is that this way of passing data seems limited to a small >> number of matrices. As I said I'm using a size of 128, so 128*16 floats, >> which doesn't seem like much (8192 bytes of memory). I want to increase >> that (my initial goal was about 1024 instances). But if I increase this >> just to 256, I get >> >> Warning: detected OpenGL error 'invalid operation' after RenderBin::draw(,) >> >> repeatedly on the console, and my instances don't display anything >> (presumably the matrices it's getting are all zeros). >> >> This is to be used to display small rocks as particles, so I really need >> more than 128 of each rock type. One solution might be to increase the >> number of rock types (so the number of drawables that will be >> instanced), but I would prefer another way. >> >> One thing I could see to increase the number of instances I can use is >> to pass less data per instance, for example a vec3 translation, a float >> uniform scale and a vec4 quaternion which gives 8 floats instead of 16 >> per instance. Would this work, i.e. am I right in my assumption that the >> problem is the amount of data and not the number of elements in the array? >> >> Another solution might be a texture. In a float texture, I could pass >> (if I use the same members above, so 8 floats per instance) over 2 >> million instances in a 4096x4096 texture. So to get to my initial goal >> of 1024 instances, I would need a 128x64 float texture, which seems >> manageable, and I could potentially go much higher if I wanted to. >> >> I've seen an example (osguniformbuffer) that used uniform buffer arrays, >> I'm not sure if this would apply to what I'm doing but the usage seems >> more complicated than a uniform mat4 array, so as long as the >> performance difference isn't too large I'd prefer to use those. >> >> Are there other ways to pass lots of data in an array to a vertex shader >> that I haven't thought about? I've thought of the above options, so what >> I'm asking is what other people have been using and what has worked for >> them. Right now the float texture seems like the best option (especially >> since the hardware we target seems fast at vertex texture fetch, which >> we use for display of height fields). >> >> Thanks in advance, >> >> J-S >> >> -- >> ______________________________________________________ >> Jean-Sebastien Guay [email protected] >> http://www.cm-labs.com/ >> http://whitestar02.webhop.org/ >> _______________________________________________ >> osg-users mailing list >> [email protected] >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
