new particle-projectile system in the works

NEW! treeform.p3dp.com/p/pyro4.zip
mirror aff2aw.com/affdata/panda/pyro4-1.zip

The particle projectile system works quite good as plain object drawer for many bill boards such as stars and the lines are handled by pyro

Beams and health bars are drawn by pyro:




I actually have not concentrated on getting good explosions out if it yet. I’ll post more shots of the explosions soon…

i am building a new particle system. My main concern is projectiles. So i create individual “particle like objects” and specify to and from possitions. Also it includes particle LOD ( in form of non important particles don’t happen). Also my particles can create trail of other particles or more particles at the destination. I have tried to use existing system with intervals but that is just do dam buggy (intervals gets stuck and explosions don’t explode and all those things don’t get garbage collected)

I am making an space based RTS and can have as many as 300 projectiles per frame many of which last under a second. I have efficient queues and priority system implemented.

This feature still needs to go through a lot of testing and feature upgrades before i release it.

Do you have any suggestions or requests?

Some ideas: (you asked)* Particles that are themselves emitters of particles. (it would allow branching effects).

  • Physics forces on particles. (allowing them to accelerate/change direction over time)
  • Metaball particles. (for liquid effects)
  • Flocking behavior. (following some controllable node or leader particle)
  • I’d like to be able to do things with particles that can be already be done on ordinary models with intervals. (like changing size, color, and/or opacity over time.)
  • Arbitrary boundaries. (particles become invisible, or die outside a certian bounding geometry.)
  • The ability to pause, reverse or accelerate a system.
  • The ability to pickle (or otherwise serialize) a paused system, that can be loaded and resumed later. (it maybe as simple as saving the pseudo-random seed value and time index)
  • Angular momentum, or some kind or orientation interpolation for non-spherical, or emitter particles.
  • Attractive or repulsive points. (like electric fields)
  • Something like magnetic effects on charged particles?
  • Collision detection. I don’t mean particle on particle, (that’s probably way too hard) but particle into collision solid. It would allow things like splatters sticking to surfaces, spawning new emitters at collision points (sparks or splashes), among other things.
  • Connected particles. (each new particle is a vertex in a linked-line) Would be nice for contrails.

Thanks Cyan! that is exactly what i wanted. I don’t know why i did not see your post sooner it was marked at read.
Particles that are themselves emitters of particles. (it would allow branching effects).
done! This was one of my pitfalls with the existing ones.

Physics forces on particles. (allowing them to accelerate/change direction over time)
sort of done but unoptimized, because every particle runs a python function one you can do stuff like this. I will define some standard functions to code in c++ later but you could always give an odd function for it to execute at a little slower rate.

Metaball particles. (for liquid effects)
hard! No plans for now. I think you should make a special purposed system for this.

Flocking behavior. (following some controllable node or leader particle)
this sounds neat there is not provisions for it yet but i will put this on the list, but this is the same thing as the N^2 collisions systems and magnetic effect. But since this is more of a projectile system homing behaviors to moving node paths is already implemented just not other paticles. I could also make particles that follow particles that created them …

I’d like to be able to do things with particles that can be already be done on ordinary models with intervals. (like changing size, color, and/or opacity over time.)
done!

Arbitrary boundaries. (particles become invisible, or die outside a certian bounding geometry.)
Would sphere and rectangle be enough? This could come useful. Will be implemented.

The ability to pause, reverse or accelerate a system.
Sadly this is not there yet. System is not deterministic so reverse would not be possible. Pause and resume is not brainier will be added.

The ability to pickle (or otherwise serialize) a paused system, that can be loaded and resumed later.
Because system is not deterministic this would take more then just save a number. Pickling ability is for python classes. I don’t think this feature will make it into the C++ stuff. Particles are just effects and should not be relied on as game state chaining features and such are not very useful to be saved any ways.

Angular momentum, or some kind or orientation interpolation for non-spherical, or emitter particles.
done!
Attractive or repulsive points. (like electric fields)
Sound neat but then every particle would have to compare to every other particle that is N^2 computation. This sound very expensive operation.

Something like magnetic effects on charged particles?
Same as above?

Collision detection. I don’t mean particle on particle, (that’s probably way too hard) but particle into collision solid. It would allow things like splatters sticking to surfaces, spawning new emitters at collision points (sparks or splashes), among other things.
Good idea (“I don’t mean particle on particleâ€

Happy I could be of some help.

It’s a start. It would be more useful if you could use more than one of these boundaries at the same time. That way, you could combine them into different shapes.

What about the acceleration part? Can you make the system go faster or slower?

If you seeded your pseudo-random number generator, and kept a consistent frame rate, you could make an apparently random system completely deterministic.

A paused particle system might make a nice procedurally generated model, like Legion’s planetary nebula or a galaxy, or cloud, or goo-monster, or whatever else you can think of that might be better rendered as a cloud of particles instead of a mesh of triangles.

As for game state, when you said,

I thought you meant using particles as bullets or missiles or something.

You could, of course, just have the particles be a pretty graphical effect to cover a background calculation, but the most obvious way to make projectiles work would be to have particle-on-collision solid detection. To make that consistent over a networked game you would need deterministic, serializable emitters.

That’s not exactly what I meant. I mean static additions to an emitter. The particles don’t have to interact with each other (that would be expensive).

Imagine: you have a point particle emitter, throwing particles in every direction. You add a point particle attractor some distance away. Each particle in that system experiences a force toward it, based on inverse-square distance. That could lead to some cool effects at only N more computations. Another point attractor, and thats 2N computations. Feasible. (Further you could limit the sphere of influence as an optimization.) If these charged points are made as panda nodes they could be animated with intervals for more cool effects.

Yeah, I still don’t mean particle-on-particle interactions. It would be like the charged points, but instead of applying a force towards or away from it, it would be a force perpendicular to it. That would make some nice spiral patterns.

That’s probably okay if we can limit the number of particles tested for collisions. It would be nice if an emitter could throw out a certain percentage of collision particles, while the rest are for show. It would also be nice to be able to turn on or off collision detection over time or distance like we could with color.

well then its just an optimization of the collide with geometry? The reason is that box or sphere would be faster to compute. I think keeping it simple providing only sphere or box collisions would be best because for every thing else there is custom hidden geom :slight_smile:

ok i will add that in!

yes deterministic system are possible but because of particles that follow objects, Particles that make other objects when they die, and particles that collide with geometry that might move makes constructing a deterministic systemem had, yo u would have to move the entire universe back too, the guns that fired the missiles and the ships that followed them which are not part of the system. For things like falling snow this is feasible unless the snow falls on a moving tank … for his reasons my system is not deterministic and cant be made out of a seed of a pseudo-random number generator.

yes true that is why i would include, start, pause, stop (soft stop & remove), remove and set/get speed.

yes that is exactly what i mean + explosions and stuff. I am not focusing on stuff like rain,snow,smoke,fire but it would be still possible using my system.

this is what i was aiming for. I have hundreds of space ships and they fire and explode a lot. With the particle lodding i have to remove less important particles or particles farther a way. Hopefully i could make the system fast enough to make this almost irreverent but it will still bethere. So now we know that some particles will not ‘fire’ if far a way or too much stuff going on already we cant rely on the particle to do collisions for us or change the game state specularity over network with different machines running different lods.

[quote]
“charged pointsâ€

only a screen shot,

how would one distribute c++/python libraries for general panda audience? Pgmm is a good example. If we get more and more of this kind of thing what would be the best way to package it transport it across platforms?

Instead of just packing this up in a zip file and sticking it on a server somewhere, you should talk with the others about how to distribute this sort of stuff.

I imagine some central point of distribution that lists dozens of panda-related utilities. It has each utility in a convenient-to-download form, with all of them standardized so that they all install the same way. I imagine some sort of version numbering system that tell you, for each utility, how long it’s been since it was maintained, and which versions of panda it has been tested with.



zip with c++ and python code, use scons to compile for you system, contains build with gcc for ubuntu.
istrolid.com/p/panda3d/pyro1.zip

release #3: istrolid.com/p/panda3d/pyro/pyro3.zip

Pyro is a particle/projectile system. Basically its a mixed C++/Python library used to create dynamic effects such as projectiles, trails, particles, radar and even line drawing. At its core pyro is NodePath with various draw commands. Its has some optimizations and genially runs faster then other methods that procedurally generate geometry.

One other core concept is the plate. Plate is an image composed of many different frames look at the 2 plates provided in the /data section. The idea of plate comes from necessity of sending only one geometric object per Pyro particle system. The included tool createplate.py that help plate creation is included.

The radar_test.py has the complete example of how to use this low level component.

# simply create
generator = Pyro("Generator")
generator.reparentTo(render)
# in your loop or any place else
  generator.begin(base.cam,render)
  ...
  generator.tri( v1, c1, uv1, v2, c2, uv2, v3, c3, uv3);
  generator.particle(pos, frame,  size, color, rotation);
  generator.billboard(pos, frame,  size, color);
  generator.segment(start, stop,  frame, size, color);
  generator.explosion(pos, frame,  size, color, seed, number, distance);
  generator.stream( start, stop,  frame, size, color, number, offset);
  ...
  generator.end()

There is are some commands and many more will be added.

But there is a higher level python library written on top of this interface that allows much better particle management. Each particle is a full python class with specific methods and attributes. It is beneficial to look at the explosions.py to see all the many different ways particle can be scripted creating many many effect. One pyro particle roughly corresponds to a c++ call on the Pyro generator class so with a particle of type “explosion” one can draw 100’s of particle in that spherical propagate form one center point.

The pyro_test.py has the example of using this higher level system.

tg = Pyro(loader.loadTexture("data/plate2.png"),16,pyro_animations,10000)

The pyro_animations is the dictionary of particle animation name to start, number of frames, and end tuple. It can be coded by hand but its much easier to generate it with createplate.py. pyro_animations look some thing like this

pyro_animations = {
 'beam-blue-A-': (238, 3, 241),
 'beam-red-A-': (241, 3, 244),
 'bigsploA': (128, 8, 136),
 'bigsploB': (136, 8, 144)}

The particle definition has many components:

class SmallExplosion(Particle):
    duration = 10.
    type = "particle"
    def restart(self,center,size=.5):
        self.pos = Vec3(center)
        self.size = size
        self.animate(choice(["explo1-","explo2-","explo3-","explo4-"]))
        self.rotation = random()*360
        
    def do(self,dt):
        """ alter the particle """
        self.size += (self.time*dt)**2*.2
        self.spread = 2*(self.time/self.duration*10)**.5
        self.frame = self.startFrame + (self.numFrames)*self.time/self.duration

The restart is the init of the particle. ParticleManager caches all the created particle instances so that less object allocations will be needed, but it just have to restart used particles. To create a new particle one just has to call new on your particle manager.

tg.new(Chunk,Vec3(0,0,0))

I will be adding more functionality such as use of the excising particle emitters, use of nerb’s curves for motion trails, better documentation and an all around easier way to use it.

Cool, thanks Treeform, I’m certainly interested in this for the battle simulation portion of my game. I’ll have to try this out.

C

the test doesn’t work on my 1.4.2, do i need some configure?

weihuan you need to compile it. I will not support 1.4.2 any more ill post a windows 1.5.0 dll shortly. On linux its easy to build.

treeform, have you messed around with the software called particle illusion?
it is pretty interesting for doing effects in a 3d texture without having to actually render the particles themselves.

actually, that question is for anyone who may have used it.

No i have not particle illusion. It appears to be windows only but I should try out the trail version. But i think my particle system has a little bit different aim basically now just a way to draw stuff using python in 3d fast with a little particle system thrown in, but i might just drop the little particle wrapper and try go get the drawer documented and pushed into the panda3d build.

Thanks treeform, i’ll update to 1.5.0 to see that.

new version compiled for panda 153

treeform.p3dp.com/p/pyro4.zip

The link for your previous version doesn’t seem to work - I get a Python error when I try to access it, which terminates with “TemplateDoesNotExist: 404.html”.

However, will the latest version work with 1.5.2? (I’d prefer to not download 1.5.3, just yet, at least, unless there are bugs in 1.5.2 that could seriously interfere with development, and which don’t have other solutions.)

If not, is the previous version still available somewhere?

This looks as though it might be pretty good, and, having gathered that there are some issues in the official particle system, I’m interested in trying it out.

[edit]
P.S. Where does your avatar come from, if I may ask?

I don’t recommend using PYROv3 (it had possible memory leaks). You can always compile it your self. If you are on linux it works for any version. You can try using v4 with panda 1.5.2 worse case it would seg fault.

I recommend using 1.5.3 from pro-rsoft though it has lots of bugs fixed.

Hmm… I’ll consider it downloading 1.5.3, but I want to be very careful with my data transfer cap this month. It’s a small enough percentage, but these things add up…

Is there a list of bugs fixed? It might help me to decide on whether to wait for next month to download 1.5.3.

I’ve downloaded the Pyro 1.4 package, although I don’t know when I’ll get around to looking at it (later today (in my time), hopefully).