Ok, V5 up and running, saved the ring file as V5 to get the same setup with the same HDRI lighting and all. And did a few tests and I get about the same noice level as in v6 in about the same time used:
I stopped the renderings after 12 seconds to show the noice level.
Neon rendering on the DUAL Xeon, so basically 2x6 CORES = 24 threads:
Yeah, I donāt work for them either, and I GENUINELY APPRECIATE any help you can offer on this. I lean more to Animations depicting my Design Assemblies OPERATING in their ENVIRONMENTS (Offshore Oil Platforms and Subsea Installations ā¦ etc.) so frame-rate IS an issue, and time-to quality is a MAJOR FACTOR.
Numbers ?
NUMBERS tell the tale, NOT static pics with no substance behind them. "What numbers ? " Let me help with that:
The numbers we KEEP going BACK to from EARLY in this thread. You can find them earlier in this thread, with extensive examples, notes, details and conclusions. LET me know if you need a refresher, as its sometimes hard going back to earlier posts on a given thread, but it SHOULD be pretty easy to find fairly recent posts on CARDS, CUDA, SLI (apparently more cores conflict with dual-processing ā¦ :=O ! ) and capacity, and THEN thereās TIMES to capture (affecting frame rate) . THEN thereās Time to FINISH with END-NOISE LEVEL .
Its DIFFICULT to hand you a āfileā as 1. ALL of my work is proprietary and Iām contractually BOUND to confidentiality, and 2. MY files run more to a real-world product design size for Assembly Modeling: 250-350MB to upwards sometimes approaching the best part of a GIG. Reasonably, I can often reduce the working file size to a % of <100MB or so, which MY system will FLY through.
So- I again would ask - to accompany your GORGEOUS pic (!!!) - NUMBERS ?
Iām sure you can NOW spot the āholeā in the āwe need a fileā argument" ;=) ! FILE SIZE should tell you everything you really need, with an assumption that the internal modeling violates no major convention which would conflict with getting a good render.
I did supply them, the numbers are there right on the images. Just click on it to see it in full size.
No it does not, because your files, number of parts, size etc can be the reason you see issues with Cycles that I do not see.
In example I too have had trouble kicking off renderings on large files with Cycles, but so did I with Neon. And MAYBE it has to do with Cycles using a lot of, and NEEDING a lot of VRAM to handle those files. I donāt know. But I would be happy to try one of your files.
So I repeat: FILE PLEASE
Just canāt bugtrack without.
So I suggest you make a huge dummy file with some scrap parts that doesnāt belong together and thus doesnāt violate any copyright issues.
Anyway, here is another test with a different file. Both stopped at 25 seconds:
One thing that favours Neon though is itās higher reflection values, and that is one thing that I miss in V6: Shiny materials reflects less. @nathanletwory do you know why? Itās a limitation when trying to achieve polished plastic etc. You can see it in the metal in the ring renderings too.
I havenāt looked into this lately, busy working on clipping planes and Cycles-native decals, and Raytraced for the Mac.
But my guess is that you are using Rhino Custom material, not Plastic and Metal. Especially the glossy finish part of Rhino Custom does nothing useful in Raytraced.
When rendering with Cycles, having couple of transparent and reflective objects bumps up render times.
At least in my experienceā¦
I suppose reducing number of passes for transparency and refraction might reduce render time among others probably that I havenāt touched for a whileā¦ But objects may come out a bit darkā¦
For the noise blender cycles improved so continuous development for rhino cycles probably would get thereā¦
@cfee is it possible to create a rhino file that
you can upload, fake stuff is fine, that runs fast on Neon and slow in cycles? Just copy paste of objects is okay I thinkā¦
Just as long as hdri and materials are set.
See how the red plastic is much more reflecting in Rendered?
That is how I expect it to be, but cycles is much less reflective.
BUT after some testing I see that this mainly affects the Custom materials.
The red material does not have fresnell turned on. But none the less this is how RhinoRender interprets it and that too is much closer to OpenGL than to Cycles:
Point is that I want them all to look equally reflective so I can tweak the materials to 90% with Rendered and when I turn on Cycles it looks as close as possible. And I want the default scene to make the materials POP.
So please take a look into the Custom material because we need that since the other materials are so limiting in their settings.
This looks like the different handling of the glossy finish bit. At some point I will look into it again, but there are some parts that will never look the same.
Sounds like you need to up the amount of transparent bounces.
That might be, I donāt have glossy turned on at all, just reflection, so what happens under the hood is out of my hands. But I am sure that if you give it a spin youāll figure it out
That doesnāt sound right to me, because it starts off looking good, and then ends up looking like crap with more iterations, so to me it should look like crap from the beginning if it needed more bounces. Anyway, Rhino should handle this in the default setting.
But letās not speculate, I attached the file so you can play with it on Monday. Now it is time to enjoy the heat of the summer. Cheers!
I was naughty and just now looked a bit into it. The black dots appear when plastic clarity is not set to fully polished. This indeed sounds like a bug, probably some NaNs happen somewhere.
At some point in the near future Iāll check the changelog of upstream Cycles to see if anything similar was already fixed, and otherwise try to repro in Blender Cycles if I canāt find any obvious fix.
Get it ? AND note the NOISE. Maybe this level of noise is acceptable in some work, NONE of my work is such that this level of noise is acceptable.
STILL NO NUMBERS (25 seconds - Woop-WOOP ! to a sub-par result) so Iāll dig out what Iāve shared here previously. OPENGL/CL (āNā) seem to work but CYCLES seems to have a problem? Seriously? I thought CUDA rendering was the whole point as GPU rendering and CUDA core count was the latest craze ? NOW weāre even seeing a problem with CUDA + SLI TOO ?!?!? And you need me to upload a file so you can bug-chase when your own displayed product has you chasing fresnel reflectivity (and NOISE !) ?!? With the level of reflectivity problems ONLY showing up in Raytraced ? AND a few transparent material items "bump up render times? Guys, you DONāT need ME to upload a file. You just need to realize YOU are making my point for me while you chase internal settings one at a time trying to overcome something THAT WORKED in its predecessor ( I wonāt use the dreaded āNā word here to spare feelings ;=) ! )
But returning to ānumbersā : Iāll dig out an earlier post to this thread and re-post it here for reference.
āNumbersā is NOT ātime to a personally acceptable sub-par renderā. Numbers is FAR more, NOT the least of which is Dollars for a āfreeā replacement.
Guys, a bit of a cautious aside here. Weāre 2+ almost 3 years into this issue and weāre still chasing bugs and NAND issues, etc. Something to consider.
The amount of testing, design feedback to development and Q&A work your are have been doing related to raytrace and materials and all rendering workflow UI is remarkable.
I canāt help to imagine how much better rendering workflow be in Rhino if McNeel actually paid you and a couple of others, to do this much more extensible. Especially considering that you are uncovering things that other rendering products have already figured out over a decade ago. And that developers are such a scarce resource.
I keep seeing the gap between what customers need and what McNeel offers widening every year. I think McNeel should take this space a bit more seriously, thatās why I have been so frustrated with it. Also I think they should work a lot more closely with Octane and Vray to solve and improve their integrations. And they should assign one more person to integrate Grasshopper with all things display like rendered/technical/raytrace and Octane/Vray.
Thanks for the cudos. Itās hard to fathom that we have done this for 20 yearsā¦ Time for a party I guess!
Rhino is an amazing software that is used in an extremely wide range of work fields and sometimes a small project grows bigger than anybody would expect. Like Grasshopper. Or rendering. Rendering in Rhino was never meant to compete against the big guns, but suddenly, as tools evolve they become so good that users will compare them to plugins that are even more expensive than the total Rhino package. Thatās not a fair comparison, but life isnāt fair though.
I think the top priorities are, and should be, to make stable, predicable solutions. With easy to understand limitations and with few and easy to adjust settings. Or to go the whole nine yards and make a top of the line tool that competes with other integrated solutions in other software. And I think that with time Cycles will do just that.
Frankly the only big issue I have with Raytraced mode is that Rhinorender doesnāt use the cycles engine. So what you see in the viewport isnāt always the same as you get when you hit the render button. Itās close, but Rhinorender just isnāt as good, and it is crazy slow. And viewcapturetofile just isnāt a user friendly approach. It is a nerdy hack for the select few. And waiting for V7 to fix this is too long to wait for normal users. It was a bad call IMO, nothing more, nothing less. But it will get there, that is for sure.
One thing I would like in the newsgroup though is a ābugā category to tidy up the flow of information and a hidden āalphatesterā category where stuff can be discussed in a franker manner that doesnāt scare off normal users
