Boundary/Outline "Contest" GH/C#

Outstanding I hadn’t thought that someone would take it to real simulation stage :heart_eyes: Can’t wait to dive in the code :face_with_monocle:

Just realized I didn’t attach my .gh file… fixed now.
Sry guys…

This is a completely different approach that doesn’t use MCX, C# or any of that Plane Fit code. Just Anemone to sequentially examine each adjacent pair of hexagons, Flip them to match direction, adjust Seam and then CCX. The “reconditioned” curves are not even used outside the loop (‘D0’ output of FastLoopEnd). There are still a few anomalies where the geometry is “dirty”, probably more than the expected two intersections.



OUTLINE_DATA_COMPLEX_2019Jul4c.gh (216.7 KB)

P.S. Confirmed. Two pairs have three and two pairs have four intersections instead of the expected two. Oh well. This kind of thing can often be avoided by changing the model that generates this geometry - or you really have to care about sweating out the exceptions.

OUTLINE_DATA_COMPLEX_2019Jul4c3

P.P.S. To see a “simulation”, substitute “Classic” for “Fast” Anemone loop components:
OUTLINE_DATA_COMPLEX_2019Jul4d.gh (214.4 KB)

I checked your approach and you just try to outline them connecting the dots between intersection points which from my pov is taking a shortcut since if we would increase stamp spacing and we would change shape to a wider rectangle in this approach we loose completely the detailed shape of the stamp along stroke edge.

If we would consider typical approach during drawing in PS with increasing spacing and introducing randomized stamp radius for eg. :
image

Here a file that works on the 2 examples you gave, it also works with jittered values
Just for testing, it is a C#, the n is just useful for me to test and debug or make animation.
outline of curves LD.gh (229.2 KB)


On first sight this is elementary with C# (see attached). But truth is that it requires a totally different approach in order to work in any situation: because the classic R Methods … work when they work.

Curve_Boolean_EntryLevel_V1.gh (126.7 KB)

Well, it seems to work however cluster is locked so it’s not much educational.

@PeterFotiadis Sure your aproach is straight forward and would work in case of planar projection to object, but as i said earlier:

As I said earlier: it’s just the V1 version (BTW: I assume that you speak C# is this the case ? BTW: The general case of this is using any 3D Mesh/Brep collection “along” any 3D curve [ but it would be VERY slow even via // ] ). But R/GH are not the apps for “3d brush painting” (Modo and the likes).

Aren’t all the brush/shape already all oriented in the same way?
Like… counterclockwise to the normal of the original mesh?

If yes, a very direct method could be implemented, as orientation is revealing the inside and outside of the curve, even if no mesh is provided…

Yes i “speak” C#. Well, in general, yes the easiest way i just to intersect sphere with any shape but it has advantages and disadvantages as you said.

To be honest i don’t see any contraindications to do such thing i use gh just for rapid idea prototyping :slight_smile: Besides we do not try to do 3d shape painting but outlining of brush strokes in 3d :slight_smile:

Did some tests dealing wiith the general case: It’s so slow that is not worthy posting it at all (even when converting Breps to Meshes [obviously the way to go to gain some millions of milliseconds] doesn’t cut the mustard).

@PeterFotiadis How about iterative mesh triming using sphere then casting to nearest fiting plane of contour line of cutted mesh and checking for point inclusion on a given plane to decide which parts of contour has to be joined ?

Maybe then instead of sphere i could use extruded closed curve for various shapes ? :thinking:

*ofc in case of sphere i mean simplified mesh shpere lets say up to 32 sides but i dont know actualy if this have any impact on computation under this conditions

Hello for sure it is not educational not to have the source, like changing the rules during the “contest”.


I prefer to post quite good algotihm. So I tested it a bit, the main challenge is when projected curves are not closed.
outline of Curves Legacy.gh (429.3 KB)

1 Like

Hmm? I changed only once the first set of curves since it was inaccurate and allowed oversimplification. Besides, i didn’t know that you guys will go such deep in it so we just clarified from where comes the data. The target remains the same just to create an outline of a set of curves fitted to initial mesh - another thing is that we also discuss which way of creating those will be most suitable/performant.

Obviously you should do that in order to check (for each step) the result … and if there’s none (or some failure) just skip that position.

But this can’t solve the puzzle (general case: 3D, lots of positions [i.e. big N]) in a way that justifies my Numero Uno rule in parametric: real-time response … othewise go do something else.

BTW: Other than that for the case that you posted you should use a nullable TTree for the t ccx values … because you assume that each Curve has ccx events with the previous/next … but the general case is that MAY be “gaps” in the collection (i.e. no ccx events). Then for each segment in the spliitted segments collection (From a Curve that corresponds to a non null double collection in the TTree), set the Domain (0,1), get a test point at 0.5 and test for inclusion (PointContainment) against a flat previous/next curve etc etc.

This is a “similar” Method with the above way of thinking :

But in your case you should test against the previous/next Curve or the previous or the next depending on the position of a given Curve in the collection (with gaps, that is OR stuff that does not intersect). Spot that this approach cares little about the orientation(s) or anything similar.

So the first thing that you should do is a FIRST pass that does the nullable Tree … and the rest are rather easy:

I have to admit that your approach is well thought :clap:

That’s the reason why i also consider using initially a sphere - it will allow some randomization but without custom shape and what’s more important it will allow solving problems on not curved shapes. Since there wont be projection but intersection which usually create closed crv if not you will be able to use shortest path drawing rest of curve from sphere wires.

@PeterFotiadis Sure i’ll investigate - overall topic is very big and solving all possible cases probably would be enough for few whitepapers about it.

@laurent_delrieu I tip my hat to your solution. Tested with mesh spheres 6/8/12/16 UV. Needed to lower bit tolerance but that not an issue at all. Curve.Contains in API is slow and custom implementation of point in polygon will help here a lot - iirc MeshRay will be even quicker for that.

Uniform radius:

Randomized radius:

Not that big - at least with regard the initial CCX OutLoop puzzle of yours. Get the general case (non planar closed curves with no self ccx events): gaps + random order [meaning in plain English: ccx clustering]. Ccx events are computed with respect the ActiveDoc tol.

The first C# does a proper FisherYates chaos (but that doesn’t bother the clustering) … then the other does the job.

Curve_CCX_OutLoop_EntryLevel_V1.gh (297.4 KB)

Added a simple case in order to get the gist of what’s happening:

And your stuff with some items removed in order to make it a bit more challenging:

1 Like

Meanwhile, i was exploring texture painting :rofl:

I cannot reproduce unwrapped mesh it is always somewhat folded along some edge… @clement did you find any remedy for this since our last talk?

Hi @D-W, i am not sure if i can follow here. Is the problem the quality of the build in unwrapper ?

btw. i never finished my texture painting tool because there was no way to use a RDK MemoryBitmap which can be updated in realtime with python.

_
c.

Moved to other topic.