Particle Universe: Need some feedback

[spookyboo]

As most people know, I´m developing the Particle Universe plugin/editor. Version 1.3 is going fine and I am already thinking about version 1.4
I´m thankful for the reported bugs and requests (the latest input from Jabberwocky was very useful). The problem is, that I need more input so I can focus more on features that people want to use, than features which I think are important. The most recurring features are a material editor (which imo should not be part of a particle editor, but maybe I will add some basic functions) and support for Unity (which is a lot of work, because PU heavily relies on Ogre). Nonetheless, I need some more input to give a useful direction to the upcoming versions. I'm all ears...

[wacom]

Not a real problem perhaps, but for my project I found the editor nearly unusable, as I use 1 unit = 1 meter. I think your editor and all your samples use 1 unit = 1 centimeter. Which is a problem alone with zooming to see my particles.

[Wolfmanfx]

What i like on PU is that is a Ogre plugin (i mean it would be really painful for you to support two different engines or you go one step back and do the particle stuff for openGL/dx/openGLES but imho stick with us )
You could build a infrastructure for tools like utility classes/functions which ease the development of an particle editor.

[spookyboo]

I think your editor and all your samples use 1 unit = 1 centimeter

It uses (Ogre) units, no real meter/centimeters. The samples are large (50 units), but they are what they are, examples. In version 1.3 zooming is adjusted again. If you set it to 200%, the distance between particle system and camera is 1 unit. If you set it to 0%, the distance is 2200 units.

[Jabberwocky]

Woo, a call for suggestions! My favorite!

Unity
Support for Unity would be a complete rewrite, and would heavily distract from PU's Ogre3D development. I'm against it, although partially for selfish reasons I guess. Besides, you never know when the Unity engine might come out with it's own particle editor.
_______________________

Suggestion: More Media Packs
While ParticleUniverse does come with some excellent samples, this could be expanded.

If possible, team up with an artist and develop some enhanced media packs like:
- Magic media pack
- Sci-fi media pack
- War Game media pack
- Weather media pack

Sell them separately for a bit of money, or charge only for a commercial license.
_______________________

Suggestion: Animated Mesh Import and Particle Attachment
It would be great to open up particle universe, import an animated character, and attach particles to character bones at a certain stage in the animation.

Example Functionality:
- load up a magic-user character (magic-user.mesh, animated)
- create a particle system called "glowing hands"
- attach the "glowing hands" particle system to the hand-bones of the character
- specify "glowing hands" to start 1 second into the "cast_spell" animation
- specify "glowing hands" to stop upon completion of the "cast_spell" animation
- hit the play button, and watch the magic-user character play the "cast_spell" animation with the "glowing hands" particles attached to his hands, as he waves them around to cast the spell.
- for bonus points: be able to activate a "fireball" ParticleSystem once the spell is cast, and have it shoot off into the distance. (This is a little more complicated, so maybe save this for later).

Exported Data Format
The ParticleUniverse plugin should not handle the runtime game logic for attaching particles to bones at certain points of an animation. Instead, it should export a separate xml file, something like this:

Code: Select all

<animation_particles>
   <mesh>magic-user.mesh</mesh>

   <animation>
      <name>cast_spell</name>

      <attached_particle_system>
         <particle_template>glowing hands</particle_template>
         <bone>bone_left_hand</bone>
         <time_start>1</time_start>
         <stop_at_animation_end>true</stop_at_animation_end>
      </attached_particle_system>

      <attached_particle_system>
         <particle_template>glowing hands</particle_template>
         <bone>bone_right_hand</bone>
         <time_start>1</time_start>
         <stop_at_animation_end>true</stop_at_animation_end>
      </attached_particle_system>
   </animation>

   <animation>
      <name>die</name>

      <attached_particle_system>
         <particle_template>blood spatter</particle_template>
         <bone>bone_chest</bone>
         <time_start>1.2</time_start>
      </attached_particle_system>

      <attached_particle_system>
         <particle_template>blood spatter</particle_template>
         <bone>bone_pelvis</bone>
         <time_start>1.7</time_start>
      </attached_particle_system>

      <attached_particle_system>
         <particle_template>blood spatter</particle_template>
         <bone>bone_head</bone>
         <time_start>2.3</time_start>
      </attached_particle_system>
   </animation>
   
</animation_particles>

(This data format could be fleshed out, but that's a good start.)

Stand Alone Viewer Program
Then, provide a sample stand-alone viewer program that loads this xml file, and plays the animations with the particles. Make this Ogre viewer as simple as possible, so that someone can use this code to incorporate particle-bone attachment easily in their own game.

Editor Requirements
The editor would need:
- a new tab called "animation" or "mesh"
- an ability to load and display animated meshes in this new tab (there may be some open-source Ogre3D mesh viewers you can borrow code from if you don't want to write this yourself, although it shouldn't be hard.)
- a drop-down list of all animations for the loaded mesh
- the ability to select an animation and play it
- some kind of simple interface allowing the user to specify a bone, a particle system template, and a time.

This is External Code and Data!!! (not in .pu scripts or implemented in ParticleUniverse.dll
I want to emphasize that all of this new data should NOT go into the particle script at all, because then you would be assuming way too much about how a project arranges their character and animation data. I can explain this further, or just trust me, it would be bad.

Instead, this is extra functionality of attaching particles to bones during an animation is built on top of the ParticleUniverse plugins and scripts. The user has to integrate it himself based on the sample viewer application. (This is very similar to how OgreMax provides a sample .scene viewer - but leaves the actual integration up to the user.)

Why this is Good
The huge advantage of this is so an artist can add one of their characters into the editor, and start playing around with attached particles. In many games, a majority of the particles are attached to characters like this in some manner. This would really improve the work flow. Right now, in my game, I have to make a ParticleSystem in the Particle Universe Editor, export it, add the data to my game, run my game, load the character, then see how it looks. Every iteration I have to redo all these steps, and it is very slow. Being able to do it all within ParticleUniverse Editor would be way, way better.

[Jabberwocky]

It would also be useful to load up non-animated meshes, so you could test things like:
- adding flames to a torch
- adding engine particles to a space-ship

So maybe you could have the option to either attach the particles to a bone, or a Vector3 offset from the mesh center.

[Zero]

I would prefer an abstract physic layer, so that other physic libraries can more easily be used.
The actual implementation with physix is good, but implement there Newton for example is very hard

[xavier]

but maybe I will add some basic functions) and support for Unity (which is a lot of work, because PU heavily relies on Ogre).

You really should consider this closely. There are very few options for particle system middleware on the market -- Fork is the only one that leaps to mind.

I would strongly recommend completely divorcing the particle system from any dependence on any rendering, animation or game engine. It's like any physics engine, for instance -- they are not dependent on any other product. Particle systems should be the same way.

Ogre was a good way to get this developed quickly, and it was a good solid base you could depend on. Now you've got a good thing going here, and it even has tools -- my suggestion is take the next step.

[Jabberwocky]

Xavier's a pretty smart guy, so maybe I should retract my earlier (selfish!) advice not to port to unity. It would increase your potential customer base a huge amount.

Although if you do decide on a Unity port, I would try to contact them to make sure there aren't other particle solutions in the works that might be bundled and shipped with Unity, making the effort far less worthwhile.

[xavier]

Xavier's a pretty smart guy, so maybe I should retract my earlier (selfish!) advice not to port to unity. It would increase your potential customer base a huge amount.

I was actually recommending it not be "ported" to anything else, and that it be redone now *not* to depend on anything else. Although at this point a "port" to anything other than Ogre would probably involve creating that necessary abstraction layer anyway, so...

Really all a particle engine needs is something to render textured quads; it's a lot like CEGUI in that regard -- it just needs some form of quad provider. That's a straightforward abstraction.

When an engine such as Scaleform or Fork (or any middleware) integrates with a larger game engine, they do it by creating an adapter layer between their abstraction and the engine's abstraction. If you need GPU acceleration, then you would also abstract the shader framework as well (and don't think of it in terms of just D3D or OpenGL -- you need to consider as well 360, PS3 and Wii, which are all different from one another and from the PC APIs as well...for example, the Wii is not programmable).

Obviously Ogre support wouldn't disappear -- it would just have an additional abstraction between it and PU.

A note on Unity3D -- it would require source access, which is something that Unity is not real keen on. Integrating with a Gamebryo or Unreal is simpler because those are source-based engines, and are already set up for this sort of middleware integration.

Doing this "right" is not a trivial task -- mistakes will be made along the way and that's fine. But IMO, the game dev community (especially indie) really desperately needs an additional particle middleware alternative.

[spookyboo]

My idea is in fact to slowly abstract particle universe, but step by step. Its not only the rendering of quads, but also script parsing and some other things that I borrow from Ogre.

[xavier]

My idea is in fact to slowly abstract particle universe, but step by step.

Excellent

[roimatola]

It would be really cool (maybe there is already one) to have a wrap to use with Mogre!!

[KungFooMasta]

I agree with Jabberwocky and Xavier, the library would be most useful if it provided a lot of hooks, so people using various libs can tap into PU and integrate it with their system. I saw in the other thread it looks like you have a lot of notifications that are useful, this is going in the right direction IMO.

Even the rendering should be abstracted IMO. In my engine everything is plugin based, even the rendering system which uses Ogre. If I were to integrate PU, which uses Ogre directly, I would have to lump that in with my Ogre RenderSystem plugin to work correctly. (This might not be bad, although it enforces a particular design) The alternative would be to include PU as its own plugin, and have it use the RenderSystem plugin, regardless of the library that does the rendering. Same concept for PU using sound.

I've recently started writing a new version of QuickGUI that is decoupled from Ogre, by abstracting the Rendering, similar to CEGUI. Basically you create some abstract classes that users must write and provide to PU, so that PU can be rendered.

Here is my current setup, largely in the works:

abstract Scene class - createRenderTexture, createOverlay, createUIPanel
abstract RenderTexture class - drawImage, drawTiledImage, drawLine
abstract Overlay class - setZOrder, setPosition, setSize, setVisible, setRenderTexture
abstract UIPanel class - setPosition, setSize, setVisible, setRenderTexture

In order to use QuickGUI, the user will have to write an implementation of the Scene, RenderTexture, Overlay, and UIPanel class, and pass the Scene instance to QuickGUI. QuickGUI can then use the Scene instance to draw UI and display it. (just fyi an Overlay is 2d, and UIPanel is in 3d space.. basically a ManualObject ) The main takeaway is that the library doesn't need to know how the rendering is done, it just expects it to work and uses it according to a defined interface.

Also with this approach you can always provide the Ogre-side implementation for users, just like the OgreCEGUIRenderSystem was written and made available for people. (the classes that bind CEGUI to Ogre)