APE - A 3d particle engine for GLBasic.

Previous topic - Next topic

fuzzy70

All Works fine on mine  =D.

1 point though (& you may be already aware of this), if I press the control key again the spacing of the explosion parts increases further apart. I have attached grabs to show what I mean. I presume its waiting for a counter or something to reset as if I don't press again for a second or 2 the explosion animates as normal.

Lee



[attachment deleted by admin]
"Why don't you just make ten louder and make ten be the top number and make that a little louder?"
- "These go to eleven."

This Is Spinal Tap (1984)

Hemlos

Quote from: fuzzy70 on 2012-Dec-13
All Works fine on mine  =D.
Great thanks for such a quick response!

Quote
1 point though (& you may be already aware of this), if I press the control key again the spacing of the explosion parts increases further apart. I have attached grabs to show what I mean. I presume its waiting for a counter or something to reset as if I don't press again for a second or 2 the explosion animates as normal.

Yup as expected, its not the kind of trigger you would use in a game, i wrote it for testing only.
And this brings up the point, the programmer must code thier own timers and such for releasing such heavy explosives :)
The reason for this...the number of special effects possible are litteraly infiinite.
You can make thousands of different explosions if you want...no two would be alike.
An array of explosions could be fired as in this test. the 3 images are the 3 emitters in the array.

All the triggers are itterated through the array, with the function call to the trigger...nice and simple....and each emitter in the array can last varying times....if you noticed the smoke lasts much longer than the firery part.

Bing ChatGpt is pretty smart :O

Hemlos

And the last of the explosion tests ...i think this looks and works good now.
The possibilities are endless, so if you dont like the way this explosion looks, it can be tweaked out in several ways.
This will be the last beta test for explosions, next and probably last test(depends if i add some other special effect) will be blackholes.


[attachment deleted by admin]
Bing ChatGpt is pretty smart :O

Hemlos

Well....one last test for explosions...i was having fun here...

made an array of 20 scatter bombs...also same trigger, left-ctrl button.


[attachment deleted by admin]
Bing ChatGpt is pretty smart :O

fuzzy70

Both the above working fine here  =D

Interestingly I was expecting a FPS drop with the last example post with all the extra drawing of the explosions but remained a constant 130 fps with or without them.

Lee
"Why don't you just make ten louder and make ten be the top number and make that a little louder?"
- "These go to eleven."

This Is Spinal Tap (1984)

kanonet

All tests work for me and I could see no problems there.
Lenovo Thinkpad T430u: Intel i5-3317U, 8GB DDR3, NVidia GeForce 620M, Micron RealSSD C400 @Win7 x64

Hemlos

Quote from: kanonet on 2012-Dec-11
Yeah this one is fast. But i think you need to have a look in alpha again, at least for that smoke particles. See Screenshot.

Finally figgured this out...


I was rendering the smoke first, then the fire.
By reversing it looks as it should.
Bing ChatGpt is pretty smart :O

Hemlos

Quote from: fuzzy70 on 2012-Dec-13
Both the above working fine here  =D

Interestingly I was expecting a FPS drop with the last example post with all the extra drawing of the explosions but remained a constant 130 fps with or without them.

Lee

the lib is very light weight, by keeping the particle count low, it makes the whole lib practically invisible in the computational sense of things.
Since the test with 30k particles with the river ...i have more than quadrupled the internal multidimensional array count too, due to adding explosions and fans and stuff.
And still with 30k particles i get about the same fps still, around 55fps...including all the explosions...30k + all explosion emitters
Bing ChatGpt is pretty smart :O

Hemlos

And then there was fixed blackholes  :whistle:

attached:



[attachment deleted by admin]
Bing ChatGpt is pretty smart :O

Hemlos

Ok guys this is the last test today..

Its a high performance test.

It is testing a new implementation to the lib, framerate regulation.
The idea here is to regulate fps when overloading occurs.
This would occur in a situation when many 10's of thousands of particles are being fired off at the same time within rendering range, for whatever reason.

Cornercase: hypothetically, if an MMO game as 150 players in close vicinity fired off 1000 particles each(way overkill imo), you would get 150k rendered, and the frame rate would simply plummet, thus sucking up processing power for the end user.

I added a bit of code to prevent frame rates to drop under 20 fps, which would prevent a complete fail of the game at the moment of overloading.
This is nice saftey measure to keep the game running smoothly under any circumstances, and reducing the amount of rendered particles is the best way to do this.....these little guys are expendable ;)

150k drop-test test attached:





[attachment deleted by admin]
Bing ChatGpt is pretty smart :O

kanonet

Good idea but i think your approach is not the best. I guess you use the this system only to decide if you create a new particle - after you have spawned them you dont reduce them if necessary, but let them life till the end of there normal lifetime?
This causes two problems:
- generally your spawning is very pulsating, cause you spawn points, than system slows down, then you dont spawn to increase framerate, which leads to a gap in your particle stream but give you more time to spawn new particles later again - so your framerate jumps every few secs and your particle stream pulsates, compare the to attached images to see what i mean.
- calculation the particles in background is faster than finally drawing them. This causes the problem, that when you look in an area with only a few visible particles, you spawn many particles in background. If you then fast turn and look in an area with many particles, you have there so many particles that displaying them slows you down below 10fps for a few secs (till the particles die).

I think you should think about implementing a simple maximum particle count (that can get changed by the user). Then you just need to find a way to take care that you spread the max number of particles over all emitters and still cause a constant stream of particles. And a way to kill active particles even before there end of lifetime could be needed too.


[attachment deleted by admin]
Lenovo Thinkpad T430u: Intel i5-3317U, 8GB DDR3, NVidia GeForce 620M, Micron RealSSD C400 @Win7 x64

Hemlos

#41
Quote from: kanonet on 2012-Dec-17
Good idea but i think your approach is not the best. I guess you use the this system only to decide if you create a new particle - after you have spawned them you dont reduce them if necessary, but let them life till the end of there normal lifetime?

You cant wait for them to die...then they will all be dead at the same time by the time it can regulate a new batch.
This actually makes the inconsistancy worse, and pulsing noticable in short burst too.

Quote
This causes two problems:
- generally your spawning is very pulsating, cause you spawn points, than system slows down, then you dont spawn to increase framerate, which leads to a gap in your particle stream but give you more time to spawn new particles later again - so your framerate jumps every few secs and your particle stream pulsates, compare the to attached images to see what i mean.
You wont even see this pulsating because typicall emitters only last a few seconds with explosions.....this test is constant, thats only reason you notice it.

Quote
- calculation the particles in background is faster than finally drawing them. This causes the problem, that when you look in an area with only a few visible particles, you spawn many particles in background. If you then fast turn and look in an area with many particles, you have there so many particles that displaying them slows you down below 10fps for a few secs (till the particles die).

Calculating 150k particles is still too much work no matter what, rendered or not.

Quote
I think you should think about implementing a simple maximum particle count (that can get changed by the user). Then you just need to find a way to take care that you spread the max number of particles over all emitters and still cause a constant stream of particles. And a way to kill active particles even before there end of lifetime could be needed too.

Believe me, when you are using alot of explosions and if 150k fast living particles fire off at once, you wont notice any problems....theyll be dead by the time any pulsating starts.

This is a constant 150k particles...of course youre going to see an issue.
That was the point of initiating 150k of them to regulate a cornercase, which you will likely never see anyhow because of how quickly itll last in time.
As a programmer if you overlook something and this cornercase happens.....your game wont stop...particles will be expended instead, and you can go fix it later....its not intended to regulate particles not at all! Its intended to prevent performance issues during a cornercase.
I hope i dont sound harsh, im not trying to be. Honestly i believe i captured this cornercase perfectly, the quality of persitant particles wasnt the focus, rather the opposite.

You know as well as i do, quality and performance are interchangable.
Always one at the cost of another, and in this case i captured the best quality possible....other options like you mentioned really looked worse, especially if you wait for particles to die and prevent new births...this causes an iregularity in timing, even with a "template of time segments", the pulsating gets worse due to the "waiting to die" and "waiting to be born".

My point is this....this "feature" is not to make your game look better, nope not at all. You must NOt depend on this feature to "save the day". You must be wise and use limited amounts of particles right from the start. And if for whatever reason your game is running slower than expected, the APE will cut losses and prevent sucking up all your resources.


Bing ChatGpt is pretty smart :O

kanonet

QuoteYou cant wait for them to die...then they will all be dead at the same time by the time it can regulate a new batch.
This actually makes the inconsistancy worse, and pulsing noticable in short burst too.
I just saw the pulsation si guess you did it this way. - If not i haven said anything. :D

QuoteYou wont even see this pulsating because typicall emitters only last a few seconds with explosions.....this test is constant, thats only reason you notice it.
You may still see a pulsation over all emitters (if you see many around same time) and some emitters are long lifeing (like fontains, burning fire, maybe smoke), so you will see a pulsation on them.

QuoteCalculating 150k particles is still too much work no matter what, rendered or not.
Of cause, thats the reason why we try to cut it down, right? I was describing a problem that i actually saw in your demo: normally when watching the scene i had around 50000 particles @20 fps. But when i turned around and looked at an area with no particles, it spawned and calculated about 75000 @20 fps. So far no problem. But when i turned back to the scene it tried to render all 75000 particles that it spawned before - which of cause slowed me down, under 10fps in my case.

QuoteIve been giving this alot of, alot of, testing.
You cant regulate with a fix number of particles...one fixed number wont cover all computers.
You must regulate slowly, and you must stop all affected particles calculations when you do.
Believe me, when you are using alot of explosions and if 150k fast living particles fire off at once, you wont notice any problems....theyll be dead by the time any pulsating starts.

This is a constant 150k particles...of course youre going to see an issue....that was the point of initiating 150k of them to regulate a cornercase which you will likely never see anyway.

If you make your game to run under 20fps...you need to think about a new job, or forget using a particle engine lol.
And if you overlook something and this cornercase happens.....your game wont stop...particles will be expended instead, and you can go fix it later.
I was not talking about a max number for all computers, at least not same number for everyone. Just let the user input the number, so the play can select the max number in options screen (along with may other options. So everybody can make it perfect for his computer.
And you should not forget: your particle engine is not made for the fun itself, it should get included in games with many other things around, that can cause slow down, scene can change fast and the particle engine is just the candy on top, the main game engine always has a higher priority and should not get influenced by PE. So its good that you try to limit the time for the PE but this should not just happen at particle spawn time, PE drawing time should be limited at all, so it never causes a slow down (see my example of low down above).
Lenovo Thinkpad T430u: Intel i5-3317U, 8GB DDR3, NVidia GeForce 620M, Micron RealSSD C400 @Win7 x64

Hemlos

Great idea.
Hows this?

myExplosion.set_minFps(20) //lowest frame rate before ape heavily regulates computation. -1 to skip

Bing ChatGpt is pretty smart :O

kanonet

I would prefer it the other way around: dont tell the PE the min FPS, tell it the max ms that the calculations are allowed to take. This way you dont need a FPS calc routine for this part of the program and you easily know how much time each part of the game loop need. But you need to be sure that your PE at all really does not use more time, no matter what happens.
Lenovo Thinkpad T430u: Intel i5-3317U, 8GB DDR3, NVidia GeForce 620M, Micron RealSSD C400 @Win7 x64