Hi!
I’ve been very happy with v-ray improving in every single aspect.
I’ve always complained ( mainly because I’m on Mac) that gpu RT isn’t strong/fast enough for me.
Sure i could buy better graphics card…
But with the same config, I’ve just tried the new Arnold render view, and its fast as hell.
Its IPR was already faster than v-ray, but this new one is ridiculous fast, and its features of selection/ isolating, diagnostics is awesome.
Please check the video.
I think v-ray deservers something like this, while keeping its awesome vfb.
i dont dispute wether arnold IPR is faster than vray or not, as ive never used it, and there are some very cool features in there, However, that example in the video is a very easy scene to render.. id imagine RT (cpu or gpu) would be pretty blazing fast in that case too.
have you done any direct comparisons using similar scenes?
Yep, 640x480 with a simple scene is a matter of how responsive the system itself is. One issue with the V-Ray’s RT is that it runs in a separate process which slows down the communication. This was fixed in 3ds Max, so it will come in Maya also.
Maybe some stuff is already available in V-Ray Max, but definitely a lot of nice feature isn’t available in V-Ray Maya.
The low-latency response is great. Like you said, there is something can be done to improve the communication between viewport and the VFB. Also a lot of stuff is achieved without re-exporting the scene. Excerpt of highlighted features from official announcement below. These features can help a lot during look-dev and lighting.
Smooth, low-latency render updates take place while dragging the mouse rather than at mouse-release time.
Different cameras, AOVs and shading modes can be selected at any time, without re-exporting the scene.
Isolate objects, lights, materials, and even individual shader nodes for easier debugging of shading trees.
I’ve tried with heavy cad data, the same file, trying to do the same thing, This new render windows is lighting fast. The old Arnold Ipr comparing to the current V-ray Rr using Cpu was just a bit faster.
Whatever they did, is super speedy.
It’s not a matter of how heavy the model is; the rendering itself is fast enough, but the pipeline for getting the image from the renderer into the Maya viewport is extremely slow. If you compare V-Ray RT in Modo for example (and our internal V-Ray for Blender/V-Ray for Houdini implementations), it is a lot more fluid than what we have in Maya - there is certainly place for improvement.
Agree. The actual rendering speed isn’t an issue at all. The responsiveness, some isolation features (lights, materials, and objects), and less re-exporting the scene are what I hope to see in VFB the most.
I did some tests over the weekend with the same model where I can tumble in Maya’s viewport in 10 to 15 FPS. I tested PRMan RIS, Arnold, and V-Ray RT with default shader (PxDisney, AiStandard, and VrayMtl) rendered in single dome light with same HDR). Didn’t actually clock it but just generally feel it. Arnold bite through geo the fastest and start the IPR. Responsiveness wise, interestingly PRMan (“it”) is the fastest, then following by V-Ray RT (VFB) and Arnold (its new render view) the last. But one thing in Arnold’s that is cool is you can “pause” the IPR (untick continuous update), change some stuff, and then start IPR instantly by ticking the “continuous update”.
One feature we don’t have is detection of RenderElement addition/removal.
Are you adding or removing render elements often during lighting work?
I’m asking in order to know if this is something that is slowing you a lot in production.
For me, no. I rarely add AOVs on the fly and expect it to just pop-up in VFB’s drop down list. Isolating light contributing, material, part of shading tree, and object with live update and no re-exporting the scene would help much more for lookdev and debugging the scene in my opinion.
I generally feel that vray rt often reloads entire scene for no apparent reason, or some times just stops updating and I’m forced to close it. A more stable and fast rt would be great.
I also really would love the isolate texture on geometry feature. I use this all the time, but I have to connect a new shader to shading group to preview the texture. This would remove that step.
Totally agree on a more stable feature. On heavy scene, oftentimes when I am praying before I stop a RT session because upon I hit the stop IPR button (either the one in Maya’s render view or VFB), Maya would crash. The thing is the crash is pretty random. It forces me to save the scene first before I stop a RT session to make sure all scene edits are saved in case Maya crashes.
Ideally RT would only update objects which you are working on (I’m not sure if it does now) But I see it reload everything, geo, textures etc. Well if I modify for example a part of the geo, a part of the shader only those textures related should be updated/reloaded. This of course coming from not knowing how internally RT builds the structure weather such thing is even possible.
Unfortunately I couldn’t provide the production scene. Sometimes I “feel” if I turned off geo and bitmap caching, it helps a bit on the stability. But I really couldn’t reproduce exactly the crash. I have to say it crashes a lot and I wasn’t doing anything special. Simply just changing light attributes and positions. After 10 minutes or so, I pressed stop RT and Maya crashed.
I agree, its difficult to isolate and pinpoint the issue. Especially when you are in production under deadline and you have to get it done. This does not mean the issue does not exist. I’m not sure what process the RT goes through went its being tested, I’d really love to see production scenes tested in RT by the development team since you can best isolate issues on your side, vs us trying to explain and catch a problem. I think its safe to say that in a med/complex scene you can expect such problems to arise sooner or later.
FYI:
We’ve found some problems in the code related to the IPR update latency.
These are mostly fixed and so the IRP should be way more responsive in current night builds and also in the upcoming 3.30 builds.
Please test and report if this is not the case.
About the crashes:
The plugin has more verbose logging capabilities that are disabled by default.
Is anyone willing to do some lighting/rendering sessions with the logging enabled
and if there are crashes to provide the generated logs for inspection?
The logging is not enabled by default, because it slows down the exporter (it is really verbose).
Regarding the test with verbose turned on, how do I enable the verbose? And if RT CPU crashed, will the verbose still be saved somewhere so I can send it over for further investigating?
To enable the logging you need to:
1. Export/set the VRAY_FOR_MAYA_RT_LOGGING environment variable to ‘true’.
2. Start Maya. You’ll see in the log/output if you’ve set the it correctly.
The log will be saved in the %TEMP%/vray4maya_log.txt file.
I think we’re making sure that even if there is a crash the log will be fully saved.