[Dev] Which bugs are slowing you down?

I’m looking for a better way to prioritize bug reports. At the moment, I’ve been mostly tackling issues that either:

  • Look easy to fix, or
  • Are affecting my current projects

With over 200 reports in the bug tracker, there are quite a few that seem rather low priority, or are non-common use cases. I’d like to know which bugs are actually causing people real problems when using the BGE. This way I can fix some meaningful bugs. Preference will be given to bugs that:

  • Have a bug tracker entry (not necessarily required, but it will help for finding duplicates)
  • Have a blend file clearly demonstrating the problem (e.g., in the file, X happens when Y should happen instead)
  • Are actual bugs. In other words, they are not feature requests in disguise (e.g., the engine doesn’t allow me to do X).

Scenegraph steadily grows while recording in game engine,

add 1 rigid body, do record,

more rigid bodies = faster growth

Watch the scenegraph,

I plan on “in game mocapping” some scenes, and this makes it not as possible (more ragdoll actors = faster growth)

it seems like a memory leak, or just a bad implementation, as it’s doing the same amount of work every frame,

Attachments

PhysicsX.blend (487 KB)

Hmm, I wonder where it’s storing the keyframe data between the BGE starting and the BGE ending. Storing to a file might be better if it’s storing the data in RAM currently.

@Moguri - Unfortunately, as I use the BGE for 2D and sprite-based stuff a lot, my bugs and usage cases would be fairly low-level and non-common. For me, key bugs would be:

replaceMesh() Crashes BGE When Used on a Parented Object (< Somewhat important. Can’t really use an up-to-date version of Blender until this is fixed)

and

Mesh vertices only updating when in cone of spotlight (< Unsure if fixed yet; haven’t checked in a recent version of Blender. Not too important, but something that definitely shouldn’t happen)

I saw your comment on my “Unable to update mesh vertex properties via Python when mesh is influenced by armature” bug report that mentions that this bug might be able to be fixed effectively if developers could rewrite the Rasterizer, which would be nice. Perhaps another “bug” to throw on the pile of things to be fixed if the rasterizer / shader system could be rewritten would be “Custom GLSL material shader error” (though maybe the rasterizer and shader systems are vastly different).

@BluePrintRandom
I tracked this down to inserting keyframes (Blender code). The problem is as a new keyframe is added, the array of keframes for an FCurve is increased by one and the old keyframes are copied over. This operation gets more expensive as the number of keyframes increases. This is a bad design (the list should probably double to avoid continuous copies), but this isn’t BGE code, and I don’t know how many people really use the record animation feature. So, I’m just going to leave it as is.

@SolarLune
I’ve fixed the first two bugs you mentioned. And yes, the custom shader code is due for an overhaul (this is actually in the works).

Well, I think with the ragdoll actors I am working on, euphoria style animations can be recorded from the bge, for use in rendering, but if the problem is outside the scope of .bge code, maybe make a note somewhere?

I am looking to use 6 armatures to drive like 20 actors…

navmesh -> memory leacks

on my PC this (stress) test increase 0.01 GB each second more or less

NOTE:
the same happen using the function of python (navmesh.findPath()) so, is not in steering actuator the problem.

the RAM still full also when the game is stopped , need close blender.

i had the suspect is a “optimization failed”, as each request (find path) is stored in some dictionary(start-end position)
but since the floats numbers of vectors is never the same it not work, just continue infinitely to store tuples.

Attachments

navmesh_memoryleacks.blend (100 KB)

I think some can be closed straight off, like this one: https://developer.blender.org/T40097

To me the most important is this one:
https://developer.blender.org/T40114
Happened on all our school computers, some of the uni computers, all over the show. Sometimes adding materials or changing to GLSL will fix it, but it’s a pain when trying to show something off.

Another I’m keen for is this:
https://developer.blender.org/T37412
But it’s not really that important.

Unimportant ones that I haven’t reported but you may like to know about

  • I ran into an endless run of LibLoad crashes about a week back that I resolved by completely revising my code. I was never able to pin it down to a concrete cause, so I haven’t file a bug report. Seems to be async libload from data property. Crashed blender completely, freezing it in place. Even pkilling it from the terminal had issues shutting it (threading?).
  • Another inconclusive bug I couldn’t find the cause of was setting the size of spotlights from python. It works 90% of the time, but occasionally it will not alter the actual size. It was brushed on in my Point Light Shadows resource thread, where MrPutuLips mentioned that his spot-lights appeared really narrow while the code was setting them wide. Again, I couldn’t find the cause of this, so I haven’t filed a report.

Neither of these are important, so don’t worry about them.

You know, I noticed that my spotlights were really, really narrow in Blender in between a couple of versions; can’t remember which ones. I think it was around 2.69 or 2.7. I have no facts here, but I feel like they might have switched something around when it comes to changing the spotlight size; what used to be a normally sized spotlight was, like, 5 degrees. Obviously no issue to just change them back, but it was just something I noticed.

@Moguri - Thanks a ton for fixing those bugs! I’m going to update and test right away.

IIRC they unified (at some point) the fact that some attributes were using degrees, and others radians. Now everything uses radians (at least under the hood)

LibNew and LibLoad are powerful tools. Since LibNew, LibLoad and LibFree are all part of the same family I think each one of these should be addressed when it comes to debugging. Some existing bugs with this are keeping me from moving forward:

Looking at the last hundred bugs in the tracker:

Other bug fixes that in my opinion should have higher priority as well are:

Other bug fixes that come close to a priority in my opinion are:

Last but not least, I think T35680 Read Physics type from KX_GameObject would help a lot. It’s not really a bug, just something, I think, the bge cries for.

Right now, my project relies heavily on LibLoad and LibNew. I uset it for the UI, terrain, most/all assets, etc. Just using LibNew now, crashes the game sometimes, so I look for older versions of blender, where it works, (mostly).
Thank you for your time, Mr. Moguri-san.

Edit:
OK, Raco beat me to the goal!
Edit 2:
So maybe add Moerdn’s join objects object.absov(other), so unique objects can be created by joining them, instead of groups of objects(scenegraph bottleneck).

Since quite a few Versions, the second UV does not work in BGE – so if I blend two Textures together, one on UV1, the other on UV2, the second UV2 just seems to turn into one monochrome Color as soon as I start the BGE.
https://dl.dropboxusercontent.com/u/104245941/geblendet/wibblywoblly01.blend
(In this Example, two Textures are supposed to be moving in different Directions – instead, the second UV just “blinks”. In the Node Editor, the selected Mapping Node can be connected to the Texture Node next to it, which gives a better Approximation of what it ought to be like, though the second Texture remains static with this Workaround.)

Another more recent Bug seems to be the Alpha Value of the bgl_RenderedTexture when writing a 2d-Filter: When looking at an empty Background, the Alpha of the bgl_RenderedTexture should be 0.0 where the Background is, but since a few Versions, that Part is also 1.0, just like solid, non-transparent Geometry. (This Bug takes away the Basis for Godray-Filters, which make use of that Background-Alpha.)

That’s a feature request, haha. Although, it would be a really nice thing to add in.

I tested out your changes Moguri, and the basic replace mesh example I had no longer crashes the engine, which is nice. I’m still experiencing crashes on my project Gearend, though. I might see if I can track them down, though I might just wait for more new builds and fixed errors to see if it just gets fixed over time.

IMHO:

  • LibLoad and company
  • Physics
  • Everything else

@MarcoIT
I fixed the memory leaks identified by your test file. It wouldn’t surprise me if you still find some more using other NavMesh features (although, I did fix a leak with findPath, so the Python API should hopefully leak less).

@sdfgeoff
I’m hoping to get that Intel issue investigated further. So far I’ve found out that the Intel HD 2000 chip has the reported problem on Windows, but not on Linux, so this might be a driver bug. :frowning:

@Raco
Wow, that’s a lot of bugs. I’ll look into the ones affecting you currently. T40172 has been fixed, and T35845 has been minimized (now only shows up when libloading without a material).

@C.A.ligári
Multiple UVs with node materials have always been problematic (see https://developer.blender.org/T33730), but I can look into them again. As for the alpha value with bgl_RenderedTexture, I’m guessing you’ve switched from an AMD/ATI card to an NVIDIA card. On AMD/ATI, the window gets an RGBA pixel buffer, but on NVIDIA it’s RGB (no alpha). The 2D filter system (and video texture’s render-to-texture features) really need to make use of FBOs to avoid these types of issues.

Amazing! This fix certainly clears the way for me (and others, I’m sure). I probably overdid it by posting so many bugs. :smiley: I tried to find those bugs that I think generally would slow people down. Of the first seven bugs I think maybe the one with KX_VehicleWrapper is quite critical. That’s the last thing I’m saying before anyone thinks I’m taking to much out of the situation. All I can say is, many thanks for giving us the privilege to share what bugs are slowing us down most.

Indeed, it’s really nice to be able to say what needs work in terms of critical bugs. Thank you very, very much for your efforts, Moguri. The BGE wouldn’t be nearly as advanced as it is if it weren’t for your efforts.

In-game, the BGE can’t detect whether or not a joystick has been plugged-in or -out. You must restart the game to check if a joystick is plugged in or not.

I’ve been told this isn’t a bug (but it feels like one) and I’m wondering if this is something that could be “fixed” in the upcoming future? Or what’s the deal with joystick detection?

Thank you Moguri :smiley:

awesome, thank you!:smiley:

sorry , i not understand this piece even with traduction:

“It wouldn’t surprise me if you still find some more using other NavMesh”

(other bugs in navmesh? i not noticed)