81 replies to this topic

[HSrdelic]

Nigel, I didn't know you were on beta for it ?
As far as review goes, anyway is fine with me, and it makes more sense you go for it because you are quite familiar with it by now.

Back on the topic - Xparticle looks great and it seems a lot of work and effort went into it. I am burried in work until the end off the month, but am eager to try this out. Guys, what are the numbers of particles you can produce and work efficiently on your systems? I would like to hear some performance numbers?

Cheers

[3D-Pangel]

I think the limit was set at 30,000 if I am remember correct from a CG Networks thread.

Dave

Edited by 3D-Pangel, 22 February 2012 - 06:21 PM.

[3D-Pangel]

No, it has to be used in conjunction with X-Particles. The reason is that the generated object accesses data from the particle stream. No particles, no effects. So you have to use it with the emitter from this system.

Regarding TFD, I don't have it myself but I know one of our testers got X-Particles working with TFD and was producing some quite nice effects. We may do a tutorial on that at some point, or someone who has TFD may do.

Steve

I just purchased TFD and I must say that it is just plain awesome! Pretty intuitive for a fluids simulation package (or about as intuitive as a simulation package can be - it is fluid dynamics after all), very powerful, fast and the viewport feedback is just outstanding.

So if you are into FX - and I imagine would be if you are interested in the X-particles plugin - then get your geek on and buy both particularly if there is a way to get X-Particles to work with TFD.

As an aside, there could be a bit of a side product if the sprite shader was re-written to either work with X-partilces or TP. Not sure how difficult that would be but I see a need for a shader that works with particle life - unless someone else can tell me how to do this witihin standard C4D without resorting to XPresso.

Dave

Edited by 3D-Pangel, 22 February 2012 - 06:22 PM.

[spedler]

Back on the topic - Xparticle looks great and it seems a lot of work and effort went into it. I am burried in work until the end off the month, but am eager to try this out. Guys, what are the numbers of particles you can produce and work efficiently on your systems? I would like to hear some performance numbers?

Cheers

It's difficult to answer that because it depends a) on your hardware and b) on what you do with the particles. The more modifiers, questions/actions, etc. you add in the more processing power is required.

As a very simple example though, I've just built a new PC with an i7 and 16Gb memory. Currently I have it generating up to 10,000,000 particles with a birthrate of 30,000 per second and to all intents and purposes no slow down in the viewport. I can add in a modifier or two and again no noticeable difference. Only when I start to generate 100,000 particles per second does it slow down a little, but it's perfectly usable.

The actual particle limit is determined by your system memory, and you can set whatever limit you like within that.

Steve

Edited by spedler, 23 February 2012 - 08:13 AM.

[deepshade]

How do you cover/fill - cover an object with particles - but with an offset. My particles are penetrating the object that they are covering? then start a timer after the objects have stuck

Edited by deepshade, 23 February 2012 - 12:58 PM.

[spedler]

At the moment they will partly penetrate because of the way the cover/fill modifier works. It might be possible to add an offset to this but I'll have to look at the way it could be done. So I'll add it to our list of potential future enhancements.

Once the particles have stuck, you need to decide when they are going to do something else. Say you have a pulse of particles and they have all stuck by frame 100, then you want them to do something at frame 120. Set up a question which tests for current frame = 120, then have that trigger an action to release the particles from the target object. To do that, you need to set the action to 'modifier will NOT affect particles'. This releases them from their target and then you can make them do whatever you want.

Does that answer the timer point or did you have something else in mind?

Steve


Steve

[deepshade]

Thanks for the feedback Steve

Probably easier to explain what I'm trying to do - i.e. recreate an anim I did last year.

Particles (bacteria) flow into scene
Attach to object surface (which has an antibacterial coating)
some stick straight away
some stick then slide before sticking again
all disintegrate (spawn into smaller bits) after a set amount of time (from when they are stationary)

For simplicity the particles are capsules and the main collision object is a tube.

The particle penetration thing is a real show stopper for me. Particle objects need to show correct collisions with each other and the surface. I really don't want to do any more workarounds (have been doing that in every particle anim ever)

[slouchcorp]

what about having a dummy object (hidden) as the sticky surface, so its bigger that the real one then they will "look" to be doing whats expiated.

made a file if you want me to send it to you

[deepshade]

Hi Mike

I've just read my post - sorry if that came across negatively. I appreciate the suggestion and it would solve the problem. But I feel some sort of offset is vital to any collision system as this 'dummy' object approach does complicate the mix.......and yes - I'd like to see whatever you have created.

Last Q - there appears to be an action to Unstick - but not the reverse?

[spedler]

Last Q - there appears to be an action to Unstick - but not the reverse?

You don't need the reverse action. If you look in the emitter, then if you select to emit from an object you have the option to stick the particles to that object on emission. If you keyframe the object's movement/scale/rotation, the particles then move with the object.

The Unstick action is to release the particles from the object they are stuck to (i.e. emitted from). If that wasn't available, they'd be stuck there forever.

Cheers,

Steve

[deepshade]

thanks for info

[deepshade]

Nope - tried to get this to work - cant seem to get anything satisfactory on the collision side. Simple capsules representing bacteria intersect.

Tried turning fill/cover on with a question - is frame >100
but doesn't seem to turn the modifier on? I want to move bacteria from one selection to another on frame 200 - but as I can't get the first to work - I'm just stumped

Also trying to get the bacteria to randomly tumble?

As the review mentions the system is compatible with R13 dynamics I thought Id try that - but can't get particle particle collision and cover/fill working

From a first look at this system it seems well suited to those who wish to do particle effects, but not for those who wish to animate particles as interacting objects.

Edited by deepshade, 25 February 2012 - 01:55 AM.

[spedler]

Hi Paul,

If you want to send me a file, I'll happily look at it. Can't guarantee to make it work for you but I'll sort it out if I can. Mike still asks me to look at his files occasionally and he's been using it for months (I'm sure he won't mind me saying that!).

Steve

[jwiede]

Regarding TFD, I don't have it myself but I know one of our testers got X-Particles working with TFD and was producing some quite nice effects. We may do a tutorial on that at some point, or someone who has TFD may do. Steve

I have TFD as well, and would be very interested in how your tester set up X-Particles and TFD to interact, any chance they'd be willing to write up a description, or produce a quick video on it?

[revla]

I am even interested in this software and TFD. I know time of render with pyrocluster but I would be interested if a user of TFD could say to me the time of necessary render with TFD to realize an image of fire or smoke for example in definition 1920x1080 with GI.

[3D-Pangel]

I am even interested in this software and TFD. I know time of render with pyrocluster but I would be interested if a user of TFD could say to me the time of necessary render with TFD to realize an image of fire or smoke for example in definition 1920x1080 with GI.

TFD is pretty fast and is not really limited by the size of the final image but rather by the voxel size. The smaller the size of each "volume element" or voxel within the TFD container, the more memory you need and the longer it takes to calculate the simulation. But then again, smaller voxels create finer detail. The other factor is the size of the fluid container - or the volume that is broken down into elements by the voxel setting. So if you have a huge volume and a small voxel setting, you best have vast quantities of memory (e.g. above 16Gb) and lots of time.

Render time is really not impacted by the size of the image as much as you would expect. All your time is consumed by how much detail you want in the fluid simulation and the other size of the container. Still, what I have noticed is that TFD is really optimized pretty well to make the fluid simulation calculations go as fast as possible. For example, the simulation calculations within the container are optimized by being restricted to the volume which the flames/smoke occupy within that container at any point during the entire simulation. It won't calculate voxels for the entire container unless the smoke and/or flames occupy the entire container volume.

Personally, I am really loving this plugin....but then again, I was the type of kid who used to set his model airplanes on fire and crash them into toy villages. Some things you never grow out of. Steve Jarratt (past 3D World editor) said it best when we were emailing each other over that "other" fluid simulation plugin: "Blowing s**t up is cool."

Need I say more

Dave

[revla]

Thank you very much Dave.

[spedler]

I have TFD as well, and would be very interested in how your tester set up X-Particles and TFD to interact, any chance they'd be willing to write up a description, or produce a quick video on it?

Hi John,

I'm sure he would, you could ask him yourself at the x-particle forum if you like. It's Lothar (that's his username there) and he tested x-particles with almost every plugin I can think of. I know he got it working but as I say I don't have TFD so can't really say much more. Lothar is really helpful though, I'm sure he'll tell you how it was done.

He posted one of the animations he did with TFD over at CG Talk if you haven't seen it.

Cheers,

Steve

[3DKiwi]

Ok, I'm having some fun learning how to use X-Particles. One thing I don't get is the direction modifier. It doesn't always send the particles in the direction I tell it to. Often changing the direction makes no difference.

Here's a couple of examples.

Particles being sent in 2 directions. Should be only going in 1. Changing the emitter orientation to +Y makes the particles go in 1 direction.
 Direction.c4d   240.24KB   22 downloads

But now, changing the direction (heading or pitch) makes no difference to the direction the particles are going in.
 nochange.c4d   239.46KB   25 downloads

Nigel

[dataflow]

change operation to absolute