Particles example

[Stuart Axon]

Hi,
   Are there any particle examples or pi3d?

Cheers
S

[Paddy]

demo in github.com/pi3d/pi3d_demos/ develop branch Particles.py https://youtu.be/EaXuZVnWmCM

[Stuart Axon]

Awesome, I will have a play when I can get it on a pi (I don't normally run python as root, so don't have access to /dev/input/mouse usually... at some time I should try and revisit this in pi3d)

I had a really brief quick look at kivy and they have and implementation of the starting particle system

https://github.com/skitoo/kivy-particle

Which lets you run pex files generated particle panda and other programmes.

[Paddy]

Stuart, I'm not sure what platform you are running from but if it's linuxish you should be able to do this quite easily http://pi3d.github.io/html/FAQ.html#permission-denied

I wasn't aware of the pex format but I might add an example with a little parser. Pretty well all the parameters are handled by the uv_pointsprite shader i.e. texture image, rotation, size, rgba etc. but obviously the macro behavior of the particles would need to be picked up. The pex system seems to be 2D like the uv_pointsprite whereas the simple example above is 3D

I would be interested to see how fast the kivy system runs (especially on RPi) as it's all done with traditional python lists of objects rather than numpy arrays (and I notice the number of particles is relatively low in the demo files - I can run the demo I posted above on this quad core i5 laptop increasing the number of particles to 500,000 without much impact on frame rate.)

Paddy

[Stuart Axon]

Currently I'm developing on a desktop linux and deploying to pis.

Cheers for the reminder on  use_pygame=True

I added it, but then got a problem starting the example

$ python Particles.py
Traceback (most recent call last):
  File "Particles.py", line 52, in <module>
    display = pi3d.Display.create(background=(0.1, 0.1, 0.1, 1.0), frames_per_second=FPS, use_pygame=use_pygame)
  File "/mnt/data/home/stu/projects/external/pi3d/pi3d/Display.py", line 546, in create
    display.opengl.create_display(x, y, w, h, depth=depth, samples=samples, layer=layer, display_config=display_config)
  File "/mnt/data/home/stu/projects/external/pi3d/pi3d/util/DisplayOpenGL.py", line 80, in create_display
    self.create_surface(x, y, w, h, layer)
  File "/mnt/data/home/stu/projects/external/pi3d/pi3d/util/DisplayOpenGL.py", line 191, in create_surface
    assert r
AssertionError
 3d  stu  beez


[Paddy]

Not sure why it does that. But.. I actually meant adding the user to the input group, which is what I do on this computer.

[Paddy]

added a pex file parser to pi3d develop branch - pi3d.util.PexParticles pretty simple to use but will add a demo. Basically just

p = pi3d.PexParticles('pex/fire.pex', camera=cam2D, z=500, emission_rate=40)
...
  p.draw()
  p.update()
...
  if k == ord('w'):
    p.sourcePosition['y'] += 10.0

https://www.youtube.com/watch?v=wy0GpjbhpuQ

[Paddy]

I've added the demo to pi3d_demos develop branch as PexDemo.py Also fixed a few bugs and made a couple of improvements. (There's still an issue of the pex y direction being top down so I might add another argument to flip the sense in the parser (defaulting to True).

[Stuart Axon]

Awesome, I've been away for a week + came back to this :)

I'll definitely have a look at the Pex class, I also noticed how the kivy example doesn't update the particles using numpy, this certainly looks like it should be quicker.

It certainly seems like at least some (all?) of the pex params are designed so they can be implemented purely in a shader.


OT:

I still haven't fully made the jump to batch updating / numpy / shader way of thinking, it was quite an aha-moment seeing your numpy sprites example, still not the natural way I think of organising things yet though.

[Paddy]

.

I replied to this too but  it might have gone missing as well; Basically agreeing that the OOP  style is much nicer and may be worth thinking of a way to keep the numpy array in the class  properties. 

[Guillaume Ludwig]

Hi there,

sorry this is an old thread…

I would like to know if you think (Paddy ?) there is room for improvements in the Pex class ? In terms of performance. 

My benchmarks : on a RPi2 a simple particle system with 5 particles consumes 4/5ms. It's not bad, but if you plan to make a game with 5/6 particles emitters, you can't have 60fps, and maybe not even 30.

Guillaume

(maybe you remember me Paddy… I have a surprise soon…)

[Paddy]

Hi, yes there is almost certainly scope for improvement. Firstly it might be possible to split the massive ndarray and update the Buffer.array_buffer in place to save a copying operation, also I tried to cover the whole scope of the Pex file which meant some convoluted numpy operations - it might be faster if it addressed a subset. I will have a look at it again later today or tomorrow (it's been a while and can't really remember the details).

Yes I remember your 2D sprite game engine idea - I was actually wondering how you had got on with that just last week.

Paddy

[Guillaume Ludwig]

Ok, this seems encouraging. I'm not really good at manipulating numpy arrays… 

My first idea was to "disable" some unused functionalities, regarding each context of the current particle emitter.

I also needed to stop a particle emitter, so I changed emission_rate to 0, and checked that the new rate after a pause wasn't higher than the max particle (I can show you the code). Not sure it's the best way, but it works quite well. I was testing it for a space ship game demo, it' s nice ( https://photos.app.goo.gl/jLyMGCaDBxfkN4Cv2 ).

I stopped working on my game engine for a long time (second baby, etc). I work again on it every morning (while everyone sleeps) since June. I restarted it completely. Not sure I'm using pi3d the right way, but it's working and my goal is reached : a teenager can use it. The demo you see is 12 lines of code, and take 3ms per frame without particle emitter (with collisions activated). 

I hope to release the code soon (working the morning was the best idea I had : super productive !).

[Paddy]

Very impressive, 12 lines of code is remarkable. I'm not sure about the 'teenager can use it' criterion - that could be pretty complicated. (My last baby turned 20 a couple of weeks ago so I no longer have teenage kids!)

There is a lot of sophistication in the Pex specification that could be masked out - or even make an alternative class completely 'SimplePex' that could read a Pex file but ignore some of it. Or have a roll your own class to do just what you want. I will think about the pros and cons.

As the animations are worked out based on time from last update it's feasible to update less frequently than every frame. With particles being a bit 'spluttery' anyway you don't notice the lower fps on them. On the PexDemo file I did the update alternate frames and the overall fps went from 37 to 56

Changing the particle emitter properties such as emission_rate sounds fine.

I will try changing a couple of things in the existing PexParticle class to see if it speeds it up a bit.

Paddy

[Paddy]

Updated PexParticles with the simplest change (updating the array_buffer in place). It improves the speed a little 37 to 39fps updating every frame 56 to 57fps every other frame. (I tried update every third frame and it actually looked fine - especially if the particle speed is low)

I suppose the next thing to look at would be making some of the parameter updates conditional on having initial values. i.e. gravity, tangential speed and colour change. This is already done for the rotation option. 

[Paddy]

Small additional change to only do the complicated acceleration calculation if gravity, radial or tangential acceleration are non-zero. The equivalent demo, but with no accelerations, now gives 48fps (59 only updating alternate frames)

[Guillaume Ludwig]

The teenager criterion is because I learned to code at 11, my only regret is not to have done it earlier. And when I see tons of teens doing code in clubs with Raspberry Pi, and playing with Pygame… I love Pygame, but it's really slow, and if you want to make a game you have to code a lot of things. I want to make something you can play with, make really precise things, but also make a "full" game in a few hours only doing simple OO coding.

For instance, I propose "example" movements (platformer, asteroid, rpg, etc) that are configurable but you can also code your very own.  

Thanks for the improvements ! That's perfect ! I will do stress tests. 

I tried to not update every frame last week, but that was really stuttering. Maybe I was not doing it right…

[Paddy]

Sounds great. What I meant was that some teenagers - your former self included probably - are technically VERY advanced. But converting the surplus of imaginative ideas into playable games quickly is a really good idea. And with a python based game engine it's possible to actually read the code, see how it works and even change it.

While I was fiddling with the code Yesterday I noticed that frequently there is just one new particle being added at a time (i.e. n_new == 1) here but the process would be more efficient to create several new particles in one update and none for the next few. I tried changing the threshold from > 0, to  > (self._emission_rate / 4) and it's really not noticeable, so I might put that in as a new argument (probably as a fraction of the emission rate)

For the update every third frame I did something like

n = 0
while display.loop_running():
  n += 1
  back.draw()
  text.draw()
  for p in particles:
    p.draw()
    if n % 2 == 0:
      p.update()

so all the other drawing and movement happened every frame, just the call to PexParticles.draw() less frequently.

[Paddy]

that should have been 'update every second frame' and 'just the call to PexParticles.update() less frequently'. Put batching argument and pushed to develop (not a massive improvement but measurable)

[Guillaume Ludwig]

The new version does not seem to provide better performance in my case. I was at 8ms and with the new 8ms too.
Strangely, when I try your method to update less frequently I see no noticeable difference also.
But, when I try your method with the new version : 3/4ms ! Huge improvement :-)
https://photos.app.goo.gl/UGrfjhqDmiawF7z23

I need to go deeper in my investigations....
Thanks for the help Paddy, that's really good !

On ven. 15 sept. 2017 à 11:32 Paddy <pat...@eldwick.org.uk> wrote:

that should have been 'update every second frame' and 'just the call to PexParticles.update() less frequently'. Put batching argument and pushed to develop (not a massive improvement but measurable)

--
You received this message because you are subscribed to a topic in the Google Groups "pi3d" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pi3d/dCQGk-2H62I/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pi3d+uns...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Guillaume Ludwig]

There is something strange. Without changing a line of code, sometime I got good performance and sometime not. With 20 particles I can have 10ms, and on the other end with 120 I can have 3/4 ms like here : https://photos.app.goo.gl/GbFEFqwaPVRuU7yE3

Waiting a long time between tests seems to help, but it's not really reliable. Problem with the GPU ?

[Paddy]

I've put a simplified PexParticlesLite class in the demo branch.  This can use Pex files but ingores the texture specification. Instead it uses a new shader mat_pointsprite that draws circular points with the alpha falling off according to the 'hardness' argument (2.0, the default is about like the existing texture based particles) There is also a bit of calculation saved where there is no change in RGBA for the particles. The original demo that ran at 37 runs at 44fps.

I've not put an alias to this class in /pi3d/__init__.py so

import pi3d
p = pi3d.PexParticlesLite(...) # wont work yet, you have to do
from pi3d.util.PexParticlesLite import PexParticlesLite
p = PexParticlesLite(...)

There's a lot of duplicated code between the two classes at the moment so I need to think of a maintainable way of implementing this - maybe just one class that switches if there is no texture file specified? If you get a chance to try this out let me know what you find. Meanwhile I will try and do some more scientific profiling. 

[Guillaume Ludwig]

Wow that's really kind of you ! Thanks for this. I will try it asap.
Maybe we could have three types. If you specify a file name it uses a texture. But if not and if you specify 'geometry' or 'shape' (circle, square) it uses this geometry.

For these fact that my code runs sometime at low FPS and sometime at high FPS, I think this has something to do with initialisation. Because it's stable when it runs high.

--

[Guillaume Ludwig]

I find the solid version even prettier :-)
Sadly the performances are fluctuating. See here : https://photos.app.goo.gl/1i95fio4jjOLmIyi1

Without particles, it runs 6.50ms +-30. At the beginning the pexparticles is really quick at updating consuming less than a ms. But after.. it sometime doubles. I'm only updating x,y and gravity x,y.

[Paddy]

Consolidated the lite option into PexParticles which will be used if the file name is 'circle' (TODO other geometries in shader).

I'm not sure at all about the intermittent type of slowing down! I can't reproduce it at all with the PexDemo version. Maybe it's something to do with memory allocation by the operating system for numpy or gpu?? Are you using standard raspbian? stretch? Is your RPi type 3?

It's possible to get a more detailed breakdown of processes by doing this kind of thing.

[Guillaume Ludwig]

Standard raspbian with Pi2. 

I will do proper profiling when possible.

I tried with only altering x and y, disabling gravity, color, etc. It helps, but it's not perfect.

--

[Paddy]

Guillaume, I've just tried the PexDemo on a RPi 2 and, though it's slower than on the 3, I still can't get the variation in speed. It must be due to other factors - maybe all the rest of your 2D game engine eats into resources in some way, but not sure how or why. I will have to try and figure it out once the code is in a state to release! (to which event I am much looking forward)

The most recent version of PexParticles checks if there is anything set for gravity x or y, radial or tangential acceleration and if there isn't it skips one rather messy calculation. It also checks if there is a difference between initial RGBA and final RGBA, again if no change it doesn't do the update -  just the initial setting. From your videos I would have thought you could change sourcePosition['x'] and ['y'] and angle as your rocket rotates. But it does look better imho with varying RGBA, though you can get some of this effect by setting start variance rather than having a different final colour. The 'circle' (lite) version is pretty quick to change the colour anyway so probably not a big saving.

Paddy