Network Rendering

[Moriah]

I've tried the deadline one as psanitra said, and its working. However, on a very simple scene with an HDRI, ground plane and the test geometry crag, the workflow is very primitive and non efficient. If i want to render 100 frames, it has to calculate locally on my machine a vrscene with 100 frames with only those objects, and it takes about 1.5GB in file size. Now, when i send this to the network, each machine will have to read the same 1.5GB file to start a single frame, and right now its taking 2min to read it and 10secs to render... So i tried adding $F and it's quite more manageable now!

Question is, how about bigger files? With hundreds of objects, and even simulations?? Let's say i have a flip fluid with a cache per frame of about 500mb (which is quite often). Does the vrscene reference the cache, or does it include the 500mb cache in the vrscene file?

Or let's say a cartoonish animation, with hundreds of characters, alembic files, environment, textures, etc. Does the vrscene reference the textures / alembics / caches? Or include everything in the vrscene?

Is there something like the delayed load feature in Mantra for vray?

Sorry if these questions seem primitive or dumb, but right now we're evaluating if it's worth it to assemble and render everything in houdini instead of 3dsmax. In max it's quite simple and straight forward, let's hope we can have something close to that in houdini

[Gosho.Genchev]

Alembic files, textures, VRScenes (imported using the VRScene SOP), V-Ray Proxies, Volumes are referenced from the files on disk, as long as you are not modifying the topology or voxel information (for volumes). You can transform alembics and volumes without breaking the referencing.

Importing obj, bgeo, FBX, etc. (ie. actual geometry) will bake the mesh info into the VRScene. The same goes for rendering live volumes or modifying a volume cached to disk (e.g. with a Volume Wrangle) and hitting render. COP images are also baked into the VRScene.

Hope that helps!

[Moriah]

Helps indeed, i did a few tests and so far it references everything correctly as long as it's properly cached. Is there any option to calculate the vrscene in the farm via deadline? Like the ifds from mantra

[Gosho.Genchev]

If this ( https://docs.thinkboxsoftware.com/pr...man-standalone ) is what you are referring to - no, unfortunately for the time being there is no way to do this, as far as I can tell. I believe Thinkbox should add this option on their end.

The closest you can get to this is using the Deadline ROP to submit the hip file. Once that's done, Deadline will launch the hip file with hython and render the V-Ray Renderer ROP. For this to work, the environment variables specifying where V-Ray is located need to be provided in the //Repository\plugins\Houdini\JobPreLoad.py file. I'm currently adding this as a short guide in the docs section.

[Gosho.Genchev]

Hey Moriah , I'll publish a guide today; delayed it yesterday because I had trouble loading V-Ray from a network location and I wanted to figure out what's causing it before publishing information that may not work.

Cheers!

[Gosho.Genchev]

I've published a simple guide here:
https://docs.chaosgroup.com/display/...line+and+V-Ray

Will update the example python file when I get the chance to test with a Linux setup.

[tronotrond]

Thanks for all these great guides and info! I came here exactly for this.
I've been exporting vrscenes per frame (huge files and extremely long export). It renders fine, but yeah. Needed to find ways to optimize that for sure. I'm going to give the references a go.

A couple questions;
- If I import bgeo.sc from disk containing just a 3D model - no modifications done to the geometry, but materials added (perhaps some attributes changes?). Can or will this be referenced from disk? What's the ideal and recommended workflow with V-Ray?
- We have V-Ray standalone working. I export vrscenes from the render ROP, and just submit those from within Deadline Monitor. What are the differences when adding the QT libraries and everything to V-Ray for Houdini? Might be a silly question, but are there any potential render or compatibility differences?


Thanks!

[bdancer]

> Can or will this be referenced from disk?

In the exported vrscene file? No. We do not support this file format. All data will be baked into the vrscene file.

> What are the differences when adding the QT libraries and everything to V-Ray for Houdini?

Differences compared to what? If you won't add Qt libraries "vray.exe" binary will just wont load. We are working on shipping Qt libs anyway, so this should not be an issue soon.

[Gosho.Genchev]

- We have V-Ray standalone working. I export vrscenes from the render ROP, and just submit those from within Deadline Monitor. Haven't done the process of adding the QT files at environment variables though. What are the differences here?

Simply put, you can either use V-Ray Standalone to render the VRScenes, or you can use the VRayForHoudiniFolder/appsdk/bin/vray.exe to render the VRScenes.

Standalone should, in theory, give you identical results but it's possible a change made specifically for V-Ray for Houdini was not picked up when V-Ray Standalone was built and distributed. This happened recently so we took note and hopefully won't happen again.

On the other hand, if you use the vray.exe from the V-Ray for Houdini folder to render the VRScenes, the result will be 100% identical to rendering from within Houdini (and if it is not, that is a bug we should fix so please ping us). Using the V-Ray for Houdini exe file requires the QT libraries, though. The reason behind this, afaik, is that the Frame Buffer for V-Ray for Houdini is implemented in a different way than the one in Standalone, and relies on those QT libraries.

- If I import bgeo.sc from disk - no modifications done to the geometry, but materials added (perhaps some attributes changes?). Can or will this be referenced from disk? Does the file node have to be set to packed disk primitive? Or what is the recommended work flow to keep things light?

No, bgeo, bgeo.sc, obj, and so on ... files (and any format other than Alembic, VRMesh, VRScene and VDB) are baked into the VRScene when you hit render.
If you want everything referenced from disk, in my personal opinion, your best option is Convert to Poly Soup -> cache to Alembic.

Hope that helps!

[Moriah]

Are there any plans to support bgeo and bgeo.sc references in the future? This is a big problem for us since a lot of cashes are done in that format

By the way thanks for the guides, i've finally been able to get around vray for houdini and actually do some proper tests!

[bdancer]

> Are there any plans to support bgeo and bgeo.sc references in the future?

There are no such plans.
What are the advantages of bgeo compared to Alembic for you? Or vrscene?

[Moriah]

Right now a simple particle sim takes about 10s to cache via bgeo.sc for 240 frames, same one in alembic takes 3min.

Vrscene conversion for the bgeo.sc takes around 30s but there's duplication of file size in the network and of course the bigger the file the longer it takes to load on the render nodes.
Vrscene conversion for the abc take 15min (file size is very low) but way too long to convert and since it has to be done locally it's not ideal

So ideally vrscene could reference bgeo.sc files, and not only it is used for particles but for a lot of other things as you know...

[tronotrond]

Besides speed, keeping workflow as close as possible to how you "normally" work in Houdini is a plus to us.

If you want everything referenced from disk, in my personal opinion, your best option is Convert to Poly Soup -> cache to Alembic.
Hope that helps!

Thanks! I'm trying this but my model does not render good at all. Convert to poly soup, export ABC -> V-Ray proxy import. Shows fine in viewport, but in the render I either just see a complete gray frame buffer, or it looks like it's instancing extremely large spheres all over the model. No errors or warnings in the console.

[bdancer]

tronotrond, use native Alembic SOP for Alembic files, use VRayProxy SOP only for *.vrmesh files.

[Gosho.Genchev]

Does your model contain any hairs (V-Ray will treat open poly lines and curves as hair), or particles (well, stray points not part of a primitive) ? If so, give them a pscale attribute before exporting the Alembic - the default used by V-Ray when rendering from the alembic file is quite large.

If that doesn't help, I'd love to take a look at this alembic, if possible.

And yup, as bdancer mentioned above, it would be best to use the Alembic SOP. The Proxy Import SOP brings in a ProxyRef type of primitive which you can't use as easily inside of Houdini as the alembic.