Cineversity

Hello Sassi,

I’ve noticed that particles sometimes escape through a collider object and suspect this happens when particle A, following particle B, passes through particle B when it’s colliding with the deflector object.  Is this accurate?

Jerome Olivier

(Sorry for the delay in answering, we had a local Web-outage)

Hi Jerome Olivier,

The problem with deflectors are based on the speed the particles have. It is not a question of groups. Normally (!), but it is clear that the event happen, hence the red cubes are escaping not the pyramids. So, it is a question for the support. I can’t fix that. http://www.maxon.net/support/support-questions.html

Some typical notes: The deflector is not a constant observation during the frame, it takes a look at a particle and “decides” that it might not hit the deflector during that frame, so no bounce. The next frame checks for particles with the deflector and the particle too far away will be perhaps already behind the deflector. You might check with the support about this, as I think it is nothing that I can solve with an explanation, it seems to be a technical limitation.

My only answer is, introduce a second deflector, which might be tricky. This can be set behind the first deflector and bounce the escapers back int the game. Not that this will not work if the first deflector is set to bounce on both sides, this can create an endless trap.
The other way would be to slow them down when they come close to the deflector with a second deflector first, but set to event only. The energy loss during the bounce can be simulated in that way, e.g., slowing the particle down for the time being (event) and the second deflector bounces them with a little bit more (than before) back. I would even think that this comes closer to reality, as the bounce moment is certainly dependent on the material, on both sides (foam vs metal for example).
I have attached an example.

Again, you might request input from the support about this. Or just check my file, as one of my workarounds for this.

As a side note, normally the processing works nice without any concerns of the XGroup, but if something doesn’t work as expected, that would be my first place to check. First things on top, a logical process down then to the last “event”. (See image).

All the best

Sassi

Dr. Sassi - 19 August 2014 03:51 PM

(Sorry for the delay in answering, we had a local Web-outage)

No worries, though I was beginning to have an anxiety attack as you are my number one source for information and encouragement with C4D. 8^)

As a side note, normally the processing works nice without any concerns of the XGroup, but if something doesn’t work as expected, that would be my first place to check. First things on top, a logical process down then to the last “event”. (See image).

Wow!  So the order of nodes in the x-manager works the same way as the order of objects in the object manager?  That’s so cool.  I should’ve known that, but I guess the way the xPresso editor is presented with nodes and curvy lines led me to believe that this part of C4D was somehow more fluid, organic or, I don’t know, touchy feely. <shrug>  What do I know? </shrug>

8^D

Thehehe, don’t you worry, Jerome Olivier, if I’m quiet, we have one of our outages here (power or web, perhaps both, even with a complete set of uninterruptible power supply (UPS) devices).

The “Object-Manager” has the priority-settings on top of that, so it might be comparable to a certain degree. Normally the XGroup-hierachy is ignored by most people without showing any signs of problems. However, if I noticed that someone cared about this, it makes it so much easier for me to read the “solution”.

As a side note: You might notice that I go always from top to button in my node set up. Normally I have on the left side my information, in the middle the process, and on the right side my results. In that way I can “read” my stuff even after years without getting confused.

The curvy lines are new. I liked the old one better, but as the majority prefers the new way, I’m happy to adapt, as it might make it easier for everyone to “read” teh set ups while the “wires” are set as they like it.

All the best

Sassi

Thanks for letting me know. ;^)

Okay, here comes the hard part: ?($1+$2>0;1)

I’m probably reading this all wrong, but from what I can gather based on the single Appendix page in the help system, the formula reads: “If the value of ports one and two is greater than zero, then one.”  Again, from what I understand, that would translate to, “If a particle gets through, bounce it.”

How far off the mark am I?

Very good, Jerome Olivier.

The particles have to stay in the current group as long as nothing else happens. If there is an “event” then this particular particles receives a “yes” or “one” to move to the next group. Each particle has an “index” number in the group, and so it should normally sort it out nicely.

What I did in the Formula node was simple—if one or both Deflectors provide an “event” message, which means a bool value (0 or 1, no or yes) then move the particle to the next group. As the “On” input of the group should receive a 0 or 1 (boole!) I introduced this formula. Just to stay clean. If there is an event then the deflector should bounce it. Except of course, the “Event Only” check box is checked to on, then you can get only the information that the particle has passed. I did it to keep the set up small. ...and of course to use the Formula, as I know your would like to see it in action (I guess ;o)

Which also proves your point, if I understand your set up correctly, that something goes wrong. The deflector allows for the event message, but gets sloppy with the bounce work. Again, nothing that I can change, the support needs to know/handle it.

The formulas in the appendix are just a very powerful resource—for many uses in C4D! :o)

Enjoy

Sassi

Thank you for the gentle initiation with the Formula node.

Just for good measure, I also tried the second, slightly simpler way, using a second deflector, and found that it works nicely also—kind of like a safety net to catch anything that falls through the first deflector.  Here is the file for anyone interested.

All the best,

Jerome

Yes, that works nicely, Jerome Olivier.

I have stress tested the scene, even with high speed, and can’t break it. However—I would feel always uncertain to not have the “safety net” not having the “even” for the Group-change. It works, so I might be just to cautioned.

Well done.

All the best

Sassi

Caution is always good, but isn’t it safe to assume if one runs an animation from beginning to end with zero errors, then the second, third and fourth time the same animation will also be error free?  From my observations, it was always the same particles that were flying through, so whatever the error was, it was being reproduced consistently.

Should be, and no particle should fly through… ;o)

Keep in mind that each cpu is not the same as another one. Each OS has parts in it to overcome typical mistakes of the cpu, AFAIK. The standard suggestion is to not mix a render farm to wildly, based on that. Even everything is based on 0s and 1s, the main work is done in double precision floating point, and there is a some kind of tolerance possible.