Thank you !
(We —the users license—pay new versions,…Rhino…
but the simple problems stay always there).
I dont understand why?.
Thank you !
I’d like to understand the “Export planar regions as polygons“ problem. If you export a 3x3 (numbers are arbitrary, anything but 1) MeshPlane to SketchUp and have “Export planar regions as polygons“ checked do you see triangles with that file in SketchUp? If yes, what shading setting do you have set in SketchUp?
Yes - there is no way to avoid this. I have tried exporting meshes, surfaces, every possible setting, etc. (Examples and discussion farther up in this string I believe.) No matter what the settings, geometry imported to Sketchup from Rhino using Rhino’s Sketchup exporter will be triangulated. It will look great initially in Sketchup and retain material mapping, include loose curve lines, layers, etc. However, when you show hidden geometry in Sketchup you’ll see that each quad surface is triangulated. This is a deal breaker if you want to do any editing in Sketchup, as the push/pull extrude tool will not work on these triangulated quads. Additionally, it creates problems down the line if you want to export to Vray or run Vray on top. So basically the Rhino Sketchup exporter is near perfect in most ways but has a fatal unsolvable flaw. Please note that Sketchup has a button in its dwg import routine that enables you to solve this issue with incoming triangulated surface geometry if you export dwg geometry from Rhino, but you then run in to other issues with lost materials, etc. The Rhino Sketchup exporter problem constitutes a truly huge issue for those of us in offices working in both Rhino and Sketchup and needing constant efficient interoperability and geometry exchange
If I make a 10x10x10 mesh box and export to skp. I’m able to push and pull sides without any trouble. Here are 2 .skp files, try them for yourself. One was the standard “Export planar regions as polygons“ and the other I turned on an option that you see when you script .skp export called “CullUnnecessaryVertices”. It will remove unnecessary interior colinear boundary vertices. So in the case of a box instead of getting 40 vertices along a face border you get 4. If these work for you then I guess I need to see your simplest model that exhibits the behavior.
It works with your example because you started from a mesh, but if you create a simple box using nurbs and you try it again, you will see the problem.
nurbs-meshbox10x10x10.3dm (3.1 MB) nurbs-meshbox10x10x10.skp (7.9 KB)
So, seems like something gets messed up at export time and export as export planar region as polygons is not been taken into consideration when working with nurbs geometry.
Thank you. That was very helpful. Sketchup uses the render meshes of objects so it can preserve the block hierarchy, it doesn’t make the meshes on export (doing that creates individual meshes that are in the transformed locations of the blocks). I was able to repeat what you said with a box and also by extracting the render mesh and exporting that alone. Now I have something I can look into.
That’s great Tim! Now you just have to sort it out
I would note that for architects, we mostly never model in Rhino in meshes, only nurbs (surfaces, polysurfaces). Or at least I never do. I did try converting complex architectural nurbs models into meshes and exporting to SKP with Rhino SKP exporter but got the same triangulation issues on import to SKP.
Whether you model with meshes or nurbs in Rhino, it doesn’t matter with regard to SU export. Rhino only uses the render meshes to export to SketchUp. And when you roundtrip back into Rhino all of those beautiful curvy nurbs surfaces will become meshes or planar polysurface approximations.
One thing I did determine is it looks like the problem happens when the initial mesh face is a single quad. I don’t know if having right angles at the corners is part of it or not. I posted on the SU SDK forum to see if they can tell what the difference is between 2 very simple files where one does the pushpull and the other doesn’t. Here’s the post if you’re interested. https://forums.sketchup.com/t/whats-the-difference-in-these-2-files/122223
Thanks, Tim. The reply you got int the SKP chat shows exactly what I’ve been seeing and describing. He has turned on hidden geometry so you can see the reality (dashed diagonal) under the surface that the quad is actually two triangular surfaces in SKP but the diagonals are hidden (softened, in SKP parlance). Push/Pull editing does not work on a joined pair of surfaces, only a single undivided face. As mentioned, SKP has a routine to join coplanar faces upon import of dwg geometry (e./g. generated by Rhino). What would be nice is if that routine could be enabled in SKP when one were to ‘import’ a Rhino-created SKP file, rather than opening it directly (in effect tricking SKP into thinking it is opening a native SKP file created in SKP). Alternatively, I wonder if Rhino’s dwg exporter, which has quite a few options and controls, could be improved to support all the things the current Rhino SKP editor does (material mapping, lines, layers, etc.) so that one could export Rhino geometry as dwg then use SKP’s merge coplanar surfaces tool on the other end… just a thought.
This should be fixed in the next RC of 6.25. See https://mcneel.myjetbrains.com/youtrack/issue/RH-57964 for details. It was a bug in my code that didn’t recognize an ngon properly when it only contained 2 faces, which occurs often.
That is awesome! Thanks, can’t wait.
Wow @tim! That was fast, thank you!
I LOVE Rhino but there is another issue that drives me nuts and is actually the main reason I export geometry to SKP in the first place. Why are Rhino shadows so glitchy and frankly bad? I don’t mean the beautiful but slow-to-create ray traced views - I’m working mostly in basic rendered viewport for speed. Shadows literally always detach from source geometry (unshadowed gap between geometry and start of its cast shadow) no matter what I do with shadow settings, clipping planes, etc. Please see how simple and clean Sketchup shadows are, in real time, as you work. Despite Rhino being 1000 times better and more powerful than SKP in terms of geometry creation and editing (not to mention the power GH integration and so much else), SKP for architects has much better shadow graphics that one can generate instantly. With Rhino being so good in all other ways, this seems a massive oversight and has been for years. The need is instant simple clean shadows (cast with geo locating geometry as in SKP) that can be turned on as a designer iterates 3D design rapidly. If Rhino could improve this to be equivalent to SKP, it would, for me at least, be a complete game changer in architectural Rhino use.
Before you start thanking me you probably ought to test it and make sure my fix actually works. It did in the few tests I tried, the ones that José brought to my attention, but I didn’t try anything really fancy.
The shadows stuff is something I know little about. I’ll see if I can get someone who knows that stuff to have a look.
Don’t worry Tim, I’ll make sure to try something fancy as soon as the new WIP comes out
Yes, I completely agree with you. Rhino is so close to be the perfect tool for architects, but a few minor things like crisp and precise shadows, and also clipping planes working reliable with blocks, are a huge deal breaker at the moment.
Hi Tim - Is your fix for this in the latest Rhino 6 update or do I need to install the Rhino 6 update ‘candidate’ instead? If the latter, how does that work? Anxious to take this for a spin.
It should be in the latest 6. I made the changes in our 6.25 branch so they should be in there. I think you can just poke the link that Brian posted above or you can set your update frequency to “Service Release Candidate” and it should happen automatically.
Are you just asking about updates in general or have you gotten what you think is the latest and are not seeing any difference?
Thanks, Tim - I tried the new release and your fix works!! Awesome!!! Thank you.