Diamond Grid component bug

Just tried paneling tools in GH for the first time and came across what must be a bug.

I am creating a grid for a regular hexagonal pattern. I have calculated the correct distances and then create a diamond grid from the planar base grid.

Using the diamond grid functionality results in lots of Null Points and a mangled data structure.

My guess would be that it cant handle properly that the planar grid is in the XZ space and not XY. I made a workaround using GH components which works fine. I think diamond grid should produce the same result though.

Is this really a bug, or am I doing something wrong?

Attachments:

Diamond_grid_buggh.gh, 23 KB

Replies to This Discussion

Permalink Reply by Rajaa Issa on June 12, 2017 at 9:38am

Hi Armin,

Sharp observation, but it is not a bug. This is why.

The grid structure (and nulls) helps indicate how panels are connected/created using PT paneling components. Panels with ptCell for example, create a cell from some u & v location (u,v), then connect with (u+1,v)->(u+1, v+1)->(u, v+1) and close back to (u,v). With your constructed grid, ptCell does not generate diamond panels. You'll have to use a smart connection method to account for it.

I hope this explains it.

The top image show ptCell from the ptToDiamond (with nulls). The middle when paneling the grid after GH clean). The bottom image show it with your grid.

Permalink Reply by Armin Seltz on June 13, 2017 at 1:36am

Hi Rajaa,

Thanks for your in-depth explanation of the data structure. For paneling this seems to be required, but I am actually just after the grid, which I am using to transform hexagonal extrusions to. The data also needs to go to the image sampler, so I need a clean data structure. I actually cleaned it up even further, so that I have alternating rows of 300 and 299 points.

Also I noticed that I couldn't see the swap U and V command that exists in Rhino (only flip U and V direction). Is it as simple as using Flip Matrix in paneling tools for GH?

Permalink Reply by Rajaa Issa on June 13, 2017 at 9:25am

Yes. PT grids are simply GH data trees. I think you need to have square grids before you can swapUV though.

Even if you need to create extrusions, PT has components to help you extract the borders, which you can in turn extrude. It might save you a bit of work. If you need further advise, feel free to share your model/definition, and I'll be happy to look into it.

Permalink Reply by Armin Seltz on June 13, 2017 at 9:53am

Thank you. Yes, I think in terms of a PT grid, yes. But I am simply using it as a 2d-grid, with alternating columns offset up basically.

I am transforming given 3d-shapes into the grid and using the points as the point where to move them to.

I will be happy to ask further questions when they come up. So I presume your knowledge of GH far exceeds simply PT, right? Something I noticed while transforming lots of referenced blocks to the grid points: a) the rhino viewport rendering doesn't take advantage of instancing, hence is super slow with many instances of a simple block (>5000) and b) transform components in GH are also quite slow. Better to use the transforms, compound the transforms and then apply transform -> its around 10 times faster for many blocks. Can you shed any light on why this might happen? (Sorry, I know its off-topic).

Permalink Reply by Rajaa Issa on June 13, 2017 at 4:53pm

Last time I checked, blocks are not supported in GH. Your best bet is to do what you described (compound transform and apply once on geometry). The reason why it is faster is that you eliminate many extra transformations (if you have 100 objects, and transform once, that will be 100 transformations, but if you apply transform 5 times, then it will be 500 transformations.

Permalink Reply by Armin Seltz on June 14, 2017 at 2:40am

The second part about transforms makes sense.

For the first part I am using Elefront to reference, transform and then bake the transformed blocks. But its regardless of GH. I am using the example of the block, because then it is definitely an instance. So say I have a block with some simple geometry in it. Now I copy that block say 10.000 times. The rendering of the viewport in Rhino shouldn't slow down at all. But it does. It seems like even though it is using blocks (ie. instances) the viewport renderer sees 10.000 different 3D objects and hence slows down. This is what I dont understand. In any 3D software if I copy the same object 10.000 times, the viewport doesn't really slow down at all. But if I do the same in Rhino, for all view modes except Wireframe (since its very performant), the viewport becomes ultra slow. I mean like 1fps slow. What I usually do is have an Octane Render viewport open, then hide the layer with the geometry in Rhino. Now the Rhino viewport is really fast, because it is not showing anything. Meanwhile I am moving in the Octane Render viewport and it is doing near real-time unbiased rendering faster than even the shaded view in Rhino. Octane recognises that all the blocks are instances and loads it into memory only once, but not all 10.000 objects. That must be why the Rhino viewports slow down linearly with increasing number of copies of the same geometry, while in Octane and other 3D software there is no difference between 10, 1.000 or even 100.000 copies of the same geometry.

Its just something really odd I noticed in Rhino, that I have never noticed in any other 3D software.

Maybe you know something about this. Its kind of hard to find information on it. But I believe if the Rhino viewport would support instance rendering like all the others, this wouldn't be a problem.

Surely Panelling tools is one of those cases where you can very quickly end up with a lot of copies of the same geometry, just transformed in different ways, the same way instances are, so I believe Panelling Tools would benefit from it.

I believe this is related to it and would be great: