yellow objects

[bayoubengal]

I moved a working program from the 2.1 version to the 2.2 version. For some reason, my items are all showing up yellow. they should be white as I call setDiffuse( { 1.0f, 1.0f, 1.0f } ) on the material being applied to the them. The items have no textures applied I simply want properly colored shapes. I get the right color if I call set setEmissive( { 1.0f, 1.0f, 1.0f } ) so I know the material is generally working. Note I am programmatically creating the material...


auto tmpName = "C3DWindowController_mat_rgba_cone_Pbs_"s + std::to_string(tmpKey);
auto tmpHlmsManagerPtr = Ogre::Root::getSingleton().getHlmsManager();
auto tmpHlmsPbsPtr = tmpHlmsManagerPtr->getHlms(Ogre::HLMS_PBS);

if(tmpMaterialPtr == nullptr)
{


auto tmpMaterial2Ptr = static_cast<Ogre::HlmsPbsDatablock*>(
tmpHlmsPbsPtr->createDatablock( tmpName,
tmpName,
Ogre::HlmsMacroblock(),
Ogre::HlmsBlendblock(),
Ogre::HlmsParamVec() , true, "", Ogre::ResourceGroupManager::DEFAULT_RESOURCE_GROUP_NAME) );


auto tmpRedValue = (float_t)((theValue >> 24) & 0xFF) / 255.0f;
auto tmpGreenValue = (float_t)((theValue >> 16) & 0xFF) / 255.0f;
auto tmpBlueValue = (float_t)((theValue >> & 0xFF) / 255.0f;

tmpMaterial2Ptr->setDiffuse( { 1.0f, 1.0f, 01.0f } );

...




WHat might I be doing wrong to get everything yellow? I don't have anything I color yellow myself in the program

[dark_sylinc]

Yellow is an indication of wrong padding in our shader structures.

What RenderSystem / OS are you using?
Are you customizing Hlms or using stock?
Would you be able to repro this bug in one of our samples? (e.g. take Tutorial02 and make a few changes to highlight the bug)

[bayoubengal]

I did try using my simple material in Sample_decals. I changed to code to apply my material to the plane. I did not get yellow color I see in my production project, but the result is not what I expect either. snippet...



planeMesh->importV1( planeMeshV1.get(), true, true, true );

{
Ogre::Item *item = sceneManager->createItem( planeMesh, Ogre::SCENE_DYNAMIC );
Ogre::HlmsManager *hlmsManager = mGraphicsSystem->getRoot()->getHlmsManager();
auto tmpHlmsPbsPtr = hlmsManager->getHlms(Ogre::HLMS_PBS);

auto tmpMaterial2Ptr = static_cast<Ogre::HlmsPbsDatablock*>(
tmpHlmsPbsPtr->createDatablock( "C3DWindowController_mat_rgba_Pbs_4294901760",
"C3DWindowController_mat_rgba_Pbs_4294901760",
Ogre::HlmsMacroblock(),
Ogre::HlmsBlendblock(),
Ogre::HlmsParamVec() , true, "", Ogre::ResourceGroupManager::DEFAULT_RESOURCE_GROUP_NAME) );

tmpMaterial2Ptr->setDiffuse( { 1.0f, 1.0f, 1.0f } );
item->setDatablock( tmpMaterial2Ptr );

//item->setDatablock( "Marbledgfgfg" );
Ogre::SceneNode *sceneNode = sceneManager->getRootSceneNode( Ogre::SCENE_DYNAMIC )->
createChildSceneNode( Ogre::SCENE_DYNAMIC );
sceneNode->setPosition( 0, -1, 0 );
sceneNode->attachObject( item );


I would expect to see a white plane, but it looks like white is being blended with the blue background. I'm not doing anything to cause transparency.

[bayoubengal]

platform is OSX 10.14

[bayoubengal]

This is the scene I am drawing. The plane in this scene should be whitish...not yellowish. If I set NO color at all, it is yellow. If I make the color emissive, it is correct.

[dark_sylinc]

I get a white plane:


I noticed you wrote:
{ 1.0f, 1.0f, 01.0f }

Could you try Ogre::Vector3( 1.0f, 1.0f, 1.0f )
I don't know if that C++11 construct has the same meaning, and also you wrote 01.0f instead of 1.0f. That zero on the left may be causing trouble.

Btw you didn't mention your RenderSystem. Are you using OpenGL? Are you able to try Metal? Or OpenGL on another platform? (e.g. Linux, Windows)

[bayoubengal]

This is what I get if I set emissive to red and diffuse to blue. It appears that something is changing the diffuse color to yellow some where

[bayoubengal]

This is what I get if I set emissive to red and diffuse to blue. It appears that something is changing the diffuse color to yellow some where

[dark_sylinc]

Place a breakpoint inside HlmsPbsDatablock::uploadToConstBuffer when you hit your datablock's name, and ensure mkDr, mkDg and mkDb are white (divided by PI).

If it's not, then your value got modified somewhere in the middle.
Adding a data breakpoint to datablock->mkDb could help you find where it's being modified.

Use:

Code: Select all

wa s e -- 0x12345678

Where 0x12345678 is the address of &datablock->mkDb

[bayoubengal]

I set diffuse to blue (0,0,1). after here..


float oldkDr = mkDr;
float oldkDg = mkDg;
float oldkDb = mkDb;


oldkDr = 0
oldkDg = 0
oldkDb = 0.318309873

same after here...


mkDr = oldkDr;
mkDg = oldkDg;
mkDb = oldkDb;

[bayoubengal]

Where mkDr, mkDg and mkDb actually make their way into the mental renderer where they are put to use to actually render the scene? I don't see those values stored to any buffers or fed to anything else.

[bayoubengal]

ah. I see how it is copied to a buffer.

The value is making its way into dstPtr.

Where is the next access point to check?

[dark_sylinc]

That happens here:

Code: Select all

memcpy( dstPtr, &mBgDiffuse[0], MaterialSizeInGpu - sizeof(mTexIndices) );
dstPtr += MaterialSizeInGpu - sizeof(mTexIndices);
memcpy( dstPtr, texIndices, sizeof(texIndices) );
dstPtr += sizeof(texIndices);

Try setting pbs->setOptimizationStrategy( LowerGpuOverhead );

Also stupid question: Your light isn't set to yellow? Because blue will never appear if the lights don't send blue.

[dark_sylinc]

Where is the next access point to check?

None, that's the last step. You can use XCode GPU Debugger to check the buffer is properly set.
But beware the value is material[materialIdx], and sometimes materialIdx is hard to get (unless you're using LowerGpuOverhead, which always forces everything to material[0])

It's also quite possible to check in XCode GPU Debugger that the PassBuffer's light colour is incorrectly set, which could happen if we missed some alignment/padding.

[bayoubengal]

Also stupid question: Your light isn't set to yellow? Because blue will never appear if the lights don't send blue.

The light is white.

[bayoubengal]

I get a white plane:

how is it white? It looks lavender to me. I'd expect pure white. given the plane is not set to be transparent. What am I missing?

[bayoubengal]

Btw you didn't mention your RenderSystem. Are you using OpenGL? Are you able to try Metal? Or OpenGL on another platform? (e.g. Linux, Windows)

Metal. OpenGL is broken on 2.2. doesn't even build. I only operate on OSX

[bayoubengal]

It's also quite possible to check in XCode GPU Debugger that the PassBuffer's light colour is incorrectly set, which could happen if we missed some alignment/padding.

ok. I want to investigate the possibility that there is an alignment error. What am I looking for in developer docs to understand the structure that is being built in the buffer?

[dark_sylinc]

Let me know if this guide helps you or is not what you're looking for.

[bayoubengal]

I pulled up the WWDC videos and saw how to get into the shader debugger. The yellow is coming from passBuf.ambientUpperHemi. But the values displayed are not what I set in the program. diffuseCol is blue like it should be in the test I set up. investigating

[bayoubengal]

passBuf.ambientLowerHemi has the value that should be in passBuf.ambientLUpperHemi. passBuf.ambientLUpperHemi is wrong. not sure where the (1.0, 1.0, 0.0) is coming from yet. Id say that is where the alignment problem likely is.

[dark_sylinc]

Is it possible your Hlms templates are out of date?

Very recently we added "float4 pccVctMinDistance_invPccVctInvDistance_unused2" to 500.Structs_piece_vs_piece_ps.any which sits right between invViewMatCubemap and ambientUpperHemi; and would be filled with 1 1 0 0 with the default values.

[bayoubengal]

Is it possible your Hlms templates are out of date?

Very recently we added "float4 pccVctMinDistance_invPccVctInvDistance_unused2" to 500.Structs_piece_vs_piece_ps.any which sits right between invViewMatCubemap and ambientUpperHemi; and would be filled with 1 1 0 0 with the default values.

that is exactly the problem. when I updated the libs in my 3rd party sdk folder, I didn't install the new shader files. thanks!

I tracked it down to exactly that chunk of code.