_1024_ParticleWarfare

franz's picture

Lightweight plugin to generate particles. Download from 1024 Blog Drop a comment if you like it !

gtoledo3's picture
Re: _1024_ParticleWarfare

Exciting! Thanks for posting this publicly.

franz's picture
Re: _1024_ParticleWarfare

thxx for your excitment. Please post some pics if you've got some interesting results.

cybero's picture
Re: _1024_ParticleWarfare

I have had a productively difficult with displacing particle system vertices by means of my own kernels this week, so this is quite a sweet addition to the two OpenCL particle systems I've been working with. Including the stock patch vertex pipeline and Particle Tools vertex pipeline methods that makes five such methods to work with.

I'm looking forward to experimenting with this. Thanks for sharing.

photonal's picture
Re: _1024_ParticleWarfare

Great plugin!

Thanks for posting that

jrs's picture
Re: _1024_ParticleWarfare

Most cool - runs so smooth

When you have some time I don't suppose you'd care to implement some of the following http://www.kfish.org/boids/pseudocode.html

franz's picture
Re: _1024_ParticleWarfare

wow, interesting. Thanks for the link ! will definetly look at it deeper

cybero's picture
Re: _1024_ParticleWarfare

Just noticed what I thought at first was a GFLog sign of plugin imperfection only to find by process of elimination that the FPS counter patch being on gives this result

[12:29:36.498]   <RenderView: 0x11b1b3880>: Render failed at time 20.042430s
[12:29:36.512]   <QCBillboard = 0x297D49B0 "Billboard_3"> OpenGL error 0x0502 (invalid operation)
[12:29:36.513]   <QCBillboard = 0x297D49B0 "Billboard_3"> Execution failed at time 20.053
[12:29:36.513]   <QCPatch = 0x297D4310 "Patch_2"> Execution failed at time 20.053
[12:29:36.513]   <QCPatch = 0x29040690 "Patch_1"> Execution failed at time 20.053
[12:29:36.513]   <QCPatch = 0x29040120 "Patch_4"> Execution failed at time 20.053
[12:29:36.513]   <QCPatch = 0x26EC2C60 "(null)"> Execution failed at time 20.053
[12:29:36.513]   <RenderView: 0x11b1b3880>: Render failed at time 20.053470s

hadn't noticed that before.

The Particles plugin by and large works sweetly, unless I overtax the available system resources [trails and emit on lines are the biggest source of pipeline overhead]. If given a sustainable set of parameters then it really does produce some great results.

BTW, just double checked and the FPS patch related GFLog error isn't reproducible by switching the Mouse x,y to a Sprite's positions. It only occurs with the FPS patch on and with the Particles patch on. Furthermore, with the FPS patch switched off, the actual rendering rate allows for set or unlimited fps to run faster.

Also, this only happens with the Single Emitter example, the Particle Trails example.

Another chance discovery.

Here's what the Single Emitter does on its own :-

Open up the Single Emitter example and render in Viewer, also open up the Particle Trails example and try running that concurrently . Set some Lines in the Trails Viewer, then set emitters in the Single Emitter example and I find that I get the following happening. Kind of unintended I think, but interesting none the less. Sort of spooky patch territory without the explicit send and receive.

Upon further examination, the same or similar result can be obtained by opening any of the examples and rendering concurrently - interesting.

PreviewAttachmentSize
_1024_SingleOnly.png
_1024_SingleOnly.png119.96 KB

photonal's picture
Re: _1024_ParticleWarfare

When I have multiple instances of the the plugin - changing parameters in one; e.g. Lifetime - affects the Lifetime of all the other instances too.

Is it possible to have ParticleWarfare systems with independent values of Lifetime or is this maybe a bug?

PreviewAttachmentSize
_1024_ParticleWarfare_MotionDetect_Movie.qtz11.3 KB

photonal's picture
Re: _1024_ParticleWarfare

Also, when enabling a Billboard to view the original movie source together with the particle system - it starts to get very flaky and constantly crashes.

I've tried changing Blend modes which hasn't helped

Any ideas what might be the cause?

cybero's picture
Re: _1024_ParticleWarfare

That's within the same composition too •~ :-)

I thought at first you'd stumbled upon the concurrent composition result I posted about above. Nice use of the image input BTW :-)

I found Lifetime to be problematic / interesting as you described. I didn't find much else that worked quite like the concurrent composition result I posted earlier.

However, like all the other _1024 examples, running concurrently with just one more Particle Warfare comp will result in one influencing the other directly.

cybero's picture
Re: _1024_ParticleWarfare

Couldn't reproduce your problem, not with any blend mode or any layer numbering for the billboards, they slow everything down a lot, but they don't crash or actually get flaky, the precise result you've gotten might well depend upon the nature of the graphics your presenting to your pipeline.

I've actually used movies and animated transparent pngs, just to see if they would provoke some flakiness and neither mpeg , nor png provoke the precise sort of problem you report, a screenshot perhaps?

photonal's picture
Re: _1024_ParticleWarfare

Here's a screen capture of what happens when I enable (about 3s into the capture) a billboard of the original movie concurrently with the particle system.

PreviewAttachmentSize
QuartzComposerCrash.mov478.5 KB

photonal's picture
Re: _1024_ParticleWarfare

This is what I'm working on - but wanting to enable/disable layers on the fly (using MIDI controllers). Currently though only getting crashes.

PreviewAttachmentSize
Target.mov3.75 MB

cybero's picture
Re: _1024_ParticleWarfare

Please find attached a re-versioning of your posted problem example that works without fail for me.

It points to two external URLs [no audio included] and doesn't crash for me, but evidently the same might not prove to be the case for you. Do you find that you also get a crash when you presenting a queue of a transformed static image?

franz's picture
Re: _1024_ParticleWarfare

This is not a bug but rather a known behavior. I'm actually using global variable for Lifetime and other internal parameters, and since everything happens on the same thread, parameters such as Lifetime are shared among all instances of the plugin. I did this b/c I'm running this plugin on 6 different QCviews from with a custom app., for a big installation, and I didn't want to set each independently. Lazy design on my side... ;( Will correct that in a future release.

franz's picture
Re: _1024_ParticleWarfare

strange. I could not reproduce your problem, sorry. Here it works without crashing on every movie I'll throw at it.

cybero's picture
Re: _1024_ParticleWarfare

With keys [not MIDI controllers], still crashes not ever :-).

MIDI controller problem?

Perhaps your hardware being slightly different from mine [doubtfully relevant]?

cybero's picture
Re: _1024_ParticleWarfare

What about the concurrent semi spooky behaviour I posted about?

Reproducible?

BTW, I too get no such crash with photonal's examples.

gtoledo3's picture
Re: _1024_ParticleWarfare

It's "lazy" in one way, but I take note of that because it's actually pretty clever in another way.

I still haven't used it... I guess my personal make or break is going to be if it acts like gltools does when you feed it nan values. Looking forward to firing it up in a minute.

franz's picture
Re: _1024_ParticleWarfare

the spooky behavior is due to global variables used inside the plugin. It was actually an intended behavior to spare me some hassle (although global variable will make any decent OOP coder ROTFL... ) I'll correct that .

gtoledo3's picture
Re: _1024_ParticleWarfare

This is kind of unrelated (?), but I sometimes have similar problems to what are being described with the movie loader and crashing when running Image Pixel OR Image PixelS. It will work fine on video signal, but I try to feed it a movie, every so often I would get a crash. Reading about the problems remind me of this. The movie loader is traditionally a somewhat flaky patch (stuff like current position doesn't work correctly, and there are other flaws). Trying the v002 movie player in this instance might stop crashing (maybe not...).

franz's picture
Re: _1024_ParticleWarfare

as a sidenote, your movies doesn't have to go through motion detection to produce particles. Just resize them to some "decent" dimensions . It will generate a particle for each pixel value > threshold (so you do the math: 80by60 is already 4800 possible emitted parts. per frame....)

photonal's picture
Re: _1024_ParticleWarfare

Thanks a lot for the fix! - am going through it to see where my version falls down.

What in particular did you do to fix it?

cybero's picture
Re: _1024_ParticleWarfare

& this is the cause of the noted concurrent behaviour, I guess?

Whatever, really nice plugin, still discovering its usefulness.

cybero's picture
Re: _1024_ParticleWarfare

could it be made a switchable option? [please :-)]

photonal's picture
Re: _1024_ParticleWarfare

I think I've discovered the crux of the matter.

Seems you have to be careful about the ordering of the various layers.

Eg. Clear at 1, Billboards 2,... and then the ParticleWarfare patches.

See the attached:

_1024_ParticleWarfare_MotionDetect_MovieBillboard-2 works fine as opposed to

_1024_ParticleWarfare_MotionDetect_MovieBillboard-2-Crashes

cybero's picture
Re: _1024_ParticleWarfare

puzzlingly enough, nothing much , I had tried out different movies and also different static images to try and provoke the kind of crash you'd reported, but only found success •~ :-) i also moved the Billboards down to the bottom, but that was just because they seemed to look better down there. They didn't crash for me in any position layer order wise.

I just wanted to know if my working and only slightly redrafted version worked for you without crashing. The fact that it does suggests some kind of cache kludge is a part of your problem. If it were hardware related, then my slight redraft - pointing the movie patch to external URLs and running asynchronous wouldn't have worked for you even though they worked for me.

bangnoise's picture
Re: _1024_ParticleWarfare

I have a QC boids plugin I haven't shared, outputs a coordinate structure for you to draw with as you see fit. Bit unfinished (iirc orientation information is borked) but if anyone's interested holler.

cybero's picture
Re: _1024_ParticleWarfare

hollering away :-)

gtoledo3's picture
Re: _1024_ParticleWarfare

On this, did you feel like there was a big impasse in supporting z? If it could support the structure from a "get mesh (vertices)" out, it would be cool (the math patch as well).

franz's picture
Re: _1024_ParticleWarfare

it can support z but it is disabled, as i didn't use it, and thought I could gain some speed that way. never thought of the get mesh (since i'm still with KnM.3D). I'll try to re-enable z for the next version, and now that I think about it, maybe an option to attract the particles to the mesh. The math patch does support Z, try the _1024_Math_Perlin example.

gtoledo3's picture
Re: _1024_ParticleWarfare

When you do "get vertices" you get a 4th dimension though (a row of 1's....what for...not sure), re: math patch. It seems like I had that working at some point (?) because I remember when you first posted, I tried mesh blending, but in other instances, I just get an exception with the math patch. I don't know if something broke, or if there was something specific to my one composition that was making it work. In general, it doesn't work when feeding it the 4d struct that "get mesh (vertices)" produces.

I still use Kineme3D too, but I'm using both in combo. There are specific cases where I find the mesh engine to be useful.

If it supported structures like this, you could just oversize it using a 3D scale/transform and have a halo of particles around the object. If you processed a structure with a mesh filter you could do things like push and pull masses of particles after establishing them, run positions through noise kernels, etc. (Just citing some more use-cases.)

gtoledo3's picture
Re: _1024_ParticleWarfare

Images on points might be cool as well.

With this, you could cycle through an image structure and have little animated butterflys or star bursts happen at each vertice of something as it grows... or the classic static image.

The look and function of this is cool and inspiring, so it immediately leads me to have many ideas.

I'm excited with a particle system taking structure like this. One thing that I always wished was possible with Kineme Particle Tools, is to be able to feed it structures for collision (as opposed to K3D objects). I'm just throwing that out there as food for thought.

photonal's picture
Re: _1024_ParticleWarfare

looking forward to z-support!!!! ;-))

perhaps mapping luminance or another parameter such as RGB value to point-'thickness'? (with the ability to have a colour gradient between the min/max z-coords? maybe this is asking too much?) ;-)

gtoledo3's picture
Re: _1024_ParticleWarfare

I made this clip with a pretty tweaked out comp that uses Particle Warfare.

I'm doing a couple of things where I hit certain CI filters with different colors to get certain looks, then invert or rotate hue. I'm feeding it a moving perlin texture that has some gamma control going on, to get the particles to act like I want. So there's some feedback going on in a couple places, hue rotate, and some NI color channel invert stuff going on at various steps.

gtoledo3's picture
Re: _1024_ParticleWarfare

Also, I've noted that with the Image Input, the "noise" settings seem to mix into the image "too much" after awhile. I write "too much" in quotations, b/c it's just my personal taste. It seems that the random noise starts to totally overtake the image I would expect. Maybe it would be nice if there was a 0-1 input that allowed you to tune in the amount of noise? For me, this would be icing on the cake, along with being able to shoot particles backwards or forwards in Z, ala the attraction or z-velocity stuff like is in the stock particle system. Even being able to just feed a z-value to the system without it blanking out would be great.

Secondly (or thirdly?), when one puts this in a RII (on my system), for some reason, the whole image outputs white, when connecting to a Billboard. This is when using the Image Input on particle warfare. However, if I put the Billboard that the RII connects to in "over" and have a black clear, stuff looks OK (oddly, what I see as "white" background, but what should be alpha does turn to alpha when I put the Billboard in over), but I can notice a very subtle black flicker on the final image that pushes to the billboard. This is extremely hard to perceive, and near impossible to screen grab (I've tried). I don't get this behavior (that I can tell), when I'm using the Particle Warfare in mouse driven mode.

I haven't tried it hardly at all w/ the structure input yet (besides pushing z values to it and watching everything disappear).

I'm giving a litany of small critiques, so I hope it is taken with the understanding that I'm trying to constructively help. I'm very grateful for this tool, and you making it public.

I think that z-value (and being able to take whatever that 4th val that comes from "get vertices" without flaking out, and just ignoring it), so that you can make particle bubbles, hair, fire, etc, come out of a 3d object will be very "hot". I know you're using K3D extensively, and I do too, but there are a great amount of things that can also be done w/ the stock 3D tools at this point, simply b/c one can access vert/normal/texture, etc.

franz's picture
Re: _1024_ParticleWarfare

Hi GT, can you post a "simple" sample comp showing the issue you're having with RII ? Here a use this plugin within a RII and didn't notice any problems. Also, when using the plug in a RII, the image input should come from OUTSIDE the RII.

gtoledo3's picture
Re: _1024_ParticleWarfare

I'm pretty sure my video feed was outside of the RII. I'll look into reproducing it.

franz's picture
Re: _1024_ParticleWarfare

hey, just tested mesh input from built-in patches.... this works great actually. I "ABSOLUTELY" must find some time to get Z back into business ( no promises, as I'm outrageously busy till... pfffff ). Good catch GT ! Check this comp.

PreviewAttachmentSize
_1024_ParticleWarfare_from Mesh.qtz25.48 KB

franz's picture
Re: _1024_ParticleWarfare

this one grows hair ....

PreviewAttachmentSize
_1024_ParticleWarfare_from Mesh_GrowHair.qtz22.62 KB

cybero's picture
Re: _1024_ParticleWarfare

Two nice examples.

Is it really important that the _1024 patch generates GF Log messages ?

Still renders, but just makes me wonder.

I find it's pretty easy to crash the first Mesh example, which seems odd, seeing as how the second example is more complex and yet seems more stable.

Just downloaded fresh versions of these files, opened them, amended and altered the second example so normals are also created, the resulting mesh is also put through a mesh filter, and that is fed to a newly added mesh normals display patch - works just fine.

However, with the first example , doing even the first step of this, feeding normals into the Mesh Creator patch results in a crash when closing and re opening the composition viewer and mousing around in the Viewer. That's without even attaching and enabling a Mesh Normals Display.

franz's picture
Re: _1024_ParticleWarfare

does mesh normals outputs a XYZ sub-structure ? I don't think so. Haven't look at mesh normals structure in details, will do so at some point.

Keep in min P.Warfare is not designed to take into account every possible combination of structures, rather a KnM GLtools compatible input. Call it "lazy design", whatever...

It surely works for vertices (Zcoord excepted, for the moment).

I'll look into the GF log messages, thxx for noticing, errrrrrrors are rather nasty.

!@$#%& bug. haha @#$%$^&*( one more.

(Having said that, it is pretty easy to get rid of it: I'll have to remove the "log on errors" part in the code. Not so elegant tho'). thanx for the feedback anyway

gtoledo3's picture
Re: _1024_ParticleWarfare

Haven't had a chance to look at the recent mesh posts (just now booted into SL)...

Mesh Vertices can, and will put out a 4 dimension structure that is the three x,y,z coords that we expect, and then in the 4th dimension, a straight row of 1's. GL Tools copes with this fine now, though it did not initially. I'm attaching a picture.

I'm not entirely sure that mesh normals would be useful, but I think if one works then the other would. The vertices is totally enough to do tons of useful effects.

I'll be interested to see if the mesh examples you have contain a z-coord, the "4th dimension" coord, or what. When I tried it with a "get mesh vertices", for some reason the entire particle system stopped rendering.

I understand you aren't trying to cover every base/type of structure. It's been handy, to me, to be able to get vertices from models, and "do stuff" at those placements whether it's with GL Tools or with iteration, so when I saw the plugin, it seemed logical.

Also, with OpenCL, you can do something like draw/create mesh in real time, then "push it around" using the deformers, and use feedback loops to "sculpt" what you just created. Being able to take the structure from something like that and pipe it to the _1024_ParticleWarfare via get mesh vertices would make for some very new effects.

gtoledo3's picture
Re: _1024_ParticleWarfare

If the mesh creator is involved, it is very likely that instability is a result of this patch, as it definitely does not work correctly, especially it's processing of normals (I have some pics somewhere that reveal it to be pretty abysmal in that).

It's more stable to use set mesh patches to reconfigure a mesh, though you do have to have an original mesh available to "set" to. This is possible in many instances.

From a composition standpoint, it seems like there isn't really a reason for mesh to be involved at all in the "grow hair" qtz, and it is likely inefficient when the structure is obtainable directly from the javascript out that makes the "line thickness" and color table stuff.

I see the fact that it does prove that it can take a 2D struct, but that's kind of already proven (to me at least). It does show that the plugin can ignore the pesky parts of the mesh struct that aren't in "quotes". (The row of 1's I was talking about... these qtz's generate a similar val, but all 0's, and the particle system ignores it without flaking out).

gtoledo3's picture
Re: _1024_ParticleWarfare

Whatever happened w/ the boid plugin?

gtoledo3's picture
Re: _1024_ParticleWarfare

Ok, here's what causes the "RII" problem.

Check the attachment - totally white screen.

What I should see is a "alpha black" background with white particles. However, you see a totally white screen.

If you pop the Billboard in "Over" you should see the particles and a checkerboard background.

However, what one has to do to get a kind of "correct" render is to actually put a clear at the root level, under the Billboard. That's not horrible, but I think it's revealing something "wrong".

When I take and put THAT billboard and clear in another RII, is when I was getting the subtle flicker I was describing (haven't tried reproducing that yet).

cybero's picture
Re: _1024_ParticleWarfare

Quote:

What I should see is a "alpha black" background with white particles. However, you see a totally white screen.

:-)

No I don't get that at all. No such RII related blank screen output here. See attached pictures for what happens here [iMac 9400 nVidia]

Firstly straight out of the box - Billboard set to Replace

Then Billboard set to Alpha and PW Emitter set to Add and Red

Finally an attempt to see what I get on my bit of kit when running no Clear patch with the initial Billboard placed into an RII, it gets close, but I think it gives a pretty nice effect, so I might make hay whilst the sun shines, even if it is a 'side effect' rather than a designed effect of the plugin.

PreviewAttachmentSize
AlphaRII_PW.png
AlphaRII_PW.png67.75 KB
ReplaceRII_PW.png
ReplaceRII_PW.png57.04 KB

cybero's picture
Re: _1024_ParticleWarfare

Mesh Normals is an array. It may or may not be the same count as the number of vertices, depends if vertices are sharing normals. Usually the vertex normals are the same as the number of face normals.

Calculating a set of normals from a given set of vertices positions is what I was doing.

Not always useful I suppose and there's actually different ways of working them out, consequently the method employed by the mesh creation application and , by extension, the mesh creation algorithm [kernel] is the key guideline for me as to to how to calculate [or re-calculate] normals for a given set of vertices.

gtoledo3's picture
Re: _1024_ParticleWarfare

( for the record: I'm not talking about "not having a clear in the RII". You seem to realize this, but you seem to mention turning off the clear in the RII. That shouldn't happen, and isn't part of any bug I'm describing- that's always a bad idea unless you want glitches, or unless you've enabled feedback rendering.)

What's really weird is that now, on re-open it works. I get the same result you are getting onscreen... ones that are expected.

However, when making the composition, the white screen happens, and continues to happen through run/stop, etc. QC goes into some kind of "not sane state".

This screen recording should note what's happening. I AM using the transmutate macro function in the screen cap. However, I just tried replicating this without using transmutate, and it still happens.

After placing the stuff in an RII, the second I put the Billboard on the Editor without a clear being there, everything turns white. This happens with no other plugin - though it is superficially similar to some problems that happen with the old Yellowtail plugin when run in SL.

Stopping QC and reopening the comp, it works like I would expect!

PreviewAttachmentSize
Screen Recording-desktop.m4v.zip4.98 MB

cybero's picture
Re: _1024_ParticleWarfare

A picture speaks a thousand words :-).

I have seen that sort of thing happen with other types of compositions.

I find also that exploding and transmuting can hiccup from time to time.

Interesting, but all the more believable that it is a difficult to reproduce effect that disappears with the next opening of the file.

cybero's picture
Re: _1024_ParticleWarfare

Having pondered this on and off for a while, it occured to me that the reason your simpler mesh & Particle Warfare comp crashed for me might even have been down to some layer ordering & related issue.

Nope , just looked again and the Vertices Display is higher than the _1024 patch and works AOK, even if I switch the Normals Display off, it's presence causes the composition to crash .

However, if I create a fresh Mesh Normals Display version of your first example, save, close and start a fresh QC session, then the file opens up well enough and does do Mesh Normals Display .

If I then stop that Viewer and restart it, a crash ensues.

Yet the more complex version you posted is far more stable.

Puzzling

:-)

PreviewAttachmentSize
_1024_MeshNormalsDisplay.png
_1024_MeshNormalsDisplay.png81.14 KB

gtoledo3's picture
Re: _1024_ParticleWarfare

It's definitely not transmutate, or k-core. I replicated this with stock methods, k-core and other stuff uninstalled, I was just unmotivated to do another screen cap. So, it's a "gonna have to take my word for it" ;)

Instead of doing the create macro/transmutate, I created an RII, then copied the clear and particle system, pasted, published appropriate inputs, deleted the orig clear and particle system, and then when I create a Billboard, stuff turns white, just like it did in the clip I attached. When I connect it to the RII, things are still white. Then, I place a clear, re-order layer so it's under the billboard, and stuff looks "ok".

gtoledo3's picture
Re: _1024_ParticleWarfare

...but in his comp, nothing is feeding normals, so there are no normals to display. It shouldn't really crash, but it kind of makes sense. It may not be a problem with the particle system.

cybero's picture
Re: _1024_ParticleWarfare

Yeah, you're right about that example composition. I know there are no specific normals calculated and thus fed into the Mesh Creator that provides the x,y structure from the Get Mesh Vertices patch.

However, the same is also true of the second composition example, yet it runs with Mesh Normals display using Normals from either accepting the Vertices as Normals [ rough and ready but no too far out], using a Grid Normals Generator, or script or kernel calculating the Normals.

See attached example, works fine for me and this is , I believe, due to the emitters being triggered on and off, rather than being emitted permanently.

Just Normals that provokes this problem, but this attached example shows how Normals can be displayed using the Mesh Normals Display patch.

Uses Audio Tools, bring you're own audio file, press the mouse on and off frequently and have some fun :-).

I like the various 'minimalist' stuff that it renders.

cybero's picture
Re: _1024_ParticleWarfare

It does seem a pity that one can't Set Mesh from a dynamic mesh.

franz's picture
Re: _1024_ParticleWarfare

Just added Z support in the 1.1 release. Download from 1024 blog

gtoledo3's picture
Re: _1024_ParticleWarfare

Thanks for sharing!

gtoledo3's picture
Re: _1024_ParticleWarfare

I love this plugin.

It's so great, because it's unapologetically aimed at art. (I'm at loss to think of utilitarian uses of particles.)

I'm so happy you took the time to add in the Z, thanks for doing that, franz.

dust's picture
Re: _1024_ParticleWarfare

yeah z depth awesome, your going to have all the other particle designers waving white flags on the battle field with this one.

franz's picture
Re: _1024_ParticleWarfare

@gt: actually, you pointed me that one could possibly plug a Mesh Vertices structure.... thanks for that !

Next step will be a "go to vertices" behaviour, for emitting AND attracting parts. with a 3d model... And eventually colliders, if I'm strong enough to cope with the maths (which is very unlikely).

BTW, any snapshots or vimeos of Warfare in action through meshes will be truly welcome.

jersmi's picture
Re: _1024_ParticleWarfare

Just checking -- setting external timebase does not work with the Particle Warfare plugin?

franz's picture
Re: _1024_ParticleWarfare

no, it is not time based

jersmi's picture
Re: _1024_ParticleWarfare

okay, thanks.