I am running UPBGE and almost every time I press the escape key to end the game, the program stops responding. Does anyone have any tips on how to prevent these unexpected crashes?
You might be freeing up data incorrectly or creating an exception access violation. Try deleting stuff in your scene till you can exit without crashing and then isolate the object or script that causes the crash.
are you clicking on the debug console?
if you do that you have to click it and hit escape
it waits for input in the console - freezing the main window
Ok. Thanks.
Would the fact that Iām using a USB game controller and keep coming up with a warning have anything to do with it? This is the message that keeps popping up in the system console: Warning: Game Controller (Logitech Dual Action) with index 0 has not force feedback (vibration) available.
Mine does the same, I donāt think thatās a problem.
Sometimes the engine freezes up on exit because Blender runs out memory; I see it happen a lot with files too large for their own good. If you have a lot of materials, textures, meshes and objects all packed into the same blend, tightly crammed into just a few layers if you want to make it worse, having to revert back from ingame to that original scene can be too much.
Also, if your code is opening up a lot of files ā even small ones ā or generating objects holding too much data, serious funk may ensue. Maybe, append a clean-up function to KX_Scene.onRemove to ensure likely culprits are taken care of?
I tried removing all complex materials and excess objects from the scene and combined all of my scripts into one, removing all repeating lines of code, but the application sill crashes frequently while the game is playing.
It doesnāt happen every time, but still quite often.
I agree that UPBGE needs some serious optimisation, not just for Windows and macOS, but for all platforms. The engine lags/freezes when I try to texture paint complex geometry with a lot of vertices, it crashes when the use of bones are involved in Edit Mode (because no GPU skinning is used), and can randomly crash when editing objects. In rare circumstances, your file may cause UPBGE to freeze/crash. The player lags terribly with complex geometry, when adding lots of objects, and when using armatures, etc. Look at a modern, up to date game like Zeldaās Breath of the Wild, and none of these issues are in the game. Believe me, UPBGE should have far more optimisations in place before being released. I have been using Blender for 12 years straight, and I know what these crashes are like since 2.45a. The freezes (unresponsiveness) on macOS is a massive pain, especially when doing cats and other complex geometry, and the crashes are a huge pain when doing rigs due to no GPU skinning. UPBGE may also randomly crash if you select a mode, though rarely. If any dev sees this reply, they should take note of the issues we face, and focus on fixing them, as well as debugging UPBGE. I managed to report on the forums that Blenderplayer was not working properly with a recent call first error, and a few months later, the player was fixed. Had I not reported this error, it likely would not have been fixed. Sorry if this turned into a little rant, but UPBGE is really like a rickety wooden bridge here in terms of stability.
1 Like
New upbge has similar performance to 2.5x if you remove point lamp shadows, remove denoising,
Remove pbr and use diffuse shader, disable global illumination etc.
To make efficient scenes consider using geometry nodes to generate your levels from instances or perlin noise that is all 1 drawcall.
Consider the fact that Blender is a large, monolithical, quasi-arcane codebase with almost thirty years of accumulated technical debt and irrevocable design decisions thatās constantly struggling to ākeep up with the industryā, or rather, chasing dragons.
The cost of the uncanny valley high is that all of these lingering issues (and more!) remain on the backburner indefinitely. People ā I mean non-programmers ā tend to point to Blender source being available to all as a form of copium, the hope being that since the code is up for anyone to fix, someone else will do it.
However, thereās (relatively speaking) not that many programmers. And most of those that are interested in Blender pick up Python rather than C, due to one of the aformentioned, irrevocable design decisions.
And so you have a pretty large community, but it seldom produces someone capable of doing anything about all these ābugsā (mistakes) and āissuesā (oversights) that have been there for ages and pop back up in threads every other day to then dissolve into nothingness yet again.
The one thing to do about it is to learn C, of course. Hereās how that goes:
0: Dive into Blender source.
1: Scratch your head.
2: Pester the devs.
3: Receive no response.
4: Scratch your head harder.
5: Hit the books.
6: Write patch.
7: Rejected.
8: goto 4;
Or you can also do what I do: just skip writing patches entirely and build your own tools. But thatās easy for me because I donāt chase dragons ā if you want āindustry standardā youāll essentially just wind up making the same mistakes and compromises in order to inject your eyeballs with the same juice.
This is also was a rant ;>
Keep in mind you are using a fork, I am not sure how much code outside of the game engine part was touched by the UPBGE team, but I am aware of those here who envision the idea of their fork being one that turns Blender itself into the BGE (so the integration may have changed in ways that introduces instability to other areas).
The idea that the Blender devs. simply allow technical debt to build up is completely false (as there has been large areas that have seen refactors and rewrites even in the last few years). Some of these changes go pretty deep as well (such as the attribute work), and changes to core components like DNA will also see major reworks.
back to the real topic
if you use 1 material / 1 drawcall for all the static stuff you can generate huge worlds that draw fast*
I will be adding building generation etc
right now without buildings / sky / folliage / props I get about 450 fps on my 3060
I did mention dragons, and what an exemplary specimen it is.
But I was using the official trunk almost exclusively for the last three years, and studying the source to boot. How else do you think I handrolled an engine so quick?
Now, I have a theory: maybe you donāt know half the story. I tend to read peopleās code to measure them up, give myself an idea of how much they actually understand. And come to think of it, I donāt think Iāve seen much from you, if any.
But you can go through my repos instead if you want, just be careful you donāt have a stroke trying to figure out how my bootstraps work.
Much love,
please go talk to someone else.
1 texture or really 1 material? That would be very limiting.
1 texture atlas with assets / kit pieces on it makes less lookups / overhead per_pixel