QuadMesh prototype command available in latest WIP


#81

Ah… I thought that was probably the reason. I am assuming that this thread is to do with updating it to v5 and presumably v6.


#82

Would this work for planar or piecewise planar surfaces?


(Nathan 'jesterKing' Letwory) #83

No, this is specifically a new command in Rhino WIP. That’s also why it is here in the Serengeti forum :slight_smile:

/Nathan


#84

Ah… I came here through Google and didn’t know what I was getting myself into… :slight_smile:

Thanks for the explanation…


(Nathan 'jesterKing' Letwory) #85

No problem, give the Rhino WIP a go when you have time for it :slight_smile:

/Nathan


#86

Stumbled across this pdf while searching for some mesh stuff and thought it could be an interesting read for you in case you haven’t seen it before.

http://www.cad.zju.edu.cn/home/zhangmuyang/projects/quadmesh_2010/Huang10WaveQuad.pdf


#87

I really hope QuadMeshing gets the love it needs and I would love to see it fused with reduce mesh.

I see that it still doesn’t respond to ESC and neither gives any feedback on the progress.

Another good read is here:


(David Eränen) #89

I hear you Holo. Currently there are other, more urgent priorities.

I’m hoping to be able to go back to working on this as some point, but no promises if or when! Keep making noise if you think quad meshing is important to your workflow.

Holo: The Blosson-Quad paper you linked - would that kind of quad mesh output be useful to you? I think it looks rather messy.


#90

Thanks for the feedback and good luck on solving the tasks at hand.

To answer your question:
I prefer rather messy over none any day.
But I prefer a tidy and optimized Zbrush-quality over messy… but it took those guys many years to master the art, so I don’t think we need to be quite there yet. That’s where the SR’s come in to play IMO.


Rhino5 vs Moi
#94

Curious to know if this has progressed any further ? I believe quad meshing is an invaluable asset to mesh export workflow. Escecially for anyone interested in exporting for game engine assets.

My main workflow, reconstructing archaeological shipwrecks, typically involves either 3D laser scanning or touch probe digitising to record and document the many individual ship timbers.

Once documented I then typically reconstruct the ship using Rhinoceros for the modelling process, and a naval architecture plugin called Orca 3D for analyzing the weight, center of gravity and flotation capabilities of the reconstructed ship.

Over the last two years I have been experimenting with Unity as a method to display and make available to the public the invaluable three dimensional data that is generated during these ship reconstructions, rather than reverting back to the more traditional 2 dimensional paper plans and drawings. I have had some success with creating xbox controller type walk around the ship “game” or visualizations, as well as some unity/vuforia augmented reality 3D models and some Gear VR simulations.

However the data size using standard Rhino exported poly mesh is a serious limitation.
Therefore it is essential to create a low poly retopo version of the model for use in the game engine.
A shame as the nurb model is the ultimate small file size representation of the gigabytes of 3d scanned data, but unfortunately game engines do not utilise Nurbs models.
Generating the low poly asset currently involves creating a quad based mesh which is uv unwrapped before having textures and the fine detail from the high res version normal mapped.

The current mesh workflow from rhino is totally incompatible with these (Zbrush 3DCoat) packages, and means another low poly retopo’d version of the model has to be created.

I have created a few prototype quad meshes and even in there current state would represent a significant time saving.
Here’s hoping Quadmesh makes it further than just a prototype idea as the only solution currently is to recreate the model in external software.

Pat


(David Eränen) #96

Hello pattanner,

There hasn’t been any work on this for a long while, unfortunately. It’s a big project, and still needed a lot of time to become usable. I may or may not get back to this in the future. I understand that this kind of functionality would be useful to many people so as long as people keep requesting it here then there is hope :slight_smile:

-David


#97

Hi David,
Thanks for the rapid response, but as @Holo said above, even a messy version of this is better than none.
It would be a crime to see this dropped from the next version.
Many of the other projects under discussion for the WIP, such as physics based, animations, walkthrough / flythrough, not to mention rendering, these are all trying to re-invent the wheel, when Free to use game engines are already doing these things more than adequately.
Having had reason to use game engines, and export file formats suitable for other 3D artistic packages, Zbrush, 3D Coat, and even 3DS Max, all the time the artists complain about the “crazy” mesh layout exported from Rhino.

A decent (or even half decent) quad mesh layout, with nice continuous edge loop flow, would make this a much more painless process, and open the whole world of game engine asset modelling to Rhino.
Pat


#98

It really isn’t. It’s actually dead simple to bring any Rhino model to Zbrush and to quad-remesh it here. One can also use 3DCoat and get good results too, but it’s Quad-Remesher is slower and more difficult to use.


#99

Hello hifred,
I agree it is relatively simple to export a standard rhino mesh in obj format, and retopo with 3D Coat(in my case) or ZBrush, however this workflow is counter-intuitive, and time wasting for me. I generally work with huge poly 3D scan data, which i resurface using NURBs in Rhino, many times, the overall model can contain several hundred or even thousands of parts. The mesh created by Rhino does not have any edge flow, almost always requiring a full retopo in 3D Coat.
Having to retopo every part, when I already have a nice simplified, small file size in Rhino seems like a lot of extra work.
Ideally the game engines would use the lightweight NURBs models, but in the meantime I currently need to rework every models component parts.
I was searching for a workflow to try and reduce or remove this second re-modelling step.
Something similar to the “min+1 mesh” in the screenshot below, but this is not possible with more complex geometry.


#100

I understand that you would like to see Rhino create Quad render-meshes in the background while you resurface your scan meshes. Or at least quickly, as soon as you export to obj. This is realistically not going to happen.

Even if the Quad-Mesher got a lot of love it still would remain a very time consuming post process.Third party apps such as Zbrush offer a High performance solution for this task. They are already available and they can deal well with meshes exported from Rhino.

I would further imagine that you need a option to bake your Highres Detail onto the Lowres mesh. It’s again something one can’t do inside Rhino.

Btw. Nurbs surfaces, which are displayed shaded or textured always require an additional mesh: What you
see in the Rhino viewport is its render-mesh, not surface data. Hence it makes sense for Game engines not to
work with Nurbs surfaces. They are pretty useless for display purposes…


#101

Yes, it is not possible to display the full high res scan mesh in a game engine, too many poly’s bogging down the display, therefore I bake detailed textures onto a low res retopo mesh, as we want to retain surface texture and detailing in the game engine display model. The problem I have is when you export something like the far right model, 3 simple cubes, with a Boolean add and Boolean subtract, it should ideally be possible to export that as a 32 quad mesh, or even a 64 tri mesh at its lowest detail level. All faces are planar and aligned. However Rhino’s simplest mesh export is still using 304 triangles of seemingly bizarre (in human terms) layout. The simple cube far left exports perfectly with 8 poly’s, and even the sphere mesh is ideal, but anything even slightly more complex becomes a dis-organised mesh requiring manual intervention.
This is my ideal world wish list scenario, maybe not achievable, but I would have thought that if the mesh layout could be fine-tuned, it would bring huge benefits, not only for game engine optimized models but it should also greatly reduce the complexity of the built-in render mesh which Rhino uses for display, thereby improving performance and reducing overall file size.


#102

You are correct that the mesher could be smarter with very simple geometry. V6 comes with
Ngons – that does clean up the mesh visually, but under the hood there’s still triangles going on.
Not useful for a subdivision based workflow downstream.

But the mesher actually gives a lot more control when using its detailed options. Those booleaned
boxes examples you posted can get meshed with only quads with the right combination of mesher
settings (here it was enough to set everything to 0) and possibly some manual cleanup (Merge2MeshFaces).

But one can’t turn complex models with a lot of trims to All Quads using this method.
Zbrush currently is the most effective option for this task.


#103

Cheers hifred,
That’s pretty much the same conclusion I had gotten to.
Was just hopeful that some miracle cure might be found :slight_smile:


#104

Is this currently planned to be in V6? For me, this feature this would be the single biggest reason to upgrade the entire office here to V6.


#105

Unfortunately V6 is not having it: