SPARK

#1 Perhaps you should consider keeping all of this in one thread called "Particle Improvements" or something, rather than making a new thread for every thing you find on google.

Before we even start into a discussion on whether or not SPARK is a good fit, could you explain what you're looking for in a particle system?

You just keep saying "We need a better particle engine" without listing any shortcomings or downfalls in the current one. I'm not saying it's perfect, but what exactly is it you're after? You might find a solution without having to tear everything apart and rebuild it.

#2 The shortcomings of T3D's particle system:
Extensibility and customizability.
Thats what I tried to solve with the IPS Pro, and there have been a decent market for such a product, so I guess thats one of the issues.

Shaders
The lack of shaders is a huge shortcoming. (But relatively easy to add)

Subjective shortcomings of T3D's particle system:

GPU acceleration
Most next-gen games will want GPU-accelerated particles in their games, so they can have 1000's of particles on the screen. However a lot of games wont need this.

Physics implementation
This is also subjective, but some games might want particles to be affected by turbulence and collision, and other physics.
This is what PhysX etc solves.

Shortcomings of T3D's editors related to particles:
Extensibility etc, it was not written for more than one type of particle system.. Trust me I have worked with it.

Sleekness / artist-friendliness.
A lot of artists complain about the particle editor tools, but then again artists seems to complain about everything with the T3D editors (looking at you Tim Watton ;) )

#3 Sorry all, I guess that was a little uncalled for Andrew. My deepest apologies.

For certain games, particles are needed everywhere. GPU acceleration is not needed, but could be implemented if anyone wanted to spend time on it. Physics implementation would make things way more releastic and should at least be a option for all game developers. Shaders are intensly needed, for me I really can't tell a good shader, but I can tell when it needs shaders. PhysX and Bullet can both take care of physics. Since I will be impementing Bullet 3 (beta is out), I will try to mess around and add turbulence or something.

There are a few things that are needed that Lukas listed, but this should give the "PhysX particle feel" without being intense on the CPU. The reason why I stay away from PhysX is because the CPU programing is... not the best and you need CUDA and no OpenCL support.

Anyways all, that is what I mean. If you look at Unreal's particle editor, it is finished and... looks good! Not to mention they have a nice addition of PhysX Particles. I'm looking to upgrade Torque3D to a fully GPU accelerated engine, making everything work faster then ever.

#4 We could split it into two systems. ParticleRenderer and something that drives the renderer by feeding it positions, counts, etc. That way that piece could be optimized separately, and shader support could added. Then we turn the part that feeds the renderer into a plugin type system similar to how physics works now allowing bullet, physx, ips, spark, etc. to drive it.

Thoughts?

#5 Thats pretty much what I did for the PhysX Particles. Works like a charm.. When it works :P

#6 Yeah, I figured as much that's why I pushed for that direction haha I knew it was already well on it's way.

#7 Just thought I would link Mercury Particle Engine.

http://matthew-davey.github.io/mercury-particle-engine/

#8 Ok, so spliting it to two sydtems would work. Adding physics again would work. I've been looking at the source code and trying out some demos. I might actually start working on this system. If anyone wants to help that would be great.

#9 @Benjamin see this thread about the Mercury Particle Engine.

@raa I know the particle system like the inside of my pocket! Just send me an email if you come in trouble.
The PhysX particlesystem I'm working on is a pretty raw implementation of that system, it might be an idea to wait untill that gets out.
I just have to get well again so I can stare at a computer for more than 7 minutes a time lol.

#10 @Lukas Great stuff, looks like we might actually get this particle system implemented.

@Benjamin the Mercury Particle Engine turns out to be 2D. Therefore we cannot use it in Torque3D.

I will start looking more into the code and into Torque3D's code to see the resemblance between the two. I was trying to run some demos earlier but for some reason my Visual Studio can never find the headers I need... sigh.

#11 @raa when you start digging into SPARK you should attempt to change it into a system similar to what I did with the PhysX 3.3 particles:

github.com/rextimmy/Torque3D/blob/development/Engine/source/T3D/physics/physx3/P...

Except in our case PhysX doesn't have any emitters at all. So we're using torque's stock emitter to feed the system data about the amount of particles ( using addParticles() ), their initial positions and velocity and then it takes the simulation from there. The data is read back out using readParticles() which returns a vector of positions that the particle renderer then draws. So, if you adapt SPARK into a readParticles() type functionality it won't be hard to slip it in place of PhysX when Lukas is finished.

I downloaded the SPARK SDK and looked through it. It has a series of emitters so you may have even less work on your hands since you could just tell it what kind of emitter and how many particles and it could act as a sort of self contained particle system ( a wonderfully multithreaded and optimized one at that ) other than the rendering.

#12 Okay, so we got some good stuff. What your doing with PhysX is great for all the PhysX users. I should look into how to incorporate the emitters into the engine. Any ideas would always help.