Godot: 3.x 3D tools - Exporting level mesh for other 3D editors (like fbx, collada, obj...)

[n-pigeon]

Ability to export Godot scene meshes (collisions also) to some intermediate format like obj, fbx, collada so it can be opened in external 3D editor at least for reference.

It's super important feature which most engines often ignore...
Usually game Level Design and most of Level Art is made in editor tools. Often there is a need to export geometry made in Editor Tools or Level assembled in Godot Editor to external 3D creation program, so models can be created in some context of the game.
Constant exporting WIP models and uploading them and them opening Game Editor to see how it looks is a big hassle.

[Calinou]

Godot currently does not have a 3D level editor, so this is not really useful until such a thing is made.

Also, the primary use of exporting the level geometry to formats like .obj would be to perform renderings with eg. Blender – it would be rather silly to use the exported model directly in another game engine (because it'll be hard to modify, inefficient, and many issues will occur).

[n-pigeon]

@Calinou Godot has very basic level editor but it has one. Are you referring to some type of mesh creations tools?
Most basic (and usually main) level editing workflow in Game Engine Editors is placing finished or wip assets in 3D space. That Godot can do.

Exported scene/model from Godot would be not to perform rendering or to work on this asset (usually at least...) but as temporal place holders in other 3D creation tools.

This type of workflow is something that I stumble often at work. It is useful in many places.
For example FX Artist wants to create "Destructible" for Asset. So, he imports tmp fbx with level made by our Level Designer and Lever Artist, from our game. Then he places model that will be destroyed in right place and works with it so it will look good (makes all simulations in 3D software and bakes animation to frames). After he finishes he deletes tmp models/scene of level that he imported and exports final asset.
Then final asset is placed in original level scene.

The same type of workflow is often needed for different type of assets.

[BastiaanOlij]

Hmm, this is a tricky one I would say. The problem that Godot has, same as many other engines, is that its not really compatible in that way. Godot adds many things into the mix that aren't part of 3D file formats, exporting your scene would just cause you to loose most of the stuff you want to retain when importing a final version with all your artists work in it. So ultimately the final assembly of a level belongs in Godot and you would be replacing placeholder artwork.

But I can see how your suggested workflow could have benefits...

[n-pigeon]

Yes, assets exported from Godot (for example created in Godot) are just for reference and should not be exported back to Godot.
They would be only used as helper when creating assets in 3D software and final asset placement should be done in Godot Editor.

[kubecz3k]

I think it's a great candidate for editor plugin.

[golddotasksquestions]

@BastiaanOlij Why would it be a problem to collect all meshes in a scene and export them as obj if nothing else? That's better than nothing.

[BastiaanOlij]

@golddotasksquestions I don't think you'd want to export it as one big obj file, obj is a great simple format but it lacks all the detail you'd wish to retain. If you do want to export the objects in a scene in a format you can actually use in a meaningful way you'd need to look at exporting to GLTF or DAE. Probably GLTF is your best bet as a well documented open format.

Like @kubecz3k says, you could write it as a plugin today if you're not comfortable with C++, meshes can be fully read out, CSG needs a small change and you can read out the data as well, no chance of support gridmaps, multimesh and that sort of objects as there is no equivalent construct in these types of formats, and you'll loose most of your material information because shaders aren't transportable. But it is doable for sure.

Godot is open source, all it takes is someone who has the need for this functionality and the skills for this functionality to implement it, if they don't have the skills but do have the need, they can pay someone to do it. But you can't expect people who work for free to build something you need just because you need it. That's not how open source works.

That argument also works both ways, seeing there has been no action on this issue for well over a year, obviously the need for functionality isn't that high or someone would have picked this up by now and ran with it. That is one of the coolest things I love about Open Source, it ensures feature creep is kept at a minimum because nobody is going to give up their precious times implementing features they don't need.

So bottom line, if you really think this is necessary, if you really think you need this functionality to complete your project, contribute! You will find many of us ready with advise and giving you a hand.

[golddotasksquestions]

@BastiaanOlij
Your comment is very assumptive. Comments like this one make me second guess any involvement in opensource. It makes me angry and sick.

1. Don't assume what I can or cannot do and then raise the finger lecturing me about what I should do.
   Has it crossed your mind not everyone here is a coder? Has it crossed your mind not everyone here has money to pay someone? People can still contribute expertise from various areas of game development without those two. Comments like yours make it sound like either they should not, or it's worth nothing. It makes me sick.
2. Don't lecture me about contribution when you apparently have no idea about the time I already spend to contribute as good as I can.
3. If you think contributing only means making pull requests and submitting code, I feel sorry for you, but then I guess we have nothing more to talk about.

[BastiaanOlij]

Owh this is going down a rabbit hole.

The bottom line for me stays the same, we are all volunteers, we're all doing this either for fun or because we're trying to build a project ourselves and are simply contributing because our project requires things that others will find useful as well.

You are absolutely, 100%, correct, that contribution can be in many many forms, it can be in submitting fixes, contributing features, submitting bug reports, advocating the project, showing off what you can do with it, the list goes on and on. Heck even people who just use Godot and never provide any feedback back into the community are contributing simply by using the project.

And yes that thus includes submitting ideas and discussing what you think is needed in Godot.

Over the 2 to 3 years I've been apart of this community I've helped many, coders and non-coders alike, I have devoted my limited time in building functionality I will likely never use myself, and I'll keep helping them gladly.

But I draw the line when people seem to feel entitled that their needs are met, that they are somehow owed. Now if I have misunderstood you in that in the posts you've made recently I sincerely apologies but you sure do put your argument in ways that do not motivate people to give a helping hand.

[golddotasksquestions]

I spend on average 50% of my time contributing, be it through testing, researching and writing issues I encounter, trying to help newcomers who are even less experienced than I am, by promoting Godot. Some days much more.

I do this because I think Godot is an amazing Project and I would love if there were more people on board using it.
Never have I ever felt entitled to anything. Not in my life, and certainly not in an opensource project where thousand brilliant and talented people like yourself spend countless hours of their free time improving it long before I ever heared of it. Even though you seem not to believe it, I feel humbled by it's existence and honored to partake in any shape of form.
While it is absolutely amazing what Godot can do so far, it is for many reasons not a suitable replacement for the dominant proprietary engines in the professional sector of the games industry. I feel like I'm allowed to have an opinion on that matter because I spend 12 + years in AA and AAA studios.
Noone is entitled to anything. I'm well aware we are all here for the pleasure of our hearts. To think anyone on this project would own me or my needs anything is far beyond bordering absurdity. All I want is to contribute my ideas of would make more people and studios adopt Godot.

I knew nothing about programming coming into Godot, and I set it my personal goal to learn with it how to code. This has been a wonderful 5 month journey so far thanks to many professional experienced coders like you, who are gratefully sharing their advice. Comments like your previous one however always feel like a massive setback. It feels like "either already be a professional coder or pay a professional coder, if not shut up and gtfo".

It's not the first time I experienced it and probably won't be the last, but it needs to stop.
If you ever want wider adoption of the Godot engine, it will mean also non coders need to be allowed to submit their ideas and opinions about it's features direction.
Why? Because the game industry and engine users consists only to a certain fraction of coders and wider adoption in larger studios means more and more non coders will have to be able to use the engine in ways that suits their professional needs. That does not make them entitled or owned, but I would surely hope they would be welcomed to speak their mind without a shutdown like your "change it or beat it" comment above.

[BastiaanOlij]

@golddotasksquestions , I think that is wonderful for the most part to be honest, I have very little problems with your opinion of what you think should be added to Godot even if I may not agree with all of it.

This however: It feels like "either already be a professional coder or pay a professional coder, if not shut up and gtfo".
I'm really saddened that you feel that way, I can see how you can get that impression and indeed I myself can react hotheaded but it does get a bit tiring after a few years of constantly having people demand you spend your limited amount of free time on things that take you away from things you need to be working on yourself.

We are not a company with paying clients able to spend funds on implementing wishes from said clients, or at least the ones that give them thousands of dollars because trust me, if you don't have money to spend and you tell Unreal or Unity that they must add something to make their game engine worth your while, their reaction will probably be a lot less civil then ours.

Nobody here has a problem with someone saying "it would really benefit Godot if it had X", nobody has a problem with people discussing what "X" should look like. To be exact, those discussions are vital once someone with the skills and desire to implement "X" turns their attention to it.

It only becomes a problem once pressure is put on because "X" needs to happen. Then suddenly it turns from a positive discussion to a negative one. Even in your reaction, as nicely as it is worded, there is this undertone of Godot not being good enough if what you perceive as necessary isn't being addressed. That is a really big ask and people tent to not react very well to that.

Off course the reality is, if you are right, and there are hundreds of game studios that have the same needs, then within those hundreds of studios there will be someone who does have the skill and the will to make "X" happen. If not today, then tomorrow. The more studios use Godot, the more likely this will happen. I don't think Godot is there yet for every thing that has been wished for by many people, not by a long shot, simply because we don't have enough people with the skill and time yet. And that may indeed mean that Godot is not suitable for your project yet. But for many game projects it ticks all the boxes, and every day more of those boxes can be ticked, eventually we'll get there.

P.S. just in case you haven't noticed, @fire who just completed work on the FBX import, another one of those "godot sucks until it has X" things, has taken an interest in actually implementing this one. So you might get your wish sooner rather then later.

[golddotasksquestions]

Thanks for your candid reply, I really appreciate it and agree with what you say wholeheartedly.
I'm on the other hand truly sorry if any of my remarks here on Github or Reddid or elsewhere have ever been understood (even remotely) as "demands". I would not even begin to know why anyone would think they can demand anything or be entitled to anything in an open source project. Imho even as a paying customer it is quite absurd to make demands if the market is not ruled by one monopoly ...

I see open source development just like you describe it very much as a democratic process. If not enough people voice their opinion on feature X, it will most likely be implemented following the opinions of the few who do. So I would always want more people to engage and contribute their opinions hoping, that we all come to an agreement about the best arguments for a solution to go forward. "Best" for me would mean more people adopting Godot who are able to use it as professional application.
Especially larger studios of more than 8 people adopting Godot. Because this would mean more experienced contributors of ideas and code and more specialized opinions, and hence better more specialized tools, greater better looking and playing games as a result, again faster and wider growth meaning more benefit for all it's users.

"My project" is just to learn how to code. I don't use CSG Meshes in Godot right now beyond some testing. But I certainly have used Boolean shape operations excessively in my career so I know what they need to be able to do in a professional environment. I'm glad people are working on it, I think it's a fantastic feature for Godot. Thanks, yes I've followed what Fire is doing!

[BastiaanOlij]

Welcome to the internet, the best place for misunderstanding each other :) :)

Things will come, we already see pretty good adoption of Godot for 2D games, 3D still has the problem that there aren't enough good examples out there. A good game takes 2-3 years to make (more often then not many more years for a AAA title), Godot 3.x isn't that old yet. You can see in the showreel that there are a few very interesting projects on the horizon. Once a few games are released larger studios will get interested and things will start accelerating. If the trip to GDC was anything to go by, it's already happening.

I have the same issue with my VR work, many people are holding off jumping into Godot VR because there aren't any (public) examples of what Godot can do in VR (I say public because I know a few private projects that are very promising). It's the ultimate catch-22, people won't jump in before they feel the engine can do what they need it to do, yet the engine needs people to jump in and work around the short comings so we get the growth needed for those short comings to be addressed. It'll get there but it's like a steam train, chuffing and puffing at the start until it gains an unstoppable momentum.

[fire]

See https://github.com/godotengine/godot-proposals/issues/341 and my pull request.

[fire]

Here's a fun picture.

Blender improvements is planned for 2.83. https://github.com/KhronosGroup/glTF-Blender-IO/pull/857

Godot Engine Export is via https://github.com/godotengine/godot/pull/34193

[golddotasksquestions]

Is this all exported in one piece from Godot to 2.83? Looking good!

[akien-mga]

Superseded by godotengine/godot-proposals#341.