vrayScene nodes issues

[Gosho.Genchev]

Hey David,

Indeed, I am aware it gets to convoluted workflows for splitting things up once many different volumes are involved. We'll try to get it sorted out, I apologize if it's causing too much inconvenience.

Best regards!

[david.anastacio]

Gosho.Genchev hey, any updates in this front?

[Gosho.Genchev]

Hey David,

Yes, sort of ... Turns out the slowdown is coming from writing the VRScene on disk. The way to resolve this would be to change how instancing of volumes is handled - we're already looking for a solution.
As to the cooking issue - we've had some urgent tasks on our plate so we were on and off of it for some time - I'll check with the devs if we can take care of it soon and inform you.

Thank you!

[david.anastacio]

Hey David,

Yes, sort of ... Turns out the slowdown is coming from writing the VRScene on disk. The way to resolve this would be to change how instancing of volumes is handled - we're already looking for a solution.
As to the cooking issue - we've had some urgent tasks on our plate so we were on and off of it for some time - I'll check with the devs if we can take care of it soon and inform you.

Thank you!

Thanks for the update.
Would be great to get those vrscenes going faster, I see render scenes of volumes everyday getting generated at snail pace
What about the material unpacking from the vrscenes in Houdini? Anything coming?

best,
David.

[Gosho.Genchev]

Hey David,

We've decided to focus heavily on USD and Solaris. We absolutely understand that you can't sit idle meanwhile so any issues that might pop up will be resolved. Missing nodes when importing the material is usually caused by the actual V-Ray plugins not being registered for V-Ray for Houdini - this is usually not hard to handle but as silly as that sounds - we need to deal with this on a case by case basis. This past week we added a couple new nodes (which are hidden since they duplicate other nodes in functionality) specifically for VRScene material import compatibility. Could you check if you're still having issues with this ? If so, sending me the VRScene through email, or even a screenshot of the error that pops up, should be enough for us to look into the problem and fix it.

[Would be great to get those vrscenes going faster, I see render scenes of volumes everyday getting generated at snail pace

Just to clarify - we're talking about instanced volumes in the thousands, correct? I'm asking because if you only have a few instances, or none at all, this shouldn't happen.

Best regards!

[david.anastacio]

Hi again,

We've decided to focus heavily on USD and Solaris. We absolutely understand that you can't sit idle meanwhile so any issues that might pop up will be resolved. Missing nodes when importing the material is usually caused by the actual V-Ray plugins not being registered for V-Ray for Houdini - this is usually not hard to handle but as silly as that sounds - we need to deal with this on a case by case basis. This past week we added a couple new nodes (which are hidden since they duplicate other nodes in functionality) specifically for VRScene material import compatibility. Could you check if you're still having issues with this ? If so, sending me the VRScene through email, or even a screenshot of the error that pops up, should be enough for us to look into the problem and fix it.

That's actually great news, although the vrscens not fully working present us some drawbacks currently, we'll give it a try with the new VFH build, 4.3 or 5 the new nodes?

Just to clarify - we're talking about instanced volumes in the thousands, correct? I'm asking because if you only have a few instances, or none at all, this shouldn't happen.

Nope, just with a single volume, it's very slow and uses quite a bit of ram. Both with Vray 5 and 4.3

Here's a recent vrscene file generated on deadline with VFH5:

A single volume in an empty scene (not even lights in it), 27 minutes for 71 frames, and the resulting vrscene is 330KB. The volume is loaded is a VDB and is set to delayed load primitives. And the ram usage is higher than it should be and indicates the volume is being read for each frame. This is what I already explained in the previous posts in this threads, nothing changed yet.

Best,
David.

[Gosho.Genchev]

Hey David,

This could only mean the volume is being baked into the VRScene for some reason. I'll check right away and message back ... my understanding was the problem was different.

As to the builds with the added nodes - the changes are from Jan 29th, in V-Ray Next - not yet merged in V-Ray 5.

Best regards!

[Gosho.Genchev]

Hey David,

A single volume in an empty scene (not even lights in it), 27 minutes for 71 frames, and the resulting vrscene is 330KB. The volume is loaded is a VDB and is set to delayed load primitives. And the ram usage is higher than it should be and indicates the volume is being read for each frame.

Could you please check if that also happens locally - simply set the Renderer -> Export -> Export Mode to "Export & Render" - the VRScene will be written next to your .hip file. If you then open it with a text editor, it should look like this (note the PhxShaderCache plugin):



If it's being baked, it will look like this ( vdb_stream instead of cache_path being populated):



This should only happen if you're editing the voxel data. We added support for some basic nodes, e.g. Transform SOP, Merge SOP so those should not force a bake. I'm at a loss here - I've tried what I could think of and the behavior is correct on my end - I suppose it could be something we've overlooked.

Thank you!

[david.anastacio]

Hey,

As to the builds with the added nodes - the changes are from Jan 29th, in V-Ray Next - not yet merged in V-Ray 5.

Thanks for the info.

This could only mean the volume is being baked into the VRScene for some reason. I'll check right away and message back ... my understanding was the problem was different.

No, this was always the issue, in another post we reported that: https://forums.chaosgroup.com/forum/...port-with-vdbs

The volume is NOT getting baked as I stated, the resulting vrscene file for that example was a mere 330KB, the vrscene contains only a link to a VDB, if it was getting baked the vrscene would reach 200GB, as the volume had around 3GB per frame.
It's always been like this with volumes, I have never seen V-Ray behaving otherwise when generating the vrscenes with volumes inside it. In the link above to the other thread post, I describe the issue in detail and the setup to load the VDBs.
The other comments about instancing volumes is also due to this as more copies of the volumes you have in the scene the more ram it takes when generating (eg: 1 volume takes 6gb, 1 additional instance of that volume takes 12gb, 9 additional instances of that volume take 60gb, boom no more ram to generate the vrscene).
Nothing is done to the VDBs, they come in with a file node, loaded as Packed disk Primitives and a shader is applied to them in the object level (not through shop_materialpath).

This is the setup of that previous test:



Best,
David.

[Gosho.Genchev]

Hey David,

Well ... I need to apologize - that's a massive mess up on my side - your scene from the other forum thread does reproduce it reliably, and it's not related to instancing which was my assumption. One of the devs just started looking into this ... I hope we'll have a fix shortly - I'll keep you informed.

Thank you!

[david.anastacio]

Hey David,

Well ... I need to apologize - that's a massive mess up on my side - your scene from the other forum thread does reproduce it reliably, and it's not related to instancing which was my assumption. One of the devs just started looking into this ... I hope we'll have a fix shortly - I'll keep you informed.

Thank you!

Tha's awesome thank you for looking into it

[Dubbie99]

Did this issue get resolved?

[glacierise]

Not yet as far as I know