VRay GPU Useability?

Hi Ryan.
I’m finding the implementation of 3.6 very good. I wish more GPU functionality was there but the basic stuff is fantastic. Rhino 6 is very, very fast…great speed enhancements under the hood. I’m very pleasantly surprised at the combo with Vray added.

You may have seen these quick tests with Vray 3.6:

Vray Cloud is still in beta, no pricing has been announced yet. But it will be valuable for almost anybody, I think the most benefit will be the small studio / individual that has periodic needs.

Thanks for forwarding the link PaulS! I need to revisit Vray and retest it out . . . it’s been a while since I’ve done that. GPU is key for me, as I have Four 1080’s and only a single i7-6850K CPU. So . . . I definitely will need to do everything on the GPU side of Vray to be productive.

Thanks Marc. Seems everything in moving to the cloud. I’m interested (once it’s released and stable) to compare price/performance for an animation and see how far ahead it comes out vs. running it locally.

Ryan…what are you currently using for a rendering engine? Those 4 1080’s have to scream!!

Hi PaulS,

Yes, the 4 1080’s have been AWESOME! I’m using Octane for most of my production work and have been very happy with it. Vray offers some additional features which I’ll best testing out in the coming weeks once I can come up for air and have a chance.

The render below is a full HD frame straight out of Octane, rendered in 11 seconds on the 4 1080’s.

https://s31.postimg.cc/5azh4taob/HPAO.png

2 Likes

That speed in Octane is pretty impressive!! I’ve upgraded Octane to V3 and downloaded it for Rhino 6 but it’s been so long since I did anything with Octane. Can you point me to a place which has some Rhino files for Octane just to get me going. Or if you have a file or two you can post here?

TIA Paul

Hi Paul,

I’m not sure where any Rhino Files are online and most of my files are confidential product or architecture files from clients that I can’t pass on. I did however create a file for you with a Basic Render Settings Setup. It just has lighting via an HDRI and some basic materials setups in it. It is Path Tracing however the setup is built for speed while maintaining quality. I hope this helps. Let me know what questions you have.

File for PaulS.zip (282.8 KB)

This is great! Thanks so much!

Hi Ryan, we do use Octane too. We love the speed and quality especially with our 4x 1080Ti box, but the geometry cashing is a real problem for animation, also the integration with Rhino rendering is very very limited.

We are considering taking a closer look at VRay RT and see if things get even better. We’d love to hear your thoughts on it as a user of both.

Hi Marc, do you know more about this? Where do they store the files, traffic encryption and all those details? also have you tested it with anything? any idea of what performance you get? compared to what hardware?

We have been looking at AWS EC2 for this but it’s a bit of a pain to setup (I used to have people who did this for me! :weary::rofl: ). Their stuff looks very capable and flexible:

Anyone else using AWS for this?

HI Gustavo Fontana,

I have not tested the 3.X version of Vray yet, but i’m planning on doing so when my schedule opens up. I will definitely report back here once I do and let you all know my thoughts. Just reading about the latest features, the biggest advantages I can see (on paper of course, we will see what testing yields) OVER the latest version of Octane are:

  1. Vray Fur – not only for grass, but for carpet on interiors – this adds quit a bit of realism and since Rhino doesn’t have any scattering tools this is a big bonus.
  2. Grasshopper integration without baking
  3. Animated Proxies – please note that these ONLY work with Rhino animations, NOT Bongo animations, so we are limited to Path, Fly through, sun study.
  4. The Rhino Animations can be pre-recorded in Vray, thus eliminating a frame by frame load time. Again, NOT for Bongo, only Rhino Animations.
  5. Clipping Plane. I’ve needed this a few times and Octane won’t render clipping planes.
  6. Vray Scene Import / Export to and from other programs.

With all of the above being said, the nice new animation features (animated proxies and no frame by frame loading time) ONLY work with the Rhino animations, not the Bongo animations. For architecture, this will probably suffice MOST, but not all of the time. However, for product animations, at least for us, we always have object animation. Vray will work with Bongo, it just has to load each frame independently like Octane does.

So . . . that leaves me to the one very big advantage that Octane has over Vray and that is that the scene load time can be eliminated with Bongo Animations by exporting the scene to the standalone and rendering out the scene in the standalone. This is what we do 90% of the time. Doing this also opens up the door for motion blur, both camera and object, which again for product animations adds a huge amount of realism. That can’t be done in Vray right now as each frame has be separately loaded. I have been told by the plugin developer for Rhino Vray that they are going to be looking into further ideas to integrate Bongo into Vray better, but who knows how long that will take.

Let me bring up one other point as well. I attended a webinar on Unreal Studio this past Friday. You can find more info regarding that in my post here: https://discourse.mcneel.com/t/unreal-engine-studio/60718 We have been looking at using Unreal Studio (which has a feature called Data Smith to import Rhino .3dm files into Unreal) for architectural animations. This could potentially save a substantial amount time for architectural animations and also open up some doors since animated foliage, object animation, VFX, etc can be done in the Unreal Engine. There are tons of architectural examples online if you aren’t familiar with Unreal. In the webinar they import a .3dm file of a wind turbine and animate the blades spinning, make instances, paint grass in the filed and import flying birds above. Pretty cool. Unreal has the capability of some very impressive quality and with real time once the scene is setup. See some nice examples here if you aren’t familiar with Unreal’s capabilities for photorealism – the first link is the real time viewer of just moving around in the scene: https://www.youtube.com/watch?v=I8RYYi6F3fc Then here’s the architectural version: https://www.youtube.com/watch?v=9h0hVZ3WIs4

So . . . the biggest drawback going into another program is obvious – changes made, then you have to re-export, etc. . … a huge pain. However, it is my understanding that the Unreal Studio’s DataSmith allows you to re-export only the changes in your scene. Also, Vray is working on a BETA for transporting a scene into Unreal from any plugin in. This could potentially be huge because that means we could do our high end photoreal still shots in Vray for Rhino, then export the scene into Unreal for animation work. Kind of the best of both worlds. Info on that here: https://www.chaosgroup.com/vray/unreal

Anyway, I know this was a long post so thanks to anyone that read it all! Hope the info is of use to someone.

Ryan

1 Like

Hi Gustavo,
They work with Google on this project.
I asked for an official statement, or spec sheet or white paper, from Chaosgroup about the confidentiality and robustness of their system. Because without this there’s no way we can use it. They understand the need and they are working on it.
The power is scalable and are testing different configurations. In the last tests I did, they matched my workstation specs.
The setup is very simple. A new service to install, credits to buy, and that’s it.
There is a podcast on Chaosgroup’s lab website that talks about some implementation details.

Hi Ryan, this is all very insightful and I really appreciate it. It does give me a lot to think about. We are going to start testing Vray soon and see what we think, I went to their site the other day and I could not make sense of their licensing approach (since they are talking about CPU nodes and I care about GPU). I’ll try to figure it out.

The most important realization in all this is that Bongo should really try to do a better job integrating with both Octane and Vray. I hope @andy can read your post and start thinking how much of the limitations are on these engines architectures and how much in Bongo’s. And hopefully make the next Bongo address this, if possible.

I do like the Unreal suggestion. This could play well for VR demos too, which we are getting asked to do more and more.

Best,

G

Hi Mark, I think that’s a deal breaker for me. I looked at them in the past, I can’t go into details but they are a big NO for me. I might be able to share some insights privately if interested, but since a lot of these policies do change overtime, and very quickly too. I need to ask for permission and also get an updated status of their policies.

I’ll keep looking into (just gettting it done actually!) setting up AWS, and see how fast can that run. Based on my calculations it should be able to go about 2X of a 4-1080ti, on a single instance. So that’s encouraging, just need to see how much that will const per job too.

Best,

Gustavo

I think the right way to go forward with this is to have engines use the ChangeQueue mechanism. If Bongo can be told to have a virtual view with attached changequeue then updating between frames becomes as fast as uploading only the changed bits and pieces. This is at least what I want for Cycles (Raytraced) - it should give quite a bit of performance boost when talking about data conversion from Rhino to render engine.

I completely agree. I can’t use several of the features in Bongo because of this issue. If Rhino animations don’t have these limitations then there has to be a way to get around it in Bongo. What I keep hearing from render engine developers is that Bongo is the issue here.

Also . . . I just saw this post: https://discourse.mcneel.com/t/3d-modelling-cnc-fabrication-work-2017/52342/13 Scroll down to the first animated GIF. So . . . this was exported frame by frame to make this GIF. If this can be done in Grasshopper, then I wonder if there is a way to make render engines be able to render this content? This would turn Grasshopper into an amazing animation program in and of itself. Of course, there would still need to be a way to sync camera movement in while animating the Grasshopper sliders. Also, I’m now wondering if the solution here would be Cycles . . . since it does in viewport rendering I’m wonder if Cycles would be able to render out frame by frame images from animated Grasshopper sliders? Anyway, food for thought.

Ryan

Hi Nathan,

This sound great, however I know Paul (the developer of the Octane Plugin) is aware of this system and I don’t think it ended up helping out when V6 came out because the programing languages were different between Octane and Rhino or something like that. I remember having this ChangeQue discussion quite some time ago and linking in Paul. We all had high hopes but in the end I don’t think it worked out. If your team knows a way to eliminate render engines having to reload the entire scene for every frame then this would be HUGE. Not only in time savings, but because we’d have access to vertex motion blur. Is it possible for your team to reach out to the Octane and Vray development team to discuss this? Or is there something we can do to help?

Sounds great! Is there a broad view of where you want Cycles to go? The Cycles version for Blender has developed rapidly in the past year and is quite impressive – can we expect the same with the Rhino version? Blender’s version is production ready but Rhino’s is not yet, as it is lacking features. Are we looking at implementation of new features on a long time table or a short one? Switching production work over to Cycles if it worked with Bongo more seamlessly would be a huge draw for many I’d think. I’d love to see Cycles in Rhino brought to the level of Cycles in Blender sooner rather than later (I know, I know . . . easy for me to say I don’t have to do the programming).

Also, with regards to my post above on Grasshopper animation of sliders working with Cycles – can you comment on the potential possibility of that? Am I just dreaming or is it doable?

Thanks,
Ryan

Yes, I have been discussing using the ChangeQueue with Paul. The programming languages are not different, but it does require some new implementation from Paul to use. I do hope he will gradually move to the system, though.

I think especially for animation rendering the ChangeQueue will be the right approach.

I already correspond and talk with Paul occasionally regarding the Octane plug-in development.

I haven’t had direct contact with them yet, I think Andy has been mostly in ceontact.

Apart from lobbying for using the new system, and intensified discussion, probably not. We are here, the devs can fire their questions about integration.

What features in particular are you missing? Apart from denoising about everything (most things anway) is one way or another accesible. I’ll link in a moment a new topic here that you can use to respond at for this particular subject. Edit \Rightarrow Blender Cycles features lacking from Rhino Cycles?

For Rhino 7 I expect we’ll have More Features directly accessible, Cycles in Rhino 6 was more about rendering without having to worry about which buttons to press (depending who you ask we either succeeded or failed).

I think the idea is to have this work through Bongo.

/Nathan

A post was merged into an existing topic: Blender Cycles features lacking from Rhino Cycles?

Right now the biggest pain in our workflow is how limited is the integration of Vray and Octane in Rhino. This is in regards of animation, materials libraries, material editor, render queue, cameras, lights, GL render preview…

It’s frustrating as users seeing how McNeel expects Chaos Group and Otoy to do the work to integrate these rendering engines. At the same time Chaos Group and Otoy expect McNeel to do that same work. Or in other words: all the parties in love are content with the current situation and see no upside on investing development effort to make something remarkable. Years and years have gone by and we still do not have a good solution to have industry standard and world-class rendering engines working well inside Rhino.

I honestly do no see a path to solve this. Am I missing something?

G