As many of you know, I have been pushing the game engine to the extreme limits of its abilities. Now as I’m working on the next Zark game (the previous one is not available, my website is down. Please don’t PM me about it) I am finding that my levels start to experience drastic slowdowns when they’re not even very complex yet. Yes, I use a lot of Add channels, complex logic brick setups, and make liberal use of the UVscroll script, but in the past I haven’t had so much trouble. I have one level, not even CLOSE to being completed yet that sometimes drops down to as little as 3 FPS. What’s really strange is, it can also go as high as 40+ FPS.
My questions are:
Am I missing something about the game engine?
Should I switch to a different engine? (Crystal Space?)
Is it because my computer is not a spring chicken anymore? (1.8 Ghz, 300 Mhz Nvidia, 700 MB RAM)
I think speed has to do with the fact that the most taxing thing on the engine is seperate objects. A scene in which every tree is a seperate object will run slower than if the trees were all part of one object.
If I was you, I should just wait for the Ogre update and now start playing with the physics engine as well scripting with python, since the Ogre integration will (what I think) totally change the game engine experience as we have now. Better graphics, better performance in realtime (I hope) and much more.
Althought there are a few things you always have to keep in mind when making games and when making them run smooth, personally I don’t know all the tech names but I know what things can improve a game it’s performance.
level of detail: were on far distance, objects are low-poly, when closer, more detailed with using replacement python scripts
object culling: were from far distance objects aren’t there, but when comming closer, they get placed by some scripts. Same can be done with viewable area of the camera. When something is in view it is there, else it is invisible and not rendered. This can also be combined with Level of Detail.
collision detection: In blender all meshes have on default collision detection. Turning it off on certain things might speed it up, since clouds, sun, air, gras and stuff don’t need collision detection, as well leaves of trees, lightbeams shadows.
Textures: don’t use 1024x1024 textures when you can do it with just a 128x128 texture, as well fine tuning texture file sizes, cause 1.5 mb for a grass texture is a little overdone.
Python scripts: in some cases they speed up certain tasks, no idea why, maybe because some things can be done with 5 lines of python instead of 20 logic bricks.
And there are more things that can tweak the speed of running a blender game. But remember that blender’s game engine isn’t really designed for performance, actually the performance in the game engine is really poor compared to another engines. I hope this will change in the future.
collision detection: In blender all meshes have on default collision detection. Turning it off on certain things might speed it up, since clouds, sun, air, gras and stuff don’t need collision detection, as well leaves of trees, lightbeams shadows.
Indeed. Also, there might be an issue with meshes of armature objects, best to switch off collision detection on them.
More details would be useful: if you show profiling, which sections are the slowest? Physics, Graphics, Logic?
Thanks for the tips, especially the one about collision detection, that had never occured to me. The UVscroll script is running on every frame (on several objects), but it sort of needs to, unless someone can suggest an alternative for UV animating.
Okay, here’s some screen captures of the game debug info.
This is the game at its best. The setting is an open courtyard. There are no animated objects in the vicinity. The camera is looking at a large (but less than 20 polys) waterfall which uses ADD filtering and is animated with UVscroll.
This area has several UVscroll/ADD filter waterfalls, plus another object with add and UVscroll to simulate mist coming from the falls. Also in the vicinity are an object moving with dRot, and an animated deforming character with armatures.
This is inside a tunnel. There is nothing of interest here, except the low framerate. There is no UVscroll here, though there are two IPOs running. Why should the framerate get slowed down here?
This is the worst of all. This is almost exactly the same as the first image, except that we are underground now. We are directly below the afforementioned courtyard, still looking at the waterfall. Similar to the tunnel image, we are underground with a floor and a ceiling. This is a very expansive room, though, unlike the small, confined tunnel.
scabootsca: I tried your suggestion. It worked wonders for performance, it’s true, but it absolutely ruined the effect of the script. even at f:1 it was still easy to tell that the script was not running as would be expected. I’m going to experiment with triggering some of them with Near sensors, but that’s not always a satisfactory solution.
I’m about at the end of my rope, and I’m considering (don’t tell my brother I said this) giving up on the Zark game altogether. The game engine has given me so much grief lately (new releases tend to bring small improvements but huge bugs) that I’m beginning to think I should give up on my games and stick to still renders. What should I do? Should I try a new engine? Can you recommend one? I know that the OGRE plugin is coming in late August, but college is coming in late August too. I doubt I’ll be able to finish any game after I start classes.
Suggestions? I’m at a total loss here. I don’t want to give up my game, but I don’t want to make a game that’s unplayable either.
How about object pop-up? That might be something to try: put an empty where an object would go, and when the character comes within range, the object is added. The object would disappear when the character moves out of range again.
Nah, PlanetPerson. College does give you a decent amount of free time. Unless you party a lot, or study like a nut. Lol, heck I’ve only been with blender during my college years. Heh, just graduated :p.
Even though the OGRE plugin is coming late August. I don’t think by any means it’s complete with all the features. :DHeh, it’ll also be continously improving. The huge world you’re planning would definitely run on OGRE most likely.
Since this is a huge project. I’d say wait take a small break, work on something smaller. No sense in scraping the whole thing altogether or finishing it in its entirety when you see what bullet and OGRE integration brings to the table.
-> On another note. Blender seems to do something like object culling. So if the object is not within camera view, the fps won’t be affected by the rendering of that not scene object. However if your object is a huge mesh that is linked even with parts not scene by the camera, it would act like the whole thing was being rendered in realtime.
I have those problem too, and I have few experience about this now.
1.Try decrease sensors which for detect other objects like near or radar etc.
2.Differentiate requirement between functions: which have to sticky active, which only need active when they’re called. Try split them into different texts and only call a script when it needed.
3.See this thread
Split and decrease scene size is a good idea, and I have another idea is disable features when it not needed. For example, a character walking may need physics, but you can suspend it if he’s dead and lie. I havn’t try this yet but this should work.
Scenegraph is at 10%. Seems like a rediculously high number for what this should be. The game engine does not like lots and lots of objects in a single scene. Try split your scene(s) up some more.
Logic at 40%! That needs massive amounts of optimisation. Consider a workaround to using a UV scroll script. It’s far too resource intensive to just plaster all over a level.
Physics at 20%. Seems like you have a lot of collision faces there, try optimise these. If there’s lots of dynamic objects this will also be problematic. Consider using alternatives such as IPO curves instead of relying on the physics engine.
Welcome to the world of experienced Game Engine developers. Where 90% of developing a game is finding workarounds & improvements to make it playable
Hey, I got a workaround idea for UVscrolling. Say you want a river. Instead of UVscrolling, give the river a looping IPO that’s set up so that it move forwards one texture length. It’s sort of like the “doing armies of characters” technique in hand-drawn animation: by making something go forwards and then reset, it gives the illusion of continuous movement.
but that’ll only work if your object is a perfect plane, and it’ll be hard to do at any angle save for along the 3 axis. I’ve tryed it, and it doesn’t work too well. the alternative is to make the moving mesh very large so you won’t notice where it ends, but it’ll have to be set in a concave mesh.
Why other official games have nice very high speed in game play? Half life II running on my system under 50-75 fps, Serious Sam by Croteam on all maps-75 and more, but blender only 10 fps. There to hide Great secred by developers of blender. (type free-bad, under cash-good)
well heretic, although the developers of AAA proffesional games have more advanced tools, they still have to worry about optimization just like us. I mean, sure those engines can handle alot more, but they cant just throw everything in a scene and hope for it to go fast. Those games use alot of culling features, and most of there textures are still the standerd 256x256 or 512x512 also. And you can bet your ass that there code-work, models and scenes are very well optimized as well.
Same for ogre…it will run faster, but your still going to have to keep optimization in mind no matter what engine your using.
I would try that suggestion by Toomai, Plant. Could you perhaps take a video capture of the river from above and then convert that into an animated texture that you could use through normal animated texture options?
