Hello, I hope someone can help me with this one cause I couldn’t find a similar post. When I render my NURBS geometry or meshes with V-ray it renders jagged. It displays OK in the view-port but the renders are jagged. It renders fine with rhino render. Also if I disable the hardware acceleration the view-port displayed very distorted (see images- NURBS geometry and 2 mesh spheres). Thank you!
A few more images. V-ray, rhino render and view port - with and without hardware acceleration. Any help will be very much appreciated!!! Also this happens only in this file but any new geometry I create is jagged as well. Thanks!!!
I am pretty sure your geometry is very far from the origin, which is the most common cause of these effects… - can you check to see where your stuff is located relative to World 0? If it’s very far, try moving it closer to the origin, clear all the current meshes with ClearAllMeshes and then try again…
Thanks!!! That was the problem, I’ve heard it before but I didn’t think of it. Thanks again.
I think the main reason stuff ends up way out there is because it it’s imported that way. Would it make sense for Rhino’s import plugins to scan for this as it’s coming in and issue a warning with a description of likely problems and offer the user a chance to move the whole thing to the world origin - perhaps while also telling him what the offset will be so he can make a note of it and put things back later if he wants to?
I suppose there might also be the case where someone is building an original model from scratch using design info that’s in coordinates well away from 0,0,0. This case might be harder to auto-detect since Rhino would need to constantly watch as each new object is added and apply some kind of AI to decide whether things are getting out of range. Or maybe it really would be practical with todays really fast PC’s to just determine a hard value thats “too big” just like we have tolerances for “too small” and check each new coordinate entry for exceeding it.
Is Rhino 5 still using single-precision for coordinates and it’s math? If so, perhaps it’s time to move to doubles for everything in V6. If we’re already there, I guess, from the number of times this comes up here, that some type of analysis and warning would be helpful. Maybe more obvious emphasis on this as a “soft” limitation of Rhino could be included in the help and training materials.
I’m sure this is in your giant mixing pot of design considerations; I’m just trying, along with those who have recently had trouble with it, to float it to the top for a little reconsideration for V6.
As a person that used ot have to work in very large State Plane coordinates, an automatic change would be a really bad idea.
I needed to precisely control the Translation so I knew what it was.
I’d to this by choosing a point near the lower left corner of the project, and insert a block at that location to identify the datum point. I’d choose one so all I was doing was stripping off the high digits of the coordinates. I would save this information as part of the instance.
Then I’d move everything, including the block instance to 0,0,0, using the block as the point to move from.
Then when I was finished and needed to send the project along, I could move everything back as needed.
Rhino itself is double-precision. The display mesh isn’t.
[open can of worms]
Maybe it needs to be?
[close can of worms]
Meshes generally will be double precision in V6.
However, when you export to a mesh format, it will revert to single precision so you’ll still need to manage it.
What’s the reasoning behind this? Seems to me that it should be an option depending on what the export is for. Rhino can’t be the only program dragging itself reluctantly into the 21st century. Why not be ready for the time when the laggards will be able to eat double precision? And what about developers who might want to develop future standalone programs that could use DP if available?
Or did I misunderstand what you said? Did you mean that Rhino will still BE ABLE to output SP if necessary?
No reasoning. If the export format doesn’t support double precision meshes, we can’t send one out.
If the export format supports DP meshes, then it will be easier for us to not have to strip them down to send them out.
I don’t have a list of the mesh formats and what their tools allow or limit.
I think STL is one that does not support DP meshes. Based on what STL is intended for, there’s no reason that it should support them.
OK, John. Thanks. I mistakenly leapt to the conclusion from the way you said it that Rhino 6 wouldn’t be able to export DP at all. Sorry.