What should we expect about V-Ray for Modo release/price/continuity?

[Dentzz]

By that do you mean more stuff updating correctly or do you mean RT GPU ?

Greetings,
Vladimir Nedev

Sorry wasn't clear, I meant extended RTGPU support. I think that it was one of the more obvious differences between Modo's Render engine and Vray. So might be nice to have extended texture support and gpu final frame rendering for animation, etc. sooner rather than later.

[vladimir.nedev]

I'd vote for extended V-ray RT support as a strong top pick

By that do you mean more stuff updating correctly or do you mean RT GPU ?

Greetings,
Vladimir Nedev

[Dentzz]

I'd vote for extended V-ray RT support as a strong top pick
Would also vote for
Variation texture modes and
Volume Grid

[BVA]

This is my wish above everything else. Being able to import and reuse stuff from Max/Vray is really important if you want to hit the ground running with MODO/Vray. I think this could make it an insta-buy for a lot of the people that are moving beyond Max/Vray. I know that I would make a big marketing thing out if this feature, if it was me.

You might be right. We have a huge asset library for max/ vray. Opening a max file, convert all materials to std materials, export obj, import obj in modo, redo textures is really a tedious process! If there is any way to import models into modo and keep all the vray settings/ shaders would really be great. And, most libraries online is for max/ vray. So this would ease the mind for a lot of people. And really help us a LOT

[WilleViz]

As for a road-map, maybe it is a good idea to have some kind of vote here, on which of the bigger features to implement first.
Most of them will require between 2 and 4 weeks EACH, maybe even more for some of them.
Here they are:

- import of materials/textures/lights/render settings from .vrscene files

Greetings,
Vladimir Nedev

This is my wish above everything else. Being able to import and reuse stuff from Max/Vray is really important if you want to hit the ground running with MODO/Vray. I think this could make it an insta-buy for a lot of the people that are moving beyond Max/Vray. I know that I would make a big marketing thing out if this feature, if it was me.

[vladimir.nedev]

I have done a few tests this morning with RT GPU...on my gtx970 it is a lot faster than cpu So if I can alter my "big dreams list", please can we get more/ better RT GPU integration.
It will make the production a lot faster

I haven't followed the RT GPU discussions and am not sure where to start searching for a list of limitations. I found that all my lights are hard with no falloffs on the shadows...is that a setting or a limitation at the moment?

Can you start a separate thread specifically for lights' support on RT GPU ?

Greetings,
Vladimir Nedev

[BVA]

I have done a few tests this morning with RT GPU...on my gtx970 it is a lot faster than cpu So if I can alter my "big dreams list", please can we get more/ better RT GPU integration.
It will make the production a lot faster

I haven't followed the RT GPU discussions and am not sure where to start searching for a list of limitations. I found that all my lights are hard with no falloffs on the shadows...is that a setting or a limitation at the moment?

[janko22]

For me it's:
- texture baking (gi and lighting)
- full variation texture support
- missing render elements
- mesh light
- vray fur

Thanks for your great work Vladimir.

[jonmoore]

I'd like to see modo's procedurals as well, but we really need TF to provide access to them through the SDK.

It would suck if every 3rd party renderer has to reinvent the wheel and implement their own automated baking (which I'm guessing would be pretty slow)

We need to get TFs attention on this issue They are already doing some cool things along these lines with the rendercache API (for geometry though), so I don't think it would be too hard to convince them.

Excellent news.

The problem that exists in VrayForC4D is that the render nodes are powered by a generic Vray standalone (at least this is the case with the existing VrayForC4d engine which uses the 2.4 Vray core). So baking of C4D procedurals is the only way of DR/Network rendering with native C4D procedurals. On a single workstation VrayForC4d utilises C4D's native procedurals without baking.

As I understand it VrayForModo ships with bespoke Modo specific render node standalones so maybe this might provide a solution for Modo native procedurals in the long run.

[1funk]

I'd like to see modo's procedurals as well, but we really need TF to provide access to them through the SDK.

It would suck if every 3rd party renderer has to reinvent the wheel and implement their own automated baking (which I'm guessing would be pretty slow)

We need to get TFs attention on this issue They are already doing some cool things along these lines with the rendercache API (for geometry though), so I don't think it would be too hard to convince them.

[jonmoore]

EDIT: I'm sorry I just noticed you only quoted the second part of my post which refers to "bake to texture" etc. Yes... in the case of bake to texture, there really would be no reason to do that in V-Ray now that I think about it.

All good.

The main thing I'm pushing for is the automated bake of procedurals at render time (in the same manner as VrayForC4D). Although I wouldn't expect a feature of this nature in the first couple of service packs; Vladimir has bigger fish to fry first.

[1funk]

Unless I'm misunderstanding things

Yes, you are misunderstanding

I'm interested in baking V-Rays shading (GI and lighting) into textures (the equivalent of "bake to render outputs" in modo)

EDIT: I'm sorry I just noticed you only quoted the second part of my post which refers to "bake to texture" etc. Yes... in the case of bake to texture, there really would be no reason to do that in V-Ray now that I think about it.

[jonmoore]

Modo has other types of baking too eg.
"Bake to texture" in the shader tree is like flattening several layers in photoshop.
Baking from object to texture, which is useful for doing normal maps from high to low poly objects etc

I assume V-ray supports something similar too.

Unless I'm misunderstanding things I think the only way to achieve something similar in Vray for Modo at the moment is to bake down using the Modo native engine then treat the those bakes as any other texture as part of your Vray workflow.

A month or so back Vladimir and I were discussing the way this is approached in VrayForC4D with regard to C4D's native procedural textures. VrayForC4D allows you to use native C4D procedurals but bakes them at render time so any Vray render nodes can make use those C4D native procedurals whilst C4D maintains the procedural nature of those textures in the scene file. It's nifty workaround and something that I think would be welcomed in Modo at some point.

[kubbek]

The shade map is a way of speeding up stereo rendering that V-Ray for Max/Maya have.
I think it involves rendering the image in two passes - first pass renders the center of the two eyes storing the shading computations in a shade map(which I think is similar to a deep EXR),
the second pass renders both the left and right eye, but reuses the shading from the first pass (the shade map) to speed things up.
Without the shade map, it might be very easy to add stereo rendering.

Greetings,
Vladimir Nedev

I would surely experiment with stereo 3d rendering even without shade map. We are currently developing our VR pipeline and I would find use for V-Ray there also. Speeding things up is always welcome though

[1funk]

Texture baking would be great! I assume it's the same as Modo's "bake to render outputs", which lets you bake your render outputs to a selected UV map. I don't have experience with V-ray in other applications.

Modo has other types of baking too eg.
"Bake to texture" in the shader tree is like flattening several layers in photoshop.
Baking from object to texture, which is useful for doing normal maps from high to low poly objects etc

I assume V-ray supports something similar too.