regular "fail"-frames in particles-animation

[mesut]

... Try with this option. ...

tried it. no difference:

...It will try to find and match the particle motion by their ID's.

not sure, what that means. something i can do to help?

[aoktar]

Ok, after checking that again you're right! Nothing solved. But hard to know where's problem. Somethings causing problems on this kind of setup of xp emitter. Probably it's on Exporter stage of plugin. There's not much thing to do in a short-time.

[mesut]

Ok, after checking that again you're right! Nothing solved. But hard to know where's problem. Somethings causing problems on this kind of setup of xp emitter. Probably it's on Exporter stage of plugin. There's not much thing to do in a short-time.

well, that's a bummer. thanks for looking into it though.

... Somethings causing problems on this kind of setup of xp emitter. ...

sorry to say, but at the beginning of this thread i once mentioned that i also tried the abc-files on octane-scatter-object way.

that is:
realflow particle export as abc-files -> stitch abc range to 1 big abc-file -> use the octane scatter object to distribute sphere on vertices of the abc-file -> resulting in the same mblur-problem.
no xp-setup involved whatsoever, in this case.

[mesut]

while trying to render the simulation at higher count, the already mentioned crash of the graphics card occured again, here's the text that showed up in the log windows, maybe it's helpful:

"OctaneRender 3.08 (3080015)

CUDA error 999 on device 0: unknown error
-> kernel execution failed(kernel25)
CUDA error 999 on device 0: unknown error
-> failed to launch kernel(kernel34)
device 0: path tracing kernel failed
CUDA error 999 on device 1: unknown error
-> kernel execution failed(kernel25)
CUDA error 999 on device 1: unknown error
-> failed to launch kernel(kernel34)
device 1: path tracing kernel failed
Error raised in callback:
[string ""]:921: render engine failure
stack traceback:
: in field 'start'
[string ""]:921: in field 'batchRender'
[string ""]:668: in function <[string ""]:659>
[C]: in method 'showWindow'
[string ""]:1096: in main chunk
CUDA error 999 on device 1: unknown error
-> failed to unregister pinned memory
CUDA error 999 on device 1: unknown error
-> could not get memory info
CUDA error 999 on device 1: unknown error
-> failed to unregister pinned memory
CUDA error 999 on device 1: unknown error
-> could not get memory info"

[mesut]

sooo... here i go again...
i set up the scene by generating tparticles from the cache-files and assigning a geometry via particle geometry. then attached an align node to the genereated tp-group in expresso - which aligns the geo according to travel direction - and rendered that in c4d-standard.
so, no octane involved whatsoever.

here's what i got (see attachement, which i just found out, one can do here in the forum ).

every 20 frames the alignment gets messed up - geo seems to be pointing to the center in that failframes. that's the exact same frames, that used to mess up octane mblur.
so, given all the experience, i start to believe, that the origin of the problem seems to be realflow and it's sim-export.

[mesut]

well, i guess now it's officially safe to say: i suck!

i went back to realflow, looked into the solver, saw "iterations" at "20". well, what a coincidence!
so, i changed that to "5", simulated and in the attachement, you'll see the result.
left is the old one, iterations at 20, mblur-fail every 20 frames, on the right hand you'll see the new sim with iterations set to 5. and yes, mblur breaks every 5 frames.

well, what can i say.
sorry for bothering you

EDIT:
well, i can't reproduce this anymore. no matter which iterations i set in realflow, i get this broken mblur every 5 frames now, when exporting to octane standalone.
and: the above mentioned setup using generated tp does not show any failing alignment at all anymore. the objects are perfectly aligned in direction of travel throughout the whole sequence.
boy... this is tiresome...