Usability of the 3D importing process (using gltf2.0) has further declined in Godot 4 compared to already bad import experience in Godot3 #63513
Comments
There is a default texture filter project setting for 2D, but I guess this needs to be added for 3D too. It shouldn't be too difficult to do if this only affects BaseMaterial3D. Also, the Advanced Import Options dialog should have an option to override the filter mode for specific materials. Meshes should also have options to set Cast Shadow, Lod Bias and visibility range properties in that same dialog. |
|
I just found in Godot4.0 Alpha12, while you can't use the trick to double click the glb file anymore to open a "New Inherited" which will update the existing model in your existing scene like in Godot3.X, you what you still can do to the same effect is to click the "Open in Editor" icon of the glb instance in the Scene Panel. This will also open the "New Inherited" popup dialog, which you can confirm (and then close again) to have your original scene show the updated model. In no way a solution for a stable release, but maybe a workaround for those who want to test 4.0 features right now. |
clayjohn
changed the title
|
Chiming in that I've had issues with it picking up texture changes, and sometimes textures AT ALL in 4.x But yes, 4.x feels worse than 3.x in this aspect |
|
// Godot Engine 4 It seems the bug recreation steps are update related: The double click hack was not an official feature so it was not preserved.
#57606 has an attempt to bugfix. |
|
// Godot Engine 4 The new importer settings is node based. A feature enhancement is to show ALL the settings for ALL the nodes in the regular import settings. |
|
Please @golddotasksquestions try to narrow down your issue report with a clear actionable issue. For example: "models/textures from glb files don't update when reimported" I understand your frustration but calling Godot "a mess" and using the tone that you're using in your issue is not constructive. People have to skim through your rant to find actually actionable stuff. In general, please keep issues clean of rants and succint in a way that contributor can easily understand the issue and work towards fixing it. |
|
I suggest you try the .blend import route. Exporting to glb with built-in textures will not work and Blender GLTF exporter is not configured to save textures externally by default. With the .blend route, everything uses the right options so things work for you. |
|
@reduz: Some of the gltf assets do not come from Blender/do not have .blend files attached ;( |
|
See it as "report" on the import situation, past and current. My issue is clearly actionable. I've included the exact steps you can follow in mere minutes to test this issue. It's so bad, it makes using Godot infeasible if your project depends on an iterative workflow. Larger more serious projects tend to be iterative in nature. Even most of all of my much smaller projects need an iterative workflow. I have spend a lot of time to test this issue and to break it down to it's most minimal reproduction steps anyone can try and follow. So if you have the time, please try these steps and report if you get the same or different results. And please: Please don't start to read tone into my written text. Text does not translate tone very well. On top there are personal quirks and cultural differences which you can't possibly know of. And language barriers - all of which make it hard to actually read the tone intended by the author. You most like have imagined a mood I don't have. I want Godot to prosper, which is why I am participating, spending a lot of time helping newcommers and beginners, spend a lot of time to test features and write issues if they don't work. I spend more than 25h a week doing this voluntary work. I have no ability to tell or to adjust how you read "tone" in written text which has no tone. I fully agree with the CoC to assume best intentions, which is very necessary thing to do when communication is basically only text based. I assume a nice friendly tone when I read your text, I hope you can do the same for me too, regardless how much we agree or disagree on any issue. I disagree for instance strongly with you on calling or not calling this a mess. It clearly is a mess (to me, if it is not to you, I hope you can take the time to follow the steps and explain why this is not a complete mess for you). From my experience, it has been a mess ever since I first started using Godot in 2018. It even feels worse right now in Godot4 Alpha 12. Maybe it has something to do with my system and configuration, which is why I have broken down the issue to minimal reproduction steps. I urge you to try and share your experience. |
Resorting to .blend is not a viable workflow solution for this issue here, since blend is specific to just one application only (and only version 3.0+ at that). I used Blender as an example here, since it is accessible to everyone, but I'm sure if you want to test this in any other source application, its really not that much more difficult to create a default cube there. Fbx is still the current industry wide standard for 3D assent exchange in the game dev industry. But thanks to Autodesk, it is pretty hopeless to ever expect continuously stable fbx workflow support when using Godot. That's ok. Having a dependency on proprietary formats is not the best idea anyway. Which is why having gltf work seamlessly is really crucial! With your .blend recommendation now, Godot has gone through at least 4 different "recommended" format workflows over the past 4 years. Which I might add is also not really trust-inducing. What's next year? Yet another format and workflow which almost works well enough, but not really well enough to do productive work with Godot? I get that there are reasons that go beyond my understanding of why this does not work or won't work. Still I would like you to accept my feedback that changing recommended workflows every year and forcing users to basically only use Blender as their Content Creation software is an issue we have. Constantly getting new only halve-working solutions replacing old unfixed halve-working solutions is what makes working with Unity so awful. |
|
@golddotasksquestions This is not a Godot thing, its more of a Blender thing that has the default settings configured in a way that its not very useful for Godot for GLTF (it creates and bundles new texture files every time into the glb instead of using your texture files). It does this because of the common use case of uploading glb to websites and we had to work with them to change it to allow using your existing texture files on disk, but this is not the default, so it should be documented how to use the format properly with Godot in a way that is useful. So, to solve this problem for most users and because we want to eventually go over the limitations in GLTF so you can export things like Materials, IK, etc, from Blender to Godot, we added .blend import. When you use .blend, Godot will ask Blender to save your file as GLTF with the right flags, but we can also add Godot specific extensions without adding a single line of code or add-on to blender to export your materials and other information properly to Godot. So, ideally, the recommended workflow with Blender definitely will be to use .blend files and exporting gltf directly will be considered a route for more experienced users. Unity had to do the same pretty much to make it easier for users to export files. |
|
The blend file importing system makes a lot of sense within the confines of developers who are working with both of blender source files and godot directly, but it just won't work with how most game development operations work. The reasoning is mostly off-topic, so I'll put it in a collapsible section below:
----
For one, most large game development operations just don't use blender. They use autodesk software. So advice that assumes they can use blender as an authoring tool is automatically not even on the table for them. Second, if I'm remembering right, fbx importing now involves converting the fbx to gltf with a third party tool. Unless you want to throw blender into the mix and automatically convert gltf files to blend files, first-class gltf support is a precondition to first-class fbx support, so blend files shouldn't even enter the conversation when we're talking about gltf support. Third, many game development operations have a very hands-off approach to how assets are shuttled off to be integrated with the rest of the game, or managing that process is handled by a single person for whom it's their dedicated job. From the perspective of someone plopping stuff around in the game world or stuffing assets into systems, it's normal to end up with exported model file updates with no choice but to do your best with them, Source files are often extremely large and clunky and/or contain redundant data or multiple assets to be split off into distinct exported files later down the pipeline. Outsourcing also sometimes involves keeping source files private, so the game developer themselves sometimes *only* has access to exported model files. Naturally, professional game development operations typically have custom asset tooling, so they can construct a perfect world for themselves if they want, but that's beside the point. A single specific "recommended workflow" is not a helpful solution; there simply *must* be a working workflow that uses exported models, not source files. Fourth, there are many 3d assets that simply don't come from conventional modelling programs, and blender could never, ever be a reasonable replacement for the tools that author them. ----In short, the blend importing system is simply not a solution to 3d asset pipeline UX problems. It will work for some developers, but some is not enough. In the opening post, there's a lot of different specific issues being brought up. Like, materials not updating in the scene editor and model data not updating in the scene editor are almost certainly very different issues. But the point being made is not that there are such-and-such issues that each individually need solutions. The point being made is that the experience in general, across each minor issue combined together, is extremely finicky, inconsistent, hard to understand, and hard to manage. In godot 3, it was impossible to have all three of The new importing process in godot 4 makes it possible to address these three points in much more direct and less janky ways, since it lets you extract materials and then configure mesh materials to use those external-to-scene extracted materials. It also imports materials into the scene by default (keeping external textures separate like they should be), not into separate resource files. Overall, this is a vast workflow improvement, and it is extremely welcome. But it seems like, somewhere in the process, reimporting was left to rot, so we come back to only having two of the three things that people should want out of the model reimporting process. For example, is there a way to configure a model to automatically re-extract materials from itself when it reimports? Because something like that would be necessary to have both proper reimporting and material sharing (not just texture sharing) at the same time. You would be affecting other object's materials, perhaps, but only ones that you've already explicitly configured to load those materials from those resources, so this would not be "thrashing", unlike in godot 3 where spewing material resources across the project's file tree is the default. I can't find such a configuration. For another example, is there a way to select a bunch of model files and tell them "look for pre-extracted materials in this folder and automatically use anything that matches"? Something like that would be necessary for it to not be extremely arduous to import (all at once) large numbers of models that you want to share materials (not just textures), which any project that's doing material reuse would have to do at least once. I can't find such a feature. An aside:
----
There are also a lot of problems with the editor keeping stale model state around after models or materials or textures get reimported. The workaround is to restart the editor, which is a bad workaround. This is probably a whole mess of small bugs being added together, but it still needs to be treated as the mess that it is. (I must note, having now used it myself, that "mess" is not a strong word, and overall in this post I'm sticking closely to conventional middle-formality-level written English. I've run up and down it several times looking for poor tone of voice and haven't found any. I'm being very firm with my assertions, but that's simply because there's a tendency for UX issues to be the first things to get thrown by the wayside in open-source project management, and I don't want to act in favor of that tendency.) ----UX issues like these should be sought out and addressed on their own terms, not ignored in favor of the fourth or fifth or sixth new high-level workflow change. Like godotasksquestions said, software that constantly cycles between new half-working solutions only makes working with it more awful. It's not just awful because changing your way of doing things all the time is awful, but because the thing that finally worked for you will eventually get pulled out from under you, potentially with no sane workaround in sight (e.g. for fbx users if the "use a blend file" recommendation were to catch on). In my opinion, it's less respectful to a useful/proven system in a piece of software to ignore its problems and try to replace it with something unproven than it is to recognize its flaws as flaws and attempt to fix them. *** Why godot 3's defaults are bad in detail:
----
In my experience, the simplest way to avoid model importing problems in Godot 3 is to make models import materials into their scenes rather than into files (because it bypasses the keep-on-reimport system entirely + prevents materials from being thrashed by other models), which is very bad because of texture duplication etc. But I'll take that duplication if it means that my materials reimport properly and aren't thrashed by the materials of other models. Yes, it's an issue that models can overwrite each other's textures and materials when reimporting if things go wrong, which is why the option to make materials import into their own folder exists. But that folder option isn't the default for the reason that it prevents you from reusing materials across models without doing really complicated inherited scene and material override stuff. But it remains difficult to reuse materials across models in Godot 3 because (by default) they're kept on reimport so any updates to the material are not automatically reimported after the model it comes from has been initially imported. But this combination of issues points to a failure to notice the conflict and find a compromise: instead of choosing defaults that prevent one model from thrashing the materials of another, or defaults that are ergonomic for material reuse, or defaults that play nicely with reimporting and the editor, godot 3 has defaults that do not prevent thrashing, are not ergonomic, and do not play nicely with reimporting. The defaults in godot 3 do not even do one of the three things that you want all three of. For example, if you import model A, it will make a material file by default. If you then change model A to store the materials in the scene instead of as separate files, the previously-imported material will remain. If you then import model B, and it has a differently-configured material with the same name as model A's material, tell me, will it, by default, overwrite the now-stale material that model A created on import? Probably not. If you then update model B's material, it will not reimport, for the same reason that model B's material didn't overwrite model A's stale material in the first place. This involves all three of material thrashing, poor material-sharing ergonomics, and bad reimport behavior. The defaults in should handle at least *one* of these three things properly, even if it's impossible to handle them all at once with godot 3's primitive importing configuration system. In my opinion, either importing materials into the scene instead of into resources, or into unique folders, should be the default, because it would allow developers to place arbitrary assets into their project and explore them in the scene viewer to see if they're rendering correctly, and examine their materials to see if they would conflict if loaded into files. But all of this is neither here nor there, since this issue report is ultimately/mostly about godot 4. ---- |
|
I agree that we shouldn't rely on blender-only solutions. In that case I think it would be useful if some of y'all that work with 3D asset workflow could open a proposal for how you envision a system working with the least friction possible for your usecases. I encourage you to find a space to talk with each other and come up with a proposed workflow that you feel like would address the issue at hand, I believe that could help us push this forward. Of note, please don't make proposals that are "do it like Unity" (or any other tool) because maintainers rarely have the time and energy to install another engine to test their import workflow in-depth to then come up with a Godot-compatible design. (This isn't targeted at something any of you said, but as a disclaimer) Additionally, please try to formulate the proposal in terms of problems and how your design addresses them. Keeping feature scope to a minimum will also raise the chance of the design being approved and subsequentially implemented. Lastly, I ask you to also accept the possibility that we could incur in technical limitations out of our control (what reduz mentioned above about the way Blender's gltf export works). Note regarding the tone, in spoiler because I don't want to argue but only express my point of view:Notes like this one:
Don't sit well with me. |
That's the biggest bear here, I don't think the advanced import screen is working well for GLTF :( it's great for small individual meshes like obj, but for GLTF I can't see what's there, the materials don't show up or are black even if they show up later in the actual scene, there is no quick way to reimport/refresh the frakking screen and/or open the scene itself (like "skip that screen I don't care" kinda button) So I think the current workflow is fine, we don't need really big reworking of the workflow, just ironing out the issues |
|
I appreciate the explanation! What you say makes a lot of sense to me. It sounds like a good way moving forward for existing Blender Artists and people who just started to learn 3D game dev and use the latest versions of Godot and Blender, and know they won't change this asset creation pipeline in future for the duration of their project. For anyone else though, it is simply out of the question. No, they will pick a different engine which supports common export formats, without crazy hacks, workarounds, or whatnot. Try to tell anyone working professionally in a studio they have to add an extra step in their asset pipeline where they have to load their asset in Blender (which they don't use), just so they can export their asset to the engine of their choice. No one is going to do that, even if they have Blender experience. It's like throwing a huge bolder right onto their efficiency workflow path. Maybe some are capable of automating this step, but even if that skill set exists, it would take a lot of RND since it adds an additional point of failure. If we want experienced game devs (3D Generalists, Technical Artists, Environment Artists, VFX Artists, Animators, Modellers) to pick up and give Godot a chance, they need to be able to use their experience without having huge efficiency roadblocks thrown onto their path. (tangent, therefore spoilers)I really have no idea how you came to this interpretation of the paragraph you quoted. This whole discussion here has imho absolutely nothing to do with "being cool", or a "cool kids club". My desire here, is to be able to have a seamless pipeline between asset creation and iteration and Godot import and reimport of the said assets. I really believe this is what we are discussing, and I really strongly believe having such a seamless pipeline is fundamental to doing any kind of productive 3D game dev work. I'm sorry if you find (parts? of) my contribution to the discussion not useful. But like the "tone" thing, I don't think there is anything I can do about that. If I read something I find not very useful, I generally just move on. If it is something factually wrong, or misleading or misinformed, I would also speak up. So if you notice something I write is factually wrong, misleading or misinformed, please continue to speak up and correct me.
No idea why you would bring up engine comparisons. I don't believe I have compared the levels of engines here in this thread. Instead I have tried to describe my personal experience importing and reimporting 3D assets into Godot over the past 4 years. My feedback and message is: This is essential and has to work seamlessly to be able to do productive work. |
That's still there, it just isn't the double-click functionality anymore. It's under the right-click menu. Edit: Also, as for the lack of a texture filter option, texture filtering is set per material instead of per texture in 4.0, so I don't think it makes sense for it to be an import option. It's possible to disable texture filtering on textures in Blender, is that setting kept on export? Edit 2: I just did a test and exported a glb with filtering disabled for a texture. When importing the glb into a new Blender file, the filter option is kept, but it is not kept when importing to Godot 4. |
|
Since we're talking usability, I have to say that the blender workflow has another major issue: performance. Importing blend files is very slow because the importer calls blender for each file, and blender takes a few seconds to start. Processing all files at once would speed it up by 10-20x (my script converting fbx->blend on ~1k files takes a couple of minutes, but importing into Godot takes about an hour). Then there's also the lack of previews in the file explorer files that makes working with blender files a bit more difficult. |
|
@jgillich can you file an issue for that blender workflow performance problem This issue is merging problems which makes it hard to track. Please make a new issue for each problem. Can be a feature proposal if you have some idea how to fix and an issue if you don't. Also, it's nearly impossible to close this task as completed because this issue merges like 10-20 issues and is vague. Most tracker issues we have do a table of bugs. |
|
Some points:
I don't think this reasoning makes sense. The problem here is how Blender exports GLTF, this is beyond our reach but importing .blend generally works well. For non Blender users, I don't think its common to see GLTF files with bundles stuff so it should not be an issue. Everyone else: Regarding reload bugs: will be hopefully be fixed by the time 4.0 reaches RC status. This is a well known problem, its just not a priority to fix until we enter Beta phase. Regarding importer performance: I also agree the GLTF2 importer is far from being fast, after Beta we will be also working on optimizing Godot and we will have a set of public daily benchmarks that will include GLTF2 importing among many other things. |
My understanding is that the new FBX importing pipeline uses GLTF as an intermediary format (via FBX2glTF, so it would still impact them. |
|
@wareya I dont think so, or at least it should not because it will not bundle the assets. |
|
I'm not sure I understand what you mean by saying The kind of people and situations I was predominantly talking about when I said They will test their workflow and then either report to the decisions makers, or if it is their own project decide themself on how much this engine fits their workflow. In a proprietary pipeline, fbx is not a obstruction. It's not even an issue. If the pipeline Non-Blender 3D authoring software -> to -> Godot, fbx is full of issues. This leaves all hope on wider GLTF market adoption and better usability on all sides regarding GLTF. I'm aware you can't make do others what is best for Godot, but in case you are not already doing this anyway, maybe you can reach out to someone in the Khronos Group, Maya, 3dsMax, Cinema4d, Houdini, 3Dcoat, Modo, ZBrush, Fusion360 teams and say to them something along the lines of you "would like the exports for their particular software to import seamlessly in Godot, but in order to for that to happen, their GLTF export needs this or that setting". I don't just want hobbyist and newcomers to chose Godot, I would like Godot to be a viable choice for industry veterans too.
This is really great to hear! I'm very much looking forward to these fixes and will definitely test them as good as I can when they are out! |
|
@golddotasksquestions tbh, I think you are exaggerating. Have you tried exporting FBX to Unity? It does not import any texture or materials (or if it does its not useful because its not PBR or even compatible with Unity) and you have to assign everything manually. I think workflow wise in that sense we are really good. I would definitely like to have better FBX support than using an external converter, but we do not have the resources for that, yet using GLTF2 really solves most issues. |
To be clear: I have no issues with gltf import performance, it's blender files that are slow; not just because they are imported twice, but because the blender step takes several seconds per file for the blender startup alone, and that really adds up when you have lots of small files. |
|
I can confirm the steps to reproduce also lead to not updated material of the mesh in 3.5. The only thing that seams to work is deleting the material and re import the scene. And even then the change is not directly visible in the editor and you have to reload the scene again. Keep on import is off and I can see in the inspector the texture of the Albeto changed in the material. Still it's not shown in the editor or in the game. Not even restarting the Editor or cleaning cache resolved this. Only deleting material completely and re importing solves this. This looks like a bug to me. On more complex models I did not managed to reproduce it and the material and model was re imported correctly and replaced in the mesh. But still scene needed to be reloaded for the editor to display all changes. So I can not say when this bug appears for sure but when it appears it is very frustrating. I hope this can be fixed for the Godot 4 release. Would it be worth raising a separate issue for this? |
See #38853 and other issues. This issue is only for 4.0, not 3.x. |
|
An option to set the default texture filter in 3D in 4.0 feels very needed to me. It already exists in 2D, why not 3D? The importing process of 3D objects is a bit annoying, but nowhere near as bad as 3.0's tilemap editor was so I think I can live with it. The extra step of having to go into the material of every single object to turn it from linear to nearest is a terrible addition, however. |
I opened a proposal to track this: godotengine/godot-proposals#5228 I won't be continuing work on my WIP implementation linked there due to time constraints, so please chime in if you want to get this for 4.0 🙂 |
|
I think this issue should be closed and have its own dedicated issues.
|
|
I'm glad to see some of the core issues I have mentioned here are already addressed in PRs. Thanks for linking more even more related PRs! @fire I planed to close this issue here as soon as the PRs are merged and I can successfully test the "Steps to Reproduce" in an Alpha or Beta build. I still think splitting up the Import settings in to various places throughout the editor is a very bad idea and makes this process worse, but I can write a specific issue regarding the UI/UX flow once the aforementioned PRs are merged and reimporting is at least fundamentally working. |
|
Just to keep up, is it not possible to set a default texture import filter in GD4? |
Please continue this discussion in godotengine/godot-proposals#5228. Don't cross-post comments to avoid the discussion diverging in different ways in different threads, as it makes it difficult for others to follow. |
|
Is there anything actionable to do with this bug report? Many of the rough edges described in the OP were actual bugs and have already been fixed during beta or early 4.0 rc builds.... or else have more specific issues already open. If we want a place to discuss how to improve the import pipeline, that belongs in a discussion, not a decaying github issue with most issues already resolved and dozens of back-and-forth comments. I think it would be healthiest to close this issue so that specific issues can be opened for each of the bugs. If the OP can re-test the original issue and tell us which issues they think still exist, it would be helpful. |
|
Please open separate issues for each bug that still remains. Thank you-all for your hard work. Closing as stale due to above comments by lyuma and golddotasksquestions. |
This comment was marked as off-topic.
This comment was marked as off-topic.
Godot version
3.4.4, 3.5.RC, 4.0 Alpha12
System information
Win Nvidea765M
Issue description
This, for me, is a regression from bad to worse.
Trying to export the Blender default cube to Godot, then make changes to the default cube in Blender in mesh and texture, export it again and have it automatically update in Godot has been unreliably in Godot3 to say it kindly. Sometimes it works, sometimes it does not. I have had better experiences in earlier versions of Godot I believe, but in Godot 3.4.4 and Godot 3.5.RC7 I can't get it to work reliably at all anymore.
Much worse is the updating of the texture, even with a simple albedo texture.
The model will reimport when Godot becomes the active window again, but the textures won't update. Unchecking the "Keep on Reimport" Material Inport option in Godot3 does not help. In Godot4 there is not even such a checkbox any more.
In Godot3, if you want to disable Filter on your textures, you would think you go to the Import Default options in the Project Settings and disable the Filter checkbox on all the Texture categories, but won't do anything at all. You have to manually disable filter on each and every texture individually after the import!
To make the changes show up in Godot 3.4, 3.5RC7 I have to create a new Inherited Scene, and then sometimes, the model will show as updated in the new inherited scene. If I then close the new inherited scene, sometimes some of the changes (mesh or texture) show up in my original scene as well. I have no idea what the criteria is for when and why. With tiny changes between multiple reexport and reimport it seems completely pointless to even try: no matter what I do the changes won't show up in Godot.
In Godot 4 this whole experience is even worse. Not only won't the model not auto-update, the hacky workaround of double clicking the glb file and opening up as "New Inherited Scene" won't work anymore, because the click behaviour changed. Double clicking the glb file will open up the "advanced" import popup, where I can click "reimport" without it making any difference. I can see the updated model in the "advanced" import popup preview, but it won't update my model in my scene.
The only solution I found was to completely delete the glb instance from every scene I have, delete the glb from res://, export from Blender again and add the new glb file back into my Godot scenes.
In Godot4, the Import Panel has been completely mutilated to a point I'm no longer sure why it exists at all. What has once (meaning in Godot3) been a good one-stop place to set up your 3D import of a file exactly as you need it (glaringly missing and enable/disable "filter" option though), has been ripped into pieces and completely crippled in it's functionality. Material options are completely gone. Everything is now spread between the Import Panel, the Project Settings Default Import Settings, the "Advanced" Popup, and the Inspector, as some things like the Filter option are now completely gone from any default import settings.
What a mess!
The "Advanced" import settings panel is almost empty and not accessible through the Project Settings Import Defaults. Why? It this not where you would typically have the split between basic and advanced settings (like it is with Godot's General project settings too?). How is this "Advanced" if there is almost nothing to do here?
It's things like this why you hear people outside of the Godot bubble say things like "Godot's 3D is bad".
A painless and seamless import-export workflow is fundamental for doing any even slightly more serious 3D development. If we want to have Godot 3D to be more than just a pretty looking gimmick, fundamentals like the import-export workflow need to be Godot's strong suit, not it's weakness.
Steps to reproduce
Export Blender default cube to Godot as gltf 2.0 directly into the Godot res:// folder
In Godot make a "New Inherited" scene, or instance the glb file to an existing 3D scene.
Back in Blender switch to the Texture painting view, set up a low res texture (like 16x16) and draw a few dots on the cube.
Export from Blender again, overwrite the glb in res://
Switch to Godot and observe it reimporting the file, without updating the model.
Try every trick in your sleeve to make the actual model show up (see description above for ideas)
Try to disable texture filter for the whole project, not just this model
Also try to do the process with some mesh edits (In Blender extrude a face of the default cube for example).
Minimal reproduction project
Minimal production project does not really make much sense here since this is about exporting the default cube experience.
The text was updated successfully, but these errors were encountered: