I just made a news post about both 2D system upgrades, and new 3D particle system: GPU-based 3D particle system, and upgraded 2D particle system for Castle Game Engine – Castle Game Engine . Sorry it took me so long — but I wanted to review everything, also looking at usage in my own games
I also submitted 3 PRs + 1 suggestions to 3D particle system ( Pull requests · Kagamma/cge-3d-particle-emitter · GitHub , Possibly ExtractRelativeDataPath can be removed, and the work done in more portable way · Issue #4 · Kagamma/cge-3d-particle-emitter · GitHub ), I hope that this is useful, as my previous PRs to 2D version.
@kagamma thousand thanks for this work!
Looking from the point of view of a developer that wants to use this in own projects:
The main drawback of 2D system is lack of a cross-platform, free particle editor You did address it greatly with the 3D system, by just doing your own editor.
Making our own editor for particles is a big task, but also I think this is a good direction – we need own particle editor, in CGE. I would like to have it one day just incorporated in CGE master, we want particles!
The 3D particle editor was a bit hard to use for me as a newbie. Quick UI suggestions:
Use tooltips to document some properties. (You can maybe just use
The color properties could get a dialog to adjust them graphically (you can use
Some properties could be better expressed as a slider than a number input. Use
Actually there is another idea for making 3D particles editor, a more drastic change:
Do not make editor yourself at all, do not implement saving / loading yourself at all.
Let CGE editor become the editor for properties of the particle system.
Define everything as published properties, register in the CGE editor and let Object Inspector in the CGE editor do the job for you. E.g. if you make a
TCastleColorPersistent backing it, user automatically gets ability to adjust color using dialogs – “providing good UI to edit a color” is no longer something you need to do, you just expose TCastleColor[Persistent] like other CGE components.
The saving/loading would be handled by CGE as part of reading/writing the files containing the component, to
.castle-transform. See e.g.
examples/editor_advanced on how to “wrap” a component with designed properties, this could be used to create a reusable e.g.
Personally I woud choose this method. It is a more drastic change, but this way you “offload” some work on me and CGE
I am prepared to make various CGE improvements here to make it perfect – e.g. right now our F1 loads API docs assuming they are part of CGE. We could make a system that allows to register custom API docs URL for custom components.
As for API, one significant suggestion I have is to hide more the GPU vs non-GPU implementations differences. E.g. in case of 2D, right now the choice between using GPU / non-GPU implementation is when using this or that class name. It would be better (but harder to implement, I know ) if we just had
TCastle2DParticleEffect class name and it is configurable by a Boolean property like
ParticlesUseGpu whether it tries to use modern OpenGL features. Underneath the “public” class could act as a proxy for 2 actual “backends” providing particle systems implementations.
So I would generally focus on:
Developing a 3D particle system (and make 2D just some special case inside of it), so that you maintain only this system.
Developing it as a class with published properties, that can be edited using CGE editor, and serialized using existing
Hiding the fact whether it uses GPU implementation more. Toggling between GPU/non-GPU should be easy, and fallback on non-GPU should be possible.