I think you are really off track on my proposal. The engine, Doom 3 BFG for simplicity, has 3 model formats supported: ASE/LWO for non-animated meshes, and MD5model (md5mesh/md5anim) for animated skeletal models. Blender can already export into all of that with various add-ons written by various people. LWO export add-on is the most recent one, ASE/MD5 are old. MD5model add-on is particularly messy as it was dragged from 2.49 to 2.5x, then to 2.6x and is messy. All that needs to be cleaned up to be easily maintainable and probably be included into Blender official releases.
All that is for getting models out of Blender and into the game engine.
There is already LWO import add-on, official. We would need ASE import and MD5model import add-on (it exists for Blender 2.49 actually).
And then there is map format. I already have basic map export add-on for Blender, but turning Blender into level editor would be a long process, where UI for level editing tools needs to be thought out and a lot of pre-production needs to be done before even attempting to improve that add-on and make import add-on.
That will constitute tight integration for assets creation pipeline with Doom 3 BFG engine.
Nowhere I proposed a new universal format to be invented. You were the one saying .blend file should be used.
I tried to understand what you mean with tighter integration since you wrote it. The answer seems to be LWO, ASO and MD5 support and preferably the map format at first. As you write, basically the asset creation pipeline for the Doom 3 BFG engine.
You could technically employ nodes system (unless it’s hardcoded specifically for materials only) in Blender to create visual scripting system, which would generate script code for the engine. Same could be done for materials, but since game materials utilize GLSL shaders, it wouldn’t be possible to have accurate preview of game materials in Blender.
Hell a lot? Not really. It doesn’t have to be done at all in Blender. I would rather prefer having Qt5 based tools that are built into the engine utilizing native rendering for preview, than put it into Blender (and of course BF wouldn’t be dealing with that part of the development).
And yes, it’s for one specific engine. Isn’t BGE a one specific engine? Yes it is. The whole conversation that spilled out has been about supporting one particular engine and have tight compatibility (I feel like using “integration” will confuse you all over again ) between Blender and that engine. And the whole purpose is to provide alternative to BGE, where people grab Blender, grab the new engine and make their game without worrying about breakages in FBX or stagnation of BGE.
Note that while it’s hard to find savvy programmers to improve game engines, it’s easier to persuade someone to improve iD Software engines, than to mess with BGE. Besides all other good reasons, it looks better and more valuable on a programmer’s resume.
Btw, it’s not a proposal to drop FBX support. It’s just a sound option for commercial development using GPL engine and GPL 3D app.
The fbx situation isn’t as bad as it sounds here in the forum. I am using the Blender fbx exporter (old and binary) on a daily basis. There are issues from time to time, but I never got to a point where I couldn’t find a workaround. It is definitely getting better and better. The same is true for the importer.
I personally doubt that there is a market for commercial GPL game engines at all, but that is just an opinion.
While there is very little room for GPL engines, there is a lot of room for games made with GPL engines.
My game was made using GPL engine, and it’s been on Steam since 2011.
For GPL engine to be a success, one needs a paid service surrounding the engine. Training, paid programming/assets creation services, marketplace, etc.
no market for a serious developer atleast. BGE stuff makes for a fun weekend project. but i would never base anything “real” around an open source license that would allow anyone to take my assets and run with them. of course, you can release under a dual licence. since anything not in the BGE standalone exe, referenced from an outside folder, is not under the terms of GPL. something like “engine is free to use, heres were you get the source code… but if i see my models used somewhere else, you will get to talk to my lawyer!” lol
less confusing to just go with a proprietary solution IMO.
i see no issues with GPL TOOLs however. some people are under the misconception that because the model is created in a GPL tool. that the model is GPL as well. this couldn’t be farther from the truth!
I hope you guys realize people don’t give a crap about what license the game is under? If you are so concerned, just put EULA upfront before the game is executed, stating that the game as a whole can not be redistributed because the content is proprietary, but engine is free, so binary and source code are totally free. In 99.99% user will click Agree and will play the game. 0.01% will read it, scratch their head and click Agree anyway.
Another good rule of thumb is not to mix non-GPL and GPL stuff. For idSoftware engines is simple - gamedata folder and DLLs/exe are separated. They can even be in entirely different folders. So aggregation(?) clause of GPLv3 is satisfied which makes it less of a gray area.
yeah, the average player doesn’t give a crap. but there are lots of ignorant people out there that think open source = free and anything made with open source = free as well. so if you want to try to build something commercial, you have to take steps to safeguard your assets against those who would hijack your work and distribute it under their name: IE copyright infringement. the seperate folder solution works according to the letter of the law, but the confusion surrounding GPL among those who do not educate themselves of it mean that you are far more likely to have to defend your copyright against some kid who wanted to use your models to make his epic BGE game without any idea that the models had any restrictions on them.
also, BGE is a junk engine at the moment. python… need i say more. add C# or at least Java support to the scripting engine and then there might be something there worth talking about.
Seriously? Do you realize that C# and Java would require bringing in virtual machines larger in size than the game engine itself?
Don’t get me wrong, both Java and C# are languages with a lot of good things to offer… but in terms of size, memory footprint, and performance - they make awful choices for scripting a C/C++ engine.
Actually you need to say more, when one makes bold unjustifiable claims unless he wants them to remain worthless, he has to justify them with some kind of evidence of sort.
Question : why you would use highly verbose languages like Java and C# as scripting languages in the first place ? As the language for your game engine I get it, but as a scripting languages , really ?
Don’t get me wrong, both Java and C# are languages with a lot of good things to offer… but in terms of size, memory footprint, and performance - they make awful choices for scripting a C/C++ engine.
The memory that Java uses is around 50 mbs from what I read around the internet which is peanuts for a modern computer. Performance wise its on par with C/C++ (in some cases slower in some cases faster) since like a decade now. Hell even modern Python can compete with C/C++.
Disclaimer: I dont use nor I care about Java, what I do care is people taking the baits of stereotypes without a second thought.
I would have discussed also “junk engine” remark about BGE but that argument collapsed since it first second.
Everybody has their pet language and the song always goes “Meh, they should at least support Haskell for scripting. Serious use is impossible otherwise.”
In truth, unless you’re fighting for every scrap of ram on a memory-challenged platform in a really serious production, the choice of scripting language is pretty immaterial. If you’re really that desperate for performance, go the UE4/id Tech 5 route and just do your scripting in your engine’s native language.
The part that’s actually important in game scripting languages is iteration time and accessibility for designers. You can use a dedicated language and an interpreter to do that, or you can just ensure nice separation of engine code and game code and quick compile times via a good API. But really, performance and footprint are secondary as long as they’re not too terrible.
Well, I might disagree with it being “peanuts” but that doesn’t really matter. In terms of of a “scripting language” that is still very heavy for a virtual machine and it’s required libraries. You then need to add on the requirements added by the game. LuaJIT needs under 300Kb of memory (and that includes loading all the JIT functionality). Python takes a couple of megabytes. You might not think much of 50MB, but you need to compare it to the alternatives given we’re actually talking about the best out of the alternatives
Um, no. On both counts. Firstly, Python is nowhere near C/C++ in regards to speed. It is 3x slower when doing simple tasks (where most of the functionality is actually in C/C++) such as regex & reverse complement benchmarks. It’s 100x slower than C/C++ when most of the code is actually in Python itself (such as when solving the n-body problem).
Java can be much better than this (1.5-2x slower depending on the task) but it requires 3-4x the memory on the same benchmarks. Not to mention that the performance relies on JIT hotspot technology which doesn’t hold up so well when jumping in & out of engine code. Trust me, I’ve crunched the numbers on a variety of languages AND I code Android apps that jump in & out of JNI native code I’ve written. I’ve done the math - Java does not hold up as a scripting language.
Me, I quite like Java. Use it everyday. It’s a great language for the tasks it is designed for. It is not a language designed for scripting. It is a language that works best when it is the sole language being used. It loses performance when jumping in & out of JNI code (such as that required for a scripting solution).
This is not about stereotypes. It is about the right language for the right task. Java is not the right language for scripting.
Indeed and it pays for it in terms of memory usage. Including the .NET Micro Framework in an application requires 12MB (~6x Python, ~60x LuaJIT). Unity doesn’t use the micro framework designed for low memory footprint, so it’s the .NET footprint it’s hitting is going to be higher than that.
Just because someone uses a language doesn’t make it the best language for the task. Wings3D uses Erlang. I don’t think you’d find anyone outside the wings dev team (and maybe a few die-hards inside Ericsson) who think Erlang is the best or even a good language for the task.
For what it’s worth, it would be more correct to state that Unity is using .NET which comes with JavaScript, C#, and even a Python “facade” to the same underlying runtime
Unity uses JS and C# for “scripting” of the game code.
Unity is based at Mono, which is Net already. And you can directly call C# stuff from within Unity. I did it with a file dialogue. Also with Unity JS or BOO by the way. Unity compiles all code to CLI, so it doesn’t really matter what language you use.
BOO is, or better was, a Python dialect. At least from the syntax. It had so few followers that they are skipping it now for Unity 5. So it seems that Python is not as popular as some wish it to be.
For once, don’t call your game “open source game” just because it uses GPL engine. It’s not an open source game since assets are proprietary.
Again, people don’t care. I released commercial game using Darkplaces game engine (GPLv2) and proprietary assets, on Steam, and the game contains source code for the engine. Assets are in the plain sight. No one used it, because assets (except maybe textures and sounds) can’t be used with any other engine. And to the date, no one else released commercial game using Darkplaces engine. The game comes with EULA that breaks down what’s GPL and what’s not.
So I don’t really understand where that misconception about “GPL game will be stolen, blah blah” comes from. Technically, none of the small indie shops has enough funds to hire a lawyer anyway. So even if you use proprietary engine, and someone takes your assets, modifies it and uses it, they won’t be capable of taking the case to court to to heavy fees involved.
With Doom 3 BFG engine it’s even better - engine compresses textures and binarizes assets into a proprietary format, upon deployment for distribution, which you can not convert back into original form. So the only way to use the assets is literally copy the game 1:1, which would be clearly understood as copyright infringement. No developer would go for that.
I completely agree with you, I would not even consider using a language that would consume 0.5% of my Ram to load a ton of libraries that gave me easy access to cross platform features.
Um, no. On both counts. Firstly, Python is nowhere near C/C++ in regards to speed. It is 3x slower when doing simple tasks (where most of the functionality is actually in C/C++) such as regex & reverse complement benchmarks. It’s 100x slower than C/C++ when most of the code is actually in Python itself (such as when solving the n-body problem).
Yes I am sorry I was wrong I should have said that python is 100 times slower than C/C++ assuming :
a) the speed wildly fluctuates from benchmark to benchmark
b) That python libraries unlike C libraries don’t even care about speed since modern technology far exceeds the demands of the average user
c) that you don’t C with python because afterall this one of the main goals of cpython.
d) that you dont mean PyPy which is anyway 2x - 10x times faster than cpython
e) you dont use cython which is afterall a dialect of python and what many python coders use
f) you dont use ctypes to use existing dlls
g) you dont use any of the myriads of optimised python libraries like numpy, scipi , blaze and much more
h) you dont use gpu accelerated code which in that case it wont even matter what your main language is it will still run circles around C code that depends on heavy parallelisation
i) you dont use fotran which also cpython interfaces well which can also outperform C/C++
j) you dont use assembly which also can also outperform C/C++
k) that the code you using is heavily unoptimised for the job you want to do
l) that you ignore or dont know that python and cpython in particular is used in many fields of performance depend demands like AI , etc.
And the best for the end, all the above is that ALL languages out there can do these things. Even my language of choice Pharo , which is very unpopular can do all that and way more for optimising speed like including an inline assembler if machine code is your thing.
Java can be much better than this (1.5-2x slower depending on the task)
(and 2x faster)
but it requires 3-4x the memory on the same benchmarks. Not to mention that the performance relies on JIT hotspot technology which doesn’t hold up so well when jumping in & out of engine code. Trust me, I’ve crunched the numbers on a variety of languages AND I code Android apps that jump in & out of JNI native code I’ve written. I’ve done the math - Java does not hold up as a scripting language.
You always going to have tradeoff, because thats how implementations work. Something you gain something your lose. Rest assured if the average developer wanted super low memory footprint then Java would provide super low memory footprint. C for example is usually, not always, but usually so fast because C was made for speed. Its the language that was invented to create an OS back in the days when even the tiny bit of performance penalty was a huge flaw.
And since also with Java you can mix code, well any language can do that, with C. Use C for lowering your footprint again assuming Java cannot do this by itself and save yourself from the horror of debugging C code for your entire application.
Me, I quite like Java. Use it everyday. It’s a great language for the tasks it is designed for. It is not a language designed for scripting. It is a language that works best when it is the sole language being used. It loses performance when jumping in & out of JNI code (such as that required for a scripting solution).
Me I dont like java, its too like C++ , verbose and with C++ one of the worst ways to implement OOP. I am however very interested in some of its very powerful cross platform libraries so overall I dont hate like I do C++.
C is ok , its still horrible to work with for serious coding but at least its smaller than C++.
This is not about stereotypes. It is about the right language for the right task. Java is not the right language for scripting.
C++ is a horrible language that needs to be nuked from orbit , python is far from ideal but at least it allows one to code without losing his sanity.
) between Blender and that engine. And the whole purpose is to provide alternative to BGE, where people grab Blender, grab the new engine and make their game without worrying about breakages in FBX or stagnation of BGE.
