One guy intentionally sabotaging Geometry Nodes Export related bug reports

General Forums Blender and CG Discussions
1

Hi,

I need a bit of help from you guys. For past year or so, I’ve been reporting many bugs related to using Geometry Node generated content outside Blender, in game engines such as Unreal. That’s because I work with both Blender and Unreal on a game, so I use this functionality on daily basis in its fullest potential. About half of them get closed by one power tripping guy with really poor explanations and the blanket “This is a feature request” messages.

This guy has single handedly set back the Geometry Nodes export functionality back by about a year by haphazardly closing many reports. On several occasions, his excuse was “You can write a python script to fix it afterwards”. This is frustrating for two reasons:
First, that the Blender is end user facing software with GUI, not a programming library. So the solution to issues shouldn’t be writing “fix this bug” kinds of scripts.
Second, that my Blender installation is already polluted by half a dozen of custom “fix this bug” scripts and I am just so tired of writing a ugly workarounds to issues that should have not exist in the first place.

The latest instance of this behavior is this report:

The issue is that if you use primitive nodes such as cube in GN node network, then when you convert the live GN object to mesh (which happens automatically on each FBX or GLTF export), the object will get one additional empty material slot, that has no material and no faces assigned to it.
image
Those of you who export Blender content outside for use in other apps certainly know what kind of issues this can cause, since many apps rely on specific material ID/slot order to assign materials properly on the other side.

I just need some help with other people voicing their opinions in the comments on the report above. Not just about this specific issue but rather how these types of issues are treated in general. That they are treated as a feature request. Imagine requesting a new feature of “GN objects not having random unused and unassigned material slots on them after being converted to mesh”. Or to help me to fight the “Just write a python script to fix it” mentality.

If these reports weren’t closed haphazardly, we could already have functioning, stress and headache free export of GN content outside of Blender. Instead, everyone has to either have custom scripts, or do ugly workarounds like having live “source” versions of the GN objects in their scene, and then manually making copies with modifiers applied every time when doing exports.

GN is still a relatively new feature, so it’s still a bit unreliable, especially when it comes to the compatibility with the exporters. But if the reports about the exporter compatibility issues are not just ignored, but actively rejected, we will never have a game engine or pipeline friendly Blender.

7 Likes
2

This isn’t just “some guy”, it’s a developer- one has provided specifics on why this isn’t a bug. I’m not sure what you’re hoping for here, trying to organize some kind of mutiny against the developers isn’t going to get you anywhere

2 Likes
3

You won’t like this answer, but it’s reality.

I understand why you think the slot shouldn’t be created, and to be honest I’m not going to read all the back-and-forth from the Dev on “why this, why not that” with the explanation… because the reality is:

That’s how they coded it to work. It’s not a bug, and that page on the internet only cares about literal bugs: Something that was coded does not work as was intended.

This is far different than Something was coded that makes no sense, or produces a result that is not wanted.

To create a silly hypothetical example that illustrates the point:

Let’s pretend that Blender codes a few feature, with a menu name that says “EXPORT EACH OBJECT SEPARATELY.”

When you choose this option, it actually deletes all the objects and shuts blender down.

You report this as a bug. Triage team takes a look, confirms behavior. Asks the person who coded it, “What is going on here?”, and developer says “It’s supposed to delete all the objects. It exports them to the trash container.”

Triage team: Feature works as intended, report closed.

What, this makes no sense!?

Please use RCS to request a new feature.

Like I said, you won’t like the answer. I don’t either.

7 Likes
4

It’s the only option I have left, so why not take it. I would not make waves if it was the first time, but this is like 10th. What pushed me over the line that it’s always the same person and he systematically rejects reports about the parts of the code he’s involved with. I am developer myself so I see another level of malice here, where it seems like he intentionally wants to avoid confronting the bad code design decision he’s made.

Yes, exactly. I am used to that answer, I get it all the time. But this was an extreme example in my case.

For example, I remember reporting that when you save blender file using Ctrl+S, images modified by texture painting don’t get saved, so even if you hit Ctrl+S like crazy, when your Blender crashes, you lose all your texture painting progress. Now, you could perform some expert level gymnastics to argue that saving images in Blender is separate from saving blender file itself, so not losing texture painting data on crash despite saving the file is a feature request.

But even in the context of already being familiar with how extreme mental gymnastics they usually perform to call bug reports a feature requests, this one was too far, simply because empty material slot that’s not assigned to any faces on the mesh serves 0 benefit but causes several issues. In other words, removing it doesn’t break anything but at the same time fixes multiple things.

I still don’t think I agree with your “works as intended” argument. I really can’t imagine someone really intended, willfully, to create empty material slot on the object that has also no faces assigned to it. What would be the reason to intentionally do that?

1 Like
5

I agree that the frustration is real. But, the Triage team isn’t a Quality Assurance team. They will 100% refuse to address QA issues as a bug.

Blender doesn’t do things that way, so the best idea is to make your case with solid example of “good vs bad” result behavior, and hope it gets the attention of a Dev who will agree with you and adjust some code.

3 Likes
6

But what would such example look like in this case? I mean the report itself has the scene file attached with a good example of what the bad behavior is. And the good one would just be the empty slot not being there. Sure, I could even make some examples of what problems it causes in the game engines, but how would that help to argue with a person who’s response is that you should write a python script to manually clean it up? :face_with_diagonal_mouth:

7

pls dont harm blender devs and users

How should it best be voiced so it is not devolving into a forum gangup?

8

Looks like they need that QA team then - or at least a different option to report this kind of stuff to.

4 Likes
9

I think your report was a fine good-vs-bad example.

So - it wasn’t that your explanation wasn’t good; it’s that triage isn’t the dept that cares.

Now, FWIW: the person who closed it is a Dev, and does work with Geonodes. His particular disagreement, as pasted here (i split the paste from 2 posts, so let’s not have someone play “Gotcha thorn, you misrepresented the quote”. It’s called a summary.)

“Empty material slot is here due to some meshes being created by geometry node primitive nodes … Unused materials are never cleaned from the mesh.”

I would query “So why is the conversion to mesh CREATING an empty, unused slot in the first place?”

I understand his answer, but I don’t understand his reasoning for why this makes perfect sense. (And I’m not a coder, so perhaps I’m too ignorant on the matter).

So - i’d suggest making the case, in the manner above. It does what it does, but what it does seems to not be something that needs to be done.

2 Likes
10

Maybe this helps:

11

The BF can’t afford a dedicated QA team though. The whole point of FOSS (at least in an ideal setting), is that the paid developers work on the big stuff while volunteers round things out and take care of all of the smaller things.

All the BF needs to do then is work on streamlining patch review and make sure every piece of code submitted gets a fair review, because a lot of people want to contribute and it is a bit suboptimal at the moment.

12

FOSS is not a free-for-all, though - nor should it be. Blender modules have owners, and it is the owners who can (and do) decide if something should be addressed for a particular reason, or not.

3 Likes
13

They can’t afford a serious show stopper for a big client, either. If this kind of thing is just glossed over, then what else gets through because of ‘not my job’? Do I need to suggest a Karen Hotline for BI? In the company I worked for, there were protocols in place for this kind of thing - if something was perceived as out of the ordinary, then it was sent upstream for review.

14

You are a bit too late (minus the Karen hotline)?

https://ubuntu.com/blog/blender-support-from-canonical

You can even chose the Severity response time.

enterprise Blender support
enterprise Blender support761×502 29.6 KB

1 Like
15

Is that guaranteed commits to source?

16

Sadly I don´t know (I´m just a small indie)

but might be worth asking via their contact form.
https://ubuntu.com/contact-us/form?product=blender-support

17

I can write such script with ease, in fact I have many similar scripts, but this is one of these cases where it just won’t do it.

You will first have to manually convert the object to mesh before doing so. It’s an extra step so it completely kills the live procedural nature of geometry nodes where you can just tweak parameters and export again.

Now, you can also write a script which will:

  1. Store the original object name
  2. Rename it
  3. Make a copy
  4. Convert that copy to mesh
  5. Clean up unused slots
  6. Export the object
  7. Delete the converted version for export
  8. Rename the original object back to the original name

In fact I had similar script when the GN export capabilities were even crappier than they are today, but it comes with huge issues. Let’s say you have complex mesh with complex nodes that takes let’s say 2 minutes to update. This usually happens with for example decimate modifier which you want to use to reduce mesh before exporting to a game engine.

If you just take the procedural GN object, and export, it will take those 2 minutes, since conversion will happen only once on export. If you go the script route however, it will take about 6 minutes. The whole modifier stack will first be refreshed when the object is copied, then again when the object is converted to the mesh, and then the export overhead of the collapsed copy, and then one more stack refresh may happen when the object is renamed back to original name.

So I triple the export time. What many people fail to realize that workaround is not a solution, it’s just a workaround.

1 Like
18

It’s because it makes no sense. As I said, I am also a developer, so I run into these kinds of situation often. The kinds of situation where my job could be order of magnitude easier if I just made a small UX compromise and offloaded some task onto the user. But developers’ job is the exact opposite. It’s exactly to abstract these technicalities away from the user.

No one cares about some internal technical limitation about why the empty slot is created, if there even is one. There is no extra material, there is no extra material assignment, so no extra slot should exist. This is a kind of thing that can only fly in the FOSS software.

Imagine for example a new version of Google Chrome releasing, and whenever you use the “Open in new tab” feature in right click menu, it would open the clicked link in a new tab but it would also open one additional blank tab every time. There’s not even slightest chance any developer at Google could tell their supervisor there’s some internal technical reason for it and that it will remain that way for the time being, and will be released to the end users.

6 Likes
19

You might be right… but they differ between:

  • real bugs; meaning something is incorrectly computed
  • something maybe should be done differently → feature request

This may sound arkward… but it is what it is…

Somehow they have to decide what to do about all the bug reports… you properly know sometimes behaviours are reported as bug and the reporting user simple does not understand the general workflow… or do not even can present something or reproduce this behaviour…

So especially with your “WTF ?” (on your bug report) you may also has pushed some buttons… ???

So this is a lose-lose situation… Shikata ga nai

:person_shrugging:

20

Huh, interesting, I’m using GN for curves all the time and haven’t noticed this before… Is it a new behavior for 4.2? :thinking:

However you look at it, it’s not a desirable outcome.

There’s no way I could call it a case of a “feature request”… you’d think feature requests suggest that some beneficial functionality should be added.
But this is a case, when a damaging side-effect of whatever’s going on under the hood needs to be removed.
The dev might have predicted this behavior and embraced the consequences, and in that sense it’s hard to call it a proper “bug”, but it doesn’t change the issue.

5 Likes