This model seems to look correction wireframe mode, but if I render it or turn to shaded or technical, it has strange warping on the ends. Is it possible my model is fine I’d hate to send this off to be made and have it be wrong.
Your render mesh setting is probably too coarse.
Go into Options - Mesh and try Smooth & slower instead.
Then it will have more polygons to smooth out the eye-candy.
This is what has me nervous even the technical view looks weird. And when I render in penguin or flamingo it still looks weird. the only view that looks right is wireframe.
I’m afraid to trust it. Even though Polygons suck.
Try this:
Select object, explode, while surfaces are selected type rebuildedges and hit enter, and then join (still while selected).
The reason technincal mode looks bad is that it uses the rendermesh.
Also type selbad to check if any objects are bad.
If so, explode and retype selbad to find the surfaces. It’s a good idea to hide all objects that are not bad.
Some how you managed to make single surfaces with kinks or creases in them. We make it really hard to do that in Rhino (this is one of the reasons), but it’s not impossible.
That said, this is all “eye-candy” and has nothing to do with the accuracy of your model. It’s just geeky computer graphics stuff you shouldn’t normally have to think about.
Hi Will- you split up the single surfaces that had tangent but not curvature continuous spans at the tangent points, making a polysurface, split up at the tangent locations. Meshing likes this better, even though it is not supposed to.
Hi John, I agree that this is mainly eyecandy, and I hate to disagree with you… but:
1: Meshes are used for Rapid Prototyping… So NEVER make a STL file with out checking it. Actually letting the user make a STL with out a preview is not OK imho.
Technical display is used more and more in layouts. And could replace Make2D in lots of situations, but that requires that this is rock solid.
Users are used to visually inspect surfaces, and tools like Zebra and Environment are using meshes. This should be taken into consideration for future development of meshing.
hey Holo, splitting hairs here but,
Render meshes are different from exported stl meshes. (totally agree with your preview rule) It’s possible the error will be there as well, but what you see in display is not necessarily what you get with a mesh export. UNLESS you run “extractrendermesh” and export selected that mesh.
So it is possible to generate a “clean” mesh from this file even though it displays “bad” by use of judicious and careful stl export settings-
all of that said, in the end, if you see a janky mesh, you should investigate why and fix it.
Well said, and to nitpick even further:
Both tools use the same meshing engine (as far as I know), just different settings. So you will/can get similar errors on a smaller scale. (lots of experience on that)
Extra annoying if you make a metal 3D print with ugly fillets or distorted holes.
3D printing is now an important manufacturing tool, not just a visual test thing. So this needs lots of attention.
I’d just like to add the CAM plug-ins use meshes generated by Rhino as well. So I don’t get any nasty surprises I have my shaded view set to flat and use custom mesh setting.
I’ve still had problems like the one above but I’ve spotted it on the screen before I’ve generated any programs.
So I have an idea on how this might have happened. The only “strange thing” I did was take the entire piece and scale it in 1D by about a 1/4 inch in each direction. Could that have created this issue? Just trying to understand what I might have done to prevent it in the future.
Hi Will- any chance you have the original boxy object still around? And the input curves? If so, can you post them here? or send them to me via tech@mcneel.com.
Hmm maybe…thesis I recall from back a long time ago is this: the mesher uses the UV parameterization of surfaces to help make the mesh. That’s the “internal” coordinate system of a surface, corresponding to the rows and columns of control points. If you edit an object in any normal way, this “parameterization” does not actually change, and if the actual dimensions of the object get way out of whack with the parametrization, then errors in meshing can occur. The “Reparameterize” command helps these errors by trying to reset the U and V parameters to better fit the actual scale.
Sorry Pascal It looks like when I made the change that you suggested the file auto saved before I saved as something else, so I no longer have the offending file.