iirc rhino did not even have a persistent shaded viewport until v3 (could have been v2), you had to use the shade command whenever you wanted to see more than wireframe
AFAIK only one of the edges is modified
Please see the following compilation. I always thought it was important to understand the following reality once I first learned about it many years ago:
Unfortunately, it’s very difficult to get newusers to understand this, no matter how many times I reiterate it to them.
So, this is good now cause I’m focused on bringing this to attention, and may reference this in the future or create a new thread or find a current more appropriate thread if this one isn’t appropriate.
Why is it most newusers can’t get it through their head that " Whenever a NURBS surface is shaded or rendered, the surface first converts into a polygon mesh."?
I think it’s because most users don’t care about the details, cause they just want to be users.
Bear with me as I get to my main point.
As newbs(newusers) or rather ‘users’ that just want to be users and don’t care about the scientific details behind all of Rhino’s characteristics, these ‘users’ completely disregard ‘mesh properties’ and in most cases disregard file tolerance.
In fact, most of the time if not all of the time these ‘users’ will just use default settings everywhere.
Therefore, as these newbs go forward throughout their work, they will model and propagate errors through bad habits caused from this said ignorance.
As these particular users model they use what they ‘see’ and snap to those ‘edges’ and ‘vertices’.
Over time, they can end up with problematic models that will only join into a ‘closed’ manner under higher and higher ‘file tolerances’.
Hence, as ‘edges’ get pulled away from ‘original 3D surface edges’, these particular users will end up chasing their own tail per say. They will be fighting for ‘vertices’ to be ‘coincident’ – truly.
They wont even realize they’re relying on a so-called ‘render mesh’ to visualize where vertices are and edges are – without understanding they’re seeing a mesh and snapping to edges that aren’t ‘original’ or true.
Instead, they’re falling victim to chasing around these edges and vertices that are ever changing as they go forward changing their models and trying to succeed with compounding errors.
The more the tolerance, the more the ‘pulling away from original’, the more the compounding error over time.
Have you ever seen a newb try to make a model where there’s 4 or more surface vertices that need to be coincident to 0.0005" but they can’t do it? And one moment they think they got it, and another where they don’t?
To overcome the mystery of this problem I have derived the following sequence over the years, in order to more quickly analyze a newbs geometry and see exactly where the ‘true’ problems are.
<><><><><><><><
1.) selpolysrf
2.) explode
3.) refresh shade
4.) rebuild edges <1xe-05>
5.) refresh shade
6.) join
7.) show edges
<><<><><><><><><
Then if, under file tolerance of say 0.0005", there’s any naked edges – I’ll see the true problem areas and address them accordingly if necessary.
Sometimes yes you can just cheat and do things like switch the file tolerance to 0.001" or 0.01" and join everything – ignoring the fact you’re letting edges and vertices getting yanked away from originals.
But that’s bad habit – imo.
I prefer to model with a strict tolerance of 0.0001", but over the years I’ve become dampened to allow 0.0005", and on occasion 0.001".
Still, under a tolerance of 0.001" a user should follow good habits, and understand the underlying nature of Rhino’s characteristics. But sadly, some users don’t care to pay attention to what’s happening behind the scenes such as “Joined and exploded polysurface Edges are pulled away from the surface” – for example, along with " Whenever a NURBS surface is shaded or rendered, the surface first converts into a polygon mesh" – to reiterate another example.
Now on to challenge your claim further, I’ll focus for a moment on a common thing newbs do, associated with using default mesh properties:
And follow it up with the following:
Point here being is there certainly is an entangled effect of a user persisting to model with bad tolerances and bad mesh properties.
Because usually if not always, “water tightness” should be the end result in the 3D modeling realm.
In modern times yes 3D printing slicer programs etc. may have ways to patch things and fix “errors”, or CAM programs can ‘stich’ or ignore solids or lack thereof.
But a nice clean accurate truly solid and water tight .step model is ideal as an origin for most work – imo.
So, I often will encourage ‘users’ to follow the mesh settings I prefer in most cases, shown in the following:
The “Jagged Seams” help topic you posted above is probably misworded.
It currently reads:
“If this option is true, all surfaces are meshed independently and Rhino does not stitch the edges between joined surfaces.”
It should read:
“If this option is true, all surfaces are meshed independently and Rhino does not stitch the mesh edges between the individual meshes of joined surfaces.”
Yes, that appears to be the case - the edge of either the first one picked or if non-pick selected the latest in the database gets moved to the other. This is different from when curves are joined, where there their endpoints seem to be averaged.
I would leave out the shading altogether if you are trying to anlayze a polysurface. Meshing has no effect on,but is affected by, the join and edge tolerances in the polysurface.
-Pascal
Meaning ‘refresh shade’ is redundant? Or focus on the isocurves and edges mostly instead?
I prefer to see how the ‘render mesh’ is composing itself to the polysurfaces so I can see how that aspect is behaving per say.
While, I still need to gain an understanding of why the edges and corners of a surface are pulling away in the first place – like the solid is generating new polynomials or something? And maybe similar to ‘trimming’ the original 3D edge?
I’m not sure if a trimmed edge is even a polynomial, but I think it would be – although maybe not that important for me to know really.
I just like to be able to explain everything I can about these issues that ‘users’ will encounter, cause I don’t like mysteries.
Plus I’m trying to differentiate in my mind, the claims of ‘render mesh’ vs ‘edge pull’ … cause sometimes the render mesh pulls away also imo.
you seem overly fixated on the render mesh – they could remove all the code related to render meshes, and rhino would still be rhino, you just wouldn’t get a pretty shaded viewport, and would have to work with curve display only for any nurbs geometry
save small → now your render meshes are gone, and will be regenerated on demand when you reopen the file and switch to a shaded viewport
The Help entry may be confusing. A polygon mesh is created based on the surface. The NURBS form of surfaces always exists and is used for math operations. The polygon render mesh is used as the input to the display system. The calculations for displaying surfaces on screens are much faster with a mesh as the input rather than NURBS.
It would be fundamentally mistaken to think that Rhino creates NURBS surfaces from the render mesh.
The “render mesh” is used in shaded viewports. Basically it is used anytime a surface is displayed other than as a wireframe. The name may be misleading. It could be thought of as the “display mesh”.
Hi @pascal
I have run into this many times and couldn’t figure out the cause. I especially see it when you orient a cplane that is not orthogonal to the typical standard 3d views. Sometimes I found that modeling on a custom cplane makes simple things like this that should be flat but go wonky. Perhaps it’s more a transform code problem where errors creep into Rhino memory or the tolerance of the object. Maybe even just moving the object around causes it or repeating operations and undoing?
This post jogged my memory to pre V1 beta where there was a wonderful person who did nurbs rendering not polygons and had I think a prototype that worked with Rhino files. I remember it took like a week to render a sphere. He also was working on 3d genetic human types that you could create in rhino and alter with sliders.
Wonder what became of his work?
RM
No, it’s just accidentally snapping or otherwise moving off the oddball plane.
Hi Jim,
I thought that too but was careful to double check I do think there is a small bug in the planarity of objects in Rhino. You’re right most of the time it’s user error but in the cases where I especially noted it I was careful to make sure the object was not snapped to other things and I had planar toggle on. In fact this is one reason why I try not to model on custom cplanes at weird angles but rather model in standard views then transform the object to the custom cplane afterwards. I’ve run into this too many times.
RM
As you’ve stated it, is pretty much how I’ve always understood it.
Agreed. I’ve not ever said that nurbs are derive from render mesh.
I suppose the confusion is mixed up into the whole "edges being pulled away from original’ aspect of things.
And maybe in some roundabout way I was misconstruing that into the ‘render mesh’ aspect. So, maybe that’s really where I have things mixed up?
I think Pascal added some clarity, I’ll have to review it, but I’m still trying to wrap my head around that aspect better.
Yes I concur with these aspects.
I’m glad you mentioned this, cause I think a lot of users whom aren’t thoroughly familiar with Rhino’s details, potentially don’t realize certain risks that pertain to certain workflows associated with outcomes derived from “tolerances” and “qualities”.
My own boss and I just yesterday got in an argument during a session, because I was trying to tell him to do things one way but he wanted to do it his normal way – and it was all to try preventing microscopic deviations associated with “tolerance” error potentials relative to ‘workflow’.
Different users choose different flows – sometimes ignorance is bliss, until you have compounding errors down the road. Then certain flows are no good, regardless of how pleasant they may be perceived in the beginning.
Over time I personally have adapted to avoid the probabilities of compounding errors and certain assumptions.
Most users, I’d imagine, choose to assume certain instances of workflow are absolutely perfect to the millionth decimal place. But I know better, and strive to reduce the numbers of clicks, and numbers of entities I create to get the job done at every inflection point within any workflow.
But I know some users hate to enter specific coordinates ever, and love to just draw lines everywhere and rely on snapping tolerances etc. instead of being specific and using the command prompt as they should.
Imo, every time a user relies on the snapping to certain objects and further derivation forward from entity to entity, they risk compounding error deviations on into the future. This workflow can lead to excessive entity creation and excessive compounding error over time.
Ultimately, I believe that ‘constraints’ and ‘degrees of freedom’ control, would solve many of these problems! At least if users had the options, and were to use it.
Rhino uses double precision floating point math which is good for 15 or 16 significant digits for geometry, and uses all the digits. In most situations this is more than sufficient accuracy. V8 has some improvements to reduce the number of exceptions which occur due to the world origin being extremely far from the model.
My experience is the results of snapping are to the exact location, not within some tolerance. Using Osnaps is a key element of precision modeling.
For anyone interested in reasons Rhino has an absolute tolerance setting and what it affects see: Absolute Tolerance - Set and leave alone, and other good practices
Thank you, that worked 
I would like to learn more about this. It sounds like it’s storing the original nurbs and making new temporary ones…
There’s still other needed corrections I’ll bring attention to in due time.
Glad you were able to adjust the wording a bit so I wont get things backwards as much going forward.
The brep edges are not the same as the surface - so the brep - the surface or polysurface you see in Rhino - is a structure on top of one or more underlying surfaces. A discrepancy between the edges on the brep and the underlying surface is what may occur on Join, and more likey on JoinEdges.
-Pascal