DAZ RIB Batch Render?

[Spectralis]

There's a new batch render script available for DS.

http://www.daz3d.com/new-releases/batch ... -4-and-rib

Is Octane Render able to use RIB files? Will this script work with OR standalone or the DS plugin?

I'd like to use it for rendering animation with OR.

[slash]

The animation tab of the plugin has a render queue option. Not sure if this will work for your purposes or not.

[Spectralis]

Thanks, I was wondering if an animation made in DAZ Studio could be saved to RIB format and then rendered in Octane Render standalone? That way DS wouldn't need to be open and this might save resources and avoid potential crashes or freezes that occur when rendering animations over many hours with DS open.

I think the next update of Octane Render is going to allow the possibility of saving out projects from many 3D applications for rendering in the standalone but it would be great if this script worked in that way right now.

I've contacted the developer who doesn't own OR and wasn't sure of its capabilities so I thought I'd try to find out about OR and RIB here.

[t_3]

Thanks, I was wondering if an animation made in DAZ Studio could be saved to RIB format and then rendered in Octane Render standalone? That way DS wouldn't need to be open and this might save resources and avoid potential crashes or freezes that occur when rendering animations over many hours with DS open.

I think the next update of Octane Render is going to allow the possibility of saving out projects from many 3D applications for rendering in the standalone but it would be great if this script worked in that way right now.

I've contacted the developer who doesn't own OR and wasn't sure of its capabilities so I thought I'd try to find out about OR and RIB here.

alembic is the exchange format that octane now provides; alembic export will be possible directly from the plugin, and this should also allow to use the standalone to render daz scenes prepared with the plugin.

but don't expect to use that for full (geometry included) animation anytime soon; the plugin is limited to what daz studio's api offers, and since it currently can only read frame-by-frame raw vertex data, geometry animation export just makes no sense - it would produce 100s of MB of data per frame, and the export time would most probably exceed the rendering time by margins. the only option would be to have daz studio get full alembic support (including vertex based animation data), plus an api for plugins; even then merging animation data from two completely independent sources (octane and studio) will be no trivial task.

on a more general view point: the plugin of course needs to - and will be - stable enough to render animations over days; the additional footprint of resources that studio uses is more or less negligible; esp. considering animations... it needs to hold geometry data in systen ram, whereas octane does transfer it to vram, all additional processing (like smoothing and the like) need to be done anyway, and the user interface updates has next to no performance impact.

what will help to work more efficiently in upcoming versions is: dropping the single instance limitation for the plugin, and an option to quickly turn the plugin completely off - both in the works; this means you can have one daz studio instance rendering, and continue work in another (with or without octane), given you have enough resources.

a last note on scripting: octane is still an independent application, even if "injected" into studio by the plugin, so it can't be scripted by the daz scripting engine right away. to provide an interface that adds scripting capabilities and translates daz script language to LUA scripting (which octane now provides) is more or less out of reach...

[Spectralis]

Hi t_3, thanks for your comprehensive reply. I wanted to find out if it was worth getting the RIB script before I bought it.

[linvanchene]

edited and removed by user

[t_3]

Nevertheless now I am somewhat worried if what I originally planed to do will work at all given the limitations of DS you just explained:

Will it be possible to work on an animated scene in DS OctaneRender plugin and then send that scene to the OctaneRender Cloud Edition?

In a best case scenario I would like to work on an OctaneRender for DS scene and have multipe animated scenes rendering in the OctaneRender Cloud Edition.

a little more explanation on that...

i.e. camera animation through octane - including camera motion blur - will work like this:
the plugin reads the camera keyframes (from ds) and creates this keyframes in the octane camera timeline. this is needed in particular to render camera motion blur; on the other hand, an alembic export from octane (through the plugin) will now also contain the camera path and should work wherever you can read back that alembic file - like octane standalone and the cloud render service.

that was the "easy" part

a little more complex but still not a big problem is a similar procedure for non-deforming meshes; geometry (vertex) keyframes are taken from ds and transferred to octane - subsequent alembic exports will now also contain motion information for moving geometries.

in theory this would work about the same for deforming meshes, but until the interface is finalized i can't say how it will work and what possible problems may arise; this is of course the most crucial part as ds animations just mostly consist of such.

so, basically the plugin needs to transfer any keyframe data (time, easing, etc.) to octane to allow motion blur rendering for camera & geometry motion, and this will in addition allow to export complete animations to alembic format, no matter if ds supports it or not.

an additional amount of work is then needed to synchronize keyframe data not only during animation rendering but all the time, i.e. to get live feedback for motion blur.

one big no-go is already there with mesh smoothing; as soon this is used, ds alters any affected geometry again _after_ the geometry was transformed by a keyframe (or the intermediate result inbetween keyframes), and does this for _any_ single frame, not only for keyframes. in practice this means that any vertex in a smoothed mesh receives a somewhat altered new position in space and that the keyframes for vertices are no longer usable; or in other words: the animation information for vertices will get bigger than the raw geometry is - for every single frame. the only way to overcome this is to have the render engine (means octane) doing direct mesh smoothing itself. i currently can't say if this is about to happen, but even if, it is not clear if the results will be exactly the same.

ps: and even if ds exports mesh anim data to alembic, it will suffer from the same limitations that apply with mesh smoothing, so i doubt that we will see that in ds in the near future...