Hey,
Maybe it’s a simple logic problem but it’s giving me a lot of pain at the moment, so if anyone has an hint in any direction it would be greatly appreciated.
I’ve a grid of quads made with cross(2d) what I’m trying to do is move each row and each column independently. This means that the columns can move up and down, and each row can move right and left in loop, shifting the first and last slice.
I can do the shifting, my problem is that the index of the elements does not change, so after a few iterations the grid gets completely messed up.
I guess that after each move I do I have to create a new index based on the last iteration, but I’ve no clue where to begin with.
If there are solutions with VL I’d like to know, since I’ve started looking into it.
I found your problem interesting, and thought I would give it a try. Unfortunately, since I’m a new user I can’t upload attachments :(, but you should be able to download my solution here: https://www.dropbox.com/s/6cy2sgzckob4ci5/GridSlider.zip?dl=0.
The counters you used in your patch are the only statefull elements, but this is not enough to store the state of the grid after each iteration. You can see how this is done in my patch.
Basically, I created a pretty generic function that shifts the indices (0 to 30 in this case) around according to the input given. This mutation is then applied to the spread of vectors that define the position of the elements.
I’ve put some comments in the patch (make sure you open the sub-patch!), I hope this makes things clear enough.
I’m sure this could be solved much more elegantly in VL, but I’m only starting to learn VL. I would be very interested in a VL solution!
only improvement is using SwapDim instead of GetSlice to rotate the index matrix: GridSlider2.zip (13.2 KB)
and your right, the key point here is storing the state of the index matrix in the FrameDelay node. this is also how a VL solution would look like. store the current state in a pad and shift row/cols. only that in VL you don’t have to deal with indices but you can work directly with the data objects.
this was not as easy in VL as the problem sounds and became a nice learning experience. what i came up with is a slice/grid cell oriented solution of the problem. i think there is also a more spread based solution like the vvvv one, but in this solution the logic of shifting the grid is inside each individual grid cell. this makes the patches quite simple and understandable because each layer of the problem has its own patch.
so lets start at the innermost patch, the grid cell. it stores its last col and row index and can be shifted with an offset in each direction. after the shift it calculates a linear data index:
the grid itself stores a spread of mutable grid cells and updates each grid cell with the associated horizontal and vertical offset and then outputs the data in the new order:
the outermost patch manages one instance of the grid and updates it with the given inputs, note that the data spread is generic and can handle any data:
this patch can then be used as a simple process node like normal vvvv nodes:
here the data input is annotated to Spread of Vector3 to manage the grid positions from vvvv. see patch for more info.
Hey, thank you both for the time you spent on this!
@Suns this is exactly the kind of solution I was thinking about when I was talking about updating the index each time you move, thank you for the comments, frame delay and s+h stuff still confuses me, this was reasonably understandable.
@tonfilm Thank you for the VL example.
The past week I had the pleasure to meet @tobyk and he kindly (and incredibly quickly) put together his solution in VL. It’s not complete but it can be easily updated following his logic.
This one uses mouse and hit detection to interact with the grid.
Unfortunately I’m still a beginner in VL concepts but I guess looking at this examples is the best way to learn.
@tonfilms solution is a lot more elegant than mine, ther’es more than one way to skin a cat in VL of course.
One detail you have to consider is that whilst the final and logical position of all the cells is a fixed grid you are planning to have a touch interface. This means that someone can press and drag on a given row or column and temporarily drag it to a partial position in between grid positions. When they release the touch is when the cells snap to their nearest grid position and any appropriate logic (eg you solved the puzzle) is triggered.
So I think you need a few main states and sub states
-OnTouch - it does an s+h on first touch coordinate (storedTouch) and finds the nearest cell. It gets the grid position of that cell.
Then you wait for the touch to either slide horizontal or vertical by exceeding some amount in X or Y difference from the first touch. Once it has you are in either HorzSlide or VertSlide state.
In HorizSlide state you subtract the X position of the current touch from the X position of the stored touch. This is XDifference. Then you do a forEach loop on all the cells. All the cells whose GridPosition Y index matches the GridPosition Y index of the original nearest Cell are in the same row. You add the XDifference to their XPosition. If they exceed X bounds they should roll around so it’s a continuous scroll. Same for VertSlide but on the other axis.
-Then eventually OffTouch is triggered when the user releases their finger. Cells get new GridPosition indices based on which grid positions they actually closest to.
