Brep to One Srf Mesh

I always find lots of cool tutorials and examples on how to make cool patterns.

The only problems is that those are always made on single surfaces.

Coming from product design, I always have to deal with Breps and I always have an hard time to figure out how to deal with them in GH.

Here is an example:

I thought to create longitudinal sections that I would then divide by lenght to get cross sections so to then create a quad mesh.

I was wondering if there is actually a better tested process and I am maybe taking a completely inadequate root.

I am not even sure if a Quad Mesh would be usefull in creating patterns ? you actually need a surface with UV?

btw I got stuck in mine effort when I relised that my curves don't have same direction

Replies to This Discussion

Permalink Reply by peter fotiadis on March 20, 2017 at 9:20am

If the brep faces are "suitable" (like in the image that you've provided) there's 2 ways to address that:

Use meshes (native component: mesh UV - works on the underlying brep face surfaces) and then making a mesh without "overlaps" (i.e. common mash faces) and then "order" the mesh faces (kinda the UV was applied in one surface) ... and then do whatever desired (most people like/use meshes for that type of stuff).

Here's a brep with 4 brepfaces treated that way:Or divide (native component: SDivide - works on the underlying brep face surfaces) the brep faces and get trees with nulls (no hit) or points (hit), then "order" them properly (kinda the sub division was applied in one surface) and use the points for whatever scope (patterns and the likes).

Here's the same collection treated that way:

In both cases the tricky bit is "ordering" , say Points, in a proper DataTree with one or two dimensions (BTW: That's easily done with code; I have no idea how to do it with native components).

On the other hand if you have no combinations in mind (meaning that you want to deal with all the "pieces" at once [no order etc]) you can use stuff the likes of WB etc etc:

Permalink Reply by sylvester on March 20, 2017 at 2:58pm

Hi Peter,

Thanks for the nice hints.

Unfortunately with my surfaces I get a result where some of the meshes don't have anything in common with each other. It results impossible to generate one common mesh.

Is that what you meant with "suitable" Brep Faces?

Your surfaces were generated from one single surface and then divided? it seems their UV where already matching anyway?

Usually in product and automotive design you will get data where the surfaces have completely different UV orientations.

Probably Grasshopper can not help in placing patterns on those geometries?

Permalink Reply by Hyungsoo Kim on March 20, 2017 at 3:24pm

Hi.

This "thread" might be of some help to you.

Permalink Reply by peter fotiadis on March 21, 2017 at 1:20am

Well Sylvester ... that's why I said "suitable".

In general there's ways to address non "suitable" UV orientations ... but they depend on topology and therefor are case specific.

For instance imagine a "flattish" polysurface where sectioning (in 1/2 directions) could yield a meaningful grid (then you can calculate all ccx events and "sort" the points etc etc). But work with a doughnut and things are not that simple.

On the other hand testing "suitable" brepfaces is not that simple: even attempting to "auto" transpose the underlying surfaces requires several lines of coding. See these 2 cases:

Both derived from a test blob (made with TSplines - dead by now but still handy):

The bad news are that most solutions (or "solutions") on that matter are rather far and away from the scope of this Forum and therefore I doubt if someone would be willing to provide any working one.

On the other hand using Plan B ... i.e. meshing a Brep and attempting to relax the mesh (and going from tri to quad faces: Google that one) and then "sorting" them (a kind of topological sort) ... but that's another animal.

Permalink Reply by peter fotiadis on March 21, 2017 at 2:11am

BTW: Here's a remotely "related" task: get one of the Breps pictured above, adjust the meshes per brepface and create a quad/tri mesh and then "distort" (all faces or some percentage) the mesh faces creating a paranoid ugly/pointless thing.

Permalink Reply by sylvester on March 21, 2017 at 6:44am

hi Peter,

thanks again for the great answers.

My question was trying to understand how are made work similar to BMW Vision or Renault Trezor.

I understand that there is really not a general process or tool that makes it easy to map polisurfaces with a grid.

Every topology can have its own story, methods and nuances which probably make a must to be coding as it makes everything much more customizable?

(GH seems to make things just more difficult sometime for things that with coding would be standard)

Would be great to be addressed in the right direction in learning those skills.

Would you say that mapping grids on polysurfaces and then work on those grid is the essential first step to create those sort of patterns on complex shapes?

Or maybe for those works studios just approximate their shapes to one surface and then once the pattern is complete they morph it onto more complex surface structures?

Permalink Reply by Erick Vásquez on March 21, 2017 at 11:29am

Hi Sylvester, bmw vision and renault trezor, both are uv surfaces, only in your case that has 4 corners, maybe rebuild your brep with naked edges curves works.

Attachments:

170321_rebuild_brep_ev.gh, 29 KB

Permalink Reply by peter fotiadis on March 21, 2017 at 7:02am

Hi Sylvester (the pattern on the Vision tire is easy [obviously: one surface] and the Tresor front panel ... well ... maybe is just one trimmed surface, maybe not)

Other than that ... have always in mind that a ?^@&@% door for your next 7 series (avoid that car at any cost) is rated about 10M (the so called development cost) whilst the whole car may require 500++ M. Did you know that the software used in a 7 series exceeds 70M lines of code? Therefor ... blah, blah.

Back to real-life things:

One "suitable" solution for flattish stuff the likes that you've captured is:

1. Make a BoundingBox and make a Point3d grid using, say, the bottom 4 corners (a single dimension tree)..

2. Declare a nullable Point3d grid [ DataTree<Point3d?> hitsTree = new DataTree <Point3d?>();].

3. Shoot a Ray3d from each point using some Vector3d (for instance using p4 - p0 out of the box points). If the Ray hits a brepface get the point if not put a null. That way you have a tree of equal List sizes and "combining" things (Points) for your patterns is greatly simplified [you can use the crude try{} catch{} approach].

4. If all these sound a bit freaky to you ... post a flattish test case (with different U/V) and give some hints about what "pattern" means to you.

best

Permalink Reply by sylvester on March 21, 2017 at 4:06pm

Hey Peter,

I understand the intention of your point and I think it is exactly the sort of process i was looking after.

I am not a master of coding and definitely not a master in coding for Rhino so yes, your explanation sounds a bit freaky.

I post a a sample of a wheel arch (in attachment).

Would be great to see an example of your methods on this surfaces.

A pattern like the BMW Vision would be fine, don't take it to litterally but something like in the image below:

I know that the Trezor's hexagons can be done easily on a single surface like in this tutorial.

But trust me, in the real world that front panel would be at least made from 2 slabs surfaces and one fillet surface.

This rear is probably a better example (is fully covered from hexagons too):

Maybe again the best solution is just to do it on a plane and then morph it on the Brep like this guy does:

https://www.youtube.com/watch?v=WjC6ZGP6OSM

Also for the BMW Vision it does not really look like made from one surface, the more so that there is a feature line passign through.

Would you suggest me any resource where to learn bits of the process that you explained in your previous post?

@Erick: Thanks, it was really interesting to go throught your GH definition, but I don't think it solves my issues. In your example if you had any definition inside your surfaces it would have been gone lost. And if you did not have any definition, I don't see any point in having a Brep representing that topology, a 1 surface would be fine so the problem would not exist.

Attachments:

samplel.igs, 176 KB

Permalink Reply by sylvester on March 21, 2017 at 4:20pm

you can also use the stl mesh version if it helps:

https://mega.nz/#!msUFGICY!Dssnh0J53fa6a4yJNIkyc3pz4kntwnMPwT8DvuCNpd8

Permalink Reply by peter fotiadis on March 22, 2017 at 4:43am

Hi Sylvester,

Well ... the perforated side (i.e. an "extended" wheel arch) that you've posted adds some attractor driven "influence" to the "pattern" (thus I must include that capability [easy] into my forthcoming example: in fact it would work with any number of attractors in push/pull mode). I'll include 5-6 different "patterns" as well (in the name of science, he he).

The example would be carried over - traditionally - via C# (and not P that you've used) meaning that it could be definitely freaky ... but no pain no gain (life sucks).

With regard training resources ... well ... I'm in the AEC market sector and thus I'm not familiar with the stuff/methods that automotive designers work (but in any case all these cases are bespoke and I expect bespoke one-off solutions as well).

BTW: Are you familiar with coding in general? (not necessarily for R or GH).

BTW: If we push the limits a "bit" this may yield a very freaky thingy; ideal challenge for the w/e ... but THIS w/e is the mother of all w/e since both F1 and MotoGP seasons start (go Lewis/Valentino).

BTW: That said a "rectangular" (hits and nulls) grid of nullable points is one thing ... whilst a relaxed (say via Kangaroo) mesh (or some reworked Delauney thingy or even a Ball Pivot mesh) is another animal ... meaning that "patterns" should work by using mesh connectivity trees. Are you 100% comfortable with these ultra freaky things? (vertices to vertices, vertices to edges, edges to faces, faces to faces ... cats to dogs etc etc).

more soon

Permalink Reply by sylvester on March 22, 2017 at 5:33pm

Hi Peter,

I am familiar with the main concepts of coding, I am not scared of it, but I have very, very little practice.

I am sure I will have lots to learn from your examples and look forward to explore them.

At worse I will ask you a few questions here and there.

Yes I was just about to ask about Python vs C#.

Is C# just your preference or it is the most powerfull when it comes to Rhino?

I am more familiar with Python, but I am sure it will not take me too long to get at the same level with C# (very basic level)

I am looking into Kangaroos and it seem an amazing tool that gives you the chance to discover patterns that you could not discover only with common rationale methods.

I am definitely up to explore that option too.

Hey if this example works well would you give me coaching? I would even pay of course