When I create a surface by selecting 3 border curves, uMake will create a planar surface if the curves are planar. It will create a non-planar or boundary surface otherwise.
While this may seem like an obvious optimization, It’s not always what I want. At the very least, it’s an ambiguous case.
When I import IGES files into Houdini, for example, it doesn’t understand planar surfaces. I want to create a model purely of boundary surfaces to avoid this issue. And also, it helps me control polygon flow, later on in my process.
But uMake creates planar surfaces when curves happen to be planar. My workaround, is to note which surfaces don’t import, and then go back, and pull a CV slightly out of plane in a curve, before recreating the surface. Which kinda sucks.
Ideally, I’d be able to create whichever surface type I prefer, when there is ambiguity. Ideally I’d be able to see which surfaces are of which type, for when I need to check my model. Ideally I’d be able to convert surfaces from type to type where applicable.
As for the issue itself… it’s interesting because when you create a planer surface, it is flat (mathematically), so it should work most time for most users. Giving the option to choose if it’s a 2D/3D surface is possible but would make the creation process slower in my opinion.
Attached find a screenshot of an import of a uMake IGES file into Houdini. Note the missing patches on the bottom of the heel (it’s a shoe.). You can see the curves that were used to create the patches, as they did import.
Those specific patches happen to be planar. And Houdini doesn’t import planar patches. At least not the way uMake is exporting them.
R.e. boundary patches vs planar: A boundary patch is guaranteed to have proper iso-parms at its boundary. Which allows me to automatically reconstruct the patch model with good quad topology as long as I keep well disciplined about what types of surfaces I’m making. The problem right now, is that I can’t excercise that discipline, because the software insists on taking the choice away from me.
Kind of. Yes, I can go through the process of manually creating a trimmed grid surface: separating out the intended curves, projecting the imported curves onto and aligned surface, and then trimming. But no, I can’t do it automatically because the Houdini importer leaves no trace of the original surface. I can’t procedurally identify which curves represent a failed planar import.
I don’t have many other IGES consuming/generating applications with which to test what exactly is happening. It’s not clear to me whether Houdini can import planar surfaces, but not from uMake, or not.
I tried that the other day. I get some artifacts of some kind of higher level surface that Houdini doesn’t fully support it seems. I get a point cloud of a grid of points that seem to follow the hull of the intended surface. I get a flat boundary surface off in space that I assume is probably meant to project to those points. I get the original curves. That’s about it.
I didn’t inspect much further because I’m used to working exclusively with 3 and 4 sided boundary surfaces as a workflow restriction.
Normally I would never expect a 5 sided patch to function well in a NURBS patch modeling environment and I’d add a curve and split it into two patches.
Attached find a screenshot of an imported 5 sided 3d patch. Note: there’s only one surface in the original uMake file. I think I see three separate surfaces in this one. One surface is actually constructed from the original curves. The other surfaces appear to be projections or distortions to other spaces.
Taking another look, some of the point cloud might actually be very complex tangents or CVs for the intended surface.
Thanks for these. Yes, it seems Houdini isn’t handling more than 4-curve NURBS surface that easily, so restricting yourself to 3/4 sided patch seems logical.
As for now, I’ll add the option to choose the surface-type to our backlog, as we wouldn’t be able to solve it right away, it that might take some time.
I’m trying to think about other ways we can help you, maybe there’s a plugin to Houdini that can overcome these or maybe importing to Rhino and then exporting from there to Houdini might solve these type of issues somehow?