Yapu (yet another particle update!): I've updated the code to take into account moving deflectors / gravity attractors. The new windows build is here. As before, it's just the exe, so unzip into a copy of the tuhopuu directory.

Also, here's a little demo vid for moving gravity stuff......

I haven't included a patch since I now have Tuhopuu commit rights, so I've put it straight into the CVS (thanks Hos!!!).

At the moment, it doesn't work for objects following paths, but objects with their own rot/loc/size IPO keys should be fine.

As far as gravity goes, things seem to work nicely.

Deflectors are a lot less impressive though! You may find a lot of leakage , especially if the deflector is moving quickly.

The reason is that I can't find a good algorithmn for calculating the intersection of a moving plane and a moving particle, so I've had to simplify things a bit. Still, with a bit of experimentation, you can get nice results.

Cheers

Leon

Great stuff Leon,

Any "mini-tutorial" or at least some info on HOW to use (or find) the
deflectors / etc...?

I have no clue where to find it to test it...

/Tommy

Hi Leon,

I really like what you're doing! Thanks.

I have a suggestion which might help solve the 'leaking' particles problem and also be a great added feature:

Make Particles Real:

Afaik, The particle system is effectively an edgeless mesh with a few special properties (life and children) Everything else is recording of particle location. So it should therefore be theoretically possible to use a vertex to replace a particle.

With this in mind, I can think of two possible options:

1) Replace entire particle system with a mesh with vertex keys for location data (similar to what the Topix cloth does)

Advantage:
- only 1 editable object

Disadvantages:
- Not possible to control life of an individual particle
- Generation of children vertices (Solvable by having a new object and mesh per child generation)
- Limited no of keys?

2) replace each particle with an object (which would only contain 1 vertex)

Advantages:
- No key limit
- Life can be controlled by either a) setting keys for Layer or b) adding a new keyable object mode; 'renderable'. (Would not do it through alpha because of possible dupliframes and because we would require a different material for every single particle!)

Disadvantages:
- thousands of objects! (possible solution might be to create a special object class for particles so they do not show up in the databrowse with other objects. The new object class could possibly also work at a 'group' level - Objects within an object. (Similar to the 'group' function which was in some nonofficial builds - ie. selecting one particle object selects all together but still possible to edit 1 individually or delete, add etc)



This would mean that once we are happy with what the particle system has generated we can 'make real' and delete offending particles as well as tweak other particles to 'perfection'! Don't know if I just wrote a load of junk. I'm probably missing out on some important things - it seems to work in my layman's head though!

Either way, thanks for what you've done so far!

Regards,
Fabrizio

leon - great to see the particle system evolving!

however i experinece strage behaviour with deflectors - they behave more like a field rather then a rigid body. most of the particle in the blend file below seem to be redirected softly before they even touch the surface. i'd actually like them to bounce off the surface like little balls. any ideas? or should i be patient until next release?
get file here
anyway - great work!

best regards

marin

JoOngle wrote:

Great stuff Leon, Any "mini-tutorial" or at least some info on HOW to use (or find) the deflectors / etc...?/Tommy

check out the edit buttons (F9) - there you'll find the toggles for deflector/gravity

greets

marin

solmax wrote:

check out the edit buttons (F9) - there you'll find the toggles for deflector/gravity greets marin

Thanks!

Last edited by JoOngle on Mon Mar 01, 2004 12:20 am; edited 1 time in total

Leon awesome work! Nice attention to an area of blender that needs it!

hi all,

JoOngle, you're right, I need to write a little tutorial for this, when I get a moment I will do! In the meantime, have a read through my previous particle posts if you haven't already done so.

Solmax - this one is a bit easier! Basically, the particle system works with key frames, then interpolates between them.

In your example, you're only using 8 key frames (the setting is near the top right of the particle effect panel). With a particle life of 175, each particle only has a key frame every 22 frames or so.

I had a play with the .blend, and increasing the number of keys to 50 or 100 gives much better results (and much longer calculation times!). Watch the damping setting though: as you increase the number of keys, you will need to decrease the damping.

Another thing you might want to try: try separating the "cockpit" area on your model, and making only this a deflector. This should cut down on calculation time (it reduces the number of faces it has to check a lot). Also, try switching "bspline" off - this sometimes makes bounces look better.

Ilac - your option 1) is pretty much what happens at the moment! It's just hidden in the background, and recalculated on loading (saves on what you need to store in a file). 2) would probably have big implications for file sizes - I've been playing around using 20,000 or 50,000 particles, and up to 100 keys per particle. You can imagine how much data this is!

Keep the ideas coming though!

Cheers

Leon

Thanks Leon, will do.

I've gotten it to work now, looks awesome, but there are something
weird and (to me) unexplainable and I hope you can shed some light
on it...

When I set up a simple "particle rain" from a cube...rains onto
a plane set up as a deflector...it works fine, but when I try
to increase the "life" value on the particle's lifespan...then
everything goes hawock and even if I'm adjusting that variable
back to default (50) it's still totally out of control.

Bug?

/Tommy

Leon, I have not looked at the particle code at all, but how hard would it be to add a recalc progress bar? Also the capability to kill a recalc. So if you choose some settings that are going to take an hour to calc and really don't want to do it right now you could kill the recalc. What do you think?

joOngle - it sounds like a bug to me! However, I can't reproduce it: can you post a blend somewhere that I can take a look at?

guitargeek - at the moment it outputs the calculation progress every 1000 particles to the console. I will probably tidy up the output (so it's a bit more like the Yafray progress bar maybe), but I'm not sure whether I could put a progress bar in the blender gui itself. If you know an easy way to do it though, let me know!

The ability to kill the calculation is a great idea (although it might make things unstable!!!). I don't really know where to start with this though (I'm still pretty new to C). Do I need to check the keyboard every cycle or something like that? Any pointers in the right direction would be very helpful!

Cheers

Leon

Hello, how about making the number of particles during the editing lower(maybe an option in % of the resulting ones), the rest could be computed during/before rendering?

hi pildanovak,

I'm not sure it's actually that helpful to do the calculation at rendertime. From my point of view, I like to render a number of stills before rendering the animation, just to make sure that everything is going ok (good material settings and so on).

I wouldn't want to have to wait for the particle calculation each time I wanted to render a single frame. Also, I prefer to be able to see all the particles in wire frame view.

Having said that, are you finding the calculation times a problem?

Cheers

Leon

I know ZERO about C programming, but it is already possible to kill an on-going render (internal render)... see how it was done there and then copy/call the same fuction when doing the particles calculations. However, remember how the ability to kill a render has allways been a source for inestability and frozen blenders in the past?

Personally, I don't have a problem with long calc times... as a wise blender user you know that if you set a particle system with 60,000 particles and 100 keys then you should be ready for some huge calc times.... it is a matter of user resposability and common sense.

hi apollux,

thanks, I should have thought of that! Will take a look.

You're right, it might make things unstable, so it's not something I'll definitely do. Probably I'll code it so that if esc has been pressed, it will just ignore the gravity and deflector code from that point onwards. That should make things fairly safe.

I do think its a good idea though - every time you make a change to the particle system it recalculates, and this can be a pain.

cheers

leon