I am currently learning about Solaris, USD, LOPs. I would need more time to be able to answer those questions. I’m not even sure how those things work with RenderMan.
I could be a bit clever and say, take RenderMan as an example on how to implement features.
I have a very complex tank asset and wish to break it down into small chunks. I wish to be able to have a solid understanding on how to surface the asset, so I can apply for jobs as a surfacing/texture artists. I have some upcoming projects involving massive amounts of assets to create an alleyway with a city in background.
I didn’t understand the alembic workflow and I believe I should invest in Houdini, USD, LOPs kind of scene assembly. One of the biggest advantages is that its render engine agnostic. I can author the assets with V-Ray and RenderMan shaders and parameters for example.
So for me, RenderMan is already well implemented. I would suggest using them as a guide for the V-Ray implementation.
I think the new workflow is very Katana like in that we need to set up procedural recipes with the use of tags and wildcards.
That’s the best answer I can give for now. I’m educating myself about this currently.
1. Supporting UsdPreviewSurface would be great to allow easy translation of simple scenes between renderers. For custom VRay shaders, I imagine you would have to do something similar to how renderman/karma implement shaders in a network that are then assigned to prims. I’m not too clued up on the progress of MaterialX and it’s integration with USD/Solaris but that could be an interesting option in the future.
2. Utilising preexisting USD prim vars would be ideal, for example “subDivisionScheme” if it was set to catmullClark vray would pick that up. For more advanced vray settings I guess these would have to be additional prim vars added to mesh and lights etc.
Solaris sounds nice and all, but I would rather have Vray 5 first
It is a game changer in many ways for our workflow.
Edit, actually solaris is more important like what other explained below
Not really. USD support and Lops is more important than the version bump that vray 5 is. From the new features coming the light mixer seems to be the biggest one, but that’s something we’ve had for a couple of years by now (through pipeline) so that’s won’t give us anything new, the coat layer yes, that’s great. The new VFB, sure why not, just a different window to look at your renders, the renders will still only look as good as you make them. But that fades compared to what USD represents to the CG industry, and the faster VRay can get there, the better. No USD, no clients in a not so distant future.
@david.anastacio I think our use cases are a bit different, we can disagree here which is fine honestly
Just wanted to say that Vray 5 is not just a version bump.. it is a massive update(at least for what we do) I have been using it in Maya/Max for months
-LPEs
-New sun/sky system
-Procedural streaks in Vray’s dirt
-Stochastic texture tiling
-New Carpaint/flakes materials
-UVW randomizer and all the randomization optons for gamma/hue/saturation
-Sharp Isotropic texture filtering, which is a big deal.. sharper details/better quality/faster to render
-Proper ACEScg support, the conversion, built to the file node or OCIO node, these ACES conversions are super fast(we needed to pre-convert everything in the past because the conversion used to be very slow in Vray) and in Vray 5 it doesn’t require OCIO setup in the frame buffer
-And that Frame buffer, is not just a new windows for displaying the renders(we have been asking about that for years).. could use LUTs directly with OCIO to experiment with different looks, could comp the elements directly in the frame buffer, or using Light Mix then applying the settings back to all lights in the scene..
-Updated proxies/faster IPR and time to first pixel
-And soon a new Caustics system, that Vlado showed recetnly
We use GPU quite a lot as well, which got a lot of updates, it almost feels like a new renderer now with features like Out of core, 2D displacment, secondary matte environment and more
I have also followed along with Renderman and Arnold progress on Solaris, it is quite a long journey before having something reliable that is usable in production.
@Muhammed_Hamed , no need to paste the feature list, we all know it very well
Yes our use cases are most likely very different, and from our perspective USD easily tops that whole list. Don’t look at USD as one feature, is a massive thing and it’s the future if scene assembly and file transfer.
And as you well pointed out, the USD road is a long one, and the other render engines are already on it and VRay not, so the sooner the better, or it might be too late. No USD, no fun.
@david.anastacio
Thanks for sharing your thoughts David, This makes a lot of sense and you guys know your stuff very well.
For the renders we do, all what comes to mind is getting from point A to point B in fastest way, saving couple of clicks here and there
Indeed on the bigger picture, USD seems to be way more important like what you kindly explained.
I think I will flip on this one, my vote now goes to USD and Solaris.
I hope I have educated myself enough with Solaris to answer;
We would like to have the option to pass the shader to UsdPreviewSurface as well as the V-Ray Frame Buffer. So we can see the shaders in the renderview using V-ray as a render delegate, and we can switch to render using the VFB.
Implement the settings as in Karma and RenderMan.
Light settings should be nested inside the lights already available as in RenderMan. So V-Ray parameters should have its own tab.
Physical camera would have its own V-Ray tab inside the already available camera
Geometry settings such as render time subdiv and displacement should be available in a geometry settings node just like with renderman.
I think Solaris is supposed to promote a render engine agnostic workflow, so we can pack assets with, presumably, a karma, renderman, vray, arnold version. I know Animal Logic Academy has a workflow to have a VFX and real-time workflow per asset so the asset can be seen in virtual production and VFX render.
Implementing V-Ray similarly to RenderMan will help to avoid confusion and promote the re-usability of node layouts. To be honest, Pixar made USD and was heavily involved with Solaris. Even Arnold and Redshift have a hydra render delegate. I was hoping V-Ray would be on top of this already since it’s the most important thing.
Houdini, Solaris, LOPs, USD is the future of scene assembly. It is ridiculously powerful and I hope it is developed robustly. It needs a lot of attention.
To get going we’ve tried to anticipate what the Chaos Group implementation could look like, and then written a USD-->VRay translator based on that (bypassing Hydra to focus more on final-frame output rather than IPR). Of course anything we write ourselves will eventually be redundant, so we’re hoping there’ll be some level of official support sooner rather than later.
At the same time we do understand that this is no small undertaking.
with features like Out of core, 2D displacment, secondary matte environment and more