vrscene, primaryvisibility

[monsteradurm]

Im export vrscenes to nuke using vray for maya. As an example, I have 2 vrscenes. 1 is a character the second is a prop.

On the character VR scene, the prop has its primary visibility off ( in an object properties node ).
On the prop VR scene, the character has its primary visibility off.

If i plug the character VR scene into nuke, it displays only the character - perfect.
If I then also plug the prop VR scene into nuke, the character doubles up on top of itself.

Is this expected behavior and is there a way around?

[Christophe.Cot]

The primary visibility attribute is set directly in the Node plugin and this is properly parsed by the VRayScene node.
Quick test here shows it works fine.
Can you compare the 2 vrscene and ensure the "Node :: primary_visibility" of the character in the prop scene is really set to 0 ?

I am not sure about your workflow here but if you set the object prop just to be able to separate both group in Nuke, I would suggest to use instead the full potential of the VRaySceneAsset and define the character and the prop as 2 separate asset.
You would then be able to use the VRaySceneGeometry node and directly select each of those asset. Eventually you could also define specific customization stage so that directly in Nuke you can fine tune material of individual parts without going back into Maya.

[monsteradurm]

To clarify - Are you saying I can use VRaySceneGeometry to load in a parent of the hierarchy ( and therefore all of its children ) as opposed to just individual geometry nodes ? I wasnt aware this was possible - ive only seen the individual geometry nodes. If i cloud plug the ObjectProperties group, or the parent of the asset hierarchy this would be much more preferable.

I can also confirm that primaryvisibility is infact off in the example I mentioned. The VrayScene files correspond to rendered EXR sequences, so I can confirm that the rendered EXRs look correct ( with primary visibility off on the intended assets ).

[Christophe.Cot]

The VRaySceneGeometry can be used in 2 different ways :

1) To load individual top level "Node" plugin from a vrscene (what you seems to do now).
2) To load an asset which is defined as a group of top level Node plugin which represent a more complex object (ex: a car object composed of seat, doors, wheels,. etc.. the "car" is the asset).
In the vrscene, there would be a bunch of top level Node plugin for all the elements - there is no higher parent than the Node plugin.

In both cases, the VRaySceneGeometry load either a single or a group of Node plugin all together. In both cases it will load the entire scene hierarchy of the Node plugin i.e. geometry, material,..
If in your scene you have many Node plugin which represents all together a specific asset (ex: the Character), it might be beneficial to use the option 2 and define your character as a VRaySceneAsset.
To do so, currently it requires some writing of the VRaySceneAsset definition.

If you feel you are in this use case, here is an example how to do it : https://drive.google.com/drive/folde...ut?usp=sharing
Let me know if you have any question about this.

[monsteradurm]

Thankyou, this looks very helpful. I could definitely get this to work on the asset level - though my query stems from the ability of the "included" vrscene to be dynamic in nature. Since there would be a new vrscene path for each scene, i would need to copy the vrscene with the asset description into each respective scene. With this in mind, could I use the post translate script in maya to create the sceneasset description ? Or is there another way I could use one vrscene containing the vrsceneasset description, but changing the linked path in nuke to the "default" vrscene.

[Christophe.Cot]

The VRaySceneAsset being a regular VRay plugin, indeed you can perfectly create and set it directly in post translate in Maya if you want.

What you can do to really make it quick is simply to prewrite the VRaySceneAsset plugin definition is a separate vrscene and then add this scene content via post translate.

from vray.utils import *
addSceneContent("path_to_the_vrscene_file_with_only_the_vraysceneasset_plugin/template.vrscene")

This will works - tested.

If you try to set the VRaySceneAsset directly by creating and setting it via post translate, there is a little problem that affects the asset_param_definition parameter:
This param requires a ListString() type for the parameter description. Using python post translate, I do not find a way to force this type, instead setting a python list will be converted to a List() type which is different.
The internal parsing checks for a ListString and as a result this specific point does not work.
If you do not use the asset_param_definition, you can create and set everything else via post translate.
Example:

vrsa = create("VRaySceneAsset", "myAsset")
vrsa.set("asset_name","Spheres")
nodes = [n for n in findByType("Node") if "Sphere" in n.name()]
vrsa.set("asset_plugins", nodes)

I will probably try to fix the ListString set via post translate later so that full post translate can be done but for now the addSceneContents will just work fine.

[monsteradurm]

Thats very interesting!

Sorry for all of these questions, im just brainstorming the best way to handle the asset pipeline for this particular project.

As another alternative, Could I use the vrsceneplugin to load the vrscene with the asset definition and then the override snippet to load in the default vr scene (or vice versa)? My thinking is if I am doing it this way I could potentially map a path from an attribute (assuming the override snippet could query the value of a node in the scene or root).

[Christophe.Cot]

I don't think you can use the override snippet to do anything more than modifying/overriding existing scene content. I am not aware being able to query or do something more complex so I don't think the direction will lead to something.
If you aim at making this include of the source vrscene file a bit more dynamic, how about making this include point to a proxy file such as a symlink pointing to the correct vrscene to use, then set this symlink via the regular Nuke python callback before render or before each frame ?
If the vrscene are named according to the frame they represent, you should be able to query the current frame from Nuke and compose the correct file name to symlink.
Of course after this is done, you will need to force a Reload on the VRaySceneGeometry.
Not sure if this is feasible though but that's the first thing that pops up in my mind.

[monsteradurm]

Yeah thats fair enough. I don't think symlinks would be viable for the project. I think your initial suggestion of post translate in maya with addSceneContent is the most robust/simplest solution. The only potential issue being that if the asset definition changes, the vrscene would need to be rewritten to account for that. Assuming there isnt any way of writing an include header with a path so that the asset definition is read on the fly with the vrscene file in nuke.

[Christophe.Cot]

Yes that's why I usually favors the usage of #include for the original source with the vrscene asset definition so that the source is decoupled from the asset definition.
But then we come back to the original remark that the animated scene should be exported within a single vrscene file otherwise we get this relink issue that you now have.
I don't think it is possible to write an explicit include header in the vrscene file via the VRay API though. Maybe however you could do that via a post render/export mel script ?

[monsteradurm]

Very true, that's a much better/simpler suggestion..

In the example provided the include references the "default" vr scene from the asset definition. Just to clarify, Is it problematic to include the asset definition from the default scene?

[Christophe.Cot]

I don't think it is problematic but it's the opposite of the goal which is to keep the source scene unaffected by the VRaySceneAsset definition.
For example if you re-render the source vrscene, it would overwrite your include so you need to re-add it somehow.

[monsteradurm]

I can see your point. I was just thinking if the post-render script added an #include to the top of the vrscene, then the definition would be read on the fly with nuke. Id have the post-translate set as a renderlayer override in maya to coincide with the asset that was being rendered for that renderlayer.
Alternatively I could have it write a third vrscene, with both the default and asset definition included which is what I would plug in to nukes vrscene plugin.