katharostech / arsenal

Blender game engine prototype written in Rust.
https://katharostech.github.io/arsenal
Other
273 stars 16 forks source link

Live Blender Game Sync #14

Open zicklag opened 5 years ago

zicklag commented 5 years ago

In order to decrease iteration time and facilitate rapid development

As a game developer

I want to be able to tell Blender to sync objects in the Blender interface live with the running game during development. I should be able to select which objects are synchronized with a checkbox for each object in the properties panel.


The synchronization could be one-way from Blender to the game, or it could be two-way. This will require planning and testing to figure out exactly how we want to do it.

This is somewhat related to #15.

Raj2032 commented 5 years ago

https://github.com/katharostech/arsenal/issues/4#issuecomment-502412429

The difficulty with displaying it in the viewport is that we may not be able to get Blender to render the viewport so that it looks exactly like the game. Its one of the trad-offs of using Blender as the primary game building interface.

Isn't it possible to integrate another interface from another game engine and the user can switch between the two interfaces. So for example if in object mode, then the user can use Godot's or some other game engine's interface when moving objects around. But if in edit mode then it uses Blender's interface?

fu5ha commented 5 years ago

Isn't it possible to integrate another interface from another game engine and the user can switch between the two interfaces. So for example if in object mode, then the user can use Godot's or some other game engine's interface when moving objects around. But if in edit mode then it uses Blender's interface?

This seems needlessly complicated and counter-productive, and I'm not sure what you'd really gain since you'd still be switching windows all the time. IMO, we should either try to draw it in Blender (which will probably be non-optimal, though maybe doable and useful in some circumstances), or just make it possible to have a floating window of some sort. Perhaps an always-on-top window so that you can move things in Blender and have the 'live view' window over top of another part of Blender's interface. Alternatively, just get another monitor or more screen space so you can have both open at once ;p

Raj2032 commented 5 years ago

@termhn

This seems needlessly complicated and counter-productive, and I'm not sure what you'd really gain since you'd still be switching windows all the time.

With my proposed idea how would I be switching Windows all the time? May I understand?

fu5ha commented 5 years ago

Well, it would be quite common that you'd want to move something, then modify its properties, then move it again, then change its shape, then move it again, etc, no? So you'd be changing windows each time.

Plus pulling in a whole other game engine's editor just for this seems very overkill and probably not even possible. It would probably be easier and better to just create some manipulation widgets and systems to go with it of our own that could be easily integrated natively into a game

zicklag commented 5 years ago

You could potentially integrate the engine directly into a Blender space or something like that if you re-compiled Blender from source, but I really want to avoid that if possible because I don't want users to have to download our custom build of Blender to use the engine.

We could ship some edit widget components, that you could enable on objects with a checkbox in Blender, to give you control over the objects live in the game like @termhn said. We could also sync those changes that you make with the widgets in the game back into Blender. That might be the best middleground.

erlend-sh commented 5 years ago

@chr15m and @nathankidd appear to have a version of this working in the px3d engine:

https://mccormick.cx/news/entries/clojurescript-pixel-game-engine-with-blender-live-reloading