It simply won’t work on Android. I don’t think this approach is good for anything at this point, pretty much everywhere you used transform feedback and geometry shaders in the past, you will want to use compute shaders now. (This article was written before compute shaders were available in OpenGL)
You don’t have to do LOD and culling on the GPU, either. Most games probably don’t. You can save yourself a lot of trouble by not forcing things onto the GPU.
I wonder if there is a method…
There’s all kinds of methods for basically anything. Do the simplest thing that could possibly work. Many games don’t need LOD or level streaming at all, don’t assume that they do. If loading assets from a file crashes, that’s just a bug that needs fixing.
NOT LEGAL ADVICE:
the blender player is GPL not the .blend
If you redistribute the Blender player in binary, you must offer to provide the source code upon request to anyone who receives that binary.
Contrary to what seems to be common wisdom, you also have to offer all the source code for your scripts. The fact that you stored them in .blend files (encrypted or not) is irrelevant. Unfortunately, the official Blender FAQ got this wrong for a long time.
Citing from the GPL FAQ:
“[…] However, when the interpreter is extended to provide “bindings” to other facilities (often, but not necessarily, libraries), the interpreted program is effectively linked to the facilities it uses through these bindings. So if these facilities are released under the GPL, the interpreted program that uses them must be released in a GPL-compatible way.”
The game engine quite clearly binds the python interpreter to the game engine facilities, which are licensed under the GPL. Therefore, any script that calls any game engine function must also be licensed in a GPL-compatible way.
The current FAQ correctly states:
“Python scripts – if they use the Blender API calls – have to be compliant to the GNU GPL as well. We are currently reviewing this with Free Software Foundation though.”