My 20 cents: Sharing Blender Data: Why can’t we do like Cycles do? I’m almost sure Cycles copy (or convert) some of the data to allow Blender to keep changing things while rendering. Anyways, I think the downside of not allowing for play/pause change material, change object property, … during the game is a big one. But I’m sure, even if the blenderplayer is a separate process we can get that to work.
As for embedding OSX I think there may be a solution, but it’s far from straightforward, leave alone “elegant”. At least that was my first impression when looking at it. Viewport Drawing: I like most of it, but I didn’t understand the need for dropping Single Texture mode. Can’t that be a subset of Multitexture and keep existing? (so it would disappear as a mode, but the same/similar results should be achievable with the same amount of work from the users). I don't even care if internally it's implemented as GLSL shadeless. If implemented properly it can be just as fast as the original fixed pipeline I believe. So it's not a matter of implementation, but instead of allowing for simple workflow/pipelines for the user - in this case, to simplify the assignment of texture faces without having to worry about setting up a full material. Cheers, Dalai -- blendernetwork.org/member/dalai-felinto www.dalaifelinto.com 2013/6/21 Mitchell Stokes <[email protected]>: > I'm all for some better integration between Blender and the BGE. I've > posted an article on my blog detailing how I think we should take our first > steps toward better integration: > http://mogurijin.wordpress.com/2013/06/21/towards-tighter-blender-and-bge-integration/ > > Below is the full blog post for everyone's convenience: > > In Ton’s recent blog post, he discussed a roadmap for Blender 2.7, 2.8 and > beyond, which included a more tighter integration between Blender and the > BGE. While this initially caused quite the stir in the BGE community with > some thinking this meant dropping the BGE entirely, I see it more as a > desire to get the two to share more code. Blender has smoke, fluids and > particles, why shouldn’t we use those in the BGE? Too slow? Then lets speed > them up and make Blender users happier in the process. The way I see it, > the BGE can benefit from new features in Blender and Blender can benefit > from performance improvements from the BGE. But, how do we get there? > That’s what I aim to discuss in this article. > > Sharing Blender Data > > The first major problem that needs to be tackled is how the BGE handles > Blender data. Currently, one of the BGE’s major design decisions is to > never modify Blender data. While the BGE does modify Blender data in a few > places (most notably lights), we’ve mostly stuck to this design principle, > which has helped prevent numerous bugs and potentially corrupting users’ > data. However, in doing so, we’ve had to recreate most of Blender’s data > structures and convert all Blender data to BGE data. This also limits how > we can interact with existing Blender tools. Blender has a lot of powerful > mesh editing tools, but we can’t use those in the BGE because they require > a Blender Mesh object while the BGE has a RAS_MeshObject, and using the > original Blender Mesh would cause that data to change. > > If we want a tighter integration between Blender and the BGE, we need to > allow the BGE to have more direct control over Blender data. This means we > need to find a way to allow the BGE to modify and use Blender data without > changing the original data. The most obvious method is to give the BGE a > copy of all of the data and then just trash the copy when the BGE is done. > However, I think there is a bit more elegant solution to the problem. If > you look at the existing code base, you can see that the Blenderplayer > actually doesn’t have to worry about modifying Blender data as long as it > never saves the Blendfile it reads. Only the embedded player has issues > because it is using the Blender data already loaded in Blender. So, why not > have the embedded player read from disk like the Blenderplayer? When the > embedded player starts, the current Blendfile could be saved to disk and > then loaded by the BGE. There are some details that have to be worked out > here though, such as where do we save the file? A temporary location (e.g., > /tmp)? That will cause path issues in larger games. Instead, I see two > feasible locations: the original file or the original file appended with a > “~”. The first would behave like a compiler would, you save before running > your program, and is the approach I prefer. However, this changes the > current behavior, which might upset some users. > > A more long term solution to the problem of modifying Blender data is to > drop the embedded player. As I mentioned before, the Blenderplayer doesn’t > run into issues using Blender data since it doesn’t share a memory space > with Blender. And, since the Blenderplayer supports being embedded into > other applications, we can still have games running in what appears to be > the viewport. In other words, we would not lose features! Some benefits to > this approach: > > * Get rid of a lot of code (the whole source/gameengine/BlenderRoutines > folder) > * A lot less duplicate code > * Smaller Blender runtime size (all BGE code would only be in the > Blenderplayer, and not Blender) > * Playing the game in the viewport and the Blenderplayer would be > guaranteed to be the same (right now small differences exist) > * The ability to modify Blender data without breaking Blender > * A BGE crash won’t affect Blender since they will be in separate > processes (like Chrome tabs) > > However, there are some downsides, which include: > > * It will be more difficult to affect the BGE from Blender. At the moment > this isn’t a problem, but if we want some goodies like Unity offers with > adjusting the game using the editor while the game is running, we’d need to > develop some inter-process communication protocol to get Blender and the > BGE communicating. > * We currently don’t allow embedding on OS X. I’m not sure if this is a > limitation of OS X itself, or a lack of development effort on our part. > > Using Blender Data > > So, we’ve got some ways to minimize the issues of the BGE using Blender > data, but what do we do with it? First off, I’d start to clean up the BGE > code to use DNA data as storage and then shift the focus of the various BGE > classes to act as wrappers around that storage. Where possible, the member > functions of those classes could delegate to the various Blender kernel > (BKE) functions. Once that is done, we can look into what Blender goodies > we can start adding to the BGE using these new classes. > > Viewport Drawing > > While the BGE and Blender already share a fair amount of viewport drawing > code (especially in GLSL Mode), this area could be much improved. The first > task here is to get all of the OpenGL (and any calls to bf_gpu) into the > Rasterizer, and only the Rasterizer. This requires moving material and > lighting data out of Ketsji and into the Rasterizer. Once this is done, we > can worry about how the BGE handles it’s drawing. The Rasterizer should > have two modes (possibly implemented as two Rasterizers): fixed function > pipeline and programmable pipeline. To do this, I would propose dropping > Singletexture and making Multitexture code the basis for the fixed function > Rasterizer, while GLSL mode would be the basis for the programmable > Rasterizer. The programmable Rasterizer could have an OpenGL minimum of 2.1 > as Ton suggested for his proposed roadmap, but I’d keep the fixed function > Rasterizer as compatible with older hardware as possible. > > After we have the Rasterizer cleaned up, we can start offloading as many > tasks as possible from the Rasterizer to the bf_gpu module, which the > viewport code also uses. The more we can put into this module, the more > Blender and the BGE can share viewport drawing. Ideally, the Rasterizer > would not have any OpenGL code and would rely entirely on bf_gpu, > maximizing code reuse and sharing. > > Conclusion > > Using the ideas outline in this article, we’d have two main points of > interaction between Blender and the BGE: BKE and bf_gpu. We could certainly > look into more ways to increase integration between Blender and the BGE, > but what I have discussed here will give us more than enough work for the > foreseeable future. Also, please note that this is only a proposal and a > listing of ideas, and by no means a definitive plan. Discussion and > feedback is much encouraged and appreciated. > > --Mitchell Stokes > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
