OK, this means the make_current issue was just a red herring: your driver was just spending time there waiting for it to finish the previous frame. Now that we’ve eliminated that call, it’s just waiting for it to finish the scene in flip() instead. Either way it still has to wait to finish drawing the previous frame before it can start drawing the next one.
So, this means your graphics card is running slower than Panda. The bottleneck is in painting the actual pixels.
You’re back to simplying the shaders, turning off antialiasing, making sure transparency is off where it doesn’t need to be on, maybe reducing the window size. Or, worse comes to worst, buying a more expensive graphics card.
many game with more stoning graphics run just fine on my computer. I do really want to to be optimized - its just drawing couple of ships its should not take this long. I will be looking for stuff to cut. But shaders are not even 10% of my fps when i cut them nothing seem to happen. The blur does slow stuff down a bit a little more then 10% but most of the slow down is just … i don’t.
Also because of your fix drwr the game does not take up 100% of the cpu is that normal?
There are six main possibilities, when a game is running too slow. In descending order of likelihood:
Too many meshes.
Too many pixel-shader instructions.
Too much overdraw.
Doing something bad.
Too many polygons.
These days, cards are so fast at pushing polygons that I usually discard the ‘too many polygons’ hypothesis out of hand, unless somebody tells me that they have millions of polygons. So that leaves several other hypotheses.
The first thing I usually do is make the window smaller. If that helps a lot, then it’s too many pixel shader instructions or too much overdraw. If not, then it’s too many meshes, or doing something bad.
By ‘doing something bad,’ I mean for instance copying from the framebuffer into a texture of a different format, thereby forcing an on-the-fly format conversion. Or something else that the driver just wasn’t meant to do.
pstats can tell us how many meshes you’re rendering. I can’t remember how to get that information out, though. I don’t use pstats much.
do you also controll your verts over your shaders - how deep you are controlling your verteces?? do you calc distances between your verts or something like this??? this would slow down the whole thing amazing. but if you are doing something like softbodys in, cluster your vertes and do your calc just in a fixated area around every cluster. but that just a impression of a unknow problem of a newbie.
well one thing i found it - some thing i suspected before - my GUI takes up have the rendering time because of many small geoms. I am thinking of maybe rendering it to an off screen texture and update only when it changes.
Josh i think its the last too; shrinking the window does nothing to the frame rate. Also the cached transform states grow and grow and grow. After running for a while it seems like it gets faster maybe some thing gets optimized or cached like transform states.
I am already using one rigid body combinator for the turrets on each the ship. Its much faster then not using them - maybe i can rigid combine more things?
That is extremely slow i do that on the stencil shadow example i posted a while ago that would send me in 1fps range. This game has no physics system or animations its just rigid meshes so far.
The rigid body combinator is cool, but flattenStrong is even better in cases where it applies. You could even try it on your GUI! Of course, that only works if the GUI isn’t using a thousand textures. Is it?
As for accumulating transform states — that suggests one of two possibilities. Panda’s caching algorithms could be doing something bad, or you might actually be leaking nodes. Check for that first.
from the pstats we see that my node count remains pretty much the same. The transforms seem to grow when i move the camera. What is the best way to check for leaked nodes?
Do you write things to the console or to a string buffer from your game loop??
If yes, where does the time spent to write such things are accounted in Pstats???
I ask because i notice that in a previous project on P3D 1.3.2 ( which animated 30 panda like models in an arena with 80 newton physics managed boxes ) simply writting a string on the console output twice every rendered frame killed my fps by 33% (i was 120 before and between 66 to 90 afterward))…
Do you write things to the console or to a string buffer from your game loop??
If yes, where does the time spent to write such things are accounted in Pstats???
I ask because i notice that in a previous project on P3D 1.3.2 ( which animated 30 panda like models in an arena with 80 newton physics managed boxes ) simply writting a string on the console output twice every rendered frame killed my fps by 33% (i was 120 before and between 66 to 90 afterward))…
Manakel going from 120 to 90 is ( 8ms to 11ms ) is difference of 3ms while frame rates like 40 to 20 si (25ms to 50ms) is a difference of 25ms.
Conclusion in the range 60+ fps really does not matter because it takes such little ms to influence it while on lesser frames ms really are visible.
And my program does write stuff out not every frame though because that is slow. I think it is accounted in the python tasks meeter.
Right now i am more worried about the accumulating transforms and the number of GUI nodes that i render (because GUI is takes up about 50% my drawing time)
another wild guess… i see this huge honey-bee-cell-textured plane in your space… does it change anything if you hide it? i remember the days back when graficcards had trouble with fill-rates and heavily tiled textures
You might be leaking nodes even though it doesn’t appear so in PStats. The node count in PStats shows the number of nodes visited during the render traversal, not the total number of nodes that exist anywhere. On the other hand, the TransformState count shows the total number of transform objects that exist anywhere.
But you can still see leaked nodes in PStats. This is the TransformState “on nodes” count. If this number is increasing without bounds, you must be leaking nodes.
The transforms dont grow unsoundly any more so that is fixed - there was some speed improvements too. My main slowdown now is LineSegs - i need lines to draw the radar and the order paths but i have to regenerate and destroy it every frame - so i might be leaking it. Also the LineSegs is a pretty slow class itself - i will be replacing it with my particle/projectile system.
Other place is the GUI. When containers are resized i throw a way the object that was there before and create a new one but i don’t do this every frame so it should be ok.
These sounds like the 2 places to leak nodes from.
What is the near a good number of geoms to draw per frame? Is 400 low enough?
There are several ways to leak nodes; the most common are (a) parenting it to hidden or some other unrendered node and forgetting about it, or (b) keeping a reference to it in some other Python object which is also leaked. But, yeah, I trust that you have solved the leak problem now (though I don’t understand the solution–I don’t know why setting base.cam would cause a problem. The quoted text must be referring to some low-level C++ code potentially being bad, not to anything you could do in Python.)
The LineSegs class is actually a wrapper around the low-level Geom manipulation, so you could just use that. But you can also use LineSegs::set_vertex() to animate a line without having to recreate it every frame.
According to NVidia, you should be targeting about 300 geoms per frame in order to maintain a frame rate of 60fps. Depending on how fast you need your scene to be, then, 400 might be low enough.
I don’t know using base.cam forced it to recompute the transform cache while base.camera does not that is my theory and it works so far.
Big problem with lineSeg is that the line is never the same length. It changes allot. Using LineSegs is almost is almost extra 30ms per frame. Maybe using setvertex and setcolor all the time will be faster - but i think i will use my faster c++ classes to do it. Right now i am at the point where I find slow spots and code them in c++.
Thanks for 300 goems i will try to cut down to to that.
After i converted the pyro library for explosions that was cool then i also converted all the radar read outs to use the pyro library to (order lines, heath bars, radar icons) - now that was a fantastic improvement. Now some times lots of this are in the same place and when you zoom out the same transparent icon would get drawn over and over in the same place now i check for that that i only draws one icon in a 3x3x3km block using hash tables.
Now the major slow downs are in the sound system. If i have 51 ships each of which has a continues 3dsound playing just kills fps. Now i need to figure out how to play sounds cheaper like canceling it if its to far a way or not playing more then 2 energy beam sounds at once …
Before most of the slow dawn was caused by a large number of radar (30 and 2d) read out nodes. Now that i use my pyrolib it turns out that most of my slow downs are caused by “over draw” drawing lots of billboards in the same place. Do you have any tips avoiding that?
Now that AI is also getting there and I have to get my “hashspace” ~ which acts like an octree but much faster implemented in python.
