SPARK Particle engine Renderer


#21

Thanks for OsX report… But if this flag is not present you can’t load spark effect files.
I just fixed the cmake build and a xml error, it’s ok now for Linux and Windows, maybe this also fix OsX errors…
Can you give me the compiler errors if there are still some ?
Thanks.


#22

No more errors on Os X.
Whoa looks good!


#23

Looks nice! What’s the performance like compared to Urho’s own particles?


#24

Good question.
It need some advanced test to really compare both. But I made some quick test and spark is really more faster…

I build a similar effect for both system and tunes both side to render nearly same particles count.

Some images with stats:

conclusions :

  • currently spark is faster and can render many more particles before dropping the fps.

  • The rendering method is faster for spark : we can see in statistics that the urho particle emitter does not dynamically update the vertex buffer count (always at max count), only the index buffer count is updated - spark update both.

  • A test without rendering (only particles update will be usefull too, but not tested yet)…

  • I see in stats that UpdateDrawables and ReinsertToOctree methods are less expensive on spark side.

  • spark is modular, when a feature is not needed (rotation, texture index, gravity, color interpolation,…) it is not computed in final effect, so a simple effect is really more efficient than a complex one. I think it’s not the case in urho particles, that always compute all features…

EDIT:
I made a little mistake when printing the “visible particle count” values on screenshots.
good values are :

(SPARK) 93787 => 62525
(URHO) 60000 => 40000

(SPARK) 357077 => 239056
(URHO) 145350 => 96900

This value is the geometry indexCount / 6. I divided by 4…
However it doesn’t affect other stats.


CustomGeometry with dynamic VertexBuffer
#25

Hello.

I’d like to know if the core team would like to integrate this library into Urho3D as an official internal ThirdParty or if I continue to my dev on it as a standalone addon ? I’m facing some code design that will change considering this answer.
Thanks.


#26

I have no issue to have it added as 3rd-party libs, as long as it is optional. I do have a concern though that the last commit in that library was made like 3 years ago.


#27

I use the URHO_SPARK flag so compile can be optional.
Yes the last commit was made 3 years ago. I talk with the spark dev and officially the lib is suspended now.

However its state is full and stable and to my knowledge there is no other such particles library so evolved and with an open source license.

Morehover I use my own fork of SPARK. As official one is suspended, I think it’s more flexible to integrate new changes. This fork remove the latest commits of the official lib that broke the gcc compilation, I also fixed some bugs, removed the unused renderers (irrlicht, dx9, ogl) and created the urho one. I also plan to add new features to the core lib and continue the dev on this fork.


#28

Ok…that sounds good to me.


#29

Nice library porting .
Quick check on Android , it doesn’t work well on Android (at least the demo )
To my understanding the only working/displayed effect is “Spark/Effects/Spark1.xml” .

I didn’t have time to debug it yet .


#30

It’s interesting that SPARK is a CPU engine and runs so much faster than Urho3d’s GPU transformed particles.


#31

I see this bug on emscripten too, manually build effects works, but loaded effects (from files) are not rendered. I’m investigating…

During my tests I found that BillboardSet (used by urho’s particles) push on the vertex buffer the max particle count (set at particle creation) but doesn’t update it according the real alive particles count during effect lifetime. so it’s often bigger than necessary and need too much memory, I think it makes it actually not optimized for rendering dynamic particles. imho Fixing this first issue should render urho’s particles a bit faster, after it will need others benchmark.


#32

Tested on Ipad with Ios 10.3, looks ok.


#33
  • Fixed bad loading effect files on some platforms (emscripten and android).
  • Clean code and fix warnings compilations.

Use this branch for now : https://github.com/fredakilla/Urho3D/tree/sparkdev


#34

I verified it on Android devices with versions 4.4.4 and 7.0
Works well.
Thanks for your work.


#35

Hi @dakilla! Are you still using this in Urho?


#36

I’m still using spark, but not with urho.


#37

Have you abandoned the integration? Could you share with the us the most up-to-date repo/branch? I would like to keep it up.


#38

Yes this integration is frozen since I use spark with others engines.

The most up to date urho3d integration is on my urho fork : https://github.com/fredakilla/Urho3D/tree/sparkdev

It use this SPARK modified version : https://github.com/fredakilla/SPARK (I made some few modifications to get it compile on linux and emscripten, fix some warnings, clean, add qt project and cmake …)

I’m also working on a node editor for spark : https://github.com/fredakilla/spkgen


#39

I’m come back to Urho :stuck_out_tongue:
I just created a new repo for the urho spark integration using an external library to maintain it independently and outside of the urho engine: https://github.com/fredakilla/Urhox

@ rku I also added your imgui implementation (thanks)