Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make GLTF module togglable when compiling release templates #51383

Closed

Conversation

you-win
Copy link
Contributor

@you-win you-win commented Aug 8, 2021

The GLTF module is excluded from release templates by default. This PR adds a build flag to enable/disable the GLTF when compiling Godot and release templates.

This change was needed for my project on 3.x openseeface-gd, which loads in gltf/glb models at runtime.

Associated PRs:

@fire
Copy link
Member

fire commented Aug 8, 2021

I and @lyuma 's stance is that runtime support is achievable and wanted.

The Godot Engine maintainers consensus from a few months ago is that runtime asset import is not desired and runtime templates should use the internal formats.

Since Godot Engine is consensus driven, we took the consensus to not have runtime asset loaders. @reduz and @BastiaanOlij were the last to have the runtime asset debate in my recollection. Maybe they can give an update on the runtime loader debate.

@BastiaanOlij
Copy link
Contributor

BastiaanOlij commented Aug 9, 2021

Just to add a bit more context as I understand it.

There are two things at play here that underline the current implementation:

  • the current import logic is targeted at the editor converting imported data to Godots internal formats (cached in .import) which are then used when running the game. The runtime thus never uses the original imported files and the logic in general (looking broader at DAE and FBX here too) is not suitable as a runtime implementation and a separate implementation is needed
  • as Godot has a large following of users who wish to keep the runtime executable as small as possible for mobile deployment where size still matters, especially as some of the import libraries can be fairly large (FBX was, not sure if it still is), it is preferable to look for alternative solutions.

The consensus so far has been that optional logic such as this should be a (potential 1st party) plugin so it becomes an easy to add-on optional module that doesn't require special builds of the engine nor knowledge of the build system by a potential user.

That all said, there is an ongoing discussion whether we should add core GLTF import support seeing there are more and more use cases popping up that warrant this but we would likely limit this to GLTF.

@aaronfranke
Copy link
Member

Does this depend on #52501? If so, what is the fate of the 3.x version of this PR?

@you-win
Copy link
Contributor Author

you-win commented Sep 9, 2021

@aaronfranke This does not depend on any other PR. It will need to be modified/might not be needed depending on how GLTF importing is handled in the future (i.e. is GLTF import disabled in release builds)

I have been using the 3.x version of this PR to compile export templates.

@fire
Copy link
Member

fire commented Sep 10, 2021

@you-win I'm consolidating this work into a proposal.

Superseded by: godotengine/godot-proposals#3273

@you-win
Copy link
Contributor Author

you-win commented Nov 28, 2021

Closing as fire is working on a better implementation for godot master

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants