What is a shader batch? How can I write one in Blender/UPBGE? A good example is binding a texture to other than a float variable.
Can anyone please give me an example on what a shader batch is and how to write one/binding textures to variables?
This is a vast topic if you don’t already know what a shader batch is there’s a lot of fundamental concepts you’re missing. I’d start here: https://docs.blender.org/api/current/gpu.html#module-gpu
Is the vertex shader batch (batch_for_shader) the real reason why on a Mac with the M1 chip, the object shader VideoTexture fails to compile?
This does not happen with a 2D Filter, so it is clearly a vertex shader problem. It seems to be batch related, as M1 cannot compile shaders with textures bound to floats or ints.
Is it possible that since the texture that is assigned to float or int values (which are phantom values on the M1 chip) need to be assigned to a vertex batch first for the shader to compile properly?
This issue drives me nuts when using VideoTexture in conjunction with shaders. It works on non-M1 hardware fine.
Shaders should not be brutally tough to assign to any object, let alone impossible. They should be easy to assign.
Will this unsupported vertex shader issue be fixed in the 0.36 Mac release? Would really hate to see this bug come back in that release.
Imagine an electric shader and it just renders solid black on Mac devices while on an older M1 Mac, it works fine.
Does the UPBGE/Blender team know about it?
UPBGE is entirely separate from any official Blender development, there’s no UPBGE/Blender team. We can’t really answer this question either:
You’d be better served asking these questions on a UPBGE forum 
1 Like
The problem with M1 and M2 generally is that OpenGL is “deprecated” now in the Apple ecosystem.
Perhaps as OpenGL has rock solid legacy stability, it can do very simple things, but the more complex and advanced the features, the worse things eventually become. It can’t handle so much stuff in it’s current state.
In the Metal release of UPBGE and Blender would this whole problem of unsupported GLSL go away? Metal is Apple’s new counterpart to GLSL.
I did see a new UPBGE 0.36 nightly build, but its only for Windows. A Mac release should come very soon, I’m sure.
I hope UPBGE/Blender can someday be able to be launched without going through Apple’s GateKeeper, and with the option to start with a terminal rather than creating an alias, like on Windows.
One more thing to mention about, is that in the Metal release of UPBGE, will this force me to rewrite any shader code? Will this make me able to apply a shader to a vertex object without it breaking due to deprecated GLSL? Will GLSL shaders work at all, or will I need to write in a new language?
1 Like
I can’t speak to UPBGE or how they do things but Blender uses (or rather, will use) Vulkan as it’s renderer. You write shaders in glsl and Vulkan will handle the appropriate hardware calls.
1 Like
For sure, the only correct way to program for Apple is with Metal, since now is the only viable option. If developers port the render pieces to Metal then things will be OK.
Is no joke that even Blender had to do the essential rennovation towards Metal as well, otherwise it would have great troubles on gaining the trust of users.
https://code.blender.org/2023/01/introducing-the-blender-metal-viewport/
Though the UPBGE has less people than Blender as a project but eventually they will get there soon.
1 Like
Thanks. I really hope a Mac release of 0.36 comes soon, along with Metal support, as there will be a big performance boost, and Metal should be able to run EEVEE Next, which will optimise UPBGE even further! 
As for rigging, hopefully GPU skinning may be around the corner in 0.37-0.38, which will further increase performance. This does leave one question - what will happen to existing Armature modifiers that are used as part of game characters? Will they be converted or will GPU skinning be automatically applied, or can GPU skinning be turned on/off, or are rig effects toggleable, or something else? I know GPU skinning will eliminate crashes in 99% of cases with rigging, as rigging can be painful with crashes giving me grief, like on a cockatoo bird, which caused a lot of crashes. This even extended to selecting bones, as selecting even one of them just caused an automatic crash… 
While 0.35 does have a small performance improvement on macOS, SSRs, crisp shadows, etc will eat up perfomance dramatically, even on M1, which M1 is supposed to be one of those performance kings that Apple claim to be. While there is some truth to this, and M1 is a very powerful processor, it seems UPBGE 0.3+ currently cannot take very good advantage of the CPU, hence why it is slow. 0.2x and below are faster because they have less intensive processes (graphics, shaders, etc), and a less intensive render engine, which is why rigs never had an impact until now. 
All other apps run fine at normal CPU speed, but UPBGE’s player seemingly does not know how to take advantage of M1’s performance capabilities.
I am curious as to why UPBGE has “Render Image” and “Render Animation” even though it is a game engine, not for creating animations like Blender is. Maybe the Render Image and Animation are to create your own spritesheets?
To wrap up this series of questions I just asked in this reply, if UPBGE is still in Alpha, will it eventually enter Beta? This would be interesting, as a Beta release is more stable than Alpha, but still a tad rocky. UPBGE should also have an option to send anonymous crash statistics to the devs, and we can opt out of it at any point in User Preferences or at the splash screen.
UPBGE also has a bug where you cannot get a static object (like steam for example) to move via applyMovement or applyRotation or linV or angV. This should easily be corrected, and this bug breaks particles unless you attach a Motion sensor.
1 Like
It seems that you know lots of details related to UPBGE, this sort of testing is very helpful for developers, if they are able to read and know what you write they will have the ability to make more corrections.
I don’t know exactly about the strategy of the UPBGE team. But in technical terms it goes like this.
There are two options, one is that having vertex skinning on the CPU, will allow you to get the calculated results for some other use (eg: On the modifier stack you have armature, and then you have subdiv, and thus you get properly calculated vertex positions). – The other case is that at game-runtime state, perhaps you have no modifier stack at all, so you just feed the GPU with vertex positions and bone matrices and everything is calculated within the shader.
So going for a hybrid approach like editor-runtime is a much more realistic case. Unless I miss something, if there is an UPBGE developer who knows better to correct me.
Perhaps the UPBGE team only works on the parts they are interested in related to the game engine. Without changing anything and having no risk of breaking or cleaning anything else. So more or less you can use it as “Blender” if needed rather than as UPBGE only.
1 Like
Another thing to note here regarding UPBGE, is that the reason the player is slow even on powerful computers seems to stem from the fact that UPBGE was written from 2.79, which was designed around an integrated game engine, and designed for Windows, hence why it worked so seamlessly on Windows XP unless you crammed too many objects inside it or too much geometry. The reason macOS and OS X had it much more difficult than Windows and PCs come from this:
-
Windows often was (and is) designed for these kinds of programs. Plus, Python was made for Windows originally I think, but was ported over to Mac and Linux.
-
PCs often are upgradeable, something that modern Macs lack. If GPUs fail, you can replace it, same with CPU, monitor, etc. This cannot be done easily on old Macs and is an impossibility on modern Macs.
-
Because Blender/UPBGE was originally built on Windows app code, making UPBGE and Blender compatible with macOS can be very difficult. It is why many apps never make it past Windows to Mac, and why thousands of games released for 32 bit Macs will never run on modern Macs without some modifications to them. To do this, you need to rebuild their code, often from the ground-up, and notarise the app to allow macOS to launch the app. This takes a lot amount of manpower and years of work, and is the real reason why Mac gamers get screwed over by PC CDs.
-
Macs have gained a negative reputation among gamers for their Cider app. When this app is in use, it is extremely prone to crashing. On Windows, your game will often work as intended, but on older versions of Mac OS X, it may use Cider to package the executable into an app, and translate the code into Mac OS X code. This process is not perfect, and the slightest glitch or just a seemingly normal action like clicking on a UI element or interacting with an object can result in an “Exception Raised” pop up, which describes some kind of “page fault” which causes you to lose your entire game progress even if you click Yes to “debug it”. This has caused many to turn away from Macs and use PCs citing Macs as “terrible for gaming”', when they really aren’t. The only way to work around this is to either use another wrapper that does not use Cider or natively code the app for Mac.
-
In the past, Macs were very slow, and expensive, with often outdated architecture. The slow, outdated architecture persisted for a long time, and rarely got updated. This has since been resolved with the M1 chip, which blows Windows out of the water, but it does have one fatal flaw: no GLSL shader compiling, which is why we see the dreaded “UNSUPPORTED” message on vertex shaders, as GLSL was dropped in favour of Metal.
-
Macs often drop features much earlier than their PC counterparts. The USB ports, abundance of I/O ports used for convenience, SD card reader/writer, and disc drive were all removed in 2015, and in their place were just 2 USB-C ports with another 2 for both USB-C and Thunderbolt. This caused massive backlash, and made PCs look far superior. At the same time, since almost every convenient feature was removed, we actually began seeing Macs become harder to use, though this has since been reversed in Apple’s 2020 iMac line up. The MacBook was the worst hit by this, with the 2017 model only having one USB-C port, meaning you needed a huge amount of adapters and dongles just to use legacy features that older MacBooks had, and made the portability aspect pointless.
-
UPBGE’s slow player on macOS seems to stem from the fact that the app does not know how to take advantage of the CPU part of the M1 chip. Other game engines can due to the fact that they are now (mostly) coded with Metal and M1 in mind, something UPBGE still has yet to have. It seems UPBGE still thinks M1 is an ATI RADEON graphics card and some kind of other CPU type still found in older iMac models. Thus, the player assumes M1 is a hybrid of these cards, and tries to draw the shaders using RADEON-esque methods which are slow on M1, and thus cannot draw certain GLSL effects, as they are not supported by M1 and UPBGE’s current version. As UPBGE’s player seems to think the CPU is an older CPU based from an older iMac model, this probably explains the GE’s slowness to an extent.
Hope I cleared some things up. Cheers! 
1 Like
Here is why I think UPBGE may be slow on rigs, especially in it’s player: One of the reasons why UPBGE is slow with rigs is nothing to do with RAM or macOS or the operating system itself, but the CPU. Everything in UPBGE (nearly) is currently done by CPU (except displacement which is changing to GPU with eevee next), the CPU also includes rigging. If I lets say, draw a bone through a simple icosphere, UPBGE doesn’t crash, and just continues on as normal due to the fact that calculations are extremely low, and are not taxing enough to cause a crash. Its like a Subsurf modifier, and you add more and more onto it, and then push P to start the player, which takes significantly more CPU the more objects and verts there are. The same happens when rigging.
When lots of bones are drawn through something complex while parented to the object like a shark, dolphin, or baleen whale for example, UPBGE may crash entirely with only the slightest selection in some of the most extreme cases. Since I use a 2022 M1 iMac, the CPU is not running hot and no fans are spinning loudly or anything like that when the bone-related crashes occur. UPBGE just crashes due to the fact that UPBGE simply cannot process the demand needed to meet the amount of bone/vertex information it has to send to the CPU.
This can be summed up like this:
When you currently draw a bone in UPBGE, UPBGE is checking (in realtime) the number of bones and verts that are being drawn on the scene. This is normal, as UPBGE must update the scene. However…
Things are not perfect. Some things are much more taxing than others, and bones are currently one of them. Since they are currently drawn on the CPU, this makes it one of UPBGE’s biggest weaknesses (partially). This is why there are high priority plans in place to gradually replace the Armature modifier with a GPU/CPU skinning optimised one. Now, if you have a mesh that has a lot of verts, and you are drawing a lot of bones, the bone and vertex calculations that UPBGE needs to perform and send to the CPU combined will eventually get so huge, that it will cause a crash eventually. Since UPBGE has no way of compensating for this, the eventual crash that results from this is not the computer’s fault - it is the complex bone/vertex calculations that are done entirely on the CPU that leads to the crashing. So, what would GPU skinning do? 
GPU skinning in reality would be a hybrid of CPU (this would be needed for information about vertex groups and other small stuff relating to UPBGE), and GPU (this handles everything else like drawing of bones/verts, etc). Unless your GPU is faulty, this would work wonders for UPBGE, and also for performance improvements. This however would require a lot of testing to ensure it doesn’t mess up, and the current Armature modifier would need to be reworked a little to have options for this. Currently, the “skinning” done on the Armature modifiers is not really “skinning” at all. It is just drawing the verts frame by frame on the CPU’s side, sending that information to the GPU (which then is responsible for rendering it to the screen), and then doing it again, which is extremely taxing, even on the best hardware. GPU skinning splits this process and optimises it for the scene and game camera, using up less resources and energy, allowing for much faster framerate and performance improvements. It’s how early 2000s 3D games in even the earliest engines (Unreal 1) for example, maintained a near-constant 60-FPS, although many were somehow capped at 30-FPS, likely to avoid overheating components back on early PCs, and to support CRT monitors. 
That is my theory and thinking on why UPBGE can have lots of crashes/slowdowns with rigs. It can be very temperamental with bones, so save as you go. 
Regarding EEVEE Next, I think the real reason UPBGE is unable to render eevee next currently on M1 is not because of the GPU - M1 is more than capable of handling eevee next without overheating - far from overheating. The reason why is because eevee next’s code is not yet optimised for M1, and thinks M1 is just a CPU and not what it really is - a system on a chip. The same happens on Intel based Macs - you need a certain graphics chip, and eevee next needs to be optimised and written a bit more on the Mac end of things to be compatible with M1 to render. The “shader buffers” error means that eevee next could not find the GPU to render, and instead of crashing, defaults to a grey viewport with only the object selected outline to prevent your work from being lost. This is also caused by the fact that on M1, OpenGL only goes up to 4.1, and has been depreciated entirely, being replaced by Metal, which eevee next is in the process of being optimised for with 0.36. Eevee next would however, drastically speed up UPBGE’s player. We could finally have fluid/smoke simulations and high-resolution reflective ocean modifiers without the player slowing down to an unusable 5 frames a second! 
The “UNSUPPORTED (log once) POSSIBLE ISSUE” commonly seen in object textures when applying a shader node of certain type to an object in the macOS versions of UPBGE is also an M1 issue that will go away when UPBGE gets Metal support, thus re-enabling vertex shaders and object fragment shaders. No more black objects when writing shaders and attaching them to Python scripted objects!
In the meantime, see if you can provide a .blend sample that crashes and report to the github project page as an issue. This will be a good idea to pinpoint the source of the problem.
1 Like
No thanks.
FYI, the less willing you are to help debug and find a bug, the less likely it will be fixed.
1 Like