usage of setAlphaHashing Topic is solved

[jwwalker]

I wanted to try HlmsDatablock::setAlphaHashing. The documentation says to set it up like this:

Code: Select all

// Disable alpha test (default)
datablock->setAlphaTest( CMPF_ALWAYS_PASS );
// Do NOT enable alpha blending in the HlmsBlendblock (default)
HlmsBlendblock blendblock;
blendblock.setBlendType( SBT_REPLACE );
datablock->setBlendblock( &blendblock );
 
datablock->setAlphaHashing( true );

That's not quite correct, as one must use the pass by reference version of setBlendblock in order to set a blend block on the stack. But more importantly, I don't know exactly how to specify the transparency value with HlmsPbsDatablock::setTransparency. I tried this:

Code: Select all

block->setAlphaTest( Ogre::CMPF_ALWAYS_PASS );
Ogre::HlmsBlendblock blendblock;
blendblock.setBlendType( Ogre::SBT_REPLACE );
block->setBlendblock( blendblock );
pbsBlock->setTransparency( 0.5f, Ogre::HlmsPbsDatablock::Transparent,
	false, false );
block->setAlphaHashing( true );

Then the log shows a bunch of warnings like this

Code: Select all

WARNING: PBS Datablock 'DebugCube' enabling transparency but forcing a blendblock to avoid alpha blending. Results may not look as expected.

followed by a pixel shader compile error:

Code: Select all

Metal SL Compiler Error in 100000000PixelShader_ps:
program_source:465:50: error: expected ')'
                                if( AlphaHashReject( finalAlpha, inPs.uv0.xy ALPHA_HASHING_ARG ) )
                                                 ^ 

If I pass the mode None instead of Transparent, I don't get the warnings but still get the shader compile error.

[dark_sylinc]

That's not quite correct, as one must use the pass by reference version of setBlendblock in order to set a blend block on the stack.

Ooops!

Fixed.

But more importantly, I don't know exactly how to specify the transparency value with HlmsPbsDatablock::setTransparency. I tried this:

I tried simply editing PbsMaterialsGameState::setTransparencyToMaterials:

Code: Select all

  for( size_t i = 0; i < mNumSpheres; ++i )
  {
      Ogre::String datablockName = "Test" + Ogre::StringConverter::toString( i );
      Ogre::HlmsPbsDatablock *datablock =
          static_cast<Ogre::HlmsPbsDatablock *>( hlmsPbs->getDatablock( datablockName ) );

  datablock->setTransparency( mTransparencyValue, mode, false, false );
  datablock->setAlphaHashing( true ); // THIS LINE IS NEW
  }

And it just worked after I hit the "-" button in my numpad. I was using Vulkan.

I also tried adding:

Code: Select all

        datablock->setTransparency( 0.5f, Ogre::HlmsPbsDatablock::Transparent, false, false );
        datablock->setAlphaHashing( true );

At the end of setBrdfToMaterials(), also worked.

However your shader build error looks like a bug. I suspect I just need a simpler material. Any repro?

Then the log shows a bunch of warnings like this

Yeah, Alpha Hashing is brand new and has mostly been written for Unlit in mind (but it should definitely work with PBS), so rouch edges like that need to be reported & fixed.

[jwwalker]

Sorry, I was wrong about the specific shader compiler error... I had somehow introduced a typo into one of the piece files. After fixing that, the error I see is like this:

Code: Select all

Metal SL Compiler Error in 100000015PixelShader_ps:
program_source:478:50: error: use of undeclared identifier 'blueNoiseTex'
                                if( AlphaHashReject( finalAlpha, inPs.uv0.xy ALPHA_HASHING_ARG ) )
                                                 ^
program_source:330:31: note: expanded from macro 'ALPHA_HASHING_ARG'
                #define ALPHA_HASHING_ARG , blueNoiseTex
                              ^

But when I tried using setAlphaHashing in one of the sample programs, I didn't get that error, so it may take me a while to come up with a simple way to reproduce it.

[dark_sylinc]

But when I tried using setAlphaHashing in one of the sample programs, I didn't get that error, so it may take me a while to come up with a simple way to reproduce it.

I'm not at computer right now, but there is something you had to do at initialization to setup alpha hashing (basically setup the blue noise texture dds file).

However this looks like a bug in our Metal backend because we provide an alternate texture-less hashing implementation when the setup is not made.

[dark_sylinc]

I pushed a fix for your shader compiler error. Could you test it works?

As for the blue noise setup call, it is:

Code: Select all

        try
        {
            mRoot->getHlmsManager()->loadBlueNoise();
        }
        catch( Ogre::FileNotFoundException &e )
        {
            Ogre::LogManager::getSingleton().logMessage( e.getFullDescription(), Ogre::LML_CRITICAL );
            Ogre::LogManager::getSingleton().logMessage(
                "WARNING: Blue Noise textures could not be loaded.", Ogre::LML_CRITICAL );
        }

Which will try to load the file LDR_R_0.png.

[jwwalker]

Yes, that fixes the error! I am impressed that you were able to figure out the fix with so little information.

[jwwalker]

What is blue noise? Is in necessary to get alpha hashing to work the way you want?

[dark_sylinc]

What is blue noise? Is in necessary to get alpha hashing to work the way you want?

White noise is just completely chaotic random noise. It looks like when an old analog CRT TV has no signal.

Blue noise is noise where there is an extra effort to keep the distribution homogeneous and even so that there are no large concentrations of holes or of full opaque spots.

This picture points out the difference (from https://abau.io/blog/blue_noise_dithering/).

So in theory Blue Noise should be better. I say in theory because I've had people tell me the white noise one looks better.

the way you want?

Define "the way you want?"

I'm still not fully satisfied with either result because it shimmers too much (aliasing) when rotating the camera or when the object moves. If I try to solve that problem, then the object looks like it's made of holes instead of giving the appearance of semi-transparency.

I'm also using the mesh' UVs to determine the noise coordinate; which is not always the best choice so it's not a foolproof solution.

In certain cases e.g. smoke it's not a problem because smoke is inherently noisy, but in other cases, it could look better.

The only thing clear so far is that MSAA dramatically improves how it looks thanks to A2C (alpha to coverage).