View Full Version : Help with a challenging particle effect

02-26-2009, 09:25 PM
Here's the scene...

A conveyor belt. An object of 50K single point polys (SSP) to be the gravel on the conveyor belt. A bucket that scoops across the belt.

The SSP gravel object has a morph to move its full length on Z. A bone is added to move a small section of the SSPs up a bit where the scoop mechanism is. Morph moves particles thru the bone and they rise up exactly as desired.

Bucket object has Collision dynamic added with mode set to Erase.

Here's were I have no clue if my assumptions are even on the right track, but I add HardFX to the SSP gravel object under the impression that the bucket with collision will "erase" the "particles"/verts of the SSP gravel object when it scoops thru them as they travel along the conveyor by the morph.

Guess what happens when I click Calc?

"HardFX, can't alloc memory" click OK and LW crashes.

Hmmm... 50K particle/points too much for HardFX to handle? Doesn't seem like a horrid amount or beyond reason.

Any ideas on another way to implement this idea?

Wait... How about this... make the SSP object a particle emitter... 50K particles in 1 frame from the verts. OK. That works! At least LW isn't crashing and is calc'ing the dynamics of the bucket erasing the particles. But wait! Nope, not working because the emitted particles are not moving with the morphing SSP emitter object.

OK, that's logical. How would the particles know to STICK to their emitter verts anyway?

Hmmm... Wow... this is a really tricky effect it seems.
Again, any ideas on getting the particles to flow with their morphing and bone deformed emitter verts?

02-26-2009, 11:49 PM
Did you hit calc with the particles?

02-27-2009, 06:55 AM
Well yes indeed I did, Larry! At least I assume you're referring to the second method I tried above wherein the particles were created and the calc proceeded without a memory crash, but were left behind when their emitting verts were moved by the object's morph/bone deformations.

Since this is the expected/natural behavior of particles, meaning, I see no options to set them to stick to and follow their parent emitter, this is the reason I first tried HardFX knowing that by design the verts of the object itself can by moved by physical forces as though they were independent sub-elements.

I also tried SoftFX on the SSP object. No memory allocation error and the calc actually progressed at a "normal" pace, but did not collide with the bucket, despite being told to do so.

Here, let me attach a stripped down scene for you to play with (particle emitter disabled and no hard or soft dynamics added).

02-27-2009, 11:23 AM
do you have messiah ? I had a quick try with this and think it would be prefect for what you are attempting. If not sorry - didnt mean to advertise something non LW in a LW forum.


02-27-2009, 11:48 AM
Nope... LW only.

02-27-2009, 12:40 PM
Hey Dean,
I think the easy solution is to treat the conveyor belt part from the scooping up part as two separate things.
Heres an example. The dropping bits and the piling up bits are two separate things.

02-27-2009, 02:29 PM
the MDD may be messing you up.
Here's a simpler scene that uses a gradient to get the conveyor warp.
Other means would also work - even nodes

I simply used collisions and an emitter in this scene.

Oh and I didn't use the conveyor points to make the particles.
just a null dropping them onto the conveyor.

Anyway....5 minutes of work.

02-27-2009, 02:33 PM
Thanks for the example, but it doesn't appear to use the same methodology as what's needed here.

1. Even if the conveyor gravel object had sections of SSPs removed to form the gaps where the bucket scoops them off, figuring out WHERE those gaps are and how wide they are is going to be ridiculously hard to do on a stationary object that's gonna be moving. I guess the only good part is that the object moves at a constant rate the the scoop is on a cyclic motion... just gonna take some math and lots of trial and error... of fun!

2. How would you animate the "removed" sections of the object being scooped away such that they align, move, and deform to perfectly match its "parent" so to speak PRIOR to being scooped away?

Hmmm... I guess each gap section could be placed in a separate layer and either a) share the same morph as its "parent" or b) each layer gets their own morph. Then I guess you'd be able to tell them to use the same bone from the "parent" object and finally scale each one to match the bucket's "collision" with them, dissolving out their HVs, and enveloping a particle emitter parented to the bucket to spray HVs out as though those sections of gravel were being scooped away. Hmmm... interesting concepts here. Gotta go play now.

Thanks for being a sounding board. Hopefully this is a promising path to travel.

02-27-2009, 10:27 PM
I would generate some particles and use a wind path to pull them along the conveyor. Once they reach a certain spot use a collison object set to erase to delete the particles. At the same time have a 2nd emitter like in my example that appears to make the particles pile up where they are erased.

02-28-2009, 03:39 AM
Try this lws.

You should model a dedicated collision object and raise the precision of the calculation.

02-28-2009, 06:45 AM
Hey Dean,
I think the easy solution is to treat the conveyor belt part from the scooping up part as two separate things.
Heres an example. The dropping bits and the piling up bits are two separate things.

Agreed, I did this one months ago, and I found that is the way to work Lightwave out...

03-01-2009, 02:36 PM
Hey Guys,

I worked out a method for this piece. I made a small cloud of points in the shape of the cross section of the gravel mound on the conveyor belt that emits 25 particles per frame at 1 m/s velocity, no particle resistance, and just ignored the slight hump in the conveyor belt. Being that I needed the particles to cover the entire length of the conveyor, I started the calc at frame -600, which resulted in 30K particles, generated over 1200 frames (600 needed for the actual anim), resulting in a 175 meg dynamics motion file.

Next I added a collision box parented to the bucket set to erase the conveyor parts. So far, so good! Oh, and I added a collision obj. at the end of the conveyor to turn the particle motion downward.

The conveyor particles were not dense enough to block viewing the conveyor belt beneath them, so I had to add a "sub gravel" mesh object under them, textured with Dpont's Rocky proc. bump and crust color textures, and moved the object at the same 1m/sec rate. Blends perfectly with the HVs. But, how to "cut a swath" thru the mesh? Ah HA! Good ol' Surface Effectors to the rescue. It still works great in 9.6... just used them on the transparency chan. Trick here was to parent the S_E null to the moving mesh and apply an equal and opposite neg motion to the null so it says in one place, cutting multiple gaps in the mesh.

To cut off the ends of this "sub gravel" mesh where it extends beyond the conveyor belt, I used a gradient clip map.

Finally, a box emitter was added to the bucket with a birthrate env to generate the scooped away gravel. These were generated in a new group so that a gravity field would act only on these particles and not those of the conveyor (setting gravity in the emitter interfered with the need to env a bit of upward velocity to simulate a "collision" with the conveyor belt, which was made an erasing collision object to prevent "stray" scooped particles from passing thru it).

So... all is working great now. It just takes so freakin long to render HVs with a Dome light at quality = 4 and angle = 45 deg. 22 mins. render a full screen of HVs looking straight down at the conveyor belt at 640 x 480, no AA. I cringe and doing this with AA=4, adaptive at 0.04, and 1280 x 720 HD rez. with PRMB.

Again, thanks for all the help, suggestions, and examples.

OOPS... one more question... HOW do you get HVs NOT to have the same identicle texture on them? ALL my surface HV particles have the same exact bump texture, which is quite obvious looking at them closeup. Any way to randomize that other than re-calcing the emitters with random rotations to give a quasi-random look to them?