had the chance to test the latest beta of EmberGen, here’s a test render:
The potential to use it in actual vfx production environment is quite high, so here are some questions/suggestions:
Does the geometry importer support animated objects?
For post production it would be important to import animated cameras.
VDB import would also be favorable.
bgeo import of houdini particles or general geo would open up alot possibilities
Does it support a graphics card raid?
Would there be a way to run sims/renders in batch and within a renderfarm context?
deep data output as exr’s would be very preferable
It is great to be able to tweak settings on the fly, but when it comes to scale up and /or to render, there’s no need in linear production to have that realtime.
Animated Geometry will likely be coming towards the end of this year.
Animated Cameras will likely come at the end of the year.
VDB imports are planned.
bgeo could be a possibility for sure.
No Multi-GPU support yet, it is planned though.
We do have plans for batch sim/rendering, but that’s pretty far away from release as it’d take tons of planning.
Deep Data is planned.
“It is great to be able to tweak settings on the fly, but when it comes to scale up and /or to render, there’s no need in linear production to have that realtime.”
when it comes to rendering images, productions are used to wait for the results, if it is many hours or just a few minutes per frame. If there’s a significant reduction in render time, that’s great, but it is by no means mandatory.
Now in the case of Embergen, there’s a reduction of simulation and rendering time towards realtime, which is very interesting in the fx department. It opens up the possibility to run many iterations and tweak settings free of waiting time. This changes the way an artist thinks about the creative side, gives the freedom to be much more creative.
But in vfx post production the end result is a rendered sequence, linear produced without any need to be run interactively. So what i mean is, the speed is gamechanging for the creative/technical part, but in the end it gets prewritten to disk.
Another test rendered from the viewport. Collision behavior does need a bit work. Here you can see how much volume is eaten up. Also moving collision objects are tricky to tweak, as it tends to force too much velocity into the sim and also produces velocity force when intersecting with the sim boundaries.