I originally planned on doing soft particle and screen-space physics by sampling the depth buffer. However it will mess up the current ScreenEffect system if I setup RenderToTexture manually. So I will wait for ScreenEffect rework first and see if I could work around the new system
Currently its only useful for effects like dust, fire, smoke, fountain etc. Other effects that require trails like sparkle, or rotating in space like falling leaves are not supported yet.
Because emitter is descendant of TCastleSceneCore and uses direct OpenGL calls instead of CGE’s own renderer, there’re a lot of TCastleScene’s functionality and behaviors that are missing at the moment. I’ve spent the last few days to add some of it back:
BoundingBox and frustum culling works. The emitter doesn’t calculate bounding box so you need to set up bounding box manually via Effect.BBox property, either by code or by using particle editor / edit particle file.
Visible works.
The component registers to TRenderStatistics as 1 Shape / 1 Scene.
Instancing, by putting the same emitter to multiple TCastleTransform nodes works. It doesn’t use GPU instancing at the moment.
Edit: I decide to remove ProcessEvents at the moment, mainly for backward compatibility with the old 2D particle system.
See at whether we’d like to just include it in the engine core? We want to have a particle system that “just works”, can be previewed in our CGE editor, and preferably can also be designed in our CGE editor.
I just add 2 new parameters: Radial and it’s variance. This allows to create swirl effects like dust devil or similar An example for this effect also added to demos.
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 TCastleLabel.Tooltip)
The color properties could get a dialog to adjust them graphically (you can use TCastleWindowBase.ColorDialog).
Some properties could be better expressed as a slider than a number input. Use TCastleFloatSlider.
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 TCastleColor with 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-user-interface or .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. fire.castle-transform, dust-devil.castle-transform etc.
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 CastleComponentSerialize stuff.
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.
The main purpose of editor is to serve as one of demos for the library, which I took inspiration from Urho3D’s editor (Urho3D Scene Editor Progress - Game View - YouTube). This editor, which is a full-blown scene editor, is actually one of Urho3D’s demos, written using the engine’s own components, including its UI.
So I prefer it to stay as it is in its current state, of course small QoL changes like color dialog and tooltips will be added soon in the future
Now, the idea of exposing everything to castle-editor and let it does all the heavy work is very interesting. I will certainly look into it in the future
Great:) I realized it may also need ability to edit non-visual components in CGE editor (as you want to edit the reusable effect settings, and only assign them to the emitter) – this is not yet available but will be:)
There isn’t, from what I know. The particle system in this thread is unrelated to X3D nodes.
We don’t have any implementation of particle system following X3D nodes in CGE at this point. And I’m not sure if we’ll ever have. That is:
for Castle Game Engine, it may make more sense to “roll our own system”, and look what Blender / Unity / Unreal offer to be competitive.
Gamedev people that design particles don’t use X3D, X3D is not really known in gamedev (except in CGE ).
We would have a small gain from interoperability with other X3D browsers like X_ITE, but this is lower priority. Higher priority is to offer features comparable to Blender / Unity / Unreal + easy visual design of particle systems.
).