OTOY Forums

Vdb from XParticles does not work.

example files: https://we.tl/t-4zVNS7RvFg

(works in 2020.1

Is it me, or the timers stopped working?

Hi Ahmet, this is a great release, extremely stable especially... the only thing which seems not working is VDB Volume Object, can't render any of my VDBs sequences, even playing with the revamped Volume Step Length, don't know if I'm missing something or it's just an issue of this release/SDK?

Thank you,
Domenico

moebius wrote:Vdb from XParticles does not work.

example files: https://we.tl/t-4zVNS7RvFg

(works in 2020.1

Have you submitted this as a bug? If not, please do so: help at otoy dot com

Hi all,
about VDB rendering, there is a known issue introduced in 2020.1.1 SDK, and still not solved in 2020.1.2 SDK in loading VDB version 223.
The core devs are on it, and the issue will be fixed in the next SDK update.
Please go back to 2020.1-R7, if you need to render VDB files.
c4doctane 2020.1-R7

ciao Beppe

bepeg4d wrote:Hi all,
about VDB rendering, there is a known issue introduced in 2020.1.1 SDK, and still not solved in 2020.1.2 SDK in loading VDB version 223.
The core devs are on it, and the issue will be fixed in the next SDK update.
Please go back to 2020.1-R7, if you need to render VDB files.
c4doctane 2020.1-R7

ciao Beppe

thank you, Beppe

bartolos wrote:Is it me, or the timers stopped working?

Capture.PNG

Not clear to me what you ask!

aoktar wrote:

bartolos wrote:Is it me, or the timers stopped working?

Capture.PNG

Not clear to me what you ask!

Sorry for not being clear. The timers in the commandline render always show 0 time for render and total. I am actually using those numbers for my control scripts.

bepeg4d wrote:Hi all,
about VDB rendering, there is a known issue introduced in 2020.1.1 SDK, and still not solved in 2020.1.2 SDK in loading VDB version 223.
The core devs are on it, and the issue will be fixed in the next SDK update.
Please go back to 2020.1-R7, if you need to render VDB files.
c4doctane 2020.1-R7

ciao Beppe

You gotta do daily builds for stuff like this. I'm not gonna sit around and sift through old builds to find one that doesn't break the scene I'm working on, I'm just gonna do it in Redshift or Arnold.

I get it's hard to balance new features and stability, but VDB's aren't really an obscure thing to leave broken for a couple days.

fatrobotsneedlove wrote:

bepeg4d wrote:Hi all,
about VDB rendering, there is a known issue introduced in 2020.1.1 SDK, and still not solved in 2020.1.2 SDK in loading VDB version 223.
The core devs are on it, and the issue will be fixed in the next SDK update.
Please go back to 2020.1-R7, if you need to render VDB files.
c4doctane 2020.1-R7

ciao Beppe

You gotta do daily builds for stuff like this. I'm not gonna sit around and sift through old builds to find one that doesn't break the scene I'm working on, I'm just gonna do it in Redshift or Arnold.

I get it's hard to balance new features and stability, but VDB's aren't really an obscure thing to leave broken for a couple days.

While I think your comment is a bit harsh, I agree that the label "stable release" is being slapped on a bit too early. Actually quite randomly as I see it from my perspective. I've done many jobs on experimental builds successfully, while sometimes having trouble with stable builds. So I think the labeling is a bit misleading.

Of course we are having two separate entities here - the octane core and the plugin which Ahmet is working on his own, and we might be having a stable plugin while the trouble comes from the core like in this case. But then again, as end users we don't care or even realize where the bug comes from. We just see a "stable release" label which I consider saying "Tested thoroughly in a broad spectrum of cases, QA passed, etc", which seemingly is not the case.

I don't think it's going to change anyway so having a few earlier builds handy just in case is a good practice.

What I do is append a brief build number to the c4doctane plugin folder name i.e. "c4doctane_20201R7" and when a new release comes out, I just move the previous version folder to "inactive plugins" folder which I created next to the "plugins" one. So I have a few older versions available in the "inactive plugins" folder, so I can quickly shuffle them if need arises. Of course if you have multiple machines it's going to be a bit more involved.

I realise it is an ugly workaround but gives and option at least.

OTOH in redshift that wouldn't be so easy, as by default it has a fixed installation folder and you need to get a bit dirty to have different versions installed independently... but at least you can rely on their stability/feature-completeness statements...