For an upcoming game I’m designing (not using BGE), I need Blender to modify some meshes in the background while the game is running. In other words, I need blender to perform its magic on a few meshes with the game renders the updated meshes with the player completely oblivious that Blender is doing some work in the background.
What is the recommended simplest way to do this?
Should I compile Blender in my exe, hide its window and serialize the meshes through C++ structures?
Should I write Python scripts to launch Blender in hidden mode and serialize the meshes to my C++ executable through Python and TCP/IP sockets?
Which approach is best? Is there a sample or code framework that does something like I’m trying to do?
(I’m a pretty good C++ developer and should have no problem serializing the meshes between my game and blender)
In this particular case the mesh modifications I need to do don’t need to run in real time. Also we’re not using BGE for our game, and the feature we’re trying to export to our game (cloth fitting) we’re looking more to the non-BGE cloth simulation than the BGE one.
Are there existing works that enable Blender to do mesh editing in the background and perform mesh editing to a hosting application?
what kind of changes or interchange do you wanna achieve? I wonder if you really need something running in the background… For export, you can simply bake everything and save to file with a python script.
Hi CoDEmanX, interesting link that Verse… will research to see how they did mesh serialization…
I need to perform cloth fitting in-game… essentially running a blender cloth simulation but have the result displayed in game without the player being aware that blender is running…
Hi CoDEmanX, interesting approach. As per just using the blender part that does cloth fitting this can be hard to do right and other features of blender (like soft selection) are useful to our game… so right now just leveraging blender ‘behind the scene’ appears to offer many benefits…
I think finding a way to hide blender when it starts by launching it to run on a Python script and have that Python script listen to TCP/IP messages coming from our game appears the best approach… This seems so useful to so many other games that I find it strange that I haven’t seen this approach used yet…
Is anyone out there using blender to perform tasks ‘in the background’ for another app??
you can run blender without UI and call multiple python scripts (you can also prepare a .blend with a py script in text editor and tick Register to make it run when .blend is loaded)
But I don’t know if you can start a modal python operator, which would listen to data and do the stuff you need (i believe modal ops are the only way to do something with python without locking blender in the meanwhile… an app handler for scene_update_post should also work, but may be slow)
//edit: i tested both methods and they work quite fast as long as the scene isn’t too complex. Not sure what happens if blender runs in UI-less mode, it should be actually always fast as there’s nothing to render in viewport… but dunno if app handlers / modal ops work in UI less mode
import bpy
class ModalTimerOperator(bpy.types.Operator):
"""Operator which runs its self from a timer"""
bl_idname = "wm.modal_timer_operator"
bl_label = "Modal Timer Operator"
up = True
_timer = None
def modal(self, context, event):
if event.type == 'ESC':
return self.cancel(context)
if event.type == 'TIMER':
loc = bpy.data.objects['Cube'].location
if loc.y > 5:
self.up = False
elif loc.y < -5:
self.up = True
if self.up:
loc.y += 0.1
else:
loc.y -= 0.1
return {'PASS_THROUGH'}
def execute(self, context):
self._timer = context.window_manager.event_timer_add(0.001, context.window)
context.window_manager.modal_handler_add(self)
return {'RUNNING_MODAL'}
def cancel(self, context):
context.window_manager.event_timer_remove(self._timer)
return {'CANCELLED'}
def register():
bpy.utils.register_class(ModalTimerOperator)
def unregister():
bpy.utils.unregister_class(ModalTimerOperator)
if __name__ == "__main__":
register()
# test call
bpy.ops.wm.modal_timer_operator()
import bpy
#bpy.types.Scene.up = bpy.props.BoolProperty(default=True)
up = True
def t(s):
global up
#s.up
#print(s.up)
loc = bpy.data.objects['Cube'].location
if loc.y > 5:
up = False
elif loc.y < -5:
up = True
if up:
loc.y += 0.1
else:
loc.y -= 0.1
bpy.app.handlers.scene_update_pre.append(t)
# Stop:
#bpy.app.handlers.scene_update_pre.pop()
Hi CoDEmanX, thanks very much for the help and these useful scripts… I’ll give this a try for sure! The UI-less stuff is great!!
However in regards to blocking, the only purpose of the blender instance launched by my game is to serve commands from my game so it’s ok if blender gets TCP/IP command, block until done, then send TCP/IP answer. Given that, do you think the answer is simplified?
i worry you rely on something hakish like what I posted. You can let blender perform a task, preferably rendering, and once done it will shut down. But as you want it to run constantly in the background waiting for commands, you need to have a script running and receiving commands (haven’t tried this). Instead of the for-loop i used, you could check for a “terminate” message to keep blender running until you want it to quit. Not sure about the blocking aspect… Maybe you can store system microtime, call scene.update, check system time again and wait a certain amount of time depending on the time the scene update took (if it took long, don’t time.sleep, if it was fast, sleep the max. interval) - just a random idea to compensate a varying time in which blender performs a task in “blocked” state.
Hi CoDEmanX, thanks for the advice & the code. I’ll try this out soon and hopefully we can make blender modify the mesh for our game without too many problems!
