TGEA Particles versus TGE Particles

#1 I've pinged the big boys on this, hopefully they will get a chance to comment tomorrow :)

#2 I think the particle system really needs a rewrite to be honest. There have been a bunch of flaws in it even within the TGE system. If we are looking at where best to move, I'd suggest looking at what is possible, rather than just what exists.

#3 I generally agree with Phil, but even an awesome new particle system would not eliminate the benefit of reproducing legacy TGE particles in TGEA. I think the opportunity to reuse existing assets is of enormous value to indie developers. The best solutions are those that offer new capabilities while not breaking the old ones wherever possible. That way we can look at what is possible AND what exists. The current TGEA particle system does neither. It makes incremental improvements to the prettiness of the particle system's code structure while incrementally discarding functionality.

BTW, if anyone knows of a great particle system which could potentially be portable across the Torque supported operating systems and the relevant Torque engines, please bring it to my attention. I would gladly consider incorporating such a thing into future versions of AFX.

#4 Damn Stephen, if you're not one of the big boys, then I'm a gnat!!!

I'll throw in my 2 cents...I think that a completely new, fully shaderized, cache efficient, particle system, while not backwards compatible, could potentially be another major selling point for TGEA.

In my opinion, one of the biggest differentiators in the look of "next gen" games are the particle effects. So, I'd love to see TGEA benefit from everything the community has learned from TGE and build upon it.

Have a great weekend everyone.
Todd


edited for silly spelling

#5 Jeff, I fully agree with you. I just wonder how much work it would be to "revert" the TSEA particles to the TGE particles.

Actually, funnily enough, I wouldnt mind having TGE particles back. Because Adam's done us some great things for particle effects and some of the TSEA ones are broken.

I dont know whats changed weirdly.. dont have time to look.

#6 Actually i figure that some lessons learned from TGB will eventually make it into the TSE particle system. At least the editor tools.

#7 We've got two terrain systems. I could live with "legacy particles" for compatibilty and "advanced particles" for nifty.

#8 @ Phil -- I haven't studied every corner of the TGEA particle system, but it appears to me that the only material difference is that it only allows the particle emitters to point to a single particle definition, and it also appears to ignore all but the first frame in particles with animated textures. The only rational reason for introducing these limitations that I can think of is that the rendering is much more cache efficient with only one texture in the mix. I think it would be relatively simple to detect the ideal cases and use optimized rendering, but fallback to an alternative when multiple particle emitters or animated textures are used.

@ Rob -- I agree... two particle system choices sounds pretty reasonable to me. Unfortunately, although it's not too difficult to code up some basic particle system, it's deceptively difficult to create one that is well-rounded and efficient. I'm not sure if there's a "fully shaderized, cache efficient" (as William put it) particle system out there waiting to be cherry picked and dropped into TGEA. We can always hope though.

#9 I'm no expert on this but... would it be possible to merge this API to Torque?

http://www.particlesystems.org

Also, I don't know if you are planning support for point sprite or shader controlled particle systems in the TGEA. This presents a more powerful way to control particle systems. Maybe you may keep two particle systems. One completely compatible with the previous version and other with point sprites.

Luck!
Guimo

#10 @Guimo

It's LGPL so there'd be a lot of tip-toeing around to implement it.

#11 Right, the particle system has changed to move to a much more efficient way of rendering the particles. It uses one texture and draws all of the particles in one draw call. The TGE support of the multiple textures per emitter is just really really inefficient for D3D - you can sort of get away with it on OpenGL because it's more optimized for small batches. But still, sending a draw call to the card per-particle is just ridiculous.

The proper way to do it would be to have multiple particles per texture and then have the particle system and/or a shader offset the UV's properly to match the desired particle. Same thing with animated particles - all of the animation frames should reside in a single texture and then have the UV's offset appropriately.

Since we don't have the time to implement all this (yet anyway), we just went with the "render one texture really fast" method. TGB shows that there is a lot of room for improvement in terms of supporting lots of effects and editor features for emitters, so yeah, I agree it could be a lot better.

#12

Quote:The proper way to do it would be to have multiple particles per texture and then have the particle system and/or a shader offset the UV's properly to match the desired particle. Same thing with animated particles - all of the animation frames should reside in a single texture and then have the UV's offset appropriately.

Although this would break legacy particles, and presumably would require a common blending function across particles, it does offer a reasonable workaround for adapting and maintaining a consistent look for legacy multi-particle emitters. Is it likely that this functionality would be added in the future? or is it more of an outline for how someone could customize the TGEA particle system?

#13 It's something that we'd like to do, but it's not on a schedule and probably isn't something that we're likely to get to in the next few months. So I'd consider it more of an outline. It's certainly possible, I think, to go with this method and set it up to use multiple datablocks in order to create something that remains more compatible between the two engines.

There are much bigger issues that we'd like to tackle than this though. We would like to have things like better Material management, some kind of Material Editor, OpenGL support, fixed function support, a much better art pipeline, etc, etc.

#14 One more question... with the single texture approach and the improved render batching, are particles from *different* emitters still sorted according to emitter bounding-box, or is it possible to get per-particle sorting. If it were possible to get per-particle sorting for particles from different emitters, we can probably workaround the single texture requirement using layered emitters and some kind of particle frequency control.

#15 If you are rendering from a single texture, may I assume you are using point sprites?
Is so, would it be possible to process the points in the buffer using a vertex shader so I can define the behaviour of the system in the transforms? That way I would be able to define my own particle animations for the particles without any modification in the engine code.

Luck!
Guimo

#16 @Jeff - unfortunately, there is no per-particle sorting across emitters, so you can't work around it.

@Guimo - it is not using point sprites or shaders to render the particles, although I think this would be relatively easy to implement.

#17 Put it on post launch roadmap. Would like to see DX10 hw geometry effects too... yea I am still chasing that magic Jaw dropping waterfall...

OMG have you seen the DX10 waterfall demo at Nvidia?

#18 /drooooooooool