Ambiera ForumDiscussions, Help and Support. |
|
|
|||||
|
Performance without considering texture sizes and stuff. Has anyone here already reached what number of polygons and how much FPS? today I made a scene with more than 2,200,000 polygons and the frame dropped to 24 and returned to 50 it stayed between 50 and 54. Has anyone done a similar test? |
||||
|
Does anyone know if I have many in proximity does something. Will this interfere with game performance? |
||||
|
Yes, I did a video on this topic a while back: https://www.youtube.com/watch?v=iuAXH70ZXfg 2.2 mill polys @ 50 FPS - really ? , thats impressive for CopperCube - did you have lots of separate objects that were culled off screen (out of the frustrum) or was it a single combined mesh ? I did a Sponza demo with 3.7 million polys and got 10 FPS with not using mesh collisions (floor collider only) - see here: https://www.youtube.com/watch?v=UYBaDYTTKuI |
||||
|
An easy test is to import your model to a scene and add your "on proximity commands to it), then use every 100ms: clone node, set variable "nodes" +1, update 2d overlay "$nodes$". Then run the app. It will add a new node every 100ms until your scene overload/crashes. This way, you can see the direct impact of scaling your textures, on-proximity, lighting etc. Main thing that impacts performance is real-time shadows, collision and rotate-action. Poly count and texture size, how many calls per second there are for anything are also large factors - whether it be on-proximity, drawing textures, moving polygons, changing variables, number of materials, character behaviours etc. One tip: do not use folders to keep your projects neat, they cripple performance. Main thing that kills my games is adding many AI animated characters to the scene or many items (such as coins) which rotate with dynamic lighting. Main thing that optimises my scenes - turn off real-time shadows, bake lighting into the textures, turn off mesh collision on large polycount models and make a low-poly collision mesh instead (using cubes and other primitive shapes). Reduce texture sizes and overall number of textures wherever possible. Use static lighting instead of dynamic. Use high-detailed normal mapped textures instead of high poly detailed 3D models. Use obj format for static objects instead of fbx - some fbx models can trash performance. |
||||
|
@VP What folders do you mean exactly? Folder nodes in the editor or folders for resources outside the editor? I can't seem to notice any performance issue with either besides playing sounds which can cause a framerate drop if you don't play them once before without volume--at least that is how I fixed that issue. |
||||
|
Hi Guest yeah, it does seem strange that folders in the editor might affect performance in any way. When I was making "the watchmakers frog" for the game jam, very early on in the build (there were actually only a few things in the scene), the game suddenly became really jerky and laggy when I placed certain nodes into a folder-nodes on the scene graph editor (just a habit to keep everything neat). I thought it was unusual that performance was affected by such a basic scene - while I was experimenting with it, I dragged the node back out of the folder and tested again - it was really smooth and not laggy at all. I would say there was over 50% drop in performance simply from a single folder-node. I then went back and tested various abandoned projects from the past with same improvement when removing nodes from folders. I reported it to the bugs section of the forum - (near the bottom of the thread....[url]https://www.ambiera.com/forum.php?t=11339[url]. Apparently, the folder node acts as a parent-node; so dropping scripts/actions/animated-nodes/static-meshes into a folder may be multiplying all the number of calculations/calls per-cycle exponentially. It's possible that it may not affect everyone, depending on their work-flow. I always use "every few seconds" and "If Variable?" to control events using loops, attached to the nodes. I also use "animated joint" nodes on models to attach other nodes as parent/children - so these may be the main culprit when using folder-nodes in the editor - if there are no "every few seconds" used and no child nodes in the scene, using folder-nodes probably wouldn't affect performance at all, but I'd need to do more testing to be 100% sure. I guess it needs more investigation, but I can state with full confidence that using folders caused a massive performance drops under certain circumstances for me. Since then, I'm afraid to use folder-nodes at all - I just leave it messy instead. I have to go to a wedding today but when I get back this evening, I'll see if I can recreate the issue using a small test-scene - I'll aim to upload 2 identical ccd files as a quick demo for you so you can see the performance difference - one using folder, the other without. |
||||
|
Here's a link to the 2files to demonstrate the issue - both exactly the same but one uses a folder, the other is without folders. Let me know what you think. "Fast" has all the actions attached directly to the child node (no folders). "Slow" is exactly the same file but the actions are attached to a folder-node instead. When using a folder, the game (for me_becomes very choppy and slow, (50% fps drop) - whereas without the folder, it's fast and smooth with no noticeable choppiness or slowdown. The only difference between the two ccb files is that "fast.ccb" is using a child node for the actions, "Slow.ccb" is is using a folder for the actions. While experimenting, I noticed the following workarounds: 1- Using no folders keeps the game smooth and fast. 2- Dragging the nodes out of the folders, speeds it back up again (even if you then leave the empty folders in the scene). 3- If you use an empty folder to house the actions, it's fast too but as soon as you add a node to the folder, it slows back down again. https://drive.google.com/file/d/... ....another example is using the "rotate" action. If you have a folder with several nodes inside it using "rotate", it will start to run choppy/jerky or not rotate at all. Now, if you have the exact same nodes running outside of the folder, it runs fine - you can keep adding more and more nodes and it will still work - as soon as you move them into a folder, they will stop working. |
||||
|
Okay I looked at your examples. There is a noticeable difference between the two. The issue seems to me that the folder node isn't meant to be used like that because it doesn't have the same properties of a regular "empty" node. Hence why the rotation stutters so much. For anything transform-related (positioning, rotating, etc) one should certainly use an empty node. Folder nodes are for organizing static meshes so that one could take all the trees in their level and make them invisible in one click instead of having to go about doing it for each one. So I guess think of it like: dynamic/empty node, static/folder node. Thanks for the example, VP. |
||||
|
@VP, it is not related to folders, I don't know what's the reason, but even if you remove the folder node, and simply make your 07_1 the last node in your scene, then it will also make the game slow down, even if you delete the folder node, so it may be the model itself or the order of node in the scenegraph explorer that is causing the slow down, though the game is slow still the FPS is 63+ for me. Maybe it is the way you set up the actions and behaviors that are causing the speed to slow down. I am unable to debug this properly, and as this is not related to the folder node, we can't really confirm if folder nodes cause any frame drop or slow down to the game, I have used folder nodes in many of my projects and they never affected the game. folder nodes are in itself empty nodes, internally Coppercube has 2 types of dummy nodes, one simple dummy node, and another one is a dummy node with transformation, so folder nodes may be the simple dummy nodes, and have no transformation data. So yeah, applying rotation and other properties to the folder nodes, will not work and won't affect the children of that folder nodes, if you want transformation then yeah, empty nodes with transformation data are much better. |
||||
|
Thanks for checking just_in_case. Yes, you're correct, it looks like it's not just specific just to folder-nodes, it happens with any node acting as a parent. Adding/Removing parent-nodes also affected performance of other projects of mine - (player movement in the T2 game)- so it could just be my crazy none-code way of doing things that's not really suitable for coppercube. It should be relatively easy for me to debug, seeing as the problem is re-creatable just by introducing a single folder/parent-node. I'll start by swapping the mesh for a simple coppercube primative to see if it still happens and see if I can deduce why it's happening. Thanks. |
||||
|
Recreating the problem, won't show the actual cause of the problem, when I tested I removed every children, and all the objects are on their own, none of them is children to any of the node, yet still the performance was slow. So it is not easy to debug what is causing the issue. |
||||
|
Yes, it's a confusing/difficult problem. When you compare the two files, the "fast.ccb" runs fine, the "slow.ccb" (which is exactly the same scene but with an extra folder) is much slower/choppier performance. If it's not the folder/parent-node that's directly causing the problem, it's probably my method or a faulty model or something. No worries, thanks. |
||||
|
btw, I have sent you free key to the 2D animation scripts pack, with the updated plugin. Check your discord DM to see the message with the link to the animations script pack. Hope the updated plugin works better than the previous version. Will update the action and behavior as well very soon. |
||||
|
Oh wow - thank you! I don't have access to discord but I bought the pack through itch.io, so I can probably download it from there. Really looking forward to the new features. I'll make a donation when I get paid -nice one []bjust_in_case[/b]. Really appreciate this! |
||||
|
Robbo wrote: Yes, I did a video on this topic a while back: https://www.youtube.com/watch?v=iuAXH70ZXfg 2.2 mill polys @ 50 FPS - really ? , thats impressive for CopperCube - did you have lots of separate objects that were culled off screen (out of the frustrum) or was it a single combined mesh ? I did a Sponza demo with 3.7 million polys and got 10 FPS with not using mesh collisions (floor collider only) - see here: https://www.youtube.com/watch?v=UYBaDYTTKuI @Robbo I created a new project and then a land with 5000 by 20 and I put 80% of trees and grass and I also put about 40 I think soldier characters playing animation I used about 20 nodes of fire particles and I put water in a single lake The total was 2,200,000 polygons. I wanted to know how long the ccb would support and I thought it was good. |
||||
|
|
){kind=link}