Hi,
I’m trying to put together a large volumetric pixel map - nothing insane really, basically a 5 x 5 grid of LED strips, but two meters tall (so 120 LEDs per column)
I was trying to use Markus’ ‘the slicer’ technique from the tutorial, but a multi GLSL in only takes up to 30 inputs, and for one of the planes I need 120. I split that plane into 4 GLSLs and added them together, but its not quite there. I changed this line to add 31, 61, and 91 to shift the pixels over in the texture to match the input vec4 color = texture(sTD2DInputs[int(pos.y)+1],pos.xz);
basically everything is squished in the previews however.
the other techniques look to be working fine, but id really like to get the slicing method down. Anyone had any luck? the network is attached if anyone has some clues.
to get around the limit of the multiglsl TOP, an idea was to use the Layout TOP and arrange all render and renderselected in a grid. Now the shader has to do a bit more math for figuring out from which section to grab the color value, but I think the attached solved it nicely.
Another change here is to use the ChopTo TOP’s feature to arrange all values in a square - makes this all more scalable.
Hi there ! I had the same issue and after reading this post situation improved a good bit, I got a contour of a shape, but now there’s same shape squashed inside of it. Been at it the whole day, can seem to find where the problem lays to make it perfectly hollow. Any help would be highly appreciated!
the main issue with my previous solution is that it assumes a cube as a base. So where things break is if the resolution of the renderTOP is not square. Simple solution would be to just fix the resolution of all the renderTOPs to (in your case) 90. Otherwise you can see that the sphere is only rendered in the center part of the renders that are 19x90 pixels… hence the double center part.
Sorry to bother you again, but I seem to be running in to another little hick-up, once I plug in a box as a shape, some of the points are missing at the top and being moved to the bottom in diagonal pattern and vice versa , I wonder whether the problem is somewhere between topto-chopto-sopto inside the ‘‘slicer’’ base?
sorry - this took a bit longer but mainly was caused by a rounding error:
in line 27 of the glslmulti1_pixel5 text DAT in /project1/slicer/xzCams the quadrant pos.b is used to calculate the quadrant root. And exactly there I made the mistake of using int() on the incoming value. I checked with a DAT what the actual values of these pixels where and it turned out that some values where 24.99609 and using int() on that rounded them down. Simple solution: use round() before using int():
Hi again,
reviving this oldish thread as the project got hung up in the pandemic, but its back on now. So I follow most of what is going on here (thanks @snaut) but I am still finding a small error here on the Y axis, every now and then the pixels jump.
I am trying to use a non cube volume, so maybe that has soimehting to do with it? It is mostly there, but just this one niggling thing I spent the last couple days trying to track down. GJG, did you see the same issue?
thanks again! NotSoHollow-mod.2.toe (45.4 KB)
it makes sense now. Thank you Markus.