Particle editor

Hi

At first look, spark looks awesome. I have a question about particle editor. Are you planning to release one? I think it might boost development of community projects, and SPARK itself. Maybe you are using some particle editor internally?

Regards,
Slovian

Hi and welcome Slovian,

yes i am fully aware SPARK lacks a particle editor. At the moment, it is only possible to set up a particle system directly within the code. A particle editor would indeed be very useful.

I am not using one internally, I only configure all the demos systems within the code.

The thing is a particle editor is a huge work, not necessarily tough but long to develop (maybe as long as designing the library itself).

So I cant tell whether or not I will provide one. I am thinking about it. Maybe I will develop one slowly in parallel and post the evolution on the board. It is indeed something that has to be done.

Thanks for your suggestion.

After having thought about a particle editor, it would be a great feature to SPARK that could boost the community, you are right.
However it is not that simple to develop as rendering modules are independant. So several version of the editor must exist. It is still possible though.

I will start working on it once I finish the release to come (which is quite huge as well). I will post the evolution of the editor on the forum.

First thing I have to find is a quite light cross plateform and cross API (opengl and directX) GUI library. If you have any suggestions...

Juff wrote:

I will start working on it once I finish the release to come (which is quite huge as well). I will post the evolution of the editor on the forum.
First thing I have to find is a quite light cross plateform and cross API (opengl and directX) GUI library. If you have any suggestions...

It would be great. I'll propably use SPARK in small game I'm just starting. After looking into demo samples and some source code I'm really impressed by the library. Design looks simple, flexible and very easy to extend. I was even thinking if I could try to do editor by myself using wxWidgets, but I want to make my current project as simple as possible and don't want to go into sophisticated systems implementation. And doing the editor will also require some flexible serialization system implementation on your library.

Particle editor might be external tool. If you would like me to suggest some GUI - I think that you should try cross platform windowed GUI framework like wxWidgets or QT. You could then render edited particles independently in application subwindow.

It might be easy to support all rendering modules while you keep them using same interface, and if you could just switch rendering system with compilation settings. Also I think that supporting multiple rendering modules is not nessesary. As external tool that user can use "out of the box" to create particle emitter for his game, he really don't care much about rendering system it uses (however there might be some difference between them). If user extends or customize SPARK you should let him customize editor - either by releasing source code or giving some interface to use spark functionalities of his own (customized zones, affectors and so on) - in this case editor would propably have to use SPARK as external dynamically loaded library.

Thanks,

The thing is that there is no base class that defines a common user interface for types of renderers. I didnt do it so that rendering modules can be implemented in any way and fit perfectly with the engine it interfaces with (by using for instance engine enums for blending, engine texture format...). So the user is really free in the way he implements new renderers but the drawback is that there is no common interface. SPARK was really designed in order to offer robust, fast and flexible particle system to be interfaced with any engine whether it be 2D or 3D.

I agree with you, the editor must be easily extendable to be able to add new rendering modules and/or new modifiers, zones... The biggest challenge will be to build an editor that can be extended easily and where particles can be rendered using any engine. Moreover the file format and the loader on the library side have to be extendable as well. I thought of some way to do that but I still need to think about it to have the entire architecture in my mind.

Concerning Qt and wxWidget, at the beginning I didnt want to use those libraries as they are huge and may have a quite long learning curve. But no doubt there are the best solutions around (especially Qt). I ll have a closer look to them.

Thanks again for your comments

I'm currently reviewing chance to add SPARK to my Irrlicht-based 2D casual game project.
This is second time i'm doing this, and it was not used in my previous game based on HGE, due to lack of HGE renderer.

So, regarding the editor, what you think about making a C# based comfortable text/property grid editor with some kind of built-in help, which will generate a XML or other kind of script file. Every time you want to test a particle you've made, the editor will launch script player - a simple windowed executable which will read script and allocate all required emitters, constraints, groups, load models and textures, and show you the result.

XML looks like preferred way of storage for me, but if script language is chosen over XML, it will be a simple language developed specifically for SPARK and its capabilities. I'm excited to play with some parser generator, but the resulting parser should work in both C# (for editor) and C++ for clients. That would be Coco/R, so far it works with both C++ and C#, and other languages.

Pros:
- Cross platform, thanks to Mono project.
- Requires no built-in renderer or C#-C++ dll interfacing due to separate player and editor.
- Cost of testing is signifficantly reduced (you don't rebuild a C++ project, but instead launch a lightweight executable to "play" your particle script).

Cons:
- Not really visual, you don't see changes instantly when they are made.
- Might require either extended amount of GUI modelling and coding to make it easy to use, or will suffer from interface simplicity.
- If a text script editor is exposed to user, might be a steep learning curve for user, unless there will be some kind of templates and wizardry to guide user through the process of creating a particle system script.

I'm given 1 day by my employer to build SPARK into the game, without the editor. And if I succeed, I'm really interested to implement the editor, at least base version for you to continue with it.

SPARK very good thing and as soon as I have seen examples at once has decided to use it in my engine. Absence of the editor of particles became one of problems. I have written own editor in which easily enough I can create fire, explosions, a smoke and other. As I can easily change parametres and to see result in real time. I think if your editor allows to change easily set of parametres and to see result in real time many will want to use SPARK in their games. As it would be good, that created particles would be possible save \load. At myself I use a binary file and I load all particles into the engine at initialization, and then simply I copy them, as in an example with explosion.

Hello,

I am currently coding the SPARK editor, but because it has a lot of contrainsts (must be extensible, changes in real-time, etc...) it will take long time to develop. The next release will allow to create particles systems (the previous ones have not this property), furthermore, the source code will be made available (on a svn, maybe SPARK svn if Juff agree). Qt4 is used.

But, be aware that this editor is for SPARK 1, and will evolve to version 2 once version 1 implemented - and obviously, once SPARK version 2 will be finished^^

My idea, as I described it 2 posts above, should be really easy to develop (2-3 workdays I estimate). Also idea is to keep it as simple and lightweight as possible, to simplify porting to Mono and extending. Most users don't need advanced UI for particle effect, just to visualise envelope graphs, give some suggestions, choices and premade templates while making the particle script.

So we have an advanced Qt-based UI editor vs. simple Windows Forms based particle script editor. Plus if my company is to sponsor my work time for this task, we will need the result fast, that's also the reason why I go for simplicity.

Btw how you save and restore particle info? Binary? Text? XML? Some script language?

I think I will use xml - but for editor project files (smth like Spark editor Particle System Project, *.psp, or a thing like this^^). Juff wants to add a file loader for systems too, and my editor will probably support it.

I think having an editor like the one you've said could be an interesting thing. If you code this editor, I advise you to use a xml-like file format. Your editor would probaly be very useful for developpers.

So:

kvakvs wrote:

So we have an advanced Qt-based UI editor vs. simple Windows Forms based particle script editor

I vote for the 2!

Darktib wrote:

I think I will use xml - but for editor project files (smth like Spark editor Particle System Project, *.psp, or a thing like this^^). Juff wants to add a file loader for systems too, and my editor will probably support it.

I think having an editor like the one you've said could be an interesting thing. If you code this editor, I advise you to use a xml-like file format. Your editor would probaly be very useful for developpers.

Here's the deal. Internally in our company I have created a python script which takes data model description as input, and generates C++ and C# classes for that data model, which can read and write themself to XML. The generator is (very) roughly explained here in my blog.

I think for sure that will be the deal for the editor's and particle-player's data model, because SPARK's data model is complicated, and tends to change over time, like adding constants, fields, flags and new classes. This is where code generator might come handy.

We will need 3 things made:
- An editor in C#
- A SPARK data loading module for C++, which will be linked with player, and perform the data initialization for the player, and for end user application as well.
- A windowed player in C++, linked with some (configurable) renderer

Data model will describe construction of (partially) a renderer, particle model parameters, interpolators, emitters, zones, obstacles, other modifiers, with all their flags and fields, all those things you use to define a good effect. Data model will be also used for controlling the particle player, and will contain texture paths, preferred window size, camera position, scales, etc.

Darktib wrote:

So:

kvakvs wrote:

So we have an advanced Qt-based UI editor vs. simple Windows Forms based particle script editor

I vote for the 2!

Ow great! Thanks for inspiring me
I started writing some design papers on editor this evening, will probably get to coding it in a week.

Your tool is interessting, it can be very useful.

kvakvs wrote:

will probably get to coding it in a week

Great!

Cool, yeah I think both Darktib's and your tool can be complementary.

As said Darktib, I am currently working on the version 2 of SPARK which will change quite a bit. I m doing that on my spare time with other projects as well so I have no idea when it will be released (the core is done but I now have to port all the extensions and to write the documentation).

Regarding the way to load scripts, I think both xml and binary are interesting : xml is faster to implement and allows the user to modify the files directly while binary will be faster to load and allows to hide the scripts and prevent modifications of scripts. Later on I will certainly implement a binary format for version 2 (I wont add content to version 1 but only maintain it now). But if some of you are working on some kind of format or xml syntax, i may add it to spark directly.

you could use GTK (gimp tool kit) as interface. or a game engine such Ogre or Irrlicht.

I want to see the particle editor in action ..

have you thinked to use some template functions with parameters settable and callback to "serialize" a sequenze of "trasformers" also ? (C++ preferred ? )

DEMonRouge wrote:

you could use GTK (gimp tool kit) as interface. or a game engine such Ogre or Irrlicht.

I want to see the particle editor in action ..

have you thinked to use some template functions with parameters settable and callback to "serialize" a sequenze of "trasformers" also ? (C++ preferred ? )

My editor is a simple one, its already finished for what we needed it to do in our game, its available for download in next topic in this same forum. And the game was already released (look in project announcement forum section). And Darktib is using QT for his editor.
What we could really use is code generator, making class files, containing all code for particle system initialization. That would allow us to avoid writing import code.

great idea. a "little" more difficult.