Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / Another 3D particles bug

Author
Message
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 12th Sep 2019 21:51
Seems to be another issue with 3D particles.

If you change the attributes of them multiple times, they frame rate drops more and more, almost as if changing the setting is creating new particles.

Can't really extract code to show just this, but it's in my particle editor - if I drop a particle the frame rate is about 140. If I then set the frequency of that particle lots of times (for example setting it in an interface), the frame rate drops to about 70....with NO OTHER CHANGES OR CAMERA MOVEMENTS.

This pretty much seems to be the jist with any setting.
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 12th Sep 2019 21:53 Edited at: 12th Sep 2019 22:36
Oh, and I should point out, this applies to increasing AND lowering the frequency. So, starting with a frequency of say 3.0, then dropping it in 0.05 incriments to 0.03.....still reduces the frame rate from 140 odds to 60 odds.

When that should DEF make it faster.

And, I tried erasing the particle and setting it up fresh every time, same effect.

EDIT: I can also confirm that AppGameKit doesn't seem to be creating new particles, but even tnruning them off, making the change, then turning on doesn't work.

EDIT2: And actually, it mainly seems to be reducing the frequency that's the problem.....I can increase it from 1.0 to 10.0 without almost zero frame rate it, but then reducing it to 0.05 brings the frame rate down to 70. Putting it back up doesn't fix the issue and then makes it worse.

PSY
Developer
8
Years of Service
User Offline
Joined: 3rd Jul 2016
Location: Laniakea Supercluster
Posted: 12th Sep 2019 23:16
Cannot confirm.
Changed the frequency of a particle emitter from 100 to 0 in steps of 0.05 every 50 milliseconds...framerate was constantly rising.
I noted the framerate at a frequency of 100, 90, 80 and so on down to 0.
When the frequency hit 0, it was reset to 100.
Wrote down the framerates at 100, 90, 80.....and so on down to 0 again.
No difference.


PSY LABS Games
Coders don't die, they just gosub without return
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 13th Sep 2019 00:31
I'll record a video of it tomorrow.
PSY
Developer
8
Years of Service
User Offline
Joined: 3rd Jul 2016
Location: Laniakea Supercluster
Posted: 13th Sep 2019 01:43
You probably got me wrong
I do believe you. But I couldn't reproduce the issue by altering the frequency, even 20 times per second.
I think the reason for the slow down must be somewhere else.





PSY LABS Games
Coders don't die, they just gosub without return
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 13th Sep 2019 08:04
Hahaha.....no, I wasnt taking it that way. But everything is working absolutely fine, until I added the control to change the settings, then the frame rate plummets. Even sitting still with the frequency at 0 (so it's not even generating any particles) doesn't fix the frame rate.
PSY
Developer
8
Years of Service
User Offline
Joined: 3rd Jul 2016
Location: Laniakea Supercluster
Posted: 13th Sep 2019 11:45
OK
Yeah, that really seems weird
Is it possible to strip down your code to just some basic framework which still has the bug, so I can run it on my machine?


PSY LABS Games
Coders don't die, they just gosub without return
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 13th Sep 2019 17:45
I'm gonna try tonight, but the code isn't doing anything in between. The only thing I can think is the particle is refreshed in a separate function, but that should make the difference either.

Will see how I get on later.
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 13th Sep 2019 21:20
So here's a demo, just particles, nothing else - same issue.

When it runs on my system, it measures the average screen FPS at 1350.

This then sits and runs in a stable fashion. Then hold in "2" to increase the frequency to 700+, then decrease it using "1" to zero.....even after the particles stop the FPS sits between 950 and 1000......a drop of nearly 400 fps.

This is just one particle....imagine it with several. The efect can still be seen by just alternatively changing the particle up and down a lot of times.

Will be very curious to see if anyone else is getting this issue.

Attachments

Login to view attachments
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 13th Sep 2019 21:37 Edited at: 13th Sep 2019 21:40
And for completness, here's a simple video showing the error happening in a real world test. You can see the frame rate tanks for literally no reason what so ever just by adjusting the frequency.

I've tried, setting it inactive then active again, changing the max to 1 then updating for a second and setting it back to unlimited.....never any joy.

It's kind of like it keeps updating the maximum number of particles regardless of whether they are still generating or not. I.e. if you set the life at 100, and the frquency at 50, then the maximum is 100*50 = 5000. If you then drop it, it's as if in the background AppGameKit is still trying to update 5000 particles. That's probably not the case, but there's def something odd happening here.

EDIT: also, note that massively increasing the particles doesn;t slow it much....it's reducing them again.

Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 13th Sep 2019 22:01 Edited at: 13th Sep 2019 22:04
Ah ha.....

I kept playing with the attached example....if you set the life to 1, the problem vanishes. If you set it to 5000, it;s much, much worse. So the issue seems to lie with the life setting. It would seem anything up to about 20 seconds works ok, but after that the longer the life, worse the slow down is.

So I guess this makes sort of sense, as the number of particles is the life*the frequency.

However, if you reduce the frequency to zero, then the max number of particles should be....well, zero. And it seems you can leave the code running a lot longer than the life cycle and the frame rate never recovers.

If you add this code:


then it should force the particles emiter to reset the maximum, but that doesn't fix it. In fact, you can erase the particle completely and create it again, problem is still there. So if I had to guess, when you reduce the particle frequency or life that results in a smaller maximum, the already produced particles that fall outwith that range stay??? I dunno - over to the community and Paul now I guess.
PSY
Developer
8
Years of Service
User Offline
Joined: 3rd Jul 2016
Location: Laniakea Supercluster
Posted: 13th Sep 2019 23:37 Edited at: 13th Sep 2019 23:38
Tested your code, still cannot confirm.

At a frequency of 100, the code runs at around 3000fps on my system.
You set the particle life to 60, which means each particle lives for 60 seconds.
I boosted the frequency to around 4000 and waited until the fps dropped to around 1500.
Then I began to decrease the frequency to 0.
After hitting 0, it took exactly 60 seconds to get my fps back to around 3000 ( after 60 seconds, all particles must have died )


I also watched the video.
Although the fps at the end are lower than at the beginning, that doesn't mean anything, because there may be particles alive outside your visible screen.
It depends on the particle life time.
Display the particle life time with print ( Get3DParticlesLife( ID ) ), wait for that time ( after you set the frequency to 0 ), and see if the FPS still don't come back


PSY


PSY LABS Games
Coders don't die, they just gosub without return
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 14th Sep 2019 00:09
Hmmm, that's odd. But, even if you change the code and literally delete the particle and recreate it, for me the frame rate stays the same. The help explicitly says this should delete all particles. It doesn't appear to.

Very strange.
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 14th Sep 2019 00:09
Have you an NVidia card?
PSY
Developer
8
Years of Service
User Offline
Joined: 3rd Jul 2016
Location: Laniakea Supercluster
Posted: 14th Sep 2019 04:09
Win10 PRO 64bit
NVidia 970 GTX
I7-2600k


PSY LABS Games
Coders don't die, they just gosub without return
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 14th Sep 2019 11:10 Edited at: 14th Sep 2019 11:13
That GPU usage is really interesting. I wonder what it is if a program sits and does nothing? With sync rate set to as fast as possible, that's probably right.

I thought of a possible fix last night though, I will try it later

Psy.....for info btw, in the game you can move the camera, and there are no particles off screen rendering.
PSY
Developer
8
Years of Service
User Offline
Joined: 3rd Jul 2016
Location: Laniakea Supercluster
Posted: 14th Sep 2019 12:37
Does SetSyncRate ( 0, 1 ) make any difference ?


PSY LABS Games
Coders don't die, they just gosub without return
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 14th Sep 2019 14:53
OK, so I took another video, this time paying close attention to task manager.

It's very interesting. Without aprticles, the GPU usage is nearly at 100%, as it normally is. CPU hits about 30%, as it normally does.

So I shift the partciles frequency all th way to 10, then down again....CPU largely statys consistent, but GPU performance HALVES even with zero particles on screen.

I turned on a texture and pulled back so you can see the particles expire, proving that it;s not just drawing some off screen. Note, between each cnage the following code is called:



This essentially advances the changes so that the new effect can be seen instantly, but turning this part off makes no difference.

It very much seems like there's some form of bottle neck in the pipeline when you alter particles attributes; either in the CPU passing data to the GPU (hard to tell since AppGameKit only uses one thread), or the GPU is getting clogged with junk from the instancing.

I guess this isn't really too important as they work ok if they are defined one time and then set (apart from the transparency issues I noted in my other thread), but I do wonder what the longer term effect of even starting and stopping particles over time would be.

I can't reallt demonstrate the issue any more clearly now - Paul will have to come in and say if this is unexpected behaviour or not I think now. Unfortunately my project still doesn't work in Studio, so I can say if it's got the same issue or not but I assume it will if it is the same AppGameKit code.

Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 14th Sep 2019 14:59 Edited at: 14th Sep 2019 15:01
Nope, sync rate doesn't impact it.

Also, I have an AMD CPU with a 1080 GTX, so we both have similar hardware.

I repeated it again and again, and the GPU kept dropping down, right down to it bottoming out at 39% utilisation....CPU didn't noticably change.
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 14th Sep 2019 20:33 Edited at: 14th Sep 2019 20:34
It's 100% definetly only when reducing any value which impacts the life of a particle.

EDIT: and that includes if you physically delte the partilce, then recreate it and set the value every single time. Must be some form of memory leak.
PSY
Developer
8
Years of Service
User Offline
Joined: 3rd Jul 2016
Location: Laniakea Supercluster
Posted: 14th Sep 2019 22:58 Edited at: 14th Sep 2019 22:58
Hey Santman,

I made a final test I'd like you to try. All others are welcome, too
The code basically waits for about 15 seconds to allow any overlay to kick in and vanish ( like Gforce Experience ), so the FPS are accurate.
After 5 more seconds, it memorizes the fps at that point of time, and starts emitting particles.
The font colour should turn to green now, which means you can delete ALL particles now by pressing A.
After pressing A, the CUR FPS should return to a value close to the MAX FPS.


Please let the code run for about 40-60 seconds before you press A.




PSY


PSY LABS Games
Coders don't die, they just gosub without return
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 15th Sep 2019 15:10
I genuinly think I'm cracking up....

Last night I continued to add more controls and the problem just randomly vanished. I literally cannot recreate the issue I captured in the video over the previous two days. The only thing I changed was adding in velocity range controls that weren;t there before, but taking them out again doesn;t fix it. I can only assume something was going on in a background process or something which finished. It seems unlikely as the problem was only compounded through multiple runs as I showed....but I dont know what else to say.
PSY
Developer
8
Years of Service
User Offline
Joined: 3rd Jul 2016
Location: Laniakea Supercluster
Posted: 15th Sep 2019 15:21
Dude....
Stay out of the Twilight Zone
Seriously



PSY LABS Games
Coders don't die, they just gosub without return
Santman
13
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 15th Sep 2019 15:46
Lol....tell me about it! If I hadn;t recorded the videos I'd think I was imaging it!!
PSY
Developer
8
Years of Service
User Offline
Joined: 3rd Jul 2016
Location: Laniakea Supercluster
Posted: 15th Sep 2019 21:51
Maybe some day, you'll find the origin of that phenomenon


PSY LABS Games
Coders don't die, they just gosub without return

Login to post a reply

Server time is: 2024-11-26 01:03:47
Your offset time is: 2024-11-26 01:03:47