Particle instance loses channel


I am constantly running into an issue with using the particle based instancing. I have a working setup, just as describer in the video. It all works, I can render stuff and change settings, but at some point it then always fails on me with this error message:

ChannelSet does not contain a channel named " - which then caused…

big problem is, neither ctrl+z nor undoing the change by hand fixes the issue, not even save+restart. I have to go back to the last saved working version and start over.

I can recreate the error. Mostly it happens when I change anything around on the particles. but as I said, even copying in a new particle setup doesn’t fix the issue.

So: can I avoid that happening? can I fix it once it happened?

Sys info:
Nuke: 12.2v2
Eddy: 2.7.2
OS: Win 10 Pro
GPU: Quadro RTX8000


So I thought I found a solution, but now the solutions is acting up:

The solution was, that eddy seems to not like the particles to be FrameHolded (lazy comper coming through I guess). Even though it works setting up the scene with the FrameHold it then at some point messes it all up. But once the error with the missing channel appears and I delete the FrameHold I can continue working.

Problem of solution:
If I now try to render I get the same missing channel error message in my render log and a failing render.

The issue might be, that I am not using the particleInstancer in the way it was meant to be used. I use it as a random scatterer, as I need to populate a sky with clouds and then fly through above them for a long shot. So I create static particles, as I am too lazy to create that many axis, also I reached the maximum input number of the RandomInstance when I tried.

So my current work around is: no framehold while setting it up, throw in the framehold and then render. But, I guess there is a smarter solution

HI Tim,

I’m not sure I 100% understand the setup issue in regards to the Framehold.
So this error can come up if you have no particles coming into the ParticleInstancer.
Can you explain me a bit more your setup ? are you using Nuke’s particles or Eddy particles directly ( eg via a ParticleCacheLoader or a particle sim graph ) ? I’ve had issues with Nuke Particles sometimes behaving strangely. I usually cache them out to disk to a vdb and then loading the cache instead to drive the instancer graph.

I’d love to replicate your setup/error and see if this is a use case we haven’t tested against.

In the meantime I’ll go ahead and increase the max input connections for the random instancer, I believe it was set to 100.


Hi Christoph,

I am using nuke particles for this setup. Emitter region is a large cube, I am emitting 500 particles at frame 1000 only, without any velocity, and no more emitting afterwards.

I used the framehold straight after the particle emitter and before converting to eddy particles.


cube-ParticleEmitter-FrameHold-E_ParticleSystem-E_ParticleIntegrate. Then into the particleInstance

Writing them out to a cache would probably solve the issue, but as I am still in the setup phase I still am changing around quite a bit.

Increasing to more than 100 inputs could lead to nuke problems I guess, as most nuke nodes seem to max out there as well (merge for example), and I am not sure if anyone would actually go down that route, as setting up all the axis nodes is also annoying as you always have to run python codes to change stuff around. So I don’t think that extension is really necessary, especially as the particles route is much better to handle. I mean this is a very specific use case.
If you want to add a feature for a usecase like this I would rather go for a randomInstanceScatter node, that just does that internally, so you pipe in a region, have a number value to change on the node and it scatters them around that region. Basically a halfway point between the particle instance and the random instance. just a thought.

Hi Tim,

You should be able to remove the E_ParticleIntegrate node, if you just want a straight up conversion of the Nuke particles. Also worth noting that it helps to reset the particle system, like you’d reset the Element during simulation. This isn’t ideal, but essentially this is designed to be part of a stepped simulation.
Hopefully we can come up with a better mechanism for this in the future to make this less of an issue.

I’ll keep trying your setup and see if I run into issues here.


Hi Tim,

I think there was an issue that particles weren’t copied from Nuke correctly sometimes when the current frame was at the reset frame of the particle system. This only makes sense when the particle system is standalone and not driven by nuke particles. For now you can set the reset frame on the ParticleSystem node to something like -1000. I’ve corrected this so this should update correctly in the upcoming release.


I’ll try that. thanks!