Users browsing this thread: 1 Guest(s)
Model submissions- what is preferred for alpha transparency?
#1
When submitting models, how do people normally handle alpha transparency in their final submission? I am providing .png textures with transparency, which users can turn on/off with alpha and blend mode.

But exporting with alpha set up in Blender seems to produce mixed results in obj/dae/fbx. When imported back into Blender, Alpha Clip seems to auto-change to Alpha Blend, and backface culling is turned off. In some cases it looks like all materials have Alpha Blend applied whether I had it that way or not, so the entire model is semi-transparent which I think might turn some people away. I've downloaded plenty of models like that in the past and I know what's happening and how to fix it, I just wonder if that's "good" or if there's a better way.

Is it okay to expect other users to know how to fix these graphical issues on import by editing blend mode and its settings? Or would it be better to leave alpha disconnected entirely, and expect users to apply the alpha themselves if they want to? (transparent areas are pretty obvious black areas)

Any tips on this topic?

Attached is an example. On the left is my Blender file which uses Alpha Clip. The middle is the result of exporting and importing back in, which seems to lose all my alpha settings. The right has alpha removed before exporting.

Another thing that seems to happen, when exporting and importing back in, is the Base Color image for example is named ExampleTex, and the same is applied to the Alpha, but in the import it becomes a second instance called ExampleTex.001. It doesn't hurt anything but it doesn't look great.

Thanks for any tips, I just want to get it right before I finalize a ton of these.


Attached Files Thumbnail(s)
   
Reply
Thanked by:
#2
Frankly, there is not much you can do about Blender, it is in a deplorable state. Both .dae and .obj have broken handling of texture transparency.

For .dae, texture transparency has been completely broken since 2.8 released in 2019. It is ignored both in import and export, ie. everything is treated as if were opaque, like your third screenshot. I actually tried to send a patch for this last year but gave up after a few months.

For .obj/.mtl, Blender exports transparency from the alpha channel incorrectly (the way it exports is correct for a black&white texture being used for transparency, not for the alpha channel of an image being used). Obviously this means it would import wrong, so they broke the importer to import incorrectly too.

Neither .dae nor .obj/.mtl have a way to specify the blend method or backface culling, so there's nothing you can do about that. The .obj importer will always use alpha blend if there is transparency. There's a task about this on Blender's tracker. Maybe they'll switch to hashed or something one day.

As for two textures getting created when importing .obj, that's another bug in Blender (it's because of the color space), but a relatively harmless one, all things considered.

Can't tell you anything about .fbx.
Reply
Thanked by:
#3
Thanks for the help, much appreciated. Good to know it's not just issues on my end. I'm very familiar with the .dae importer in particular screwing up all kinds of things, including bones and custom normals. I guess I just hadn't dealt with alpha much until now (at least, not for export).

I will probably go with opaque then, and let others apply alpha if they want. Seems like the simplest, most controlled approach for now. Hopefully blender's future versions will have fixes for some of these things. Thanks again for the reply.

(Also... thank you for apicula and melon ripper, great tools.)
Reply
Thanked by:
#4
My impression was that as long as the proper textures are attached in the right places, and there's maybe a readme file for explaining some of the more obscure things required, the exact material settings don't matter too much, since material settings tend to vary widely between the different programs. Personally I don't worry about it, I've never had any issues with my submissions.
Reply
Thanked by:
#5
Thanks for the reply. Yeah I was maybe overthinking a bit. And I agree about different software interpreting differently, just have to be okay with that I guess. A readme is a good point. I will do what makes the most sense for each situation.
Reply
Thanked by:


Forum Jump: