I’m experimenting with a simple project where a camera travels around a sort of infinite universe. To accomplish that, the faster solution I found is to draw thousands of Quads with a simple alpha’ed texture of a star.
But, here is my problem: When drawing those stars, I found a magical number of aprox. 10000 stars. After that, everything I render screws all over the scene.
I’m just starting my experiments with vvvv, and I don’t have a decent hardware to accomplish some of my dreamy projects. Used with bugs from my bad old Intel x3100, I have this little doubt: Is this a DirectX limitation, a Spread amount limitation, or even worst, is my graphics card fu**ing me again?
Notice: When using Group, to render 10000, and after that, more 10000, it works. So, I’m assuming it’s a limitation with the Renderer.
without having a look at your patch…the quad has a hidden pin you can reach only with Hrn. Inspektor. it is called Draw Slicewise. turn this on.
what you see is a vertexbuffer limit. quads have an internal optimization: if they have no or only one slice of texture and renderstate connected they can all be drawn with one drawcall, which is quite nice performancewise. if you want to draw more quads you’ll have to draw them slice by slice which impacts performance but will let you draw unlimited numbers of quads.
Interesting, I was asking myself what was this Pin, yesterday. Thanks for explaining joreg. It has some noticeable impact on performance, wich my old x3100 can’t handle.
So, I’ll have to find a solution to automagically split this Spread in N Spreads of 10000 quads, and draw them using Groups.
Joreg, do you know the exact number of how much quads can be draw at the same time?
correcting myself a bit: what you see is actually the limit of the 16bit indexbuffer used for the mentioned quad optimization internally. a quad having 4 vertices needs 6 indices to be drawn. so in a 16bit indexbuffer we can only fit 10922 quads.
i just discovered that when having a look at that quite old part of the code. fcourse this needs a fix to use 32bit indexbuffers. then we would in theory be able to draw around 700mio quads per call. but there is another limit on graphiccards, the MaxVertexIndex, which may be different on newer cards but on my nvidia 9800GT is: 16777215 (see the Caps output on the Device (EX9 Auto) node) which would boil us down to ~2.8mio quads per call, wasn’t there the MaxPrimitiveCount capability which may constrain us even further (not on the 9800GT though, which has 8388607).
just being curious: does ‘draw slicewise’ simply invoke one render call per slice/quad, or does it attempt to render as many quads in as few calls as possible?
Draw Slicewise really draws one slice per render call. which is actually its only option. the optimization only works as long as you don’t have the texture and renderstate spreaded (as mentioned above).
