Extend mesh with Edge Colors for Bleed (printing)

[crz_06]

I need to extend the edges of my meshes and keeping the colors , as I want to create a bleed for printing purposes.

I have a method with is overly large and complicated. I’m trying to replace it with a elegant and fast method, ideally that respect vertex colors as well. I attach my current working method as for now with solid colors per mesh face. And my work-in-progress, which has some obvious mistakes. These are caused by the fact that the mesh eval to extract mesh colors doesn’t know with vertex color to take into account when multiple vertices are at one location.

Any feedback to make this work is much appreciated. I am sure I am missing the very obvious

I’ve include 2 base mesh, one with the solid colors/face and one with vertex colors. Ideally the method would work in all situation.

bleed.gh (195.8 KB)
(updated possible alternative, based upon member search vertices)

on the left the W.I.P.

[inno]

the following is very little about GH but not completely off topic

I had to take a few courses of graphic design, like 2 million years ago, and at a certain point of my life I was living out of graphic design
about the bleed topic, it also very much depends on the type of final result you want to get

the main point of bleeding is to print an overextended abundant size (usually a few mm) to account for cutting errors, in such a way you don’t end up with white stripes left here and there

the point is -generally speaking- in order to get the very best final result, the extension of your print should be seamless (of course you can always do whatever you want and feel, my point is just a sort of personal point of view), and with seamless in this context I think something like “if the image is trimmed 2mm less or 2mm more, I still perceive it the very same way”

if your image gets printed with no bleeding and badly cut like this, you won’t be happy because you very much see a white border all around:

but if you apply bleeding as “duplicating the most external colors” and get the very same trimming on it, you will get something like this:

which of course is already ten times better than the previous, but gives the feeling like there’s a sort of few flat background colors on top of which the beautiful mesh is applied, and makes me perceive a very neat division on these areas, as if the background and the mesh were two different things

so, in my humble opinion of graphic designer of 16 millions years ago, instead of extending the mesh border by sampling the color of the “closest neighbor” or similar approaches, I think you might get a better result by extending the mesh pattern itself, with all its beautiful complexity, in such a way when the trimming is done abundantly, I wouldn’t see a flat color overextending the border, but I would see something as beautiful as the content itself

like “don’t make them perceive the image was supposed to end here”

[crz_06]

thanks @inno , always much appreciate expert feedback. I think you are right and it’s much easier this way. I’ll adjust my code logic accordingly. The above example is a extremely lowres of final result (4x2m wall mural, with color changing effect defining on viewing direction. We’ve seems in the past the plotter is not super precise between the individual panels, so the 2mm bleed is kinda required. I’ll take it form the adjacent panels, so I only need to care about the panels at the very end. For this the duplicate color is ok. I’ll post a picture in 2 months time of the final results

Nonetheless … still curious how to approach the initial subject. I’ve tried many thing, some fast, some slow (Member index search), but the one thing that would be super useful to have it when you have a mesh, and attach a MeshEdges node to it, it give you the at E1 the Naked Edges and at E2 the InteriorEdges. However it doesn’t provide an list of indices, so one would be able to cull away related faces.

[laurent_delrieu]

Hello
I didn’t read all the thread carefully but here is my 2 cents.
If the whole idea is to have a sort of color interpolation/extrapolation on side faces. It seems possible to affect a color at each face center. Then each color is transformed to a vector.
Then the whole idea is to smooth vector as it is described here
Smooth Vectors On Mesh

Vector Field Smoothing

Hello, I have a list / field of vectors in grasshopper but i have some runaways (top left). My question is now, is there a possibillity to smooth these vectors to get a result without vectors facing in a completely different direction and get a smooth transition. [image] Based on this vectors i want to do a pathplanning in a subsequent step. Thank you very much in advance! Kind regards Raphael

I’ll use here my tool from Nautilus (I didn’t check if the one from Daniel can do the same) that can have fixed vectors. So all existing color/vector are fixed and exterior not fixed so depending on the number of iterations you could have new colors for each face.
No itterations

1 itteration, initial color = black (-1,-1,-1)

1 itteration, initial color = white(1,1,1)

1000 itt, Uniform weighting

1000 itt, Edge Length weighting

bleed_LD.gh (79.8 KB)

Using some mesh division and edge constant color it is possible to add others effects

[crz_06]

Hi @laurent_delrieu love how your brain works and thank you for once again showing us here what grasshopper and creative coding can achieve. Love the last effect and picture!

Maybe i am missing the obvious, but my initial question could be more simple in its needs. It’s comes down to the question:

Given a mesh, with naked edges, how to extend those outer edges while keeping the vertex colors, creating a border around them that copies the colors of the mesh outer edge.

The challange i face is that its easiy to get the naked edges or vertices, I cannot easily find nor map the associated vertex colors, except and only when using many individual steps and many nodes (and even then it is super specific from rectangular shaped meshes).

It becomes even more cumbersome when multple faces share a vertex on the naked edge, and thus one needs to first find and cull all inner faces, which in itself is hard to generalize.

I’ve approached this though 4 different directions, and while some are more elegant than others (fewever nodes) they perform extremely slow.

[maje90 (Riccardo Majewski)]

bleed 02.gh (48.6 KB)

[crz_06]

Yeah … I was so close so many time, but made the wrong turns

@maje90 thanks man!