I feel like Blender Game Engine is a massive waste of dev resources. There are much better game engines out there. I wish Blender concentrated on their core software. Full OpenCL support in Cycles would be nice.
I feel like building the engine in to blender is not very viable because of the GPL license, but using Blender as a game editor is not a bad idea at all - so if you're going to do an OSS game engine I think the best solution would be to start with a more permissive license (eg. MIT or something like that) and not have any dependencies on blender in the actual engine, instead the blender integration code should be strictly separate, that part would be covered by GPL, but the engine core would still remain MIT as it's not derived from GPL code, so you could distribute your game without releasing the source.
According to the licensing page[1], you just need to distribute your executable and core .blend file separately. You would have a (GPL) small python script which loads your (commercial, closed source) blend file containing all of your artwork and Python code.
[1] https://www.blender.org/manual/game_engine/licensing.html#st...
That's simply wrong - your scripts use GPL APIs - this means your code is derived from GPL - if you could just ship stuff that uses GPL at run-time without being affected LGPL would not exist.
And even if that's how they interpret the license this still means you can't ship smartphone apps.
Any content you make using blender is not restricted by the GPL (or any other license). Only blender itself is.
Why does LGPL exist then ?
You're saying you can dynamically link to GPL content from say a scripting language and distribute the GPL stuff separately and you would not be affected by GPL. This is not how I've seen people interpret GPL and is clearly against the spirit of the license. LGPL is meant to cover that use case explicitly.
Python would work well for this purpose, and I have been hearing about usage of Blender in with context of biology, and also things like GIS, and disaster recovery. (I've thrown in disaster recovery as I've at least seen once on TV that it was used modeling Fukushima power plant after the earthquake/tsunami.)
It's not exactly the usual definition of open source.
1. Free Redistribution The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.
2. Source Code The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost, preferably downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed.
3. Derived Works The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.
That doesn't make something "open source". That's closer to "Shared source" if you don't also have the right to modify and redistribute the code.
The UnrealEngine 4 license is definitely not open source by any commonly used definition of "open source" and absolutely isn't using the OSD.
I want to create a model of some real world item (say a simple 2mx2m block for arguments sake) using the exact sizes of the object. Then I want to import it in Unity and have the size stay correct. Iirc one base unit in Unity is 1mx1m so if I make a 2mx2m block I'd like it to be imported and displayed as 2 unity units...for some reason the conversions lead to all sorts of bizzaro size adjustments. Must be a Unity thing but that was a rather frustrating experience.
I've written custom importers for Unity and it's a fairly straight forward process as long as the format you want to export to a format Unity likes from has an exporter you can call from the command line.
You just maintain some metadata on what hasn't been imported yet and use the asset import hooks to activate your conversion to a format that Unity already knows (usually FBX for 3D).
But honestly I wasn't aware that Unity doesn't already have reasonable Blender integration. I've been using Unity + Blender for years and never had too many issues.
It's been broken between Blender versions before because it does exactly what I describe (fires up instances of Blender with a python script that converts to FBX), but you can edit the script that Unity uses to convert and apply fixes which usually get shared pretty quickly.
There's also a little weirdness with the differences in coordinate space, but it just takes some mindfulness on the Blender side of things to deal with.
I don't know how much better the integration could get without going a step further and actually generating the FBX data from outside of Blender, but you can already do that with the same asset import hooks I mentioned before
I'm all for OSS just like the next guy, but saying it would be easier if unity weren't propriety is just FUD.
Also take a look at the ancient .NET integration in Unity that has been strangled by licensing problems with Xamarin. Even though Microsoft has re-licensed .NET recently, it doesn't look like Unity will have an upgrade anytime soon. The only development environment for Unity is C#. Look at the numerous VMs and language integration in Unreal, in addition to any language that links with C++.
Answering your own questions is obnoxious. Public API documentation for software only available behind a commercial subscription is completely irrelevant when integrating with open source.