Is there a verbose flag that can be set for Rhino processes?

So I’m trying to run MeshToNURBS on a complicated mesh model and it’s a silent process - I have no idea if it’s hanging, working or just about to crash. It’d be really helpful if there was some kind of output in the command bar (or a progress bar) that’d give some indication that process is still alive. Even if it’s a case of including a timer for the process duration that counts up, just as long as it gives some kind of indication that I’m not waiting around for something that’s not going to happen.

Is there such a thing already, be it a launch flag or something concealed deep in the settings?


As long as Rhino hasn’t crashed, it’s still working away, generally speaking. How is the code supposed to know it’s about to crash?

The more important question is what the heck are you doing using “MeshtoNURB?” It’s not something you should be routinely using on “complicated meshes,” it’s only useful purpose is to test how much RAM you can make a model use up before it crashes.

I’m not expecting the code to know when it’s about to crash, I was asking if there was some kind of indicator that it’s stilll crunching away.

I work in an industry that has a lot of mesh models come our way, and I need to integrate them with Rhino desgins that we work with here. This is just one instance of this ‘silently working’ problem - I’ve had Make2D grind to a halt without result several times, too. All I’m looking for is some kind of periodic message to indicate that it’s still alive, even if it’s just a string that says “working…” and has a timestmp next to it.

As for the MeshToNURBS thing, I wanted to see if there was an easier way of converting meshes into a surface that SprutCAM will talk to rationally. Meshes are a pain in the neck to work with when you need to reorient a robot tooltip multiple times across several toolpaths. If it’s just a memory testing tool, what’s it doing on a consumer release?

Make2D has a progress bar, and 98 times out of 100, if Rhino hasn’t crashed, it hasn’t crashed. And adding what you want is not as simple as you think, like how much do you want your commands to be slowed down because they have to pause to check to see how long they’ve been running? It seems trivial, but it’s not.

Because no matter how useless it is someone will complain if anything gets removed.

You’re talking reverse engineering here. Meshes are just not easy to convert back to surfaces. MeshToNurb on high poly count meshes is also next to useless if it actually succeeds - it is likely that the receiving program will not be able to handle a surface model with millions of individual surfaces anyway. If MeshToNurb takes more than a minute or two to complete, the resulting polysurface will probably choke most programs anyway.

MeshToNurb is useful under certain limited circumstances, and thus has a reason to exist.

1 Like

I’m aware that it’s not an ideal utilisation. I had already decimated the poly model and run it through quad remesh to try and minimise the workload involved. Reverse engineering is obviously a whole new depth of things to get into, and I figured that actually getting in and testing the idea with the tools I had was better than idly asking about it - empiricism and all that.

For the record, it did work, although it took quite some time. It also generated a surface model that SprutCAM was happy to work with, and I could even read a normal orientation off it to align the robot spindle to, which was the core premise of this entire exercise.

To go back to my original question, it would be nice to have some indicator of continued function. Not essential for everyone, but nice. I’m glad that you’ve apparently never had Rhino lock up on you @JimCarruthers but it’s been something of a problem for me here, in this and other associated applications. I’m aware of the fact that including a ‘heartbeat’ output consumes computational overheads - I have done some programming work, and I am well aware that everything comes at a cost.

Maybe you could convert it to Sub-D via QuadRemesh and then use ToNurbs on the Sub-D to make surfaces…?

1 Like

That’s the process I ended up following. I ended up with ~63k NURB faces instead of >200k polys. It’s a ridiculous number of faces to work with, but it does mean that I can do a lot more with the model when machining it.

I’m going to keep looking to see if there’s some kind of semi-automated tool I can include into my workflow: this is obviously giving Rhino a painfully hard time.

Hi -

The simple answer is to check the task manager and look at the Rhino process.

1 Like