PDA

View Full Version : FX Emitter + Collision Object Question (Flowing Water)



Giacomo99
02-06-2009, 03:02 PM
Hello—

I'm using an FX Particle Emitter to create a stream of particles which are supposed to run down a flume (which has an FX Collision Dynamic applied)) and over a water wheel (which also has an FX Collision Dynamic).

1.The main problem I'm having right now is that most of the particles are going straight down— right through the damn Collision object, as shown below:

http://home.earthlink.net/~bucket/RightThru.jpg

I'm wondering if this has anything to do with what seem to be the extremely large size of the particles. When I click on "Show Size," they're huge. (When I click on "Output Size," they're small again. I have no idea what any of that means.) I have no idea how to change their size, other than to scale the emitter, which seems undesirable because it will make the stream extremely narrow. See below for examples.

http://home.earthlink.net/~bucket/ParticleSize.jpg

2. I'd like the water to flow less forcefully, but it seems almost impossible to make small adjustments in the speed of the flow. Setting the "Particle Weight" to 0, 100, 1000 or 10,000 makes no noticeable difference to the flow of the particles; adjusting "Bounce/Bind, "Friction," or "Fix" in the FX Collision panel are similarly useless—there seems to be a small range between which the particles neither bounce all over the scene nor all fall straight through the flume, and beyond avoiding such undesirable outcomes, minor adjustments seem useless.

3. Does ANY documentation exist on the practical use of Particle Emitters and Collision FX? I've been through the LW manual, "Essential Lightwave," and Dan Ablan's LW 8 and LW 9 books—none of which offer anything other than the simplest, most intro-level material on the topic.

Please advise. I am attaching the Scene and Object files for analysis.

dballesg
02-07-2009, 02:52 AM
Hi Giacomo,

I managed to make your particles collide correctly.

1.- I cleared the size of your particle emitter on frame 0. And used the Particle Generator Size to scale it to 150 mm on all axis.
2.- I reduced the Birth Rate to 40.0 and Generate by Frame.
3.- Opened the FX Browser, clicked on Option, and changed the resolution from 100 mm to 5 mm.

I attached your scene and my modified one.

The only thing I noticed after the calculations it is the particles touch tangentially the wheel, but they do not pass that point. Maybe there is another problem there but I couldn't find it.

I hope at least my modifications let you continue with this. BTW is a nice scene.

David

Dodgy
02-07-2009, 03:15 AM
Try also setting your collision type to Advanced in your collision object. It gives much better results, I've found, especially with particles.

Giacomo99
02-07-2009, 07:46 AM
David—

Thanks for your help. Unfortunately, in the file you attached, the problem remains (image attached below)—most of the particles are going right through the surface they are supposed to be colliding with. I can understand why scaling the emitter might produce some undesirable results, but can you please explain why you thought reducing the Birth Rate and switching to Generate By Frame would make a difference? I can 't find anything in any documentation anywhere that explains how Birth Rate and Generate By Frame are related. Also, what is the FX Browser? I'd never seen any refernece to it until I looked it up in the manual. What is the resolution and how does it affect anything?

Dodgy— The collision type was set to Advanced in the scene I attached. I don't want to seem ungrateful that you responded— but did you even bother to open the file and look at it?

http://home.earthlink.net/~bucket/Wheel2.jpg

DBMiller
02-07-2009, 07:53 AM
Some of the tips I've gotten from Tim Dunn's tutorials (Kurv Studio):
Set up groups for your interactions. That way only the items in the group will interact.
You can set the probability of interaction to greater than 100%. I don't have lightwave at work and I can't remember which tab that is.
I'm still learning particles myself so my answers may seem a bit basic but give them a shot. DBMiller

Edit: Also, change the size of your emitter so that it is flat (almost no Y size). Tim uses that when he shows how to make rain or snow falling.

DBMiller
02-07-2009, 08:29 AM
Another option, if all else fails, is to just erase the extra particle as they fall through. Set up another collision object just under the flume and set it to erase.

walfridson
02-07-2009, 08:43 AM
Also, don't forget to use calculate instead of scrubbing frameslider.

DBMiller
02-07-2009, 08:49 AM
Also, don't forget to use calculate instead of scrubbing frameslider.

Good point. Sometimes you just have to recalculate to update the dynamics.:agree:

vfxwizard
02-07-2009, 09:45 AM
The problems you experienced are tied to particle size and the use of "No shift" option for the collision object. I was able to fix the fall through but unfortunatly I'm at home while the dongle is in the office so I can't save and attach the modified scene.

So here's a step by step (assumes you have just loaded the scene you attached).

1. Add a new Emitter, placing it where Water is now
2. Remove "Water" (don't change its properties, remove it)
3. Select "Flume" and in Properties/Dynamics turn off "No shift", Bring radius/Level to 0.
4. Select new emitter and set it this way (I tried to preserve your choices):

Generator Tab
Birth rate: 2000
Generator size X/Y/Z: .15,.15,.15
Particle limit: 10000
Particle Tab
Particle size: .02
Life: 300
Show size: OFF
Outputs size: ON
Etc Tab
Y Gravity: -9.8

5. Open Hypervoxels, activate the new emitter and set it this way:
Particle size: 2 meter
Show Particles: ON
Use Particle scale: ON

Now click calculate in a dynamics tab, it should work and render properly (at least it does on 9.5 discovery under vista 32). Particles pile up in the waterwheel, but I guess it's gonna be animated. Btw, the Waterwheel collision has a small offset you should remove.



I'm wondering if this has anything to do with what seem to be the extremely large size of the particles. When I click on "Show Size," they're huge. (When I click on "Output Size," they're small again. I have no idea what any of that means.) I have no idea how to change their size, other than to scale the emitter, which seems undesirable because it will make the stream extremely narrow.


The way different Lightwave tools interact on particle size can really be confusing. I'll try to quickly sum how it works.

Particle size depends on Particle Size as set in emitter's Particle tab - this is each particle's radius. For this to work, you have to activate "Output size", otherwise particles will default to a radius of 1 meter. This is the value used in dynamics calculations.

Particle size does not depend on emitter object's scaling factor, however layout's preview ("Show size" checked in particles panel) will. This can lead to all sort of confusing behaviours, where your particles seem to miss collisors, or hit them too early. So it's better to leave scaling to 1 (besides, scaling does control other emitter behaviours).

Luckly, Hypervoxels own layout preview does not take object scaling in account, and should be preferred as long as you activate "Ouput size" in particles panel and both "Show particles" and "Use particle Scale" in Hypervoxels.

This syncs particles as used in the dynamics with particles as rendered by hypervoxels. To get an 1:1 match set particle size in Hypervoxels to 1 meter (or two meters for surface hypervoxels, will explain why below).

With those settings you can be confident that what you see in preview matches what gets rendered. Also make sure not to set "no shift" in collision objects. No shift treats particles as sizeless points.

If you need particles to appear only in a small area, don't scale the emitter. Use "Generator size X/Y/Z" (in particles/generator tab) instead. This will confine particles to a smaller or larger area shaping the nozzle properly.

If you use surface Hypervoxels, as in this water project, you should take in account that a single Surface HV appears to be rendered at half size because radius really represents each metaball's area of influence. To avoid troubles, just set size in Hypervoxels to 2 meters when using Surface. This compensates the shrinking and gets rid of particles floating above the collision object.

As a side note, Particle size can also be set in the rotation and scaling tab, choosing Random rotation and scale. Also, dynamics calculation is needed for object-advanced collision to work properly.

There's more, but I hope this helps.

dballesg
02-07-2009, 05:04 PM
David—

Thanks for your help. Unfortunately, in the file you attached, the problem remains (image attached below)—most of the particles are going right through the surface they are supposed to be colliding with. I can understand why scaling the emitter might produce some undesirable results, but can you please explain why you thought reducing the Birth Rate and switching to Generate By Frame would make a difference? I can 't find anything in any documentation anywhere that explains how Birth Rate and Generate By Frame are related. Also, what is the FX Browser? I'd never seen any refernece to it until I looked it up in the manual. What is the resolution and how does it affect anything?

Dodgy— The collision type was set to Advanced in the scene I attached. I don't want to seem ungrateful that you responded— but did you even bother to open the file and look at it?


Hi Giacomo,

Sorry I forgot to tell you to press calculate. Mi mistake. Collisions are only calculated correctly when you press calculate.

There difference between Generate by Frame or by Second it is the tim unit. So 2000 particles emitted on 1 sec = 2000 / 25 fps = 80 particles / frame. I reduced it to the half of that to speed up the calculations.

The FXBrowser has been there I think since LW 8? It was like a central panel where you can control all the settings of your dynamic objects on the scene. The Resolution option, affects the internal resolution of the calculation of Particle FX. If I remember well your scene had 100 mm that is a distance too big for the scale of your scene, that is why I reduced it to 5 mm. That distance as well has influence on the speed of the calculations, a bigger distance, less time of calculate, but with worse precision.


David

Giacomo99
02-08-2009, 09:59 PM
vfxwizard, dballesq, DBMiller, walfridson: Thanks so much! You guys are, as they say on the Internet, teh awesome!

I didn't have time to implement VFXWizard's full solution yet, but I did have time to fool around with the scene this evening and I want to add two points for present or future readers of this thread:

1. "Calculate" refers to the "IKB Calculate" button in the "Tools" section of the "Modify" tab. I bring this up to minimize the confusion of anyone reading this thread in the future—because I had to dig through the manual for about ten minutes before I figured it out.

2. Calculating the waterwheel scene with 10,000 particles in it locked up a 2 x 3.2 quad-core Xeon for fifteen minutes—after which I force-quit Layout because it was progressing verrry slooowly (and the "Abort" button didn't work.) So there seems to be a practical limitation on how many calculated particles one can have in a scene and still be able to easily tweak it. For now, I will keep the number of particles low and do test calculations until I get everything flowing correctly, and then do a longer calculation at the end.

Dodgy
02-08-2009, 10:13 PM
Dodgy— The collision type was set to Advanced in the scene I attached. I don't want to seem ungrateful that you responded— but did you even bother to open the file and look at it?


No I didn't. I didn't have the time. That was the first thing I thought of, since I've recently had a similar problem. I apologize for not having more time.

Giacomo99
02-10-2009, 07:55 PM
First off, thanks to everyone who responded. I couldn't've gotten this far without your help!

However, problems remain:

1. Even after setting up the scene according to vfxwizard's detailed instructions, the flowing particles don't stay on the surface of the collision object—they "float" above it at a distance of about an inch, as shown in the attached image. (Note that the actual collision object is NOT the waterwheel—it's an invisible form built to get the water to cascade correctly.)

2. Checking "Use Particle Scale" in the HyperVoxel control panel doesn't seem to do anything. I guess I'm expecting little spheres to appear that show the size of the HyperVoxels—is that correct? I'm afraid that even after vfxwizard's explanation, the relationship between particle size, particle scale and HyperVoxel size is still pretty opaque to me. Right now I have to do a render to get a sense of how big the particles are. VIPER is helpful, but it'd be great to see it in the preview.

Please advise. Attached below are a sample render of the scene in its present state, a screen cap of the not-colliding particles, and the scene files for those who might wish to examine them. Anyone with hints on how to get the water surface looking more realistic is welcome to chime in too.

http://home.earthlink.net/~bucket/TestRender.jpg

http://home.earthlink.net/~bucket/SideWheel.jpg

vfxwizard
02-11-2009, 01:45 AM
Checking "Use Particle Scale" in the HyperVoxel control panel doesn't seem to do anything. I guess I'm expecting little spheres to appear

Your expectations are correct, but your emitter lacks the HyperVoxelsDrawing plugin in Properties/Geometry tab. Add it and the preview will work. This is weird, as it should have been added by Hypervoxels by default.

I'm sure as soon as LW draws the scene as intended everything will make sense: there will be no gaps and you'll only have to deal with the Emitter's particle size control. Just a little note: set HV particle size to 2meters. What matters in Surface HV is the smaller solid circle drawn in preview, not the larger dotted one.


As for making water look more realistic, I'd add a light probe and turn on trace reflection. FastFresnel as currently set in your water surface has translucency and luminosity turned on and this is unlikely to work well.

I attach a quick test done with the following parameters in HV as a "clean water" starting point:

Color: white
Diffuse/Luminosity/Specularity/Reflection/Translucency: 0%
Transparency: 100%
Refraction: 1.33
Turbulence on bump, size 0.5/0.5/1.0

Default fast fresnel in shaders replaces the current one

Smoky1 HyperTexture with size 0.5/0.5/0.5 (to break up a little the spherical particles)

Rnl_probe in Image World

Currently your scene has a 16 ray recursion limit and a 5% reflection blurring in the Chrome surface. When you turn on raytrace reflections renders will take ages. Lowering recursion limit to 5 and turning off reflection blurring will make render times more acceptable.

Depending on your goals you may want to add another emitter, flowing smaller and faster particles, to break up the surface. Or randomize the particle size, which would be quicker and easier.

Btw, the hidden collisor you added produces a really nice flow.

Giacomo99
02-11-2009, 10:04 AM
Thanks for the help and kudos! Unfortunately, problems persist.

1. I entered the values VFXWizard gave me for the HyperVoxel water surface—but the Turbulence (on Bump) and Smoky (on HyperTexture) produce wildly different results from the render he attached. (Not to mention that rendering the scene at 50% (attached below) took 35 minutes on a 2 x 3.2 quad-core Xeon.) I suppose I could tweak the values until they look right and render at an acceptable speed, but I'm curious why they're so far off. (I'm on a Mac—does that make a difference? I vaguely recall reading somewhere that the same procedural settings render differently on Mac and PC)

2. With a Particle Size of 0.02, the particles flow correctly; with a Particle Size of 0.01, they start to go through the floor again (JPEG attached). This is incredibly annoying. Why is this happening? Assuming the HV Size should always be left at 2m, how can one adjust the particle size without adversely affecting the dynamics?

3. I'm new to using HDRI, but VFXWizard's render looks great, so I suppose now is the time to get into it. However, why is the HDR image previewing as a spherical map in VFXWizard's render (above) and as a flat backdrop in mine? (Also, the reason I've never used it much is that the available HDR files never seem to produce the exact lighting I want. Is it possible to paint one's own HDR maps in Photoshop for use in illuminating 3D scenes? (I've Googled this topic and I can't find a solid answer—the best I can find are articles on combining multiple exposures of photos to make HDRI images, which isn't much help.))

Please advise. Scene file attached below. (Please note that the rnl_probe.hdr image is omitted due to size, but it's available at http://www.debevec.org/Probes/rnl_probe.hdr)

http://home.earthlink.net/~bucket/WaterTest11Feb.jpg

http://home.earthlink.net/~bucket/Particles11Feb.jpg

dballesg
02-11-2009, 12:15 PM
Thanks for the help and kudos! Unfortunately, problems persist.

2. With a Particle Size of 0.02, the particles flow correctly; with a Particle Size of 0.01, they start to go through the floor again (JPEG attached). This is incredibly annoying. Why is this happening? Assuming the HV Size should always be left at 2m, how can one adjust the particle size without adversely affecting the dynamics?

Please advise. Scene file attached below.

Hi Giacomo,

I tried only your problem with collisions. You ARE right, if I change the particle size to 0.01 there are particles that suddenly fall incorrectly.

I opened the FXBrowser, clicked on Option, and changed the resolution from 100 mm down to 20 mm. Any value bigger than 20 mm and suddenly one or two particles fall incorrectly.

I think you have hit a small bug with PFX precision on collisions and particle size.

Remember that lowering that value would made the calculations slower.

David

dballesg
02-11-2009, 12:51 PM
Hi again,

I just made a render with your settings after I calculated the particles with a size of 0.01 and a PFX resolution of 20mm as I posted before. I am not having that strange problem you have with Image World. But i am on PC under Vista 64.

My Quad Core 2.40 GHz has taken 26m18s to render the image!! YIKES! :) LOL

David

Giacomo99
02-11-2009, 02:01 PM
Yeah, the problem seems to be with the procedural settings in the water surface. Hopefully VFXWizard will pop up and have some feedback on that. If you want, you can disable or remove the procedurals on the water surface and the HyperTexture tab and it should render faster, or, if you're motivated, you can double-check the settings against what VFXWizard posted earlier on this thread.

Or are you saying the scene renders faster with the resolution at 100 mm? I don't really understand exactly what the Resolution setting in the FX Browser does—if it works, great, but a larger explanation of how the whole system works would be enormously helpful. Please advise.

serge
02-11-2009, 03:37 PM
... I don't really understand exactly what the Resolution setting in the FX Browser does—...
I've never seen a good explanation of 'resolution' (how it works under the hood), but what you should know is: the lower the resolution, the more precise of the simulation (but longer calculation time). At least, this is how it's supposed to work. However, sometimes I've noticed that lowering the resolution can cause worse simulation results; I've seen that with ClothFX especially. So, you'll need to experiment: start with a high resolution (depending on the size of your scene), and lower it until you're happy.

Anyway, I've had a look at your scene. The particles won't fall through if you do the following: copy the last 8 flat polys of the flume (the polys where the particles are falling on), and paste them in a different layer. You can use the same collision settings as the flume. Don't ask me why this works. :)

Giacomo99
02-11-2009, 04:51 PM
You can use the same collision settings as the flume. Don't ask me why this works. :)

Thanks!

Rant: How on God's green earth do you guys figure this stuff out? Because my history of working with Lightwave has been five years exactly like this: all the tutorials I can find on a topic are intro-level and completely inadequate, the manual is no help at all, and if someone is kind enough to help me on the forums the solution turns out to be 100% counterintuitive (a good example is shown in this very thread.) Please advise.

dballesg
02-12-2009, 01:43 AM
Or are you saying the scene renders faster with the resolution at 100 mm? I don't really understand exactly what the Resolution setting in the FX Browser does—if it works, great, but a larger explanation of how the whole system works would be enormously helpful. Please advise.

Hi Giacomo,

I was saying that with a resolution of 100 mm the PFX calculation are done faster. Serge explained it! :)


Thanks!

Rant: How on God's green earth do you guys figure this stuff out? Because my history of working with Lightwave has been five years exactly like this: all the tutorials I can find on a topic are intro-level and completely inadequate, the manual is no help at all, and if someone is kind enough to help me on the forums the solution turns out to be 100% counterintuitive (a good example is shown in this very thread.) Please advise.

On the PFX case is very useful see the scenes included with the content. And disect them, I know a very time consuming process.

And trial and error, plus a lot of search on this forums. That is what I do.

For me the manual is a reference this days if I forgot where is something, but basically ANY that is said on the manual I take it with a pinch of salt.

I asked MANY times for much better explanations of the tools and add a simple example of their use. But that never happened.

David

vfxwizard
02-12-2009, 02:43 PM
I'v lost a long posts twice just before submitting, so here's just the essential: I didn't save that scene and can't check but I surely have made a mistake copying the Smoky size, it probably was 1.5mt on all axes. Sorry for the confusion this generated.

This is also the reason why it's so slow: the small texture creates lots of high dynamic range detail to be smoothed by adaptive sampling. A quick fix would be to turn on Limit Dynamic Range. With the larger Smoky and Limit Dyn on, I rendered frame 200 of the 11Feb scene in 17 minutes at work (similar system as yours: Mac Pro 8x3.0Ghz, running in Vista 64 under bootcamp), but there's room for improvement (try the attached scene, it renders frame 200 in 7m33s with a little brightness loss -you will need to clear the saved particles solution).

Regarding collisions and particle size, as dballesg and serge said lowering the resolution will work. I'll try to be more specific tomorrow (unless Explorer freezes again :mad:).

vfxwizard
02-13-2009, 04:22 AM
with a Particle Size of 0.01, they start to go through the floor again (JPEG attached). This is incredibly annoying.


I understand how frustrating this must be, but there's a logic behind.

First, a few examples that will also provide quick solutions.

1. Load the 11Feb scene, set particle size to 0.01, and as already suggested lower the resolution (from now on resolution refers to PFX Solver, as set in FX Browser). You'll see that progressively lowering resolution reduces the number of falling particles, until they are all caught. As dballesg pointed out, this happens when resolution is around 20mm. I got it working at 25mm, with a total of 2613 steps. Disadvantages: it's slow.

2. Reload, set particle size to 0.01. Reloading the scene resets resolution to 100mm. So particles should fall, right? Try changing Gravity, lower it to -5 meters. Particles will NOT fall, and only 1006 steps are computed leading to faster feedback. The disadvantage is that you may want your particles to move at a specific speed. This shows that particle speed plays an important role.

3. Reload, set size to 0.01, then add a small offset, 5mm, to collisors (Radius/Level 0.005). Particles won't fall, will move at intended speed, and computation will still be done in 1006 steps. Disadvantages: there's a small offset that can be compensated by increasing particle render size in Hypervoxels panel.


Now for the explanation, I'll try to keep it as non-geeky as possible.

Resolution is not like the size of a net, with small particles falling thru holes. It looks this way but really relates to speed.

The way most physics solvers work is thru integration. Time is subdivided in steps, and a solver is used to "predict" where the item will be in next step according to its velocity and position. This process accumulates errors, but using steps fine enough the error should not be noticeable.

Just like in Adaptive Sampling antialiasing, it makes sense to add more steps when needed instead of doing a brute force evaluation. Luckly LW does this for us increasing the step size as needed. But just like Adaptive Sampling, there are some scenes that will require finer evaluation. PFX's Resolution control forces the solver to do more steps.

Try this: add a particle system in a scene, set its motion Y to 1 meter and calculate: 204 steps. Increase particle Velocity to 1000%, recompute: 421 steps. To keep up with the faster particles LW triggers more evaluations. And guess what? If you bring Velocity back to 100%, and lower Resolution to 10mm, you'll get exactly the same number of steps (421) because the ratio is the same.

Now in the same scene, reset resolution to 100mm, then add a collision object -box, sphere, plane. Those primitives won't require special computations. Regardless of where you place them, you'll always get the same number of steps (204).

Delete the collisor and load any object, even a single poly. Set this as a collision object. Calculate. Number of steps will go up, as long as the collisor is within the space particles will traverse.

From all this we can derive a rule of thumb: fast particles and collisions will require more steps and be more subject to errors. Also, polygonal collisors will require many more computations than primitive collisors.


As serge said, we want to start with the highest resolution possible then lower it only when needed. How?

I would always try to fix problems reducing speed and/or adding offsets to collisors before altering Resolution. The increase in computation time -expecially with self interacting particles- quickly becomes unmanageable.

Often, it's better to arrange several "primitive" collisors (boxes, spheres...) instead of using a polygonal collision object. In the attached scene the flume collision has been replaced with a separate box collisor and particle emitter has been moved a little. This solves at 100mm with .01 particle size in 1031 steps.

Another common trick is to calculate a solution where particles move slowly, save it as a .pfx, then alter its playback speed in Particles/File.

As boring as it may seem, it pays off to have a look at the detailed step computations displayed in FX Browser window. You'll see how LW increases and decreases step size according to what happens in the scene. You may jump from 3 steps per frame to 20 or more simply adjusting bounce factor or collision probability.



Regarding how to figure out this stuff... Guess I have a slight advantage because my background is in 3D development. However this only allows to make educated guesses. To really understand how LW works there's only dballesg's route: scene dissection and trial and error. For example when Ouput Size was introduced around v9, there were no docs. I had to try the various checkbox and do test renders to devise the "2mt surface hypervoxels" method posted earlier. On the plus side, when you own LW there's no need to shell $$$ for Nintendo's Brain Training. :)

As usual I hope this may be useful -and without typos.

Giacomo99
02-13-2009, 06:54 AM
VFXWizard- awesome, thanks so much for your help. It may be a few days before I have time to carefully study what you've written, though.