Layering Alpha Enabled Meshes

[SatoriLotus]

Sorry if this is the wrong section to post this, please move it if need be.


I'm new to this sort of thing so please excuse my terminology and ignorance in general.

Okay, so this issue has mostly shown up with modder's hair in the past; alpha channels hide meshes (or pieces of the same mesh) behind them if they're also alpha-enabled. - Usually it's not a big deal, but this is something OpenMW should fix in the future right?

Here's an example:

Spoiler: Show

As you can see I'd need to seriously rework this mesh (and increase the poly count by a lot!) to have it work without alpha.


I'm not sure if this is helpful, but over in the Mount & Blade modding scene, OpenBRF (basically like nifskope for that game) has material flags. One of which is called "No Z-Write" if you enable it when using Alpha Blending, it fixes this issue.

Spoiler: Show

Is this something that OpenMW or the OSGT format will fix? Or is it already fixed with OSGT?

Also, can anyone recommend a temporary work-around?

[Capostrophic]

Enable alpha testing in addition to alpha blending in the alpha property. Problem solved.

[SatoriLotus]

Enable alpha testing in addition to alpha blending in the alpha property. Problem solved.

Wow, I feel incredibly dumb for overlooking that.
Sorry for the clutter thread, then.

Why do some modders report this as an issue with their hair? They also just overlooked it or what?

Thank you so much though!

[Chris]

Why do some modders report this as an issue with their hair?

Depending on how the hair is done, there may not be a practical fix. Alpha testing works when you're just doing "masking" (that is, a texel is either completely opaque or completely invisible), because the invisible texels can skip the Z-Buffer writes and properly show what's behind them. But if the hair tries to use translucency (that is, the result is a blended combination of the hair texture and what's behind the texture's surface) to simulate looking through hair strands that are too small to model or texture individually, then the meshes need to be sorted to draw from farthest to nearest. But depending on the shapes or placement of meshes, there may not be a sorting that satisfies all viewing angles.

Ideally when using alpha, you should try to stick with masking (alpha testing only) or blend modes that are order-independent (like additive). If you must use order-dependent blend modes, try to use simple shapes, and realize that you may still get oddities when multiple blended meshes are near each other.

[SatoriLotus]

Thank you for the detailed explanation Chris.

I'll keep that in mind in the future when working with transparency techniques.

[SatoriLotus]

Is this a Z-Depth sorting issue? Or is this kind of thing even possible in OpenMW?

Nifskope (left - no stencil | right - with stencil)

Spoiler: Show

Blender 3d Viewport

Spoiler: Show

Blender Image Render

Spoiler: Show

Edit: This is with material alpha, not texture alpha channels.

Edit 2: Also, why does this mesh using the same technique look totally normal both in Blender and Nifskope? (pic in nifskope)

Spoiler: Show

Edit 3 (lol): Okay I figured out why the second item displays correctly; the front face and back face were originally separate meshes. For some reason, even though they're joined into one nitrishape, they retain Z-Depth sorting.

I tried out the theory on the bottle and it works, but separating every single tri and then joining them seems ridiculous. Is there any other way to do this?

Edit 4:Actually, not only did separating the polys not work, but it understandably shot the vert count through the roof.

According to this: https://blender.stackexchange.com/quest ... y-viewport it's a viewport limitation.

Which means OpenMW also has this limitation.

Are there any plans to implement automatic z-depth calculations?