As I get a denser SubD file I’m finding I am crashing on saving a file. Not repeatedly but enough times where I am very cautious about saving.
One other thing which seems to escalate this is running Octane 4 pluggin a little before the save. But it is to do with SubDs. Never had this sort of issue with just Nurbs.
I’ve been diminishing the render tessellation to keep them as sparce as can be without loosing much quality.
My goal in asking the following questions is to try to narrow down where we need to focus our attention.
When Rhino crashes, are you getting the opportunity to send crash information to us and have you sent any? If so, what email did you use - this lets me find your crash report. (You may send the email address you used to me at dalelear@mcneel.com to avoid sharing it in this public forum.)
Are you running on Mac or Windows? If you’re running on Mac, is it possible to see if you can repeat the crash on Windows? We get much better crash information from Windows.
Do you get this crash if you never render in a session? Wireframe and shaded viewports used for modeling render SubDs directly from the SubD. When you run the Render command, the SubD is meshed (as if you ran the mesh command) and that mesh is used to generate the Render command image. Depending on your rendering materials, a rendered viewport may create a rendering mesh.
I don’t recall crashing without rendering a test in Octane. Maybe but not certain. I never crash with Octane open. I always close it to ensure no heavy over-head. The last time I crashed I was sure not to have Octane open and made sure I was in wireframe in the viewpoints.
We’ve done our best to design the SubD addition to Rhino 7 so that plug-ins written for V6 that know nothing about SubDs will get either a mesh or a polysurface and be none the wiser. We’ve tested lots of V6 plug-ins and the design appears to be working well in many cases.
We’ve run across a few cases where plug-in code had a bug that the new SubD object type uncovers.
At this point, it’s too early to say if Octane has a bug or if it is simply exposing a new bug in core Rhino code.
So true. I just haven’t wanted to go onto a subscription for software I only use time to time…so V4 stays installed and is fine until a file starts to get larger and larger, seeking how it seems to be the culprit.
I like octane, and it has it’s definite benefits (as in my current project) but after using Maverick for a year it’s hard to spend money there.
Interesting. I’m curious makes you chose Maverick over Octane?
I wish there’s was ONE production quality render well integrated with Rhino. We use Vray and Octane here. Vray if we do animation or Grasshopper stuff, Octane if we just need best quality of materials for stills, fast, but in both cases the integration with Rhino is just awful. And sadly I don’t see that ever improving when no company involved sees that as important to them.
I love the library of quality materials, lights and environments…and complete ease of use.
With the new export pluggin for Rhino it’s just a mater of one button push and Maverick is up and running. Update a model in Rhino and another button click and the Maverick scene updates with the new version. This way I can model in Rhino and have a complete interface for rendering.
Also in Maverick, anything and everything can be translated (with precision accuracy) within the scene and this keeps the back and forth to a minimum.
For me it’s a very fast, smooth and creative work-flow.
That makes perfect sense to do final artwork/assets. For us since we are constantly designing and evolving models and showing those changes to ourselves and clients we need a production quality rendering that works flawlessly inside Rhino.
Things like decals, clipping planes, thickness, curve piping, edge softening, shutlining, GH unbaked previews, curves, Bongo animations, dimensions, picture frames, ground place settings, background image settings, snapshots, blocks, worksessions… should all work in a production quality renderer.
Pretty much nothing of that mentioned above works, and the couple of things that do they are limited and buggy AF
I still think there’s room in the market for one Awesome render engine for Rhino that just works. No one is doing that. Not a single 3rd party. Not McNeel.
Yes, I understand. I’m fortunate that Maverick does just about everything i need. Octane has a couple of functions very well developed so it still is of use to me.
Brazil didn’t work out for them. It is a good rendering engine but a bit complex for the average user. I still use it for certain projects.
@PaulS the answer from the plug-in dev I got was: crash happens with either old plug-in version, or displacement settings are high. So please check your plug-in version and update if it isn’t the latest. And check if you have any (material) displacement and adjust settings.
Cycles (new rhino render) is getting close in testing here. Decals need work and Nate is working on that, should see updates on that after the new year.
What are you missing in cycles that you are getting elsewhere?
We are continuing to (and have been) working quite actively on making the new rhino render a complete solution. I’ve been a render nerd for years, and it has delivered really nice results here and with the correct hardware it’s blazing fast.
Good to hear that everything is moving along well.
Two things…I haven’t had a chance to spend more than just a little time with it. And I much prefer to render outside of Rhino, be it Maverick or Octane.
Hi Kyle, I said it probably over a year ago, maybe before you fully joined McNeel: I’m recusing myself to talk about anything Rhino-Rendering development related until I see anything that’s even worth talking about. That has not happened yet.
Keep in mind that besides industrial design services we sell services in virtual photography (products alone and in complete virtual environments), realtime assets for AR/VR (using baked-rendered details from high-rez into low-rez model). And animations with complex deformers, hands/heads poses/movements, fur, particles, etc.
We need a super fast, unbiased, photo/video quality (according to my standards, and matching a very skilled product photographer). More importantly our work done in Rhino, Blender or Modo has to render seamlessly and be combined. Sometimes as overplayed frames in AfterEffects with matched cameras. That’s why we have started favoring Octane over Vray since there’s no Vray developmet for Blender. This is why even Keyshot is not useful for our needs anymore, they seem to be showing up with good stuff a bit too late for our needs.
So my original wish stands: we really need Rhino to play extremely well with those 2 world-class engines. Probably a live-link bridge to Blender could be the solution for these advanced rendering needs + advanced SubD modeling needs?
BTW, I do keep an eye at all render engines’ development out there. I think Maverick, Corona, Arnold are doing great work. I think Bella looks very promising if it can get GPU speeds. I’m yet to see a single great (as in as good as what a professional photographer would do with a physical product, and a physical setting), rendering done in Cycles for Rhino.
In summary: I’m not your target customers for rendering, and that’s fine. I’m sure Cycles in Rhino will be absolutely great for a market 100x bigger that what I represent. Just don’t forget to please also play well with the 1% I represent.