GLBasic forum

Codesnippets => 3D-snippets => Topic started by: Hemlos on 2012-Dec-11

Title: APE - A 3d particle engine for GLBasic.
Post by: Hemlos on 2012-Dec-11
APE A particle engine, a 3d particle system lib for GLBasic.

This lib was last updated in january 2013.
This lib is released 11/26/2013.
Happy Thanksgiving, happy holidays!

-Neil





[attachment deleted by admin]
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: bigsofty on 2012-Dec-11
Very nice demo, smooth, I'm getting about 280fps.  :good:

The only problem is that I am getting an App Crash on exit.

Title: Re: APE - A 3d particle engine for GLBasic.
Post by: erico on 2012-Dec-11
Hi Hemlos, some feedback:

-Everything goes on 60fps as expected.
-When close to the clouds, the snowy ones, some has borders alpha fade to the background, it does not consider the other clouds behind, some consider the floor.
-inside of the blue ball is really cool!
-app crashed on exit (esc) here, tried twice.

Good going!
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: Hemlos on 2012-Dec-11
Quote from: bigsofty on 2012-Dec-11
Very nice demo, smooth, I'm getting about 280fps.  :good:

The only problem is that I am getting an App Crash on exit.

Awesome

I wonder why it is crashing?
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: Hemlos on 2012-Dec-11
Quote from: erico on 2012-Dec-11
Hi Hemlos, some feedback:

-Everything goes on 60fps as expected.
-When close to the clouds, the snowy ones, some has borders alpha fade to the background, it does not consider the other clouds behind, some consider the floor.
-inside of the blue ball is really cool!
-app crashed on exit (esc) here, tried twice.

Good going!

Itll go faster if you force off the vysnc in your video card settings on your computer.

Wonder why it is crashing?
I use older hardware to test this, with no crashes. 2ghz cpu with 1 gig ram.

The clouds are Z fighting, which is expected.
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: kanonet on 2012-Dec-11
Yeah that crash was on both test versions that you gave me too. Always expected an Array problem, but when you said it does not happen on your machine, it must be something else.
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: Hemlos on 2012-Dec-11
Ok i did find a couple sneaky globals lingering around, got rid of those.
I uploaded the fixed version.

As last resort, If that still crashes, i will do a sub on exit with arrays wiped next.

Everyone please get the new download from my site and re-test it, report crashes.
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: kanonet on 2012-Dec-11
Still crash on exit.
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: erico on 2012-Dec-11
Crash bandicoot here too.
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: Hemlos on 2012-Dec-11
Thanks for testing guys, really appreciate it!
Bugs founds were more serious than i originally thought.
All in all, this is good, i am converting the lib into a TYPE object which will be easier to code.

before you had to make a bunch of emmiters just for one explosion.
after im done you will be able to define an array of emitters, to group them up.

somethign like this:

Code (glbasic) Select
GLOBAL Explosion[] as lib_APE_Object_
DIM Explosion[3] //fire smoke and shrapnel
Explosion[0].Create(stuffstuffstuff)
Explosion[1].Create(stuffstuffstuff)
Explosio[2].Create(stuffstuffstuff)


then you can make a few emitters in the explosion array, and can show the emitter group all in the same location with a for loop:

Code (glbasic) Select
for i = 0 to 2
  Explosion[i].show(x,y,z)  //show all the explosions at this xyz location
next

Does this sound better? maybe theres a better way to set this up? Advice here is welcome while im revamping.



Title: Re: APE - A 3d particle engine for GLBasic.
Post by: Hemlos on 2012-Dec-11
If you guys wouldnt mind, i need this program tested bare bones with only one particle being drawn.

Need test for crash.

Its here, uploaded to forum:


[attachment deleted by admin]
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: fuzzy70 on 2012-Dec-11
Just tried your version just posted (V2) & no problems with any crash. I moved around both forwards & backwards to the imposed limits for about 10 mins no problems & no crash on exit.

Avg 190 fps on a AMD II P320 Laptop with Radeon 4250 gfx, Win 7 x64 & 6gb RAM.

Went on your site to download your earlier version to check for problems but was unable to find the demo so presume you have removed it for the tome being  ;)

Lee
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: kanonet on 2012-Dec-11
Quote from: Hemlos on 2012-Dec-11
If you guys wouldnt mind, i need this program tested bare bones with only one particle being drawn.

Need test for crash.

Its here, uploaded to forum:
No crash on that Version.
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: Hemlos on 2012-Dec-11
Awesome, thank you Lee, and Christoph!
need more feedback from erico and big, check if the barebones still crashbandicoots them.

Im glad i converted the lib...it seems to run, litteraly 20 times faster so far...although i need to add a couple details.
I will have a new demo today, itll be running 30k particles, instead of 1500 ;)

heres a screenshot

[attachment deleted by admin]
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: kanonet on 2012-Dec-11
OMG i will not really be able to test with 30k particles my machine is to slow to render this.
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: Hemlos on 2012-Dec-11
I just noticed, the load time went from about a minute on my comp...to ...0 seconds with the new version.

kano you might be surprised...

here the new demo

[attachment deleted by admin]
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: 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.

[attachment deleted by admin]
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: Hemlos on 2012-Dec-11
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.

As expected i think.
the smoke = 10k particles, and the fire = 10k
zfighting is happening, and the ALPHAMODE's are clobbering each other.
This becomes very noticable with huge amounts of particles overlapping each other, especially spread over large areas of the underlying 3d world..

Im not really sure if theres a way to fix this, though it would be nice it if there was a way without losing efficiency.


Title: Re: APE - A 3d particle engine for GLBasic.
Post by: mentalthink on 2012-Dec-11
Hi for me the demo runs at 26 Fps under paralels7...

Nice Job!!!
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: Marmor on 2012-Dec-11
30 fps , no crash !
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: erico on 2012-Dec-11
60fps  and no ´esc´ crash.

haven´t tried without sync to see how fast it reaches, let me know if you need that info as feedback.

going good!
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: Hemlos on 2012-Dec-11
Excellent, all good news, thanks guys!

A few more things need to get moved over.

The biggest flaw i can see is the alphamode issue, im not even sure how to approach this, anyone have suggestions?

Title: Re: APE - A 3d particle engine for GLBasic.
Post by: mentalthink on 2012-Dec-11
Hemlos for changing the Alphamode I think you have to make some calls to OpenGl directly...
When you use alpha mode from GLbasic, only it's opaque and transparent, don't have interpolation...

Another thing, perhaps works, it's put in the planes textures from Black to White, and using Alphamode... perhaps changing the real color of the particles the interpolation works... Perhaps this don't makes nothing...
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: kanonet on 2012-Dec-12
Maybe try to avoid GLB ALPHAMODE at all and pack all alpha info into the texture? Just an idea, i havent tried it.
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: Hemlos on 2012-Dec-12
ALHAMODE 0 forces off alpha in an image.

Title: Re: APE - A 3d particle engine for GLBasic.
Post by: fuzzy70 on 2012-Dec-12
55 fps & no crash with v3.

:offtopic:
Btw is there anyway you can add the date/time to your site in the downloads area, just makes it easier for me to keep track of when your SVS_Modules has been updated  :good:

Lee
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: Hemlos on 2012-Dec-12
Quote from: fuzzy70 on 2012-Dec-12
Btw is there anyway you can add the date/time to your site in the downloads area, just makes it easier for me to keep track of when your SVS_Modules has been updated  :good:

Lee

Thanks for the continued feedback Lee.

About the SVS modules:
The version i post on my website is the date.
eg.  1.121212 would mean: Version 1, 2012 december 12 was the last update.
Glad someone finds them as useful as me  :booze:
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: fuzzy70 on 2012-Dec-12
I would have tested V3 earlier but sometimes when I click on unread posts from last visit it doesn't show all off them  :S, especially when i'm using tapatalk on my mobile.


I deliberately picked a laptop with AMD cpu & Radeon GFX as my desktop has Intel cpu & NVIDIA GFX so it allows me to test the 2 main platforms & any differences. There is not a lot of difference most of the time but that wasn't the case back when I was coding in Blitz3D as some programs that would MAV on the Nvidia gfx worked flawless on the ATI.

Feel like a noob now not noticing the date in the filename  :-[, The SVS Modules I find awesome from the point of view in what they do & how they are coded, also using the Spell Checker as well.

Keep up the good work mate  :booze:

Lee
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: Hemlos on 2012-Dec-13
Whew! Reimplementing gravity into V3 was a real challenge.
I got gravity and all vectoring to calculate all objects(particles) precisely the same regardless of frame rate.
In the end, the vectoring algorithm remains super efficent and small O(n)

On to the blackholes and explosions! Explosions will be unique in this version, it will be something you define at the beginning of a program, just like any other typical emitter(billboards, cylinders, objects, explosions)




Title: Re: APE - A 3d particle engine for GLBasic.
Post by: Hemlos on 2012-Dec-13
Ok here is the next test sequence..
This is the first test of the explosion emitters.
It is a simple explosion with no outward vectoring..only random movement here.
A triple explosion emitter effect. fire smoke sparks.
Explosions will be triggered with a call to the lib, but its up to the programmer to design the triggering mechanism.
The explosion in this test has a not-so-great coded trigger...this is on purpose, for testing.

The test:
Use this jpg screenshot to compare to what is on your screen.
The arrows should -almost- be touching the fire.
Use left-control button to trigger an explosion.

Test is attached here:
http://www.glbasic.com/forum/index.php?action=dlattach;topic=8790.0;attach=5553

[attachment deleted by admin]
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: fuzzy70 on 2012-Dec-13
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]
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: Hemlos on 2012-Dec-13
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.

Title: Re: APE - A 3d particle engine for GLBasic.
Post by: Hemlos on 2012-Dec-13
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]
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: Hemlos on 2012-Dec-13
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]
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: 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
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: kanonet on 2012-Dec-13
All tests work for me and I could see no problems there.
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: Hemlos on 2012-Dec-14
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.
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: Hemlos on 2012-Dec-14
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
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: Hemlos on 2012-Dec-16
And then there was fixed blackholes  :whistle:

attached:



[attachment deleted by admin]
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: Hemlos on 2012-Dec-17
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]
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: 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?
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]
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: Hemlos on 2012-Dec-17
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.


Title: Re: APE - A 3d particle engine for GLBasic.
Post by: kanonet on 2012-Dec-17
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).
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: Hemlos on 2012-Dec-17
Great idea.
Hows this?

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

Title: Re: APE - A 3d particle engine for GLBasic.
Post by: kanonet on 2012-Dec-17
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.
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: Hemlos on 2012-Dec-17
Its already using milliseconds as a regulator, I said 20 fps, but i meant 50ms(same thing).  :good:

Title: Re: APE - A 3d particle engine for GLBasic.
Post by: fuzzy70 on 2012-Dec-17
On my system there are problems with the regulating/prevention implementation in that it dips below 20fps for 2-3 seconds which is a bit longer then I was expecting. For example drops to 19fps then 13-14fps for a couple of updates before going above 20 again. If I zoom in closer the problem gets worse.

Lee

Title: Re: APE - A 3d particle engine for GLBasic.
Post by: Hemlos on 2012-Dec-18
As expected Lee.
150k particles is EXTREME.
Without the regulator, your game framerate would drop to 0 fps instantly!

The way it works is, it chops off 10% of total count each frame, until it detects minimum designated speed.
eg. if it were 100k particles, this stabilization would happen quicker.
Keep in mind, when you build a game, you should not be depending on the regulator to provide max particles to your end users.
This is simply an emergency cutoff to prevent instantaneous frame locking.

Typically, you wont even use the regulator at all, because using it will create more unneeded computations.
The regulator will be an option you will use as a programmer, in situations where you dont know whats causing a game to lock fps to 0.
That said, its a debugging tool as opposed to a performance feature.

Title: Re: APE - A 3d particle engine for GLBasic.
Post by: Hemlos on 2012-Dec-18

Ok since this is going to end up being a gbal, a better way of doing help file is directly in a separate .gbas file.
This file not only contains help information for all the commands, but also all the actual function calls in the type.
So what you would do with this, is open it in your ide, but not your project source file list.

I rewrote the helpfile knocking out typos.
Also, i added honorable mentions for people who helped with testing, if i forgot anyone let me know.

New help file attached here:



[attachment deleted by admin]
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: Hemlos on 2012-Dec-18
Here is a test of explosion arrays.
I made an array of 20 explosions which each have 3 particle emitters, 100 particles each emitter.
The 3 emitters are flames smoke and embers.

So, that 300 particles for each of the 20 explosion arrays.
Theyre all in an array like this: array[20][3]

Left control to fire one....left shift to fire all of them.

You will notice, these arrays are being recycled.
This is great because many explosions can ingite and no memory will be wasted.
I picked 20 arrays, which may be overkill, you may want more...or less for a game, depends on the game i suppose.


[attachment deleted by admin]
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: fuzzy70 on 2012-Dec-18
All working fine here, explosion sounds odd with left shift being pressed but that's prob due to so many sounds being triggered at once.

Also I assume you are aware that the explosions (both single & multiple) shift to the right (if looking from the starting viewpoint) if the key is pressed again to soon. Only mentioned it just in case  ;)

Lee
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: Hemlos on 2012-Dec-19
ya its just to show 20 arrays of explosions waiting in line to be used, and being recycled, proof of concept.
thanks for the feedback lee
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: kanonet on 2012-Dec-19
I think i found a bug in your arrows, but dont know how to describe it. Maybe ask me about it next time in IRC. Or i need to make a video dont know, will need to think about it.
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: Hemlos on 2012-Dec-19
I know what you mean, its not really a bug per say, but rather a side effect of fluxuations in processing time.
All objects are using time segments to move, to maintain consistancy of distance movement, from one machine to the next.

I already have an averaging algorithm in place for 10 frames.
Do you think its bad enough i need more time segments averaged in?
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: Hemlos on 2012-Dec-20
After putting it aside for a day, i reviewed the code before trying to fix it.
Discovered i forgot to use square time with the gravity duh lol.
Now its sorted out, everything is relative as it should be.
I reduced the explosion array to 10 explosions, this is enough to fluxuate the fps for this test.
They die quick, its enough for a large game too.

The test:
Keep your eyes on the arrows when you test this explosion array, no particles(including arrows) should go off its course when the fps fluxuates.




[attachment deleted by admin]
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: kanonet on 2012-Dec-20
This did fix the problem with arrows, at least i cant see it again.
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: Hemlos on 2013-Jan-04
Be on the lookout for a new test soon.
Ive been studying the science of sorting algorithms to implement a very fast z sorting, as you would guess for better quality of transparencies.
I have a couple hours of studying to do based on the theories of sorting algorithms from my harvardx comp science course, after this ill be able to make some solid descisions for which to do tests with.

In a sense i am reinventing the wheel here.
Why you might ask? Yes, and surely, there is proven sorting methods for great speeds to sort many numbers.
However the reasoning behind the many sorting algorithms out there is due to the fact not all computational systems are alike.

This particle system is not based on fixed computational methods, so using proven methods based on nondynamic computation systems isnt really going to prove to be faster, ie.. merge sorting
The numeric system is an emerging depth order, and i am thinking that bubble sorting might actual prove to be fastest, especially because not all particles are rendered at once.

If my theory here is correct, the sheer speed of big O(<n) will be a great advantage!

Title: Re: APE - A 3d particle engine for GLBasic.
Post by: Hemlos on 2013-Jan-04
big O(<n)

My bad, i meant the sorting time is going to be O(1), which means...Fast!

Ill have this done in the next couple days when i get the time.
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: Hemlos on 2013-Jan-05
No test will be published for the z ordering, afterall.
The z ordering is working perfectly as i expected it to, however, there is no observable difference!

It seems the only thing that really plays a role in the "slicing" of the transparencies (as observed by kanonet) in an earlier test, is alphatesting.

Kano, do you think there is an issue with TSprite here using the glarrays as it were?
Shouldnt the transparencies by additive(accumulatating the colors) when rendered z ordered from back to front? (eg first rendering the particle furthest from cam, to the particle closest to cam being rendered last)

Im finding this system difficult ( if not impossible ) , to truely blend all the colors as expected from any transparent particle emitter.


Title: Re: APE - A 3d particle engine for GLBasic.
Post by: kanonet on 2013-Jan-05
Old version of TSprite used glarrays, new one uses just good old glbegin. There should be no visible difference in both, only speed. Alpha works the same on both.

Alpha is always an issue in opengl there are millions of texts about this in the web, seems like its very hard to get it looking the way you want it. I would say, dont waste to much power on ordering everything - i mean you cant order everything, even if order all your particles, thats still not everything thats inside the game, so other objects would still be out of order. Maybe this is a working compromise: order all particles in each emiter (independently from other emiters) and order all your emiters. In theory this few small lists should get sorted faster than one big list and the result should still look ok in most cases. Just an idea. ;)
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: Hemlos on 2013-Jan-05
Youre right, and thinking along the same lines as i am...

There is almost no difference in speed as far as i can tell.
Its extremely efficient, each emitter has a a list of pointers. Each time a particle is moved, it checks itself against the next one in the list. Thats it, a single distance test per particle.
....a reversed bubble sort is basically merged into the loop.
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: kanonet on 2013-Jan-06
Only a single test? That would mean that you wont sort it properly when the particle needs to get moved more than one position. This means in case you did move it, you need to check it again and again till you dont need to move it anymore. But this means in worst case your sorting would need O(n^2) which is not very efficient (its a form of bubble sort then).
In my opinion it would be more efficient to move all particles 1st and then sort them right before you render everything and maybe use a more efficient sorting algorithm (no sure which would be best in this case).
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: Hemlos on 2013-Jan-06
The emitters are already O(n) to start with. Bubble sorting all particles on each pass...very ineficient and definetly not needed.

In the case the camera moves and particles lives too long(more than a second or two): The quality of the sorting will not be perfect.
These wont even need to be sorted anyhow, chances for a majority of thier life they are no where near the thickest area where the problem exists.

In the case where particles are short lived, this is good enough, and provides higher quality results.

As it is, in all cases: no performance drop, and there is always some chance of quality being increased.
IMO this is a great tradeoff.

Title: Re: APE - A 3d particle engine for GLBasic.
Post by: Hemlos on 2013-Jan-06
This feature only slightly increases quality where alphatesting is looking odd in some situations.
And it can be totally omitted to maintain maximum performance of the emitter.

Edit:
This feature forces the closest particles to the camera to always be rendered last.
Not all particles will benefit in all situations, only the closest to camera are guaranteed sorted in all situations.
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: Hemlos on 2013-Jan-06
Ok test programs are uploaded..

There are 2 version, the campfire is the focus in these tests.
The executables are named sorted and unsorted.
The sorting is done only to the fire and smoke of the campfire.

The explosions in both demos are NOT sorted.



[attachment deleted by admin]
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: mentalthink on 2013-Jan-18
Nice, NIce--- I don't look from today... I only see in the middle of the xplosion the yellow sprite turns very faster...
Sometime Ago I send to MrTatoad a guide for make a particle system in 2D i found in somewhere (sorry I don't have bookmarked), but I think pass this to 3d can be too much complex...

I like a lot, and the last part the little sparkles are very very nice...  :good:
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: SnooPI on 2013-Jul-30
I know the difficulty of 3D development. It is necessary that you stay motivated Hemlos.  :)

It seems that this is a good LIB. I tested a demo some time ago, it was very good (maybe a bit slow) you just need to optimize it.
Maybe using the INLINE function for mathematical calculations.

You have my encouragement Hemlos.  :good:
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: erico on 2013-Jul-30
I have tried some stuff Hemlos did in 3d and also a bit of this lib, it is great work.
I also noticed it has been a while since you are around.

Welcome back. Yep every development is hard. You did a great job so far.
You have my support too Hemlos, and don´t go away for too long! :good:

Maybe we should strike an IRC soon?
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: Hemlos on 2013-Jul-30
thanks for the compliments

snoop, it was a bench test, yes slow, overloaded.
inline might not work on some devices.
however, many improvements have been made, it is really a solid lib now.
I think the lib will be ultra fast and seamless for nay software, typically a game will use a VERY limited amount of particles at any given time...
...you will be able to use hundreds, if not thousands, of these APE particles with very little notice in fps.

thanks erico, im not discouraged, just strapped for time and cant wait any longer to release APE!
i had a prospect for a release in a game with a game maker, but he kinda disappeared and so i will just have to release it without him.
the plan was to release it with a game, showing it off, but i just dont have the time to do one myself.

ill hit IRC on friday as soon as i get out of work (will try my best)
-Love you guys
-Neil
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: erico on 2013-Jul-30
Great Neil!

There are some chaps working on games on the board right now, maybe contact them or they contact you to get a showcase going?
It would be really nice to see it in action that way, I agree! :good:
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: mentalthink on 2013-Jul-30
Hi think Neil put whit a price the Lib it's a good idea.. 3 years it's a lot of time... I think this works or very explaned tutorials,  or another interesting thing have to be a price... The forum it's like a family but I think this contribute to the people make more things and perhaps make very huge GLbasic...

Another example, I think it's very valid for this it's the port of physics Bullet 3D, now don't works but put a good price for this can be very interesting...

Unity it's a good program but another good point it's the huge market, I sell some models, and I have to use it... perhaps GLbasic only have interest in some people for develop code , models 3d, Sprites or sounds... I think open a Market can be very very good for glbasic.
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: SnooPI on 2013-Jul-31
Good idea mentalthink :good:
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: kanonet on 2013-Aug-05
Hemlos are you aiming at mobile devices or only desktop systems with this? My libSPRITE only works with OpenGL (so only on desktop systems) but not with OpenGL ES (so not on mobile devices). But I could create you a version that works on both, desktop and mobiles (only tested android, but all OpenGL ES systems should work). PM me about this issue if needed.
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: Hemlos on 2013-Nov-03
..Back...

I dont know kano, the underlying structure(aka guts) that drives the pixels to the screen is your baby LOL. :P

My plan is still to release open sourced this year.
I want to make a few tweaks, and review the help file for editing.
The code will be "AS IS", i dont plan on changing the code style again.
Christoph, That said, you can take this project and FLY with it.

I do want to make a GUI/EDITOR for this particle system(eta next year?), with a code generator....shouldnt be too time consuming, yet it is an afterthought.
Dont worry though..the help file i created is extensive, almost worthy of a book ( hint hint nik :) )
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: kanonet on 2013-Nov-03
Nice to see that you are working on this again. I updated my libSPRITE several weeks ago, so if you use the current version, android (and propably all other mobile stuff too) is working: www.glbasic.com/forum/index.php?topic=7992.0
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: SnooPI on 2013-Nov-06
Quote from: kanonet on 2013-Nov-03
Nice to see that you are working on this again.

Me too  :)

It's a good news kanonet that libSPRITE became multi-plateform   :good:
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: mentalthink on 2013-Nov-23
Hemlos if you need ideas for this IDE search some video on internet about programs like 3ds Max, Cinema, Blender or another of the "greats"-"expensive" soft, and you can see the way them do the systmem particles and how works.

I always lookinf this program I thinked in a Ide for touch a lot of things, and agree wind, types of wind gravity, and change the sprites...

I think the point, IMHO fail the program it's the image selected for the billboards, perhaps you have to add another way to change the sprites, an idea, for heigth, depend on a single particle it's hegth from the floor changes to anoter sprite animation.


Title: Re: APE - A 3d particle engine for GLBasic.
Post by: Hemlos on 2013-Nov-27
The special effects are very much like 3d studio or any particle system.
@mental
There is not any gui to make ape code for you....you can do that yourself with this system as the backbone.
I think my directional particle algorithm is unique, i dont think 3d studio has that in thier system ;D

You can use this system inside any algorithm you want....thats what makes ape so sweet.

For instance...you remember the bezier lib i wrote in 3d snippets?
That lib includes 3d beziers curves, and you can warp them easily with timers and spinners (sin()cos()).
You can link several ape's to the curves ....like strings of christmas lights....or crazy looking firework strands of fire...blankets of fire swirling around.

Really, the imagination is your limit what you can do with ape.

@kanonet
could you crack open this lib and find your code to see if its multi platform?
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: kanonet on 2013-Nov-27
Thank you for releasing your project, its very nice! :good:

Quote from: Hemlos on 2013-Nov-27@kanonet
could you crack open this lib and find your code to see if its multi platform?
You are using a version of my libs thats almost one year old, I made it multi platform later, in September 2013 so you would need to get a never version to get it working on android etc. Happily this just means you need to replace your copy of my lib with the current one, simple copy+paste (or better add it as separate .gbas files so it could easily get replaced) and slightly alter your lib_APE__Obeject_.Show() (rename billboard.init to billboard.start + maybe add billboard.stop, which is not needed but recommended).
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: Hemlos on 2013-Dec-06
Im glad to hear APE has the possibilty of being multiplatform, thats good news.
Plans for an APE utility program are in the works.
Eventually, I will do an overhaul based on your latest multiplatform billboard controller.
This utility will generate a visually designed particle system, and generate code for GLBasic.

One other thing in the future of APE, is spawnpoint mapping, using vertice data from objects. This allows tou to create object shaped particle spawn points.
I have already done this in the past, but alot of changes were made to GLBasic so I have omited this function for now.
Someday ill reimplement it, i feel this will be important to some game developers.
With the this vertice mapping, you will be able to "write" words that are built out of particles, which was the coolest effect i doing with it.
As a matter of fact, the idea comes from SpriteZ image mapping function, the difference here is you will use an object instead of a bmp.

If anyone has questions about constructing specific special effects, i am more than willing to throw you some ideas to help you make some cool stuff.
Here are generic ideas that ive done with this system over the years:
Bullets, missles(3d and guided with smoke and rocket fire exhausted), water fountains, water falls, snow, snow melting on the ground, lightning, clouds(moving ones), rain falling, rain splash on the ground, explosions(multi layered, smoke and debris and fire), explosion spall, glass shattering, steam, tornados! , black hole(part of APE is gravitation energy, both positive and negative), fireworks, fireballs, arrow storms, bugs crawling on the ground, bugs swarming.

Title: Re: APE - A 3d particle engine for GLBasic.
Post by: Hemlos on 2015-Mar-13
Does anyone still use this particle engine for anything?
Or is the code out of date for the modern GLBasic?
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: kanonet on 2015-Mar-16
I dont see any reason why it should be outdated.
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: erico on 2015-Mar-16
Me either, it is just I haven´t tackled 3d yet.
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: Hemlos on 2015-May-31
actually 3d isnt that hard.

just need to get the camera where you want it.

a game in 2d could be converted to 3d....3d is 2d with a height map in 2d/3d games.
heights can be assigned in the player types, monster types, object types etc

What APE needs is a game, based on the PE itself, something simple and fun.
wish i had the time, i dont.
Title: Re: APE - A 3d particle engine for GLBasic.
Post by: Hemlos on 2015-Aug-11
Quote from: Hemlos on 2015-May-31
What APE needs is a game, based on the PE itself, something simple and fun.
wish i had the time, i dont.

Ok i made time...and i have been working with APE in a new game test environment.

APE is coming along great, and i think i finally got the math 100%....check screeny..
ps. ill be starting a new beta thread soon with the current project.

and i will update APE here in this thread when im certain its corrected.

Right now, using kanonets libTsprite, i can run 50k skinned particles, smoothly, and accurately.
Blackholes effect is working, perfect, and all the other features ape has is working too.

The timers seem 100% now, and all motion is smooth and logically calculated.

The goal for this is to make the inputs 100% logical to allow the programmer to calculate how the output should look 100% as expected.

Ive made ALOT of progress, and the entire library has been revamped....its faster, smaller, OOP, and just amazing looking.