Godot 3.0 Alpha 1

[Preses]

Então, finalmente a primeira versão alpha do Godot 3.0 saiu!

Tô pensando em depois fixar este tópico como oficial do engine ou criar outro.

Vou escrever mais extensivamente sobre o engine, mas saiba que esta versão promete bater de frente com o Unity.

Por enquanto, é só para ver como está mesmo. Os devs já avisaram que está cheia de bugs, não serve para projetos sérios e nem há ainda documentação e lista de features. Mas não deve demorar muito.

Por enquanto: bora testar!

DEV SNAPSHOT: GODOT 3.0 ALPHA1

After almost one year of development, the master branch (future Godot 3.0) is mostly feature-complete and ready for broader testing by the Godot community. We are therefore releasing a first alpha snapshot for existing users to play with and report bugs.

DISCLAIMER
IMPORTANT: This is an alpha build, which means that it is not suitable for use in production, nor for press reviews of what Godot 3.0 would be on its release.

There is still a long way of bug fixing and usability improvement until we can release the stable version, and this release comes with virtually no documentation. This release is exclusively for testers who are already familiar with Godot and can report the issues they experience on GitHub.

There is also no guarantee that projects started with the alpha1 build will still work in alpha2 or later builds, as we reserve the right to do necessary breaking adjustments up to the beta stage. Finally, the desktop platforms (Linux, macOS, Windows) are the only ones in a usable state, Android, iOS, UWP and JavaScript all need further fixes to properly support the new Godot 3.0 features.

Note: New Godot users should not use this build to start their learning. Godot 2.1 is still supported and well documented

THE FEATURES
Now, there are still some cool features that can already be played with in this alpha1 build, and we are looking forward to seeing what you will come up with using the new 3D renderer. There is no exhaustive listing of all the new features to experiment with, but you can read past articles of this blog and check Juan's Twitter feed for some teasers :)

Please use the community channels to discuss with existing users and learn how to use the new workflows of Godot 3.0 - as of this writing there is almost no documentation on the new features, but this alpha1 build should serve as a starting point for documentation writers.

DOWNLOADS
The download links are not featured on the Download page for now to avoid confusion for new users. Instead, browse one of our mirrors and download the editor binary for your platform and the export templates archive:

• Mirror 1 (HTTPS)
• Mirror 2 (HTTP)

Also clone the godot-demo-projects repository to have demos to play with. Some of them might still need adjustments due to recent changes in the master branch, feel free to report any issue.

BUG REPORTS
There are still many open bug reports for the 3.0 milestone, which means that we are aware of many bugs already. We still release this snapshot to get some early feedback while we work on fixing the known issues.

As a tester, you are encouraged to open bug reports if you experience issues with alpha1. Please check first the existing issues, using the search function with relevant keywords, to ensure that the bug you experience is not known already.

You can also consult this list of known issues, which is a hand-picked list of the most visible problems you will likely encounter.

FAQ
We can already see many questions coming regarding this development snapshot, so here are some answers.

What is the ETA for Godot 3.0 stable?
When it's ready. We're all working on our free time on this project, and can't commit to a given deadline. We consider the master branch to be feature-complete, and we are now working on fixing bugs in the new features and enhancing the usability of the new workflows. Depending on how it goes, we may be able to release 3.0 stable in a couple of months.

Does it support C#?
No, the alpha1 build does not contain the Mono/C# module yet. It should soon be merged in the master branch, so it might be available in alpha2. The 3.0 stable release will support C#, the integration is almost ready.

Does it support Vulkan?
No, and there are no plans for Vulkan support for the time being. Our resources are too limited to focus on too many renderers at the same time, and the new OpenGL ES 3.0 / OpenGL 3.3 renderer of this build was already a huge refactor. Vulkan being only relevant for a small fraction of our users, it's low priority for now.

How to run my 2.1 game in the alpha?
Projects from Godot 2.1 are not compatible with Godot 3.0, as many things changed in the Godot API as well as in GDScript. There is no porting guide for now, but there is an export tool in Godot 2.1.3 and later which can be used to export 2.1 games to the formats expected for Godot 3.0.

Since the master branch is a moving target, the exporter in Godot 2.1.3 is already outdated and won't work as smoothly as it should. Your best bet is to compile the 2.1 branch yourself to use the latest version of the exporter, and report any issue you experience with it.

How to use GDNative?
As for most features, it lacks documentation for now. Still, you will find some infos on the godot_headers main repository, as well as the CPP bindings. You can use the Q&A with the gdnative tag to mark your questions; Thomas (Karroffel) will do all he can to help you get started.

Will there be more alpha builds?
Yes, as the name "alpha1" suggests, we plan to have newer builds regularly to bring the latest state of the master branch. Depending on the user feedback we get, we might make weekly releases or biweekly if it proves too much burden.

Site oficial: https://godotengine.org

 

[Zeorymer]

Muito bom... mais como esta com bugs ainda melhor só testar mesmo hehehee

 

[Preses]

Muito bom... mais como esta com bugs ainda melhor só testar mesmo hehehee

Pois é! Por enquanto, só para matar a curiosidade e já ir pegando o jeito.

Meu próximo projeto sério pode esperar alguns meses. Então, para mim, está tranquilo. Hehe

 

[Zeorymer]

Preses, estou querendo fazer,. Jogo estilo produção como productionline

Tem ideia por onde devo começar? Ou do estilo simport.

Enviado de meu XT1033 usando Tapatalk

 

[Preses]

Preses, estou querendo fazer,. Jogo estilo produção como productionline

Tem ideia por onde devo começar? Ou do estilo simport.

Enviado de meu XT1033 usando Tapatalk

Whoa. Bem complexos. rs

Você já tem algum game desenvolvido? Talvez seria melhor um mais simples para começar. Só uma sugestão!

Porque te digo: até um gamezinho de quiz pode dar trabalho. rs

De qualquer forma, sugiro garantir que está afiadíssimo em conceitos de programação orientada a objeto e design patterns.

Estes são aqueles tipos de games que se você não tiver uma estrutura muito bem pensada acabam virando pesadelo de programação. Pode ficar mega difícil fazer qualquer tipo de fix, adição etc.

E outra coisa que tenho feito atualmente é fuçar as APIs de frameworks estabelecidos no mercado, como Phaser, PixiJS. Tem me ajudado bastante a melhor meu código.

Essa galera, além de saber muito mais que um noob como eu, está trazendo várias ideias novas de estruturação e features para a mesa.

 

[Raikage4269]

Putz, logo agora que baixei a 2.1. É melhor começar a mexer e aprender com a 2.1 ou com a 3.0?

 

[Preses]

Putz, logo agora que baixei a 2.1. É melhor começar a mexer e aprender com a 2.1 ou com a 3.0?

Se pretende fazer algo sério, mesmo que a curto prazo, pode continuar com a 2.1. Os devs ainda continuarão a trabalhar nela.

A 3.0 é só para ter um gostinho mesmo. Ainda falta arrumarem bastante coisa.

 

[Raikage4269]

Se pretende fazer algo sério, mesmo que a curto prazo, pode continuar com a 2.1. Os devs ainda continuarão a trabalhar nela.

A 3.0 é só para ter um gostinho mesmo. Ainda falta arrumarem bastante coisa.

Acho que vou mexer com a 2.1 para aprender a Engine. Será que a 3.0 vai ser parecida?

 

[Preses]

Acho que vou mexer com a 2.1 para aprender a Engine. Será que a 3.0 vai ser parecida?

Terá algumas quebras de compatibilidade, mas a essência será a mesma.

Pode aprender com a 2.1 mesmo que não vai ter erro.

 

[Preses]

Eu não tenho muita experiência com 3D, mas resolvi tentar importar uns modelos que fiz no MagicaVoxel para ver como ficaria o resultado. Tipo, quando tentei basicamente a mesma coisa no Godot 2.x ficou: "Ah, legal. Nada fantástico, mas também não tão ruim".

Porém, no Godot 3.0 ficou tipo: "Nó! Nem acredito que um noob como eu conseguiu um visual até decente na primeira tentativa".

O Juan Linietsky, principal desenvolvedor, tinha dito uma vez que seria possível conseguir renderizações como as do MagicaVoxel. Eu pensei que ele estava exagerando um pouco mas agora vejo que não.

 

[Preses]

Eu não tenho muita experiência com 3D, mas resolvi tentar importar uns modelos que fiz no MagicaVoxel para ver como ficaria o resultado. Tipo, quando tentei basicamente a mesma coisa no Godot 2.x ficou: "Ah, legal. Nada fantástico, mas também não tão ruim".

Porém, no Godot 3.0 ficou tipo: "Nó! Nem acredito que um noob como eu conseguiu um visual até decente na primeira tentativa".

O Juan Linietsky, principal desenvolvedor, tinha dito uma vez que seria possível conseguir renderizações como as do MagicaVoxel. Eu pensei que ele estava exagerando um pouco mas agora vejo que não.

 

[Preses]

Eu não tenho muita experiência com 3D, mas resolvi tentar importar uns modelos que fiz no MagicaVoxel para ver como ficaria o resultado. Tipo, quando tentei basicamente a mesma coisa no Godot 2.x ficou: "Ah, legal. Nada fantástico, mas também não tão ruim".

Porém, no Godot 3.0 ficou tipo: "Nó! Nem acredito que um noob como eu conseguiu um visual até decente na primeira tentativa".

O Juan Linietsky, principal desenvolvedor, tinha dito uma vez que seria possível conseguir renderizações como as do MagicaVoxel. Eu pensei que ele estava exagerando um pouco mas agora vejo que não.

 

[Landstalker]

Infelizmente não foi nessa release que saiu a compatibilidade com C#, mas ainda está programado para a 3.

 

[Preses]

Infelizmente não foi nessa release que saiu a compatibilidade com C#, mas ainda está programado para a 3.

Verdade! Acredito que não deve demorar muito.

Acho que no máximo em uns três meses já teremos alguma versão estável para projetos comerciais.

 

[Landstalker]

Verdade! Acredito que não deve demorar muito.

Acho que no máximo em uns três meses já teremos alguma versão estável para projetos comerciais.

O que eu temo é que eles estão tirando o padrão da C# pro Godot, deixando ela parecer muito mais com o próprio script deles ao invés do C# em si, e eu acho ruim também, principalmente para quem já conhece C#.

Eu acho o que eles estão pensando é o seguinte, quem já trabalha com GDScript vai querer migrar pro C#, o que é um ledo engano, uma boa parcela vai continuar usando o script, até porque muitos já NÃO trabalhavam com C# ou nem se quer conhecia essa linguagem, a maioria que vai migrar são aqueles que justamente já conheciam e trabalhavam com C#, pessoas como eu, então nada melhor do que tratar o C# como ele realmente tem que ser tratado.

 

[Preses]

O que eu temo é que eles estão tirando o padrão da C# pro Godot, deixando ela parecer muito mais com o próprio script deles ao invés do C# em si, e eu acho ruim também, principalmente para quem já conhece C#.

Eu acho o que eles estão pensando é o seguinte, quem já trabalha com GDScript vai querer migrar pro C#, o que é um ledo engano, uma boa parcela vai continuar usando o script, até porque muitos já NÃO trabalhavam com C# ou nem se quer conhecia essa linguagem, a maioria que vai migrar são aqueles que justamente já conheciam e trabalhavam com C#, pessoas como eu, então nada melhor do que tratar o C# como ele realmente tem que ser tratado.

https://godotengine.org/article/godot-getting-more-languages

Bom, pelo o que eu entendi, os desenvolvedores tentaram extensivamente alternativas, mas o GDScript foi a melhor solução. Eles disseram que vão incluir C# mais porque tem sido muito requisitado pela comunidade, por programadores acostumados com a linguagem, e não muito porque o engine precisa. O GDScript continuará sendo a linguagem principal.

Eu não sei te dizer o quão padronizado será o C# no Godot. A única coisa que vi o Juan perguntando um dia é se a comunidade queria que o C# continuasse em camel case ou se passaria a utilizar snake case, como no GDScript.

De qualquer forma, reforço o que disseram na explicação do link: o GDScript é bem fácil de aprender. Em menos de uma hora, um programador já consegue aprendê-lo.

 

[Landstalker]

https://godotengine.org/article/godot-getting-more-languages

Bom, pelo o que eu entendi, os desenvolvedores tentaram extensivamente alternativas, mas o GDScript foi a melhor solução. Eles disseram que vão incluir C# mais porque tem sido muito requisitado pela comunidade, por programadores acostumados com a linguagem, e não muito porque o engine precisa. O GDScript continuará sendo a linguagem principal.

Eu não sei te dizer o quão padronizado será o C# no Godot. A única coisa que vi o Juan perguntando um dia é se a comunidade queria que o C# continuasse em camel case ou se passaria a utilizar snake case, como no GDScript.

De qualquer forma, reforço o que disseram na explicação do link: o GDScript é bem fácil de aprender. Em menos de uma hora, um programador já consegue aprendê-lo.

Foi mais ou menos o que eu falei, como as pessoas que já conheceram e trabalham com o Godot na GDScript muitos deles não vão mudar, quem vai mudar é que já conhece e trabalhou com C# bem antes, esses é que querem a mudança por inúmeros fatores e não é apenas que GDScript não é difícil, é uma linguagem baseada no Python, mas é também pelas limitações que a arquiteturas deles atualmente apresenta.

O exemplo da mesma engine que sofre do mesmo problema é o Game Maker Studio, que o povo estava ávido por mudanças como essa, mas mesmo com a versão 2 a Yoyo não trouxe nenhuma linguagem orientada a objetos, e nem ferramentas simples como um Struct da linguagem C (que é procedural) para organização de dados, tendo que as pessoas fazerem armengues como usar map ou vector para suprir a carência.

Sei que GDScript tem uma estrutura bem simples de orientação a objetos, eu testei um pouco e ela se comporta até mais como um struct "com herança" que um verdadeiro OOP, achei bem limitado e também não gosto da sintaxe da linguagem baseado em Python.

Enfim, acho que os caras estão indo pro caminho certo mesmo não padronizado o C# deles com o padrão .NET/Mono, ainda assim a engine tá mostrando bons avanços e quando a versão 3 oficial lançar eu darei uma estudada nela novamente.

 

[Preses]

Godot tem agora um importer para GLTF 2.0!

WHY WE SHOULD ALL SUPPORT GLTF 2.0 AS THE STANDARD ASSET EXCHANGE FORMAT FOR GAME ENGINES

INTRODUCING GLTF 2.0
glTF 2.0 was introduced two months ago by Khronos, the body behind Vulkan and OpenGL.

Today, this format was added to Godot, which now supports the full specification. The reasoning behind this late feature addition is that, now that we released 3.0 alpha1, users need more content to test with the new 3D engine.

Sites like Sketchfab provide plenty of PBR-ready assets for downloading, and plugins that export scenes from other popular game engines to this format.

The surprise, though, is how good this format is for video game asset exchange. Nothing as good existed before, and it solves a problem that we, as an industry, have been struggling with for a long time.

Khronos, with glTF 2.0, has given us a fantastic chance to standardize a smooth workflow between 3D modelling software and game engines. To better understand why, a list of previous attempts will be explained and why they failed.

OBJ / 3DS
The first formats used for asset exchange were Wavefrom .OBJ and Autodesk .3DS. Both are formats from the early days of 3D computer graphics (late 80s, early 90s). Despite their popularity, they only support basic geometry, and .OBJ does not even support object transforms.

COLLADA
Collada (also from Khronos) was the first serious attempt to create an open exchange format, but it was not really intended to be used by the game industry (until later, at least). It was more of a tool to exchange assets between 3D modelling applications.

Despite supporting almost everything a modern game engine needs, the format fell into disuse. There are many reasons for this:

• The specification was not that complex, but parsing an XML based format can be a hassle as all datatypes need to be converted from text. Implementers preferred libraries to do this work, but no good libraries existed. FCollada was discontinued, and OpenColladaturned out to be bigger than most game engines.
• The specification was very ambiguous in many aspects, such as how data, skeletons, blend shapes, etc. had to be exported. It also gave exporters a lot of freedom in units used, as well as world transform specifications (e.g., which axis was up). All this resulted in a tremendous work for anyone wanting to parse the format.
• Most exporters are, to this day, broken. IDs are not unique in some, the order of sections dictated by the spec is not respected, and information is often missing.
• Collada is a text format, so loading large files is slow.
• Autodesk (willingly or unwillingly) worked against the format adoption by including an incomplete and buggy exporter in their products. To this day, a large amount of developers believe Collada is not capable of a lot of functions that it actually is.
• Blender (willingly or unwillingly) worked against the format by adopting an incomplete exporter.

While many factors worked against it, the truth is that Collada was never good enough.

FBX
One would assume (given its popularity) that FBX is pretty much the industry standard... except there isn't any standard published by Autodesk about it.

FBX is used via the FBX SDK, which has a very restrictive license. This license makes it very hard to use in open source projects (an EULA must be accepted by the user unless a special license is purchased from Autodesk).

Besides the legal issues, implementing the library is rather difficult and suffers many of the same format ambiguity issues Collada does. One could argue, though, that the main technical advantage about it (besides working with the most popular 3D modelling applications) is that the file format is binary, so parsing it is fast.

That said, as an industry, we should look for true standards to work with. As useful as FBX may be, Autodesk alone controls its future.

OPENGEX
OpenGEX was born from one of the most brilliant minds the game industry has ever produced: Eric Lengyel, who single-handedly created the C4 engine. It has a well defined specification and comes with exporter plugins for the most common 3D modelling software, as well as documentation and support libraries. It also has the very innovative approach of encoding floating point data as hexadecimal for quick and efficient parsing (despite being text based).

Unfortunately, OpenGEX did not catch up. The main reasons I can think of are:

• There are no open tools where you can test and visualize your exported files, save for Eric's own commercial engine.
• It's not really standard, as it's not registered in any relevant body.
• Development is not peer-based, only Eric decides the future of the format.

In short, for a format not so open, it does not offer many advantages over FBX.

GLTF 1.0
The first version of glTF had many good ideas, but it was clearly intended as a storage format for WebGL. In fact, materials could only be created by writing GLSL shader code. This made format unusable for anything else, as modern game engines only allow the user to create materials by customizing a small part of the rendering pipeline.

GLTF 2.0: WHAT MAKES IT GREAT?
By just reading the spec, the advantages should become clear. Still, I will detail the key points below:

JSON BASED
GLTF is a JSON based format. It's very easy to parse and the data already comes typed. This significantly reduces the need to rely on complex third party libraries to read it. Many languages (e.g., Javascript, Python) even support this format natively.

Comparing the size (in lines of code) of both Godot's glTF 2.0 and Collada importers, the result is as follows:

• Collada: ~5000 loc
• glTF 2.0: ~2000 loc

Godot does not even use third party libraries to parse these files. This makes it more evident how simple the format is in comparison.

Theoretically, glTF2 should be less efficient to parse than Collada, as it requires parsing the whole JSON into memory. Collada can be streamed in by using a SAX XML parser but, in practice, glTF beats Collada hands down. This is because (besides many Collada exporters not obeying the specification, so they can't be parsed as SAX anyway) glTF has yet another killer feature:

SEPARATE BINARY BLOB FOR ARRAYS
glTF allows specifying an external file for the big data, in binary format. It even supports many common GPU data types, so in practice this file can be moved in chunks directly to the GPU memory. Yes, glTF is the first of these formats that can even be used efficiently as in-engine data.

Even if engines would prefer to import to their own format, like Godot does, glTF is extremely fast to export and import. This makes it ideal for making changes to a complex file in the 3D software and updating them to the 3D engine almost instantly.

NO AMBIGUITY
glTF's file structure is crystal clear. No extra or redundant data exists. There is only one way the scene definition can be understood, which gives no room for exporters to take shortcuts. It also makes life for importers simpler, warranting that all existing scenes will work on the first implementation attempt.

Collections of objects of the same type are stored in JSON arrays and referenced by indices. No more confusing IDs.

There is also no support for different coordinate systems or units, and this is great. Quoting one of the first paragraphs of the specification:

• glTF uses a right-handed coordinate system, that is, the cross product of X and Y yields Z. glTF defines the y axis as up.
• The units for all linear distances are meters.
• All angles are in radians.
• Positive rotation is counterclockwise.

Just one simple use case to care about. No extra conversions. All work is left to the exporter. As there are usually way more importers than exporters, this is an excellent design decision.

MODERN FEATURES
glTF 2.0 fully supports skeletons and morph targets, which can be parsed easily and unambiguously.

It also supports PBR based materials using the Disney/Unreal format, which is what most engines and 3D modelling applications use nowadays, with albedo, metallic, roughness, normal, emission and ambient occlusion. It also handles two-sidedness and transparent materials, including alpha to coverage.

Extensions for handling shader material graphs are in the work.

GREAT ANIMATION SUPPORT
Animation support is also well done. glTF 2.0 supports multiple animations per file, which is ideal for exporting character actions (though be careful with some official examples, they are old and incomplete). It also supports many key interpolation types, such as Catmull Rom and Cubic Spline.

Animations are also stored in the binary file, so they can be loaded quickly.

CLEAN DOCUMENTATION
The specification is very complete, I personally found it well worded and not lacking in any area. There are many sample files to test all functions.

FLEXIBLE EXTENSION SUPPORT
glTF uses the same extension system as other Khronos specifications, which is proven to be centralized and well organized.

STRONG BACKING
glTF is developed by individuals from many companies, such as Microsoft, Unity, Google, Adobe, NVidia, Oculus, etc. in collaboration with Khronos.

BEST OF ALL, IT'S COMPLETELY OPEN AND EVERYONE CAN CONTRIBUTE!
glTF is an open standard and the development process is also transparent.

SUPPORT GLTF!
For glTF to succeed, it needs strong developer adoption. Ask your favorite 3D modelling software or engine developer to support it!

Currently, the Blender exporter is in the works and not complete, and there is no support at all for Autodesk products (export plug-ins need to be written).

This is the best chance we'll ever have in a long time for a proper, open standard. Let's work together to make it happen!

 

[Landstalker]

Será que eles vão dar suporte a Vulkan?

 

[Preses]

Será que eles vão dar suporte a Vulkan?

Não. Algumas pessoas já perguntaram no grupo oficial do Face e os devs disseram que não há planos.

 

[Preses]

Vídeo com algumas das novas features do Godot 3.0!

 

[pavomba]

Godot tem agora um importer para GLTF 2.0!

WHY WE SHOULD ALL SUPPORT GLTF 2.0 AS THE STANDARD ASSET EXCHANGE FORMAT FOR GAME ENGINES

INTRODUCING GLTF 2.0
glTF 2.0 was introduced two months ago by Khronos, the body behind Vulkan and OpenGL.

Today, this format was added to Godot, which now supports the full specification. The reasoning behind this late feature addition is that, now that we released 3.0 alpha1, users need more content to test with the new 3D engine.

Sites like Sketchfab provide plenty of PBR-ready assets for downloading, and plugins that export scenes from other popular game engines to this format.

The surprise, though, is how good this format is for video game asset exchange. Nothing as good existed before, and it solves a problem that we, as an industry, have been struggling with for a long time.

Khronos, with glTF 2.0, has given us a fantastic chance to standardize a smooth workflow between 3D modelling software and game engines. To better understand why, a list of previous attempts will be explained and why they failed.

OBJ / 3DS
The first formats used for asset exchange were Wavefrom .OBJ and Autodesk .3DS. Both are formats from the early days of 3D computer graphics (late 80s, early 90s). Despite their popularity, they only support basic geometry, and .OBJ does not even support object transforms.

COLLADA
Collada (also from Khronos) was the first serious attempt to create an open exchange format, but it was not really intended to be used by the game industry (until later, at least). It was more of a tool to exchange assets between 3D modelling applications.

Despite supporting almost everything a modern game engine needs, the format fell into disuse. There are many reasons for this:

• The specification was not that complex, but parsing an XML based format can be a hassle as all datatypes need to be converted from text. Implementers preferred libraries to do this work, but no good libraries existed. FCollada was discontinued, and OpenColladaturned out to be bigger than most game engines.
• The specification was very ambiguous in many aspects, such as how data, skeletons, blend shapes, etc. had to be exported. It also gave exporters a lot of freedom in units used, as well as world transform specifications (e.g., which axis was up). All this resulted in a tremendous work for anyone wanting to parse the format.
• Most exporters are, to this day, broken. IDs are not unique in some, the order of sections dictated by the spec is not respected, and information is often missing.
• Collada is a text format, so loading large files is slow.
• Autodesk (willingly or unwillingly) worked against the format adoption by including an incomplete and buggy exporter in their products. To this day, a large amount of developers believe Collada is not capable of a lot of functions that it actually is.
• Blender (willingly or unwillingly) worked against the format by adopting an incomplete exporter.

While many factors worked against it, the truth is that Collada was never good enough.

FBX
One would assume (given its popularity) that FBX is pretty much the industry standard... except there isn't any standard published by Autodesk about it.

FBX is used via the FBX SDK, which has a very restrictive license. This license makes it very hard to use in open source projects (an EULA must be accepted by the user unless a special license is purchased from Autodesk).

Besides the legal issues, implementing the library is rather difficult and suffers many of the same format ambiguity issues Collada does. One could argue, though, that the main technical advantage about it (besides working with the most popular 3D modelling applications) is that the file format is binary, so parsing it is fast.

That said, as an industry, we should look for true standards to work with. As useful as FBX may be, Autodesk alone controls its future.

OPENGEX
OpenGEX was born from one of the most brilliant minds the game industry has ever produced: Eric Lengyel, who single-handedly created the C4 engine. It has a well defined specification and comes with exporter plugins for the most common 3D modelling software, as well as documentation and support libraries. It also has the very innovative approach of encoding floating point data as hexadecimal for quick and efficient parsing (despite being text based).

Unfortunately, OpenGEX did not catch up. The main reasons I can think of are:

• There are no open tools where you can test and visualize your exported files, save for Eric's own commercial engine.
• It's not really standard, as it's not registered in any relevant body.
• Development is not peer-based, only Eric decides the future of the format.

In short, for a format not so open, it does not offer many advantages over FBX.

GLTF 1.0
The first version of glTF had many good ideas, but it was clearly intended as a storage format for WebGL. In fact, materials could only be created by writing GLSL shader code. This made format unusable for anything else, as modern game engines only allow the user to create materials by customizing a small part of the rendering pipeline.

GLTF 2.0: WHAT MAKES IT GREAT?
By just reading the spec, the advantages should become clear. Still, I will detail the key points below:

JSON BASED
GLTF is a JSON based format. It's very easy to parse and the data already comes typed. This significantly reduces the need to rely on complex third party libraries to read it. Many languages (e.g., Javascript, Python) even support this format natively.

Comparing the size (in lines of code) of both Godot's glTF 2.0 and Collada importers, the result is as follows:

• Collada: ~5000 loc
• glTF 2.0: ~2000 loc

Godot does not even use third party libraries to parse these files. This makes it more evident how simple the format is in comparison.

Theoretically, glTF2 should be less efficient to parse than Collada, as it requires parsing the whole JSON into memory. Collada can be streamed in by using a SAX XML parser but, in practice, glTF beats Collada hands down. This is because (besides many Collada exporters not obeying the specification, so they can't be parsed as SAX anyway) glTF has yet another killer feature:

SEPARATE BINARY BLOB FOR ARRAYS
glTF allows specifying an external file for the big data, in binary format. It even supports many common GPU data types, so in practice this file can be moved in chunks directly to the GPU memory. Yes, glTF is the first of these formats that can even be used efficiently as in-engine data.

Even if engines would prefer to import to their own format, like Godot does, glTF is extremely fast to export and import. This makes it ideal for making changes to a complex file in the 3D software and updating them to the 3D engine almost instantly.

NO AMBIGUITY
glTF's file structure is crystal clear. No extra or redundant data exists. There is only one way the scene definition can be understood, which gives no room for exporters to take shortcuts. It also makes life for importers simpler, warranting that all existing scenes will work on the first implementation attempt.

Collections of objects of the same type are stored in JSON arrays and referenced by indices. No more confusing IDs.

There is also no support for different coordinate systems or units, and this is great. Quoting one of the first paragraphs of the specification:

• glTF uses a right-handed coordinate system, that is, the cross product of X and Y yields Z. glTF defines the y axis as up.
• The units for all linear distances are meters.
• All angles are in radians.
• Positive rotation is counterclockwise.

Just one simple use case to care about. No extra conversions. All work is left to the exporter. As there are usually way more importers than exporters, this is an excellent design decision.

MODERN FEATURES
glTF 2.0 fully supports skeletons and morph targets, which can be parsed easily and unambiguously.

It also supports PBR based materials using the Disney/Unreal format, which is what most engines and 3D modelling applications use nowadays, with albedo, metallic, roughness, normal, emission and ambient occlusion. It also handles two-sidedness and transparent materials, including alpha to coverage.

Extensions for handling shader material graphs are in the work.

GREAT ANIMATION SUPPORT
Animation support is also well done. glTF 2.0 supports multiple animations per file, which is ideal for exporting character actions (though be careful with some official examples, they are old and incomplete). It also supports many key interpolation types, such as Catmull Rom and Cubic Spline.

Animations are also stored in the binary file, so they can be loaded quickly.

CLEAN DOCUMENTATION
The specification is very complete, I personally found it well worded and not lacking in any area. There are many sample files to test all functions.

FLEXIBLE EXTENSION SUPPORT
glTF uses the same extension system as other Khronos specifications, which is proven to be centralized and well organized.

STRONG BACKING
glTF is developed by individuals from many companies, such as Microsoft, Unity, Google, Adobe, NVidia, Oculus, etc. in collaboration with Khronos.

BEST OF ALL, IT'S COMPLETELY OPEN AND EVERYONE CAN CONTRIBUTE!
glTF is an open standard and the development process is also transparent.

SUPPORT GLTF!
For glTF to succeed, it needs strong developer adoption. Ask your favorite 3D modelling software or engine developer to support it!

Currently, the Blender exporter is in the works and not complete, and there is no support at all for Autodesk products (export plug-ins need to be written).

This is the best chance we'll ever have in a long time for a proper, open standard. Let's work together to make it happen!

Interessante o projeto, tomara que dê certo.

Mas existe toda uma treta né, vale lembrar que aqui quem tem grana quando vê a água batendo na bunda quer propinar geral, só ver que a Intel fez anos atrás na era Pentium 4 e o que a Nvidia faz hoje quando os jogos basicamente saem cagados de propósito na AMD.

A Autodesk poderia começar a fazer cu doce e não vender a licensa do FBX pra quem quiser aceitar o GLTF, porém, se criarem plugins free pros produtos dela, ai sim vai ser uma reviravolta, pois basicamente qualquer um pularia fácil essa restrição.

 

[toad02]

Ta ficando muito interessante essa Godot.

e @Preses te segui no twitter ;)

 

[Preses]

Interessante o projeto, tomara que dê certo.

Mas existe toda uma treta né, vale lembrar que aqui quem tem grana quando vê a água batendo na bunda quer propinar geral, só ver que a Intel fez anos atrás na era Pentium 4 e o que a Nvidia faz hoje quando os jogos basicamente saem cagados de propósito na AMD.

A Autodesk poderia começar a fazer cu doce e não vender a licensa do FBX pra quem quiser aceitar o GLTF, porém, se criarem plugins free pros produtos dela, ai sim vai ser uma reviravolta, pois basicamente qualquer um pularia fácil essa restrição.

Essas disputas são problemáticas mesmo. Mas eu fiquei feliz mesmo pelas possibilidades técnicas. Agora, se o formato vai ser adotado, eu realmente já não sei.

 

[Preses]

Ta ficando muito interessante essa Godot.

e @Preses te segui no twitter ;)

Tá demais! Acho que vale a pena ficar de olho no engine.

E te segui de volta!

 

[Preses]

https://godotengine.org/article/how-actually-make-your-dream-game

O Juan escreveu um artigo contando sua experiência como desenvolvedor e deu algumas dicas bem valiosas. Acho que todos deveriam ler porque realmente nossas expectativas quanto ao desenvolvimento e monetização de um game na maior parte das vezes são bem utópicas.

P.S.: Ele tem 20 anos de experiência desenvolvendo e embarcando (shipping) games, além de 10 como consultor técnico. Já atuou de programador até dono de projetos, mas na maior parte do tempo como diretor técnico ou consultor técnico. Já foi dono de várias empresas e ajudou outras na parte de negócios.

 

[Cristiano Sword]

conheci essa engine recentemente e gostei muito dela, o fato de ser free e compilar para varios sistemas, esta fazendo ela bater
com a unity, eu msm estou pensando em portar projetos antigos da unity pra ela e ve como ela desemprenha as msms funcoes