Set_Shader_Input

[Kesslerb2]

I’ve got another 1.8->1.10 question here.

Back in commit cd79de1 it looks like set_shader_input() was changed to no longer accept strings. I’m trying to track down a bug that I think might be shader related and wanted to just clarify that this is doing what I think it is.

I had a line in the 1.8 code that was

this->terrainParentNP.set_shader_input( "cameraAltitude", camPositionLLA.GetAlt() ); //alt is a double

and changed in the 1.10 code to

this->terrainParentNP.set_shader_input( "cameraAltitude", camPositionLLA.GetAlt(), 0); //alt is a double

in my new code so that it compiles.

I believe the old code was basically calling

void set_shader_input(const string &id, double  n1=0, double n2=0, double n3=0, 
      double n4=1, int priority=0); //where n1 = altitude

and the new code is calling

  INLINE void set_shader_input(CPT_InternalName id, int n1, int n2, int n3=0,
                                                    int n4=0, int priority=0); //where n1 = altitude and n2 = 0

Could anyone clarify this for me? I’m having issues with my terrain and water showing up oddly or not at all and would like to cross this off the possible causes.

Thanks

[rdb]

I don’t think that commit is related. The string version is no longer necessary now that Panda can automatically coerce a string to CPT_InternalName.

You should consider changing your code to this, I think:
set_shader_input("cameraAltitude", LVecBase4(camPositionLLA.GetAlt()));

[Kesslerb2]

Ahhh, that makes sense. I’ll try out your suggestion.

[Kesslerb2]

Unfortunately it didn’t help at all but it is more readable. I’m still getting weird issues with the terrain rendering.

1.8

1.10

[Edit 1] When I zoom out really far the 1.10 flickers a bunch as I zoom (z-fighting possibly?) and then settles here:
1.8

1.10

[Edit 2]
If anyone runs into this issue later I’ve made some progress that might help you. I’ve flipped the sort order of my 10 texture stages and made some headway.

[Kesslerb2]

Small update:
I’ve continued to mess with the sort_order of my layers and can now see some washed out terrain when very close to it.

However, once I start to zoom out (in this case just moving the camera away from the hill), the terrain disappears and then bottom of the world shows through.

[Kesslerb2]

@rdb Is there anything that you know of from 1.8->1.10 that would change the frame buffer capabilities? I just noticed that color bits went from 32->24. I can’t find a function in my build of 1.8 that will let me query rgb separately so I can’t see if those match.

The following is an ouput from FrameBufferProperties::Output

1.8 Output:

INFO  app - Display capabilities: depth_bits=24 color_bits=32 alpha_bits=8 stencil_bits=8 back_buffers=1 force_hardware=1  max_texture_stages=4, max_texture_dimension=16384, non-pow2-tex=1

1.10 Output:

INFO  app - Display capabilities: depth_bits=24 color_bits=24 red_bits=8 green_bits=8 blue_bits=8 alpha_bits=8 stencil_bits=8 back_buffers=1 force_hardware  max_texture_stages=4, max_texture_dimension=16384, non-pow2-tex=1

Edit:
The config.prc files are exactly the same and have this in them:

# These set the minimum requirements for the framebuffer.
# A value of 1 means: get as many bits as possible,
# consistent with the other framebuffer requirements.

depth-bits 1
color-bits 1
alpha-bits 0
stencil-bits 1
framebuffer-multisample 0
multisamples 0

[rdb]

It might be helpful to use a tool like apitrace to generate a trace of the OpenGL calls, and then use qapitrace to inspect the OpenGL state and shaders to see if something odd is going on.

color-bits should not be 32; it only includes the red, green, blue channels, so 24 sounds right.

As for requesting framebuffer properties, the new recommendation in 1.10 is to use set_rgba_bits(8, 8, 8, 8) instead of something like set_color_bits(24).

Have you seen these notes?

Panda3D 1.10 Migration Notes

[Kesslerb2]

I haven’t seen that, I’ll take a look now! Is there a version that isn’t on dropbox by chance?

Edit: Nvm, I made an offline copy and sent it to myself.