tesselate or Vray Sub-D

[shadevfx]

which is more efficient? Using low poly cages with the V-ray sub-D attribute? or pre-tesselating your geo for smoothness.

[cpnichols]

which is more efficient? Using low poly cages with the V-ray sub-D attribute? or pre-tesselating your geo for smoothness.

Depends... Vray subd can be faster (and leaner) in many cases, but I would advise against using it out of the box. This is especially true when view dependency is on.

Try using subd with a max subd of 4 and view dependency off. Adjust your edge to whatever is relevant to the scale of your scene.

If you are noticing massive slow down when the camera is close the the geo, this is most likely the view dependency issue with subd. I don't notice this as much at all with displacement.

However, vray can deal with a fair amount of geo, especially if you do proxies, so pretesselating is not terrible.... I used to do it all the time until we I figured out how to make the required adjustments to the subd.

[shadevfx]

Thanks, I will do some testing and get that sorted out. That's exactly the sort of direction I was looking for.

Regarding proxies, I haven't dug deep yet (week 2 of vray) but, could you describe your basic process flow for using them?

For the last hardy mental ray pipeline I built it went like this:

When an asset was published we exported discreet .mi files representing the geometry or scene elements.

These were then assembled into a scene via an asset management DB, with low res geo representing the exported .mi data.

When you render, MR standalone was invoked and glued all the .mi data into a file and rendered.

Is this a pretty similar logic for v-ray proxies?

Any hints are appreciated.

Bryan

[3DMK]

It's really simple to use proxys in Vray as you simply select your object & right click and choose Vray-mesh export. The dialog box that comes up is simple and easy to understand.
A couple of things to remember!
--Do a reset X_FORM on your mesh first as this gets rid of any scale issues.
--Once you have created a proxy make sure any copies you do of it are INSTANCES other wise you will be loading the mesh multiple times.
You can still scale a proxy once created as well as give them different materials[which is very handy] as the Proxy does not store the material, only geometry & mapping co-ords.
Hope this helps

[shadevfx]

yes, certainly seems very straight forward. The only issues we are having is with Sub-d or displaced objects.

Otherwise, its brilliant. Animators publish out vray proxies for each item in their scene, and the lighters "reference" or import those vray proxies, for an incredibly clean and lightweight scene. No rigs, no references, no clashing name spaces...

Truly fantastic if we can get around those two small details.

[vlado]

Yep, currently it is not possible to sub-divide or displace the proxies. Displacement is perhaps easier to implement, but subdivision is more complicated, as the proxy is split into chunks, so mesh connectivity information is lost. This is because the original idea behind the proxies was to allow rendering of very large meshes (millions and millions of triangles). However, it turned out that people mostly use them for asset management and scene simplification - definitely something that we have to consider

Best regards,
Vlado

[shadevfx]

Yep, currently it is not possible to sub-divide or displace the proxies. Displacement is perhaps easier to implement, but subdivision is more complicated, as the proxy is split into chunks, so mesh connectivity information is lost. This is because the original idea behind the proxies was to allow rendering of very large meshes (millions and millions of triangles). However, it turned out that people mostly use them for asset management and scene simplification - definitely something that we have to consider

Best regards,
Vlado

I think we could live without Sub-D easily, but would LOVE to get displacement in there...

It really presents an amazing advantage to Vray to have such a simple geometry caching solution. It's so straightforward and elegant, very easy to script up an asset based system using it. Would really put V-ray right over the top of renderman for large film style production...

thanks for responding Vlado!

[cpnichols]

yes, certainly seems very straight forward. The only issues we are having is with Sub-d or displaced objects.

Otherwise, its brilliant. Animators publish out vray proxies for each item in their scene, and the lighters "reference" or import those vray proxies, for an incredibly clean and lightweight scene. No rigs, no references, no clashing name spaces...

Truly fantastic if we can get around those two small details.

I would be careful, and do some testing. Having a ton of different proxies can actually be a problem, as the way that Vray works is that it reads the proxy data as it is rendering, and dynamically loads and unloads the data. Separating that data into a ton of different files could kill your rendertimes in IO time. Proxies generally work best when written as one (or a few) big proxy files.

[shadevfx]

I would be careful, and do some testing. Having a ton of different proxies can actually be a problem, as the way that Vray works is that it reads the proxy data as it is rendering, and dynamically loads and unloads the data. Separating that data into a ton of different files could kill your rendertimes in IO time. Proxies generally work best when written as one (or a few) big proxy files.

definitely knee deep in testing right now.

So far, we are attempting to use it as an alternative to geo-caching. Basically we have a script that will grab the top node of each hierarchy of animated objects in an animtors scene and bake those out to v-ray proxies. Each static group is already exported from the modeling/asset building phase as well.

so workflow is: Static assets are exported as proxies to the asset library. rigged assets are maya files, animators reference rigged maya files, an import proxy static objects. When an animator publishes animation, the script bakes out top nodes of each animated deforming object.

Then lighting TDs import both static and animated proxy files for final lighting.

Interesting about how the proxies work dynamically...

Is it possible to do this another way? By exporting vray objects that get assembled before render time? Therefor keeping the geometry static in memory to avoid the IO issue?

I'm basically trying to find the best way to recreate a RIB archive or .MI data archiving scheme using as much native v-ray data as possible.

Thoughts are welcome!

Bryan

[vlado]

Well, the geometry has to be read from disk, one way or another; if you are rendering through the standalone, loading from the .vrscene file or from a .vrmesh file will be very similar. Even if this was done in some other way, the actual description would still need to be fetched during the rendering, so my guess is that IO will be there in any case.

Best regards,
Vlado

[shadevfx]

Well, the geometry has to be read from disk, one way or another; if you are rendering through the standalone, loading from the .vrscene file or from a .vrmesh file will be very similar. Even if this was done in some other way, the actual description would still need to be fetched during the rendering, so my guess is that IO will be there in any case.

Best regards,
Vlado

seemingly if thats the case, then dynamic meshes would be ideal, as they'd throw out any geometry that doesn't need to be rendered.

Vlado, are there other facilities following the logic I've proposed? I'm just wondering if I am headed down a good path with using proxies for asset management and scene simplification.

thanks
Bryan