Probably this deserves its own project repository, but this issue would serve
as an infoboard about one of Curio's integration possibilities.
Highlights:
Blender: www.blender.org. It embeds complete python environment installed on
the machine. So you have everything. On gui every operation performed by the
user is logged on a panel as 'Python Calls' so you may copy and reuse them
in you scripts. That's an important accelerator for development.
With the rise of networked game engines, collabrative modelling,
and parametric/programmatic (perhaps networked) CAD engines, there is
certainly interesting opportunity here. There is already some Blender community
inertia for those.
Non threaded scripts cause Blender to wait for script to finish which
results in all other functionality (especially GUI) to freeze. So they are
intended for short running scripts.
https://github.com/z25/BgeHttpServer
An other solution is for headless blender. Python script owns
the main thread and can perform however it likes. Naturally
there can not be any gui. All operations can be done via
REST gateway/backdoor.
Perhaps we may expect a proper (and safe) engine access
support on blender for upcoming releases. But even without it, above
approaches can employ Curio.
Probably this deserves its own project repository, but this issue would serve as an infoboard about one of Curio's integration possibilities.
Highlights:
Blender: www.blender.org. It embeds complete python environment installed on the machine. So you have everything. On gui every operation performed by the user is logged on a panel as 'Python Calls' so you may copy and reuse them in you scripts. That's an important accelerator for development.
With the rise of networked game engines, collabrative modelling, and parametric/programmatic (perhaps networked) CAD engines, there is certainly interesting opportunity here. There is already some Blender community inertia for those.
Currently threaded python scripts can not safely access Blender internals. There is no thread safety. See: Strange errors using ‘threading’ module https://docs.blender.org/api/blender_python_api_current/info_gotcha.html
Non threaded scripts cause Blender to wait for script to finish which results in all other functionality (especially GUI) to freeze. So they are intended for short running scripts.
https://github.com/akloster/blender-asyncio One solution for long running scripts. It uses asyncio, a mix of execution time sharing and some capabilities of blender. https://blenderartists.org/forum/showthread.php?405124-Running-background-jobs-with-Asyncio
https://github.com/z25/BgeHttpServer An other solution is for headless blender. Python script owns the main thread and can perform however it likes. Naturally there can not be any gui. All operations can be done via REST gateway/backdoor.
Perhaps we may expect a proper (and safe) engine access support on blender for upcoming releases. But even without it, above approaches can employ Curio.