Shell ejection, framerate down

O

Old Rob

New member
During my tests I run into massive trouble with the framerate while agent was firing.
Lastly I could point it to rifle ejecting shells. It is the same if agent, or me, is shooting.
A few shots will do more or less nothing, but firing a lot bullets, as the agent does, let the framerate drop near zero. Uncool.
I played around with all shell settings, lifetime, duration and layers, but I had no good result.
Only way is to disable eject shells at AssaultRifle Item (shell set to none) and the framerate will be stable even I fire the complete magazin content in row.

So, I don't believe that this is the correct behavior which I can see here with the shells, I must overlook some thing(s) here.
Any hint?
 
Have you profiled your project to narrow down the issue? It sounds like this could be related to instantiating new objects and on the Object Pool component you can prepool a number of objects which will help in this situation.
 
Sorry, I'm not sure if I understand right.
If,
I used under Game => Object Pool
several values for the Object Shell.
There is no difference if I enter 50, 100, 500, 1000.
While the mag contains ~50 bullets and there is for test, the player rifle only, I think 50 should be enough.
If this was what you meant by prepool, yes I did.
I just tested the Demo scene again, there is no problem sightable with a value of 50 shells inside pool and framerate. I must have missed something while comparing my settings with the demo.
If I didn't translated "have you profiled..." correct please help me ahead with the meaning.
On the other hand I'll compare with demo once more again, may be I can find something _this_ time...
 
Thank you very much for pointing this to me. I never had a look to profiler up to now.
Well, that's again one new thing which I have to learn from 0 to 100 in short time :)
I could mange to show the timescale while shooting the mag empty.
I made a screenshot from which I thought that this is the main point to look for.
If I'm right, it tells me that here could be the problem, but I can't see what it will really tell me now.
Assumed my problem is really correct localized by me now, Shell.FixedUpdate(), ok, but what can I do with that info, where to look now?
Could you please have a look to the screenshot and comment it?
 

Attachments

  • Profiler.jpg
    Profiler.jpg
    60 KB · Views: 6
If you view the profiler in "hierarchy" mode (bottom-left dropdown) then you can get an actual callstack of where the issue's coming from. Enabling "Deep Profile" is a good idea too, to get more precise info. It's coming from Shell.FixedUpdate, so it may be something weird with the shell's trajectory or even some kind of pooling thing (trying to pool/destroy but can't).

You've added the shell prefab to the object pool prefab list, right?
 
Yes, I did. And I can see that the shell(Clones) are removed from the hierachy after a short time.
Shorten the lifetimes will not help too.
I choosed the Oposive shell prefab but during my tests I used different shell prefabs, with same result.
I compared the settings a few times now but I can't find the problem.
I can just tell that the framerate problem is away if I choose no shell to eject.
Only thing I can do in the moment is to start a new project and see if the problem would be away.
Not really what I like to do, would be much better to be able to hunt that devil down ;)
Thank you for your help, any ideas are still welcome.
 

Attachments

  • ObjectPool.jpg
    ObjectPool.jpg
    100.1 KB · Views: 7
  • infos.jpg
    infos.jpg
    166.6 KB · Views: 7
It looks like you've got "Auto Sync Transforms" enabled in your project's physics settings? If so, disable it and test again.
 
Yes, that was ticked. Unchecked it but no success.
But it forced me to compare all the settings again, but no success.
Last thing was a new project and all went well this time, stable framerate.
Finally I saw a difference now, oh oh, it was Game -> Surface Manager!
I had ticked the Detect Terrain Tree Textures. Unchecking it and all works, the framerate is near stable now.
Don't ask me why I ticked that point, and why I should have come to the idea, that surface manager interact with the shell before.
Ok, now I know this very well ;)
Again thx for your help and patience!
 

Attachments

  • Problem solved.jpg
    Problem solved.jpg
    63.1 KB · Views: 2
You must log in or register to reply here.
Top