Surfacing... just a nightmare

Well, actually the hull is better to use Solidworks because Rhino is not capable and then passes that first surface to Rhino to built up all the rest.
@scottd In Rhino is missing a second-degree network tool!
And almost all this is made using rhino [link] but I’m struggling because I use second-degree surface in one direction. Grasshopper now covers up this gap.

Thanks,

I Do own a personal Orca3D license, still learning how to properly use it, and I am doing my final work for the university using OrcaCFD, again, still learning the do(s) and don’t(s) with it, and for sure I am getting ahead of myself asking these kind of questions that for sure will get me complicated answers.

Orca3D’s team does keep up with McNeel amazing support, it looks like there is never a bad time for you guys.

But I think I got ahead of myself, I will try to make a future post being more specific about this, it is kinda off topic for what this topic was first created.

So are you saying with Grasshopper you can get what you want? That is great. Good reason to use Grasshopper.

Normally I do not use network surface, too much fitting noise when fairing hulls. Just using direct surface manipulation works most of the time.

But a blanket statement about the marine industry is difficult. The discussion here is a great example. Many if the tools we use are now talking design requirements, fabrication method downstream partners, etc…

As you get out into new companies where you feel the workflow is complicated and too difficult knowing all these different methods can be super helpful.

Alan,
The problems associated with fair hull creation in Rhino are not trivial. I gave up with Rhino because of the difficulty of mouse clicking on planes at odd angles in 3D space. Thats where Grasshopper entered the picture

The other benefit of Grasshopper is that is a FULLY PARAMETRIC tool. Rhino interface is not.

But even better than that, in Grasshopper, every step from points to curves to surfaces to solid hulls is preserved for you to walk back through and rework at any point.

I struggled with a fair round bilge for months. I tried many approaches. Most of the suggestions you will find here are either simplistic, inadequate or require extensive fabrication time.

With GH, Rhino can turn out a hull that is better than any mouse clicked interface including Catia.

With respect to Orca3D, I was a little underwhelmed with this and just about every other software tool for boat design, evaluation and construction. These tools require extensive data entry, most of which you are trying to get FROM the software not put in to it.
The hull design tool is primitive and certainly doesnt to sophisticated round bilge hulls of constant radius. Its also pricey.

I strongly recommend RhinoHyd for Rhino 6. It does the Intact Stability analysis very nicely. Its simple and FREE
http://pingud.com/download/

I have tried all the tools I could find and I keep coming back to Grasshoper. You can bend it to do modeling, create very accurate weight and CG analysis, Structural analysis and plug ins that can calculate bending loads etc.

You cn do all this in GH AND have access to all the pts. curves and surfaces for other operations. Im no knocking this product, but olike maxsurf, you gotta learn the way it works, what its limitations are (and there are always some) and then you married to it. GH comes with Rhino. How can ya beat that!

Just about every tool I have looked at that tries to make a software program around these requirements has serious limitations. MaxSurf structural analysis simply works its way through a mesh calculating loads and bending as it goes using FEA, but it chokes at a full ship with structural detail of the beams and their joints, so its virtually useless. GH can do simplified modelling better and faster.

Frankly, I dont know why McNeel doesnt just retire the Rhino interface and offer a rebranded, parametric product around Grasshopper with Rhino providing the viewports for GH. GH is undoubtedly the jewel in the crown. If I had begun w GH I would have shaved years off the learning curve

I use “Network surface” in one of the following occasions:

  1. When I want to build some basic surface not possible with other Rhino tools, then I convert it via “Rebuild surface UV” and then apply “Match surface” with various options.
  2. When I want to build a surface with questionable quality just for fun. :slight_smile:
6 Likes

I fight with the rebuild uv command … its behavior drives me crazy … it turns all surfaces into degree 3 it’s the only downside .
networksurf is good for certain situations my best command are lofts and edgsurf , they inherit the topology of the curves
. in my opinion rhino is in urgent need of good surfacing improvement .

Yes, is exactly what I was trying to explain. Plus is very customizable for each particular client workflow.

@Rhino_Bulgaria Yes “Network” is almost not useful and this confuses new users.

Almost all my surfaces are built up in this way:

But in my way of doing this clean surface, if I move just one point, any, I need to update all the other surfaces. That means the hole model including trim and connected surfaces. And that is a nightmare for me. @scottd Grasshopper is part of the solution but is very very slow because I need a lot of connected surfaces to update. And so is not viable.
That is the reason why I’m asking for a Grasshopper compiler so that it runs faster (all the model on stack and the heap) and pushing for a SubD of second-degree that is missing, important to cut time.

To fix nightmare THIS IS MY WISH SINCE 90s LINK <---------------------<<< [¡¡¡ WISH FEEDBACK!!!]

Define “a lot”?

1 Like

One complete wheel rim poly-surface.
I was not going more complex than this because was getting slower: https://forum.unity.com/threads/wip-gogo-tires.783767/
But if I do a Ferrari wheel I probably divide it in independent Grasshopper graphs. Because as a designer, you move a lot of points searching for the volume that actually works in all views. Probably what is missing in Grasshopper is a sort of cash optimization, that extrapolate just the data that will be updated, putting it into an inline array with better memory management and making just the job modification of only that data needed (that is not much) in sequence instead of prepossessing the hole object containing sub nested objects full of variables that essentially you will not change. I ask Unity that, like many others, and Unity thankfully came out with this: link example

@DavidRutten [Sci-Fi idea] Now I’m wondering, since the mouse is now connected directly to the GPU, bypassing the CPU; If instead of a traditional C, a shader graph is use instead to make the red Grasshopper surface mesh,… I mean using shader language to build the mesh directly. You bake the final surface just one only when you press the button as you do now. But you can update more complex models by working actually only on the GPU mesh bypassing compliantly the CPU. In other words building the red mesh inside the GPU via shader. And using the CPU to make the surface when you bake.

Are you proposing we convert our multi-thousand line NURBS mesher, which relies on hundreds of other methods, from C++ into GLSL?

I think he is, and I think you are on the verge of rejecting it out of hand as “too much work”. I think Alan has a very interesting idea with what sounds on the surface of it as having a lot of potential. I think it would be useful if you (and the rest of the team) adjusted your attitude to “probably a lot of work” and started giving it some serious thought and consideration. After all, the “multi-thousand line NURBS mesher” probably took a lot of work. So did the conversion from ACIS and the Mac port. They turned out to be worth it. Perhaps after some serious consideration it will turn out that it’s not a great idea or doesn’t make any sense at all but at least we’ll know why.

Or maybe Alan and I just don’t know enough about the subject to understand why it’s a silly suggestion. I know I’d like to be enlightened if that’s the case.

Oh I’ll let @stevebaer reject it out of hand for me. I don’t even know if it’s possible in a shader language to create a functionally equivalent mesher. You’d have to basically convert a huge chunk of Rhino core code from C++ into GLSL. That’s a very different thing than switching to a different OS but still using (roughly) the same language.

What might be possible is creating a much, much simpler meshing algorithm. However since I won’t be the one doing that I really don’t want to be the one saying it can or can’t be done.

OK. Understandable. It’ll be interesting to hear what Steve has to say, should he choose to respond.

The only reason to have computation code run on the GPU is to take advantage of the large number of processors available. These processors aren’t faster than the CPU, there just happen to be a lot of them.

Moving code to work on a GPU isn’t the issue, it’s about rewriting code with entirely different concepts to take advantage of multiple processors when it makes sense to improve performance.

1 Like

Yes! old and new running in parallel together. One (red mesh in shader language {meshlets mesh shader??}) in real-time with low precision for visualization only, other (Grashopper → C++) for double-checking and baking
To resume, I know about shaders but not how to use the tensor core side other than configure and use it for training them. There is also some lag between pasing info from the CPU and the GPU. GPU is slow but now or soon you got the pointer directly connected by passing the CPU. For few points can work well (I presume). In game dev we make mashes on the fly in GPU.

Having 9 surfaces connected together as shown in the screenshot above sharing a total of 49 points. At the moment there is too much (Rhino-Grasshopper) code around, and take time to update just that simple mesh.
Putting aside on the complex part of logic on how to maintain them in tangent when moving one point.
I think that several orders of magnitude improvement can be achieved. Moving 1 point and updating must take a few ms and not seconds. I agree is not for Grasshopper 2.
A Concept Scripting can be handy to sniff if possible and learn.
A 9 point input Shader that calculates inside Nurbs equation surface and build the red mesh. Just to test.
I know I can do that in Unity and ship compatible with different OS and I try that before

That is the reason I also ask shifting to Unity somehow. Now that Unity and Rhino can talk(via scripting). A concept is possible.

I misunderstood what you were asking. Yes it is possible to color pixels on the screen with raw polysurface data and GPU shaders. I would say possible, but also very hard to implement (and make work on the majority of graphics cards out there).

I’m sure there are a number of research projects that attempt to draw shaded polysurfaces entirely through GPU shaders. I know some applications use tessellation shaders to draw SubDs which is a significantly simpler thing to do. We use tessellation shaders to draw curves and have found them to work great for 90% of our Windows users (they don’t work well on Mac). Just drawing curves in a shader is complicated and required a lot of time to handle weird driver issues. Handling trims on a polysurface would be so much more complicated. We don’t have plans to do this, but if someone else implemented this in a plug-in I would love to see it work and would consider figuring out a way to integrate it with core Rhino.

1 Like

I don’t believe that video is what I was trying to explain.

2 Likes

3 posts were split to a new topic: GPU Calculation Support