modo procedural support

[lllab]

hi guys,

just to avoid some confusion from above posts, VRAYforC4D Does still support native c4d procedurals in rendering, also in new versions (1.9 and v3.25 beta), as the c4d sdk allows that. it only added also the V-Ray shaders from the sdk (those shaders are actually just from the V-Ray sdk, which Chaosgroup added to it. no native max or maya shaders are in there),
only when the V-Ray standalone on render nodes are used (for V-Ray DR p.e.) the c4d shaders cant be used as c4d is not installed and used there (but they still can be baked "on the fly to a bitmap" feature also there)

cheers
Stefan

[jonmoore]

Thanks for clarifying things Stefan.

It's for much the same reason that I would like to see wider support of V-Ray shaders in the Modo version. DR workflows will be somewhat restricted without a similar solution to the one you provide for C4D.

I was aware of the real time baking solution for C4D procedurals and was actually going to suggest something similar to Vlado with regards to Modo (although it's still not my preferred solution).

I haven't had access to VrayForC4d for a while but have been told that the SDK shaders function standalone in C4d too, not just as part of DR tasks. Is this not the case?

It was my assumption that the SDK shaders named XSI***, Max*** and Maya*** were Chaos Group shaders that were unique to each platform but included in the standalone for network rendering tasks - hence you having access to them for VrayForC4d. I'm sure I've got a few of the specifics wrong in my assumptions though.

jm

[lllab]

"I haven't had access to VrayForC4d for a while but have been told that the SDK shaders function standalone in C4d too, not just as part of DR tasks. Is this not the case?"

the c4d shaders and vray native shaders work along side within c4d,yes.
when used DR only vray native or bitmap baked shaders can be used (a standalone cannot render native shaders from a host app)

by the way from my tests with modo V-Ray, i think it is an excellent V-Ray version.

[vladimir.nedev]

Here's that screengrab as promised. As you can see VrayForC4d bundles a bunch of Max, Maya & Softimage shaders as part of the package.

[ATTACH=CONFIG]25058[/ATTACH]

I've modified the image with information on each texture (save a few I couldn't figure out, since I don't have V-Ray for Cinema 4D).

Green dot means it is already in V-Ray for MODO in either "V-Ray Textures" or "V-Ray Textures procedural".

Light blue dot means it can be done with some native MODO construct (shader tree blending or gradient texture usually), that is supported by V-Ray for MODO.
In some cases, it might be worth adding the actual texture though, for example MODO has "Color blend" texture for the Schematic, but it can blend only 2 textures.
It has been requested to add something similar to TexLayered or TexLayeredMax that can blend multiple textures.

Yellow dot means it is similar to a V-Ray texture that is already in V-Ray for MODO. Some of these I can add, but it might be confusing to have multiple very similar textures.
For example, I think Bercon wood is definitely better than "Wood"(which is something we implemented for Maya) or "VRayWood"(which is something we implemented for XSI).
VRayFlagstone on the other hand is similar to "V-Ray Cellular", but can sometimes give better results.

Red dot means I should probably add it at some point.



Greetings,
Vladimir Nedev

[vladimir.nedev]

I was aware of the real time baking solution for C4D procedurals and was actually going to suggest something similar to Vlado with regards to Modo (although it's still not my preferred solution).

If you are going to resort to baking, it might be better to look into something like the "Substance" textures.
They are designed to be baked to 2D image maps, so they can be used in game engines.
Baking procedural textures, kind of negates their most powerful features :
- they don't take RAM
- you can zoom in/out on them pretty much infinitely
- you can tile them infinitely with no repetition
All of these are gone, once you bake the procedural texture.

Greetings,
Vladimir Nedev

[jonmoore]

Good to see that many of these are on your radar for future inclusion.

There are are few of your 'red dot' nodes that I'd like to see added as a priority and Ramp is probably at the top of this list. I'm aware that similar things can be achieved with Modo's gradient but having the Ramp node available will aid with converting materials originally created in Max/Maya (so many glossy surfaces are created with Ramp's in Max/Maya versions of V-Ray).

It's more a workflow thing really. Until the likes of Evermotion sell their wares as native Modo assets, the population of ArchViz renders with pre purchased 'set furniture' (you don't always have the luxury of modeling/surfacing every little detail) will rely on the conversion of Max assets.

It's also worth re-iterating that the reason it's important to have Vray native SDK nodes (even where Modo native versions exist) is for DR/Network rendering. Unless you're going to add the Modo native nodes to the V-Ray standalone, artists will need to ensure they're using V-Ray native nodes for DR/Network rendering to function properly. At least this is my understanding of how it functions on other platforms. This is also an area where the VrayForC4d (real-time) render time baking of C4D procedurals becomes a useful workaround. DR rendering of scenes using C4d native nodes would otherwise be impossible.

Thanks again for looking into this Vladimir.

jm

[jonmoore]

If you are going to resort to baking, it might be better to look into something like the "Substance" textures.
They are designed to be baked to 2D image maps, so they can be used in game engines.
Baking procedural textures, kind of negates their most powerful features :
- they don't take RAM
- you can zoom in/out on them pretty much infinitely
- you can tile them infinitely with no repetition
All of these are gone, once you bake the procedural texture.

Greetings,
Vladimir Nedev

The clever thing with the VrayForC4d solution is that everything remains procedural and is only converted to textures as part of the render process. This way you keep the infinite zooming capabilities of procedurals but the Vray DR nodes (utilizing the Vray standalone) is able to make use of native C4D procedural info. This will obviously slow down the renders if a lot of procedurals have to be baked on the fly but it seems a reasonable compromise to me. If infinite scaling isn't required the artist always has to choice to pre bake their procedurals - Modo artists can do much the same thing now.

[jonmoore]

If you are going to resort to baking, it might be better to look into something like the "Substance" textures.

Greetings,
Vladimir Nedev

Are Algorhythmic Substance textures supported in the same way in Vrar/Modo as they are in Vray/Maya? I'm a huge fan of Substance for texturing 'set furniture' (anything mid to far distance from camera).

[vladimir.nedev]

It's also worth re-iterating that the reason it's important to have Vray native SDK nodes (even where Modo native versions exist) is for DR/Network rendering. Unless you're going to add the Modo native nodes to the V-Ray standalone, artists will need to ensure they're using V-Ray native nodes for DR/Network rendering to function properly. At least this is my understanding of how it functions on other platforms. This is also an area where the VrayForC4d (real-time) render time baking of C4D procedurals becomes a useful workaround. DR rendering of scenes using C4d native nodes would otherwise be impossible.

I am not using any native MODO nodes currently.
Every MODO native shader/texture that is supported is implemented using V-Ray standalone plug-ins (some of them already existing, some of them I wrote).
If and when The Foundry provide support for sampling their procedural textures, DR will become an issue. But currently it is not.

Note that the V-Ray standalone plug-in that I wrote for supporting MODO features is currently not part of the V-Ray for Max/Maya installations.
We can easily add it, but even if we do, it will always be better to use the V-Ray standalone from V-Ray for MODO for DR purposes. This ensures that you have
exactly the same version of the plug-ins. We may have changed something very small, and if the versions don't match, you get slightly different buckets, which are very apparent.

Greetings,
Vladimir Nedev

[vladimir.nedev]

Are Algorhythmic Substance textures supported in the same way in Vrar/Modo as they are in Vray/Maya? I'm a huge fan of Substance for texturing 'set furniture' (anything mid to far distance from camera).

The 701 version of the Substance for MODO plug-in should be fully supported - you can even modify tweaks in V-Ray RT or animate them in production rendering.
The latest 801/901 version doesn't quite work, as my initial implementation was for the Beta version of the 801 Substance plug-in.

And I've had some problems with the Substance plug-in release that can be downloaded from The Foundry site - modifying tweaks doesn't update even in MODO's preview or OpenGL renderer.
So I am still trying to get it to work.

Under the hood, I think V-Ray for MODO does the same thing that V-Ray for Maya does - the substance textures are stored as internal "bitmap buffers". That might cause exported vrscene files to become
quite big, so if you are done tweaking them, it might be best to bake the substance textures as image files on disk. Then they can be handled by the DR asset cache, and speed up DR scene transfer.

Greetings,
Vladimir Nedev

[jonmoore]

I am not using any native MODO nodes currently.
Every MODO native shader/texture that is supported is implemented using V-Ray standalone plug-ins (some of them already existing, some of them I wrote).
If and when The Foundry provide support for sampling their procedural textures, DR will become an issue. But currently it is not.

Note that the V-Ray standalone plug-in that I wrote for supporting MODO features is currently not part of the V-Ray for Max/Maya installations.
We can easily add it, but even if we do, it will always be better to use the V-Ray standalone from V-Ray for MODO for DR purposes. This ensures that you have
exactly the same version of the plug-ins. We may have changed something very small, and if the versions don't match, you get slightly different buckets, which are very apparent.

Greetings,
Vladimir Nedev

That makes more sense now.

VrayForC4d appears to use the standard generic V-Ray standalone and I thought that the Vray for Modo standalone would follow the same methodology. I hadn't realised that V-Ray for Modo ships with a bespoke standalone for DR/Network rendering as my test workstation isn't set up for network rendering.

Just to ensure that I'm understanding things fully. If I had a scene that makes use of native Modo gradient nodes for glossy materials (because Ramp isn't available), is the V-ray for Modo standalone able to read the native Modo gradient when DR/Network rendering?

Hope the question makes sense.

jm

[jonmoore]

The 701 version of the Substance for MODO plug-in should be fully supported - you can even modify tweaks in V-Ray RT or animate them in production rendering.
The latest 801/901 version doesn't quite work, as my initial implementation was for the Beta version of the 801 Substance plug-in.

And I've had some problems with the Substance plug-in release that can be downloaded from The Foundry site - modifying tweaks doesn't update even in MODO's preview or OpenGL renderer.
So I am still trying to get it to work.

Under the hood, I think V-Ray for MODO does the same thing that V-Ray for Maya does - the substance textures are stored as internal "bitmap buffers". That might cause exported vrscene files to become
quite big, so if you are done tweaking them, it might be best to bake the substance textures as image files on disk. Then they can be handled by the DR asset cache, and speed up DR scene transfer.

Greetings,
Vladimir Nedev

Very useful information Vladimir. It's easy enough to change the config file to read the 701 Substance plugin in 801+.

[vladimir.nedev]

If infinite scaling isn't required the artist always has to choice to pre bake their procedurals - Modo artists can do much the same thing now.

I don't understand this part - even if you are doing the baking on the fly, you won't have the infinite scaling.
When baking you need to give the procedural texture a fixed set of UV coordinates.
Based on how it was applied on the geometry, you might bake too much or too little of it.

Greetings,
Vladimir Nedev

[vladimir.nedev]

That makes more sense now.

VrayForC4d appears to use the standard generic V-Ray standalone and I thought that the Vray for Modo standalone would follow the same methodology. I hadn't realised that V-Ray for Modo ships with a bespoke standalone for DR/Network rendering as my test workstation isn't set up for network rendering.

Just to ensure that I'm understanding things fully. If I had a scene that makes use of native Modo gradient nodes for glossy materials (because Ramp isn't available), is the V-ray for Modo standalone able to read the native Modo gradient when DR/Network rendering?

Hope the question makes sense.

jm

Yes, it will read it.
If you want to see the scene that V-Ray for MODO creates internally, you can go to File -> Export As and choose the "VRay (.vrscene)" format.
This is pretty much what gets sent to the DR slaves and also what V-Ray for MODO renders internally.

The MODO gradient is actually converted to two V-Ray standalone plug-ins : TexColorCurve (which we wrote for XSI initially) and TexModoSampler (which I added),
which implements the different "inputs" of the gradient texture (like incidence or thickness).
TexModoSampler is part of the V-Ray standalone that comes with V-Ray for MODO. It is not yet added to the standalone that comes with V-Ray for Maya, for example.

Greetings,
Vladimir Nedev

[jonmoore]

I don't understand this part - even if you are doing the baking on the fly, you won't have the infinite scaling.
When baking you need to give the procedural texture a fixed set of UV coordinates.
Based on how it was applied on the geometry, you might bake too much or too little of it.

Greetings,
Vladimir Nedev

What I mean by this is that on the primary workstation (and the OpenGL viewport) the artist is working with native procedurals. But as soon as they fire off a render, the C4D native procedurals are baked to textures on the fly (and I would suppose cached somewhere). If the camera view is changed the procedurals are re-baked and sent to the DR nodes. I'm working from memory here, so I'm sure Stefan can provide more info if he's still reading this thread.