lighter vrscene for animation

[dddjef_vanilla]

I've just noticed that, even a mesh is animated or not, the exporter will write it into the vrscene for each frame.
Since it is common for our use to have a few millions of triangles, I understand now why vrscene make errors sometimes. A millions of triangle multiply by a hundred of frames, inside a very big ascii file. I think this is why some of my scenes are up to 17 go, and networking rendering struggle to death...

So... Do you think it could be possible to export static geometry data only once? And maybe a binary format for stability and performance?

[dddjef_vanilla]

And, by the way, vray proxy are a good way to speed things up. But making a vray proxy of each object in my scene takes ages, and you always got the risk to forget to update it when we modified an object. It's too dangerous.

[andybot_cg]

I'm not sure if it's the best way, but I always export manually as a single frame image. Then I change settings to animation and don't export before starting the animation. Hope that makes sense.

[dddjef_vanilla]

Thanks andy, but how do you manage animated characters?

[andybot_cg]

ah, ok. that only works for no animated meshes. Is it possible to export as an animated proxy? Not sure how it works, but you may be able to use this method if you only have a few things moving. I'm not talking from experience here, so I'd be curious myself if this works

[dddjef_vanilla]

I think animated proxy could work for objects with constant vertex count. You have to forget it for animated boolean, particles, etc...

Anyway, we can't reexport all animated props and character each time we modify something in an animation, I'll better go back with 3dsmax

And for some shots, this really big vrscene make vray.exe crash.

[bdancer]

We could add an option to manually select objects whos meshes are changing during the animation, this could speed things up.
Geometry data is already binary, I could only add additional ZIP compression (and also export transform matrices in HEX).

[andybot_cg]

We could add an option to manually select objects whos meshes are changing during the animation, this could speed things up.

+1
That would be great to have this. I've avoided animating objects because of the current limitations.

[dddjef_vanilla]

There's no way to detect if objects are statics or still with blender? Manual tag is a good workaround, but could lead of many errors too.

[bdancer]

We could try to implement such a function, but I'll need your help to test if we check all the ways of animating things correctly.

[dddjef_vanilla]

I've a project which could do the thing. For the moment, I've a found a solution with afanasy which can render blender file directly, but a few strange error are there too (some strange message about the edit linked library addon prevents some file to render).
Maybe could you contact phonybone, is currently under alembic cache developpment, and since he try to cache all scene animation, it should have answers for you. By the way, could it be a solution, exporting alembic from blender for geometry, and read it from vray?

the phonybone page : https://developer.blender.org/T37578

[bdancer]

I've already coded some ideas about animation detection (basically the code was already there for some years =) but untested). I've made a few additions and will test it tomorrow and upload the changes.
You could use alembic files in VRayProxy.

[dddjef_vanilla]

Ok, I'll test it.
To be clear about my issue, there are two bottlenecks when I render animation :
1. when I export vrscene, heavy scenes (about 5 million of tris) take abouts 20s per frame to export, even if I have only a 50k character animated. This task can't be distributed, so my computer is stuck for an hour (for a 200 frames shot), before I can see any image. It's very common to forgot something in render (a renderpass disabled, wrong GI setting...). Every error cost me an hour. It's harsh
2. a vrscene files for a shot like this is about 40 Go. Every slave computer takes 10 minutes before starting to render a frame. Because, even if the computer have to render the first frame, it will read the entire 40go file before starting anything. And it will take 10 minutes again every 5 frames (because time segment is split in tasks for network rendering). The bad thing too, is that slaves become unstable when they read such big files. To be honest when files are more than 20 go,they barely compute. The workaround is to split your scene in little time segments to make lighter vrscene, but it's very 'try-error' and expensive solution.