Forum

Building a vertexbuffer with spreads

vvvv beta question
#1

Hi all, first post, very recent user. Come from PureData and Flash development , so this is a brave new world for me <3

Having lots of fun, but I’m confused about the right way to solve a specific challenge. Feel free to correct me if I’m flat out wrong about my approach altogether.

Given a 3d cross spread of cubes, my GPU starts coughing blood as the spread count increases. I figured since I’m not dynamically manipulating the spread, I might as well just generate a mesh of all the cubes I want and render that alone, “spreadless”. Of course this means I still need to generate that mesh…

So I make an IOBox 8x3 matrix of vertices (3 values per vertex) and an IOBox list of indices, hook them up to a VertexBuffer and a Mesh node and boom, there’s my box. So far so good. So my problem then is taking my vertex matrix and spreading it in a way where the relationship between each vertex in a cube remains the same. The best I can do right now is to make untranslated 1:1 copies of the same cube, but that’s not the effect I’m after, obviously…

I’ve been playing with stallones and various spreads but stallone never seems to be able to maintain slice order in a usable way for my purpose, and spreads such as linearspread will likewise distribute the slice data with no respect paid to my idea of vertices (as they should). So my general understanding right now is I think I might be lacking a general understanding of how something like this should be done.

So hm. How would you guys create larger meshes or generate vertexbuffers/indexes by repeating/spreading other procedurally generated meshes?

Cheers,

  • Andreas
#2

You should also try with ApplyTransform (Transform), since the way you build the mesh seems (to me) to need this. Posting the patch would also help - the version with 3d cross too, since it’s strange it’s eating so much performance: maybe there’s the way to improve something there.
Also Cull (EX9.RenderState) could help with performance in some cases.

#3

Ok cool, here’s an annotated example patch; Just a box in a vertex buffer. I think I’m trying to gauge just how much work this is going to be; Do I need to separate each triplet of coordinates, or can I work on the whole set?

The 3D cross performance hit occurs naturally, if you ask me, when I’m dealing with a thousand if not thousands of cubes; I’m making the assumption that each box is passed to the gpu in its own vertex/index buffer? In my mind, a single vertex/index buffer pair with 12k triangles total should be a piece of cake for any modern gpu, whereas I can see the bandwidth stretching a little when that many buffers are being drawn.

Of course I could be totally wrong and maybe v4 does what I’m trying to do automatically for me ;-)

An annotated basic patch (11.6 kB)

#4

I am not sure I completely understand you right, but it sounds like you could save yourself a lot of trouble if you translate a single box several times instead of trying to generate one huge mesh.

are you looking to do something like in the attached patch?

-sunep

multiboxExample.v4p (8.9 kB)

#5

Looking at your patch you seem quite experienced about this kind of graphics.

So sorry if you’ll find mine contribution to your problem too little.

Also may I suggest you to split a Box (EX9.Geometry) to see how is it done inside? But this you have already done for sure.

Uh, yes. I’ve patched this with 27.1. Maybe u wanna download 27.2 and see if everything’s ok?

Thank you

boxmodeengaged? (18.1 kB)

#6

This is very cool h99, just the kind of help I was after :-) I “know” the terminology but I don’t really understand the best ways to deal with mass data in VVVV, so your patch really helped a lot.

So the weakness I’m seeing now is the need to create Stallones with individual input pins with our offset values to generate the required spread of offsets… Looking specifically at the Stallone offsetting the indices for now, what would be a patch where I could pipe in a “boxcount” IOBox with an integer to generate that spread of 360, 368, 36*16? The 0, 8 and 16 (…) are easily derived, and the required spread length can be gotten by multiplying the slice count of the original index list by the boxcount…

But how can we avoid the Stallone here, or make its inputs dynamic?

#7

Like this?

boxmodeengaged^2? (20.0 kB)

#8

So the good news is adjusting that patch to “manually” create a mesh of 8 boxes and then crossing THAT mesh gives me much better performance with, tbh, a ridiculous number of boxes on screen ;-) Progress!

edit: just saw your updated patch. Yeah this is getting there… I didn’t even consider that there would be a Sort node, go me.

I added some more connections to tie everything together. Fun times!

boxmodeengaged3.v4p (24.0 kB)

#9

Why? Or better: what you mean with “manually” - you also didn’t create a mesh of 8 boxes, but a mesh of 8 vertices placed in box shape -? You would start from a point, no? Usually an input is needed. And this point is that IOBox you created as source for vertexbuffer position inlet.

So you create a spread starting from the values inputed there. I don’t think you’re crossing values, you’re simply creating bigger spread, though when you pass it into Cross3d you create in the fastest way a bigger - than previous - spread of values to obtain, in our case, a cube of cubes.

Create an IOBox out of the Vector (3d Join) and have a look at data. That’s why I made just three boxes, to make easier for you to read their data.

At this point I think you’ll be able to input dynamically any value in linearspread, and also to adjust “automatically” its spreadcount to fit vertexbuffer\mesh needs. Yes, in someway you have to do this manually.

Or I don’t get the point?

Edit: I see just now your edit. So this way is better, no? Next step is hlsl, but for this, as in poker, I call a check.

#10

spreadedmeshwriter

maybe this helps?

© vvvv group