Ambiera ForumDiscussions, Help and Support. |
|
| [ 1 2 ] Page 1 of 2 |
|
|||||
|
Trying to finalize the first level, I tried adding enemies. What I did not expect, however, was that the performance will seriously drop just because the enemies are present. I tried spawning them without AI and collision, with no animation, with no hitboxes, performance is still bad. It is supposed to be 60 FPS (due to the limitation I've set), and it is 60 FPS without enemies. But just adding them made FPS drop from 60 to 40-35. Right now, I've only tested this with one model, but all three models are almost the same. The one I am using right now is made out of 33 971 verticies (17 572 triangles). I heard that Coppercube can't handle lots of verticies very well, but the example I saw was a highly detailed scene with I don't remember how many verticies. There are 13 enemies in total for now. FPS starts to drop when there's more than ONE. Here are the results for 1 to 4 enemies: 1 enemy - 59-60 FPS; 2 enemies - 56-57 FPS; 3 enemies - 54-55 FPS; 4 enemies - 52 FPS. Can it be due to multiple materials being used, or because of all the objects on scene (there aren't many of them actualy)? |
||||
|
Do you have dynamic shadows enabled? - this is a huge performance killer. Also is it the same for directx and opengl? Do you have both discrete/integrated graphic cards? - in that case you need to check you're running your game on the discrete one. Do you have some other behavior/actions/scripts you're running in the scene? - if so you can measure their execution time to see if something is not optimal. From my experience raycasting and built-in actor behavior are both huge performance killers. I usually develop with 200 fps cap to make sure my actions do not affect performance - adding 3 raycasts inside same onAnimate function usually drops fps to ~180 for me. Aslo adding 10-15 enemies with default actor behavior drops fps drastically (I believe, to around 120). You can try removing all game logic, i.e. all actions/behaviors and see if you also get low performance. Also, how much is multiple materials? Is it 4 per model or lets say 30? I don't think polygon count is big enough to cause issues, but have you tried to test the game with other models with lower polygon count? |
||||
|
Dynamic shadows are disabled. Switching from DirectX to OpenGL doesn't seem to do anything. Like, nothing, everything looks and works the same way, even FPS count. I am not sure about this graphic card thing, I think I only have a discrete one. And, now... Well, I just tried to remove one thing that the game needs the most, and from 46 FPS (7 enemies), it skyrocketed to 100+. And that thing is... character controller. And that might be problematic. Deleting behaviors from all buttons and doors just gives about 10 additional FPS. Same with enemy AI, which is quite strange to me. I do not use standart actor behavior. I used to do so, but it was really bad for the game - enemies were hilariously stupid. Multiple materials is, actually, just 2. In conclusion... I believe, I have to rewrite the whole character controller? That's quite terrible, but it seems like there is no other way around... Edit: I forgot to ask, how bad is it when character controller destroys about 50% of performance?
|
||||
|
What kind of character controller do you use? Can you post its code? |
||||
|
Uh... I don't really know if I can... But whatever, I already know it is terrible, so... https://disk.yandex.ru/d/Ymb-qZu... Yeah... It's too big to post here, it doesn't fit in 8192 characters limit. So, yeah, if you want to see the most obscure coding crime that I have made, here you go. Proceed with extreme caution |
||||
|
It's fine, I've seen worse:) I believe, it's because you're using ccbGetCollisionPointOfWorldWithLine for collision a lot. As I mentioned in the original answer raycasting is very performance intensive in coppercube, On line 218 you have a loop, inside which there are two more nested loops. I believe, if you want to optimize your extension, you need to optimize that part. I'm sorry, but I can't tell how it can be done practically. But, probably, quickest and dirtiest thing to try is making it less precise by changing 9 steps to 5, like for (let i =0; i <= 9; i += 2). But obviously, you need to try that, since I'm not sure how it works in-game. Are you using physics engine or only distance check? In case it's distance check only, you can probably try achieving decent collision by using multiple sphere colliders. Even if it's not that precise, it would be at least better performance wise. |
||||
|
Huh, so that's what you've meant by raycasting. I thought about shooting at first. You were right, I changed amount of vertical steps, thus reducing amount of raycasts from... About 72 or more (I only counted top loops, so, 9 * 8 = 72) to 40, and it gave me additional 30 FPS! Perhaps, if I will make this a bit lower, it will be greater. Thanks for that, okeoke! About the physics engine - I only use distance check, because physics engine was working quite awkwardly. But I do not plan to use just multiple sphere colliders since they don't work good. I know that because once I made a window on a level, and my character could easily go through it. So, I use this... "Monstrocity" of a collision check to work kind of like a BEAN collider. Kind of. And, on behalf of extension optimization, I used loops just for that. I don't exactly remember why I made this, just like with... 50% of my extensions? But it has to do something with collision check, that's for certain. Not that I really understand how it works by now... Addition: Seems like I also went a little wild with trying to remove certain behaviors and actions before - some parts of the game just stopped functioning. At least it's not done with only built-in actions and behaviors like in older wersions of my game, so, maybe it's just a quick fix.
|
||||
|
I wrote an alternative Linepick for Copperlicht a while ago. It first reads all triangles of the scene into a simple list. the list also contains a field storing the node each triangle is part of. This way the script can parse the geometry without any tree structure losses, making the code streamlined for the JS JIT compiler with its optimized assembler bits. The code also contains a working, fast Ray-In-Triangle function, based on the industral standard (still I guess). Just if somebody is interested. https://jfkeo1010etc.itch.io/alternative-linepick-for-copperlichtjs |
||||
|
Some new findings here: apparently, just editing character controller to use less collision was not enough. Sure, even 9 enemies is not leading to FPS being around 45 or so. Now it is about 70-75. Thing is, that's obviously not enough enemies, at least for a shooter game. What's more interesting is that without hitboxes, FPS actually went to 110-111, which is much better... except the fact that I can no longer hit enemies, since they have no hitboxes. Funny thing is, even removing AI is not boosting FPS that much. There are 16 hitboxes on every character, so, I believe all the movement of attached nodes takes quite some power. What do I do with this? |
||||
|
You could try keeping the hitboxes invisible, except for the moment the player shoots a bullet. Maybe also use a single hitbox first, and in case of impact, unhide the 16 other hitboxes and do the test again. Probably even hide anything hit-able, other than these 16 hitboxes, temporarily. |
||||
|
No, this does not work Dieter. Hiding all the hitboxes or their folders (joint folders) had no effect on performance at all. I believe that the solution might be more complicated... I think about making a separated "dummy" character with the same skeleton and attaching hitboxes on it, spawning it when a bullet collides with character's bounding box, thus reducing amount of hitboxes (that is, of course, if you wouldn't shoot multiple enemies in a row, though I don't have any weapon in my game with ability to shoot through that many enemies). It could also help with the fact that I have several character models with identical animations, so, changing animations on "dummy" character will allow me to not update animations on each character. However, I am not exactly sure wether it will make things even worse. You know, copying animations from one node to another might be problematic, but, hey, I still never tried out this new "ccbSetAnimationFromSceneNode" command, so I have no idea about that. |
||||
|
Hi there, @Dekon_17, as others already suggested you are using so many collision thing, and that too in a nested "For Loop", Collision API affects the performance drastically, it also matters where you write it in your code. When I was using the same Collision API within one of my 2D top down shooter behavior, I was having some sort of similar issue of frame dropping, what I did to fix the issue was moved my collision api to the last of the onAnimate function and it fixed the issue for me. Maybe you should try this and check if it fixes your issue or not. Also, I recommend you to avoid using Collision detection API if it is killing the performance, if you really need to detect collision, then you can try proximity based detection, Also for hitboxes, you can try using my proximity behavior, and can use it as hitboxes, for detecting bullet hits or melle attacks it will much easier to use and won't be resource heavy, I think. It allows you to check direction as well, download the extension for free from here https://vazahat.github.io/ccb_be... Also if you want to stick to the linepick then I suggest you to use the inbuilt shoot action, to fire an invisible bullet continuously and check it that hit the desired target, it is a much better way to check collision, though it also uses the same mechanism, but it won't affect the performance. there are many non-coders in the community that uses shoot action for collision detection. @VP might be able to provide you a better example on how to detect collision with shoot action. I strongly beleive if there are no other behaviors and stuff that checks for the children of nodes and other stuff, your hitboxes are fine, and should not affect the performance, there might be something the scripts are doing, maybe they are checking the hitboxes for collision and other stuff as well, so let say if you have 16 hitboxes per enemey, and you have at least 8 enemies, then it is 128 checks, and you are running collision API in a forloop, and for all the 128 checks, though I am not sure if it is actually checking the animated joints or not am just guessing, it is definately resource heavy. Try removing the collision API, or move it to the last, or check the other method provided by other users like @Dieter suggested custom raycasting or inbuilt shoot mechanism. |
||||
|
You can also try spawn/despawn groups of enemies as player hits a trigger, so you don't have more than 10 enemies in-game at the same time. If player moves from one part of your level to another - save information about enemies in that location into an array. Use same data structure to spawn enemies in second location. You can also add another trigger which does the same if use moves from location 2 to location 1. You can also store the ID of current location as a variable so it's easier to track. Or you can set fps cap to 30, change Coppercube starting logo to UE5 and say its a cinematic console experience in your game description. Coppercube is sort of really annoying than you have to make collision detection, AI, or pathfinding. it feels like there is not enough tools to do it properly. Every implementation I came up recently either don't work as expected or works too slow:) |
||||
|
Well, I am not sure if any behaviors actually check hitbox collision. They (hitboxes) are only used when a bullet out of only player's weapons collides with bounding box of an enemy, then the script for bullet looks if it collides with bounding box of a hitbox. But, well, I believe you know more about this engine than I do, so, I might check that. For collision, well, as I said, I have reduced amount of those raycasts significantly, which actually led to a better performance. Though I cannot put all the collision part in the bottom of the script, or so I think at least. Thing is, collision should affect movement in real time, not with a frame of delay. That's also the reason I cannot use Coppercube's shooting for collision, since it has no connection with character controller, so, that might give me more trouble. On the part of using someone's API's, I really don't know about that, I'm trying to use as much of my own stuff in my game as I can (in fact, all the scripts, models and, if I wouldn't forget ro remove any Coppercube placeholders, textures were made by me. Of course, not without a help from people, which made all that possible). And, also, I am not sure wether I will be able to fully learn and understand them (API's). You know, spending more time learning a new thing might result in another burnout at the time I will understand the damn thing, and I wasted too much time already... More than 2 years. |
||||
|
I wasn't aware there's a third party collision api involved - is it? So my advice was meant for a scenario in which you do either CC linepicks, or CC camerapicks. As these don't work if a mesh is hidden, yet collision still works, if checked on, hiding should speed up any linepick. So if 16 boxes have collision off, and visibility most of the time off, they should not have a huge impact on the framerate. But maybe you should compare the NPCs when animated, to non-animated, to see whether the translation in position and rotation of the boxes is the cpu hugger, or that of the animation to begin with. But also keep in mind, most engines or games are using tricks to have more than 10 fully animated characters onscreen. NPCs in a FPS are not the same as those in isometric or topdown shooters. Depending on Genre, you can activate and deactivate NPCs, in respect to whether they can actually be seen. Another aspect is: use the compiled parts, avoid complex javascripts. Naturally, the interpreted scripts are slower. So if the target is DirectX and there's embed collision or linepick in CC, use that, rather than too much javascript. |
||||
| [ 1 2 ] Page 1 of 2 |
|
|
){kind=link}