Khronos has introduced glTF: a new runtime asset format for WebGL, OpenGL ES, and OpenGL applications.
It can handle mesh data, animations, textures, and shaders:
Concretely, a glTF asset is represented by:
JSON file (.json) containing the node hierarchy, materials, and cameras
Binary files (.bin) containing geometry and animations
Image files (.jpg, .png, etc.) for textures
GLSL text files (.glsl) for GLSL source code for individual stages
Binary, image, and GLSL files can also be embedded directly into the JSON using data URIs.
So is using this a good idea? Can we use this as a custom file format for BGE? If we use say ‘.bullet file format’ along side it for physics?
The idea is that it takes collada (.dae) files and converts it into this new format. It would be nice for BGE to read data that is not the entire .blend file (data that is only relevant to the game engine).
However BGE has a whole lot more additional data that it needs: like game logic bricks, PyNode data in upcoming 2.67, among other things. So baking .blend files into .bge files maybe the better approach, since .blend files will always contain the complete set of data.
By baking .blend files into .bge, I mean removing some data from the .blend files that is not relevant to the game engine.
The advantage of the blenderplayer is that it can use .blend files as they are. A few other formats can be used already (like image formats, sound files).
Introducing different file formats has it’s own benefits and drawbacks.
To support other file formats you need to write according converters.
@Sinan - I don’t really see the need to adopt this file format. Another format would need to supplement the unavailable data, as you pointed out, so it wouldn’t really be that helpful. We also wouldn’t be able to play non-BGE games in such a format, since the necessary data is still unavailable.
However, another BGE-specific file format would definitely be useful for the licensing and security issues currently present with the BGE. I’m all for another format that only the BGE can load.
glTF looks promising. I hope they do a better job this time then what they did with Collada.
The direct direct mapping to OpenGL seems very nice.
As already pointed out: game data is more then graphics.
And this file format is meant for optimized rendering.
Using glFT means easy to use rendering data and probably faster & optimized rendering as you don’t need to convert anything and just can use what comes from the file. That also eases streaming data. Mapping the file directly in RAM or on a SSD / flash drive you get “instant” access. Fast and easy.
Using the new filetype should be beneficial.
As you can already use extern images and text files it should also be possible to include glFT and in the blend file say “there is the graphics data, right in that file”.
Creating a “BGE only” all-in-one file format is nonsense.
First: as Blender and BGE is open source the new file type also might be open source. How else you gonna implement & use it? And as long as the specification is open somewhere anyone can write importer and exporter for any software. So the format will be non-BGE-only in no time.
Second: one BGE file to include all needed assets is painful. In a normal development environment you have lots of files. Sounds. Graphics. Scripts. Mesh data. Shader. Material. etc… It is much easier to change just the one file you want then open one big file and then edit in there. With a bigger team it is also easier to exchange many little files then one big file all people are working on. And a blend file is not supported by any version control system (afaik).
Some engines, like the id tech ones, allow there assets to be packed in an archive. After you developed with lots of files and a filetree you simple archive the filetree with its files and deploy the executable with the archive.
id tech 4 has an extremely nice asset and file situation. Nearly all files are human readable text files. They integrate smoothly in VCS.
The downside is that they doesn’t load as fast as binary files could.
Security for assets is a joke. “They” might not be able to tackle a secured file alone. But at least your game knows how to de-secure the file so it can access its content. With a open source game engine and file format “they” can find the method of security very fast. It probably contains some password. And your game knows that password because else it couldn’t access the file. So those people just need to scan your game for the password and can access your file.
As long as people can get access to your game and its contents they also can get access to the assets. It’s just a matter of time and knowledge.
And what licensing issues are you talking about?
BGE is GPL. Right.
And your content is under whatever you like it to be.
Just because of using another file format doesn’t change your rights.
There is no issue using “blendplayer file.blend”.
The exporter could easily be rewritten to create a script to start the game that way then to append the blend-data in the blenderplayer.
probably the less useful thing in the entire Khronos history, I can’t see the point of this, I hope that they will push on the StreamInput library because it will be far more useful than this thing.
I don’t know how a format can be ‘optimized’ when it’s general purpose - not every game and engine works the exact same way. Blender meshes are already converted into a BGE-usable mesh when you start the game engine, as far as I know. I think it’d be far more effective to optimize that converter for Blender mesh > BGE mesh that handles all of the nuances than to write a new one for Blender mesh > GITF format > BGE mesh. In order for GITF to serve its purpose, the BGE mesh would have to be written to load it in and apply the optimizations, so why not do it from the start with the conversion from the Blender mesh?
In order for Blender to be able to use GITF, someone would have to write the source of Blender to be able to convert blend data to GITF format. That part of the source would also be GPL. The GITF format also must be open to some extent, otherwise it would be impossible to write an exporter for it - you have to know what you’re converting meshes to.
Someone could write an external Python add-on (presumably) that does this and thereby sidestep the GPL problem, but dealing with such close Blender data (mesh, texture, sound, animations, etc) out of source probably wouldn’t be wise. I would imagine it would make maintaining the exporter a right pain as Blender develops.
My preferred method of the BGE format would also make the exporter part of the source, but I think it would strip out the Blender data, thereby making a file that can’t be opened by Blender. Also, just as the blend file format isn’t GPL, the BGE file format wouldn’t be either.
As a side-note, with a common file format, any importer for the data would work for the BGE as well, thereby rendering it relatively insecure. It would only take someone to write an importer for a GITF file for Unity or UDK or whatever for it to be possible to convert a GITF file to a obj file, or a GITF file to a wav file, or whatever’s inside of it.
The more advanced into Blender and the BGE you go, the more you learn about how it’s available to you to externalize things like this. Shaders can be written in files and loaded in via Python, if you wanted. Scripts can be external to the blend file, if you specify them to be via Module mode. Graphics (image data) are easy to be external to the blend file, and external sounds can be loaded in via the Audaspace Python module. Mesh data and materials could be external blend files. Just link everything up, and allow everyone to work on the portion of the game that they need to.
The problem with this to me is that when you’re finished and distribute your game, the blend files are just ‘out in the open’. In the way I envision it, either:
Exporting a blend file as a run time would convert it and all linked blend files (and all linked to them as well, etc) to a BGE-specific, Blender incompatible format, or
Accessing the blend file at run time would convert all ‘touched’ blend files to the BGE format.
You make an interesting point about packing the game data in an archive. That might make distribution simpler.
I’m not sure what you’re referring to here - security for assets with the BGE currently? If so, the idea of a new BGE-specific format would mean that you couldn’t really get at the data - at least, not with Blender. I think it would be wise to just strip out the Blender data, leaving something that can only be opened by the BlenderPlayer. You could append dummy Blender data to the stripped areas, but that’s kind of a lot of measures to take just to get at some data. (And it’s not like commercial games are foolproof anyway - you’ve got meshes from closed AAA CD games out there on the Internet, and hacks for disc-based console games.)
I was referring to the issues of BGE being GPL, and you either choosing between having your file be external and exposed (bypass GPL), or bind it in with the executable to be relatively more secure (and thereby fall under GPL). You could try other things, like BPPlayer, or encrypting your file, but it’s not really that secure.
"We also asked Ton Roosendaal about gITF, and he said:
The launch of a new file format, glTF, is a confusing message. It’s presented as a “transmission format”, as a companion to COLLADA. Its specs seem to align to render engines more, allowing fast reading, so hopefully it has a much more narrow specification than COLLADA. If so, this then could become an exchange format as well. But why bother of using COLLADA then?
It’s possible that with the focus on WebGL (and glTF) COLLADA gets the momentum again though. Maybe it’s not the a suitable format for film/animation pipelines, but to kick off “3d on the Web” it might well be the best choice we have."
Like one or two others have already mentioned, before the devs. even consider the use of this format, we need to find out the possible advantages and disadvantages compared to the .blend file format.
So imagine that the .blend file is now converted to a gITF file when ‘P’ is pressed, will it increase FPS and overall performance, will it give the game features that are currently not possible, will the startup time decrease? The reason these questions should be asked is that if there’s no clear advantages (and especially if it lacks some of the major features of .blend files), then it’s better just to stick with the .blend format.
The whole point is, that you as gamedeveloper do not care the dataformat. This is the purpose of the framwork (bge indeed). You want the framework to provide you with the necassary functions to run your game. You choose the dataformat that carries the data you need. E.g png, tga when you need alpha channel, dds when you need mipmap, jpg when you need small filesizes.
There are indeed demands that are not satisfied by the blendfile format. For example hard data extraction (often referred as security). Better integration towards versioning systems, streaming data…
Gltf is the in application format, we’ve all played with different importers, OBJ,FBX,DAE blah blah blah. Gltf is all about the in engine format, it’s not efficient to run full on fbx, DAE models realtime. So we need an in Opengl format to convert our many import format geoms to a workable in engine format (Im not talking about BGE, wouldn’t touch it with a barge pole) for all opengl engines. If your discussing that this should or shoulnt be included your nuts. OPENGL FULL STOP HAS NEEDED AN OPTIMISED IN ENGINE FORMAT FOR YEARS. Support this dev!.
This is the Blender Game Engine section of the forum. The focus of this discussion is how and if this new file format can be used with the BGE. If it can’t be used with the BGE, there’s not much any of the BGE developers can do with it, as BGE users have no need for importing game models. If your point is that it should be supported in Blender for import and export, then that’s another topic entirely.
