I second vitorbalbio’s request for loading bars. Thank you for your tireless efforts in improving the BGE.
@Moguri - I didn’t say this before: Thanks from me, too, for working so hard to improve the BGE. It’s really come a long way, and a lot of that has been due to your efforts.
As another suggestion for an improvement, I was wondering if you could look into making an easier way to use compiled Python script files? Currently they’re renamed AND in a separate directory - it would be really easy if they could drop the renaming convention to just be ‘script.pyc’ instead of ‘script.cpython-32.pyc’. That way you could just copy and drop the compiled files into your standalone executable folder / script folder.
Okay, wow, I probably should have responded sooner, but I’ll try my best to answer everyone’s questions:
- Sending binary data to startGame() is a bit trickier than sending it to LibLoad(), but I’ll at least try to get LibLoad() working right for your needs.
- Try using a hemi lamp instead of the ambient color for global brightness.
- Please post a bug report regarding the command-line arguments with multitexture mode (I couldn’t find a related bug with a quick search)
- Asynchronous loading should eliminate the need for users to split loading over multiple frames as it can be done in a separate thread.
- I have some preliminary code for toggling fullscreen. It has some viewport bugs when switching between the two modes, but I’m hoping I can get that sorted out. Also, I did some research into OpenGL and vsync, and it looks like that should be possible to do as well.
- For the pyc names, look at the compileallmodule:
python -m compileall -b script_dir
@juancarlospaco:
The specific features you mentioned (aside from possibly some better mesh manipulation tools) are out of the scope of this GSoC project (especially integrating another engine). Also, I’d rather not switch Blender from gzip to 7zip since that is non-bge code, which I’d like to avoid touching as much as possible (it makes merges/reviews easier).
@Scrible:
I think that bug has already been fixed, please check the tracker entry for more information.
@Jorge Bernal:
That patch is really Benoit’s area. I’ll poke him to see if he can review the patch.
@Everyone:
Thanks for the feedback and kind words. 
A note on asynchronous loading: The idea behind this is to handle the loading and conversion in of a library in a separate thread, which leaves the main thread to continue running the game. The upside is, yes, you could load assets with minimal freezing (some might still occur when merging the scene). The downside is that you don’t know when the asset is loaded. I plan to have LibLoad() return a type of Futureobject when async is used. I’m hoping this object could be used to tell when the object is loaded, and, if it’s not loaded, how far it is (a rough percentage). I have the basics for async loading working in the Swiss Cheese branch already (I’m not sure if there are any builds on graphicall yet) if people want to play with it.
Moguri, Quad-Buffer stereo works now; thanks for pointing that out.
Thanks for the link to the compileall module - I’ll definitely be using that in the future.
And yeah, hemi lamps are fine for global brightness, but I thought that it would be worth the effort to try and save resources spent on lighting whenever possible, which is why I suggested the color spinner. It would help eliminate the usage of one or two lamps that do nothing but provide ambient lighting.
I think I posted a bug report about multitexture mode quite awhile ago - it just never got looked into, I believe. Here it is (Google to the rescue!). I also posted a bug report about the Clip Alpha blend mode not working in GLSL mode, though I’m not sure if that’s a graphics card related issue or not, since nobody else seems to be having the same issue that I’m having.
Something that I just noticed that would be a nice fix to add in is the ability to create objects from other scenes (i.e. create a GUI element from the game scene). Currently, doing so causes Blender to crash on exit (maybe an issue with freeing the data?). I tried creating the object from a different scene and using a reference object from either scene, and neither worked.
For me the best is to make BGE stable, then add warever should be added later, Moguri and some few others are turning BGE into something better, and that is great, Thanks for your work man!
1-you can lower the resolution of the blender player?
I can not seem to go below 800 * 600 (more or less)
so it is still too high, and the FPS is about 40/45.
I have no software that can have a very low resolution, so it may be that depends on the drivers, not blender?
I like to play full-screen viewing with 400 * 300 or so.
I think there would be no problems with the rasterizer: D
2-one more thing:
you can have a function in python to control collisions with no collision mesh? including the assignment of the ID (instead of the property)
This is for example to simulate collisions of hair for the characters, without overburdening bullet.
3-currently there is no way to use more texture with the same material (it is only possible in Multitexture, not in GLSL)
pretty usual that the materials can be 5/6, while many more texture.
but we now require you to add materials useless, because technically you can not use 1 material for more texure
I hope that the translation is understandable.
thanks
I pull this thread up to ask for a couple of features.
-
Could you possibly look into fixing the blending mode property for materials? It’s really cool that it’s there (and not well-known, at least not to me), but it doesn’t work.
-
Could you possibly look into objects’ meshes’ materials pointing to KX_BlenderMaterials (instead of pointing to KX_PolygonMaterials, which don’t have nearly the same amount of features)? It would be really cool if we could alter the diffuse or specular colors of materials in run-time.
It’s odd that these things don’t work or aren’t available in the BGE - the API still lists them, and there’s no deprecation errors. It would really open up possibilities (at least to me) if these things could be fixed.
There appears to be a bug with the Compositor - it would seem that you can’t use a second UV map with the Node editor - materials that use the UV setting of the Geometry node only use the UV in the top of the stack, regardless of which one you specify.
Hi Moguri,
I tried to get swiss branch to compile, finally it worked so far. LibLoad crashes on async scene loading.
blend = GL.expandPath("//library.blend")
GL.LibLoad(blend, "Scene", async=True)
async=False works as expected.
I try to load a simple scene (suzanne with or without default material)
Reading symbols from /home/moerdn/Blenderprojekte/swiss/install/linux/blender...(no debugging symbols found)...done.
(gdb) run
Starting program: /home/moerdn/Blenderprojekte/swiss/install/linux/blender
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
[New Thread 0xb7fd0b40 (LWP 6181)]
[New Thread 0xb77cfb40 (LWP 6182)]
connect failed: No such file or directory
ndof: spacenavd not found
[New Thread 0xb6fa0b40 (LWP 6183)]
[Thread 0xb6fa0b40 (LWP 6183) exited]
[New Thread 0xb6fa0b40 (LWP 6184)]
[New Thread 0xb25ffb40 (LWP 6185)]
[New Thread 0xb1dfeb40 (LWP 6186)]
[Thread 0xb1dfeb40 (LWP 6186) exited]
found bundled python: /home/moerdn/Blenderprojekte/swiss/install/linux/2.63/python
register properties
Stack init
read blend: /home/moerdn/liLoad.blend
Detected GL_ARB_texture_env_combine
Detected GL_ARB_texture_cube_map
Detected GL_ARB_multitexture
Detected GL_ARB_shader_objects
Detected GL_ARB_vertex_shader
Detected GL_ARB_fragment_shader
Detected GL_ARB_vertex_program
Detected GL_ARB_depth_texture
Detected GL_EXT_separate_specular_color
Done
Blender Game Engine Started
/home/moerdn/library.blend
[New Thread 0xae4f2b40 (LWP 6187)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xae4f2b40 (LWP 6187)]
0x00999f06 in glGetIntegerv () from /usr/lib/nvidia-current-updates/libGL.so.1
(gdb) backtrace
#0 0x00999f06 in glGetIntegerv () from /usr/lib/nvidia-current-updates/libGL.so.1
#1 0x08c30008 in BL_Texture::GetMaxUnits() ()
#2 0x08c16f2f in KX_BlenderMaterial::Initialize(KX_Scene*, BL_Material*, GameSettings*, int) ()
#3 0x08bcf320 in material_from_mesh(Material*, MFace*, MTFace*, MCol*, MTF_localLayer*, int, unsigned int*, MT_Point2 (*) [8], char const*, KX_Scene*, KX_BlenderSceneConverter*) ()
#4 0x08bd2b39 in BL_ConvertMesh(Mesh*, Object*, KX_Scene*, KX_BlenderSceneConverter*, bool) ()
#5 0x08bd33c7 in gameobject_from_blenderobject(Object*, KX_Scene*, RAS_IRenderTools*, KX_BlenderSceneConverter*, bool) ()
#6 0x08bd45a8 in BL_ConvertBlenderObjects(Main*, KX_Scene*, KX_KetsjiEngine*, e_PhysicsEngine, RAS_IRenderTools*, RAS_ICanvas*, KX_BlenderSceneConverter*, bool, bool) ()
#7 0x08be0751 in KX_BlenderSceneConverter::ConvertScene(KX_Scene*, RAS_IRenderTools*, RAS_ICanvas*, bool) ()
#8 0x08bfa626 in KX_KetsjiEngine::CreateScene(Scene*, bool) ()
#9 0x08be1f8b in async_convert(void*) ()
#10 0x00dd1d4c in start_thread (arg=0xae4f2b40) at pthread_create.c:308
#11 0x00cdface in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
(gdb)
I also tried a build from http://graphicall.org/939, but it produces the same crash.
My system is Ubuntu Linux 12.04. Hope this helps.
regards,
moerdn
With the patch from Moguri, it works now for me. Still have to do some further tests, but it looks great so far. With higher density meshes there is still a little bit slowdown on invoking the LibLoad method and on merging the loaded scene into the active one. The loading process is nice and smooth. Great work!
EDIT: LibLoad(…, “Mesh”) is not threaded for now?
greetings, moerdn
Asynchronous Lib-Loading is very nice, indeed, and I’m glad to have it. Asynchronous scene switching would be a nice next step (i.e. loading a certain percentage of a scene in a given game frame). That way, you could have a loading screen in-between scenes in a single game file.
Serializing the needed parts into a blend file might be a good method to use, since a blend file probably won’t open without the other Blender parts.
Something that also needs to be considered is library linking. Since someone can link in objects or characters from external blend files, they would also have to be serialized (otherwise, you would have an unopenable main blend file, alongside unprotected resource blend files). I think one of two things could be done.
-
Someone could add an add-on that performs this serialization function to all blend files in a directory (also with an option to do so recursively downwards), or
-
Someone could add the serialization as part of the BlenderPlayer and run it whenever the game references an external blend file (i.e. loading it, LibLoading a scene from it, using a linked blend file, etc). This process would output a serialized blend file of the same name (i.e. “MyGame.blend” and “MyGame.bge”) whenever the game is run, or whenever the blend file is newer than the “BGE” file. When it’s time for release, you can run through your folders and delete the blend files, leaving the serialized BGE files.
The benefit of method 1 is that you have a bit more control over which files are serialized, and you can even add an option to replace the files (i.e. create a new BGE file from the .blend file, and then delete the ‘source’ .blend file). The down-side is that it’s another add-on to deal with, and so would have to be kept up to date apart from Blender. If the serialization function itself is a part of Blender, though, then the add-on could just call a hook to perform the actual serialization function (making it easier to keep the function up to date).
The benefit of method 2 is that it’s automatic, and you don’t have to think about it; it will always work, though you don’t have direct control over which blend files are converted, and when it does it. For example, you might want it to generate the BGE files for the first release, but you might want it to later leave alone custom blend files that people place in game directories to mod the game.