Python: longer version of Rhino.Geometry.CreatePatch expected IEnumerable[GeometryBase], got list?

There are three CreatePatch commands in Rhinocommon:

http://4.rhino3d.com/5/rhinocommon/?topic=html/Overload_Rhino_Geome...

Two of them work normally but the pro version with full control won't take the same list of curves as the others?! The starting surface works fine too with the version that only takes a starting surface instead of the full list of options, so really it's the Curves input that is saying my list isn't an IEnumerable. Not a common error as far as Google lets on.

Printing Curves gives:

[<Rhino.Geometry.NurbsCurve object at 0x00000000000007E0 [Rhino.Geometry.NurbsCurve]>, <Rhino.Geometry.NurbsCurve object at 0x00000000000007E1 [Rhino.Geometry.NurbsCurve]>]

Replies to This Discussion

Permalink Reply by Nik Willmore on February 25, 2016 at 10:49pm

Here djordje mentions it, actually, this specific problem:

http://discourse.mcneel.com/t/issue-with-ienumerable-geometrybase/7...

"An Overload CreatePatch()1 list shows three methods. There stands that all of them require IEnumerable(GeometryBase) as their first parameter. But somehow the first and the second one accept regular python lists too. Only the third3 one requires a .NET list, which I did after Menno's advice.
The only thing that confuses me now is this inconsistency - when IEnumerable required: why is it sometimes ok to only pass a regular python list, while some other time you need to pass a .NET one?

I think Mitch was talking about that too."

Permalink Reply by peter fotiadis on February 25, 2016 at 11:19pm

Have some "fun" with this (obviously not P ... but you can attempt to translate it).

Attachments:

patch_V1.gh, 130 KB
patch_V1.3dm, 93 KB

Permalink Reply by Nik Willmore on February 26, 2016 at 12:47am

Indeed helpful:

bool[] fixedges = {false,false,false,false};

Brep membrSP = Brep.CreatePatch // SP means Second Patch, got it?
(MCList, // list of geo to attempt the patch (may the Force ... etc etc)
membrFP.Faces[0], // start/quide surface: going from DC to NY via LA
uSpans, // obvious
vSpans, // obvious
true, // trim outer loop. Fails in most of cases. NOTE: inner loops ARE NOT treated
false, // tangency
1.0, // point spacing
patchFlexibility, // flexibility: use a generous value around 50
surfPullFactor, // surface pull factor (this needs some investigation)
fixedges, // get 4 false values you stupid method, like that?
0.2); // tolerance - be generous: we are talking about tissues here not NASA sourced things

Do you know of a generic container in Rhincommon I can store geometry form meshes, breps and curves to points? That's what I seem to need to get around the IEnumerable error.

I have to figure out how to format the Boolean array in Python. Ah, parenthesis worked!

P = Rhino.Geometry.Brep.CreatePatch(CURVES_CONTAINER, Starting_Surface[0], 10, 10, True, False, 10, 30, 0, (False, False, False, False), 1)

At long last, only to find out it won't work right, as in no setting of flexibility will affect it at all?!

Tolerance has a sudden crazy effect if I turn it way up, like a piece of paper bending up opposite corners and it no long is trimmed, but flexibility is dead. I used your same values and same curves for everything. Yes, all the curves are participating, if I bake them and move them around.

My Patch is broken. Weird. Is there magic with the starting surface? I made a naive assumption just a plane would do. Yet you seem to be using your simple CreatePatch results for this?

Ah, the second CreatePatch command type that takes only a surface gives the same thing, nearly. You need a starting surface at all?! They said you could now leave that out as of Rhino SR10 by using Null, but Null or Nothing gives an error. How do I make a null? In Python it's None, as in just entering None into the Rhinocommon command or assigning a variable to None.

Now I have a patch!

But your's is more expressive, more crazy, like your starting surface is greatly influencing it to have extremely extended feet, whereas mine works like a normal patch, as if you were trying to smooth over things. And indeed your surface pull slider makes it more obvious you chose a specific starting surface attached to one of the curves. My starting planes had no such effect, earlier.

With such a starting surface to bias the results I get the same thing finally, indeed, good to know what that does, I never knew from using the command in Rhino.

Why did my use of a plane shut this down so badly though?! Crazy command.

I've enclose a working script for the record.

Attachments:

CreatePatch FAILURE QUESTION.gh, 227 KB

Permalink Reply by peter fotiadis on February 26, 2016 at 12:57am

Well ...

1. Coding is 99% about informing you about what's wrong and 1% about doing things. This is the main reason that I'm not so heavily involved with Bentley Systems these days > they never listen, he he > meaning that they deliver a (stunning if things are going well) product that when it fails in some method it reports: "unable to do it".

2. NEVER take the short route when coding: try to "report" anything that's happening; it's a bit boring but you'll see the actual reason when later you'll do real-life complex things.

More patch freaky stuff soon (but given the opportunity: where's my goats? nothing arrived insofar).

May the Force (the pink option) be with you (I'll take the black option).

Permalink Reply by Nik Willmore on February 26, 2016 at 1:24am

Might have taken me hours simply not knowing that a starting surface could so vastly influence the outcome. The way a starting surface can raise hills by pulling on the background may be useful to my curve loop puffing system. I only turned to coding to try parallel processing, but this is another huge advantage in having more control.

Permalink Reply by peter fotiadis on February 26, 2016 at 3:52am

// is the next big thing (although tricky in most real-life cases) but power is nothing without control.

Permalink Reply by Nik Willmore on February 26, 2016 at 6:18am

The strangeness with my earlier starting surfaces that ruined the command was that they needed to be rebuilt to have more UV spans. If you make a simple PlanarCrv surface from a closed curve, you can see in my bottom post image there is only one isocurve showing in U and V.

In Grasshopper there's no surface rebuild? Well, the same old Grasshopper Patch command will let you specify spans I guess, to make a surface from a planar curve, but it won't work for things with holes since they will just fill in!

You can recreate a surface painfully by untrimming, adding many UV points, rebuilding from those points, then retrimming with the original surface info, but the retrimming simply fails.

If you make a planar surface from a curve in Rhino, you end up with utterly no point editability:

No wonder my CreatePatch tests were a failure. The starting surface could not be distorted except in the extreme case of moving four corner points!

I have no idea how to successfully rebuild a surface akin to the Rhino rebuild command. It's great to be able to prototype in Grasshopper, but with Python I can rebuild easily ( http://4.rhino3d.com/5/rhinocommon/?topic=html/M_Rhino_Geometry_Sur...;), so I guess I should start a collection, like peter, of little script components for prototyping with.

Permalink Reply by peter fotiadis on February 26, 2016 at 7:01am

In Grasshopper there's no surface rebuild?

Answers to: The Lord, District 9, North Pole, Planet Zorg

(Notify if you need a detailed span report)

Attachments:

surf_rebuild_transpose_blahblah.gh, 18 KB

Permalink Reply by Nik Willmore on February 26, 2016 at 8:37am

Gee thanks, for untrimming my valuable surface!

I'm starting to understand that Rhinocommon is indeed the deep core of Rhino but that the actually useful commands like Rebuild that do all the high level bookkeeping (and re-trimming) are *not* in Rhinocommon exactly because that's their low level internal stuff that McNeel won't add sophisticated stuff BACK into, or it would all become circular in hierarchy.

For a time they pushed Rhinoscript onto the masses, like their nanny state poor man's version of programming, but that alone held me back by sheer confusion with Rhinocommon for many months. Now I think, how would I, as a thinking, confused human being, KNOW if the obscure bugs I deal with are not just some Rhinoscript hidden crap?

I think Rhinocommon should be inclusive of all normal Rhino commands but that's extra work for McNeel that doesn't benefit them as programmers, so we have to re-invent the wheel and try to figure out how to save then re-invoke trims on surfaces that are really breps, since surfaces are just distorted rectangles.

Did Bill Gates add high level Basic language functions back into assembly language? No. Steve Jobs kinda did though. Kept trying to do that.

Permalink Reply by peter fotiadis on February 26, 2016 at 9:08am

My dear Watson:

Rebuild Surface and rebuild a SheetBody (i.e. a Surface + trimming info = a Brep with one BrepFace)are totally different sorts of tasks.

Since a trimmed thingy is derived from an untrimmed thingy > do whatever Surface opp (rebuild, transpose etc etc) is required prior and not after; in the sense that you first check your tires and then you ride the bike (don't attempt the opposite).

Of course there's this way available as well :

Permalink Reply by peter fotiadis on February 26, 2016 at 12:15pm

Here it comes: the ultimate challenge for real men:

We have a closed Brep, a BrepFace, a Surface and ... er ... hmm... a Curve (LOL).

We also have 4 ways to skin the cat: Rebuild (works), the 2 flips (hmm) and the swap (hmm): the challenge is ... well ... open the def and be the winner (1st Prize: the usual stuff; 2nd: null, nada, nothing, void).

he, he

Attachments: