Hi
(Bug)
When we execute the QuadRemesh command, the settings for the output are different
Same settings but different output
When you run the zremesher command in zbrush, you get the same output, but the quadremesh command offers different outputs.
@mehran09197306634me It appears you are using an older version of the v7 WIP. Please update and let me know if you’re still having issues.
Thanks
The problem was solved
Since there were a couple of updates and a new showcase video was released I updated my WIP and repeated the same goofy test as 2,5 months ago. I hope that this problem wasn’t overlooked because it is still not working.
@Czaja it’s not an overlooked problem at all, simply a current limitation of the remeshing algorithm. The algorithm is constantly being improved and getting better and better. A very hard situation to automatically solve is the pointy edges with angles over 35 degrees, which is your example. You’ll find that as you decrease the corner point the meshing is solved more correctly. As we work to improve the “sharp pointy things” this edge case should resolve itself.
Thanks, it’s good to know what causes situations like that. I appreciate your work. Best luck with it!
Why the algorithm produces unsymmetrical results from completely symmetrical loft surface? I know I can force symmetry, but when dealing with complex unsymmetrical polysurfaces it is impossible and it looks for me like the problem is more at the “core” of how it works.
Why since it is a loft made from two identical curves, and every vertical isocurve has the same shape as the edge, Quads near edges are different shape?
The same bending in the center of the quad grid is visible on your video and I wonder why it happens. (pause at 3:59)
Hey Travis, we use Rhino for modelling geometries which are then moved into simulation software - this often means we work with tetrahedrons, pyramids, wedges and hexahedron elements in meshes but Rhino can be used to generate a number of geometries and we even have a script for doing so. Unfortunately, all mesh faces must be planar for any FEM/DEM simulation software - the quad remesh tool is an awesome feature addition to Rhino, but I can’t seem to find a way to restrict the generation to planar quads. Is there any way of doing this or do I have to post-process meshes with Rhino common? Could this be implemented in the feature as an option?
@jouni.valli You would need to continue post processing your meshes. I don’t see a planar option making it to v7.
Alright cheers - if you can drop it into the bottomless wish-list bucket, I’d be much obliged!
It’s pretty straightforward to planarise the faces of a quad mesh using the Kangaroo solver in Grasshopper (within reason). Which are both part of vanilla Rhino 6. See the Planar_Quads.gh example here:
Brilliant thanks, I’ll have to test it out!
Just to add a word of caution to this-
While Kangaroo can adjust quad meshes by moving the vertices slightly to make the faces planar, this is only possible when the initial mesh meets quite a high standard for regularity and curvature alignment.
The usual application so far has been for architectural panelizations, where typically the surface is smooth, and there are only a very small number of irregular vertices (and even then, it’s also often still necessary to not keep the boundary vertices fixed to allow the mesh to slide around to better align with the curvature).
From what I’ve tested so far, the output of the quad mesher does not reach the required level of curvature alignment on many meshes, and trying to make the faces absolutely planar is likely to lead to frustration.
If quads are oriented diagonally to the principal curvature directions (think of a diagrid on a cylinder), then it’s just geometrically impossible to make them planar through any amount of nudging vertices without changing the topology. While the QuadRemesher does produce meshes which are mostly fairly well curvature aligned, for complex surfaces it seems they often still deviate enough around the irregular vertices to make absolute planarity impossible.
I was wondering why I was having difficulty getting them planarised easily - this explains a lot, thanks.
Hi
I did some tests and found that when the preview is active with complicated objects if you change from “Target Quad Count” to “Target Edge Lenght” it takes long time to calculate an unnecessarily dense object.
Has anyone encountered the same problem ??
Is it possible to change the default value in the “Target Edge Length” option? I think it is better to leave it empty or with a much bigger value.
Try adding a little thickness to the surface then remesh. Afterwards, select and delete the additional faces. The small holes are going to try to be looped as open edges. This in combination with your edge length size mean that loops can’t be created since the edge length is as long as the hole. All of this together means you end up with unwanted noise.
So for this case having some additional face data from some extrusion surfaces helps the algorithm understand how these holes work and how to better preserve them.
srf to test remeshed.3dm (1.0 MB)Adding thicknes is a general advise or this case only?
