XParticle motion blur/ increasing render times Tweet

[bepeg4d]

Please make sure to have updated c4doctane to v2020.1.3-R2.
You need to select your purchased version from the Select Software pop up:


Motion Blur seems to work correctly with latest XP update here:

ciao Beppe

[dasmodular]

Hello,
the problem still persists!

Please have a look into the attached scene file, the Octane log file and the screenshots.
In the scene file there is an emitter with a kill modifier, so that after frame 8 the particle count is constant at 29000.
Caching the particles does not make a difference.
Geometrie Control is set to All Objects Movable.

Please have a look into this issue!

Best regards,
Denis

C4D R25.010
Octane 2020.2.5-R3
X-Particles Build 1036
Windows 10 64-bit
Asus Geforce RTX 2080 Ti

[bepeg4d]

Hi,
please try to set the XP Cache to Basic, rebuild it, and report back, thanks:

ciao Beppe

[dasmodular]

Hi Beppe,

setting the xpCache to basic does not make a difference:
motionCnt and mblurTM is still increasing at the same particle count per frame.

Best regards,
Denis

[young.r85]

Hi all,

We're having this same issue. Using Motion Blur and XParticles makes every frame increase in render time. Our work around is manually rendering 10 frames at a time. Not ideal.

Octane 2020.2.5 with C4D 24

Anyone have a better work around?

Cheers!
Ronny

[aoktar]

Using a Kill object will not cause having less IDs are stored to define motion data in current algorithms. Increase on stored IDs that are causing bigger and bigger preparation times for motion data. Only way is to use more CPU threads in cameratag/motion_blur. See my picture for parameters and results. But increase over time undeniable with current versions.
Anyway I'm checking to improve it for this case.

[KeeWe]

Ahmet, just a quick question: is a value of 0 for used CPU Threads not utilizing ALL available cores? I always thought 0 means "go with all you have" and typing in a number is only to limit how many threads are used.

[aoktar]

Ahmet, just a quick question: is a value of 0 for used CPU Threads not utilizing ALL available cores? I always thought 0 means "go with all you have" and typing in a number is only to limit how many threads are used.

Checking that but I might be wrong because related part seems disabled for the builds. I'll give info for updates

[aoktar]

Here's my results with a test build, I'm using 16cores cpu

[KeeWe]

Would there be any downside of setting the core count to the max available, even if not working with XPparticles?