Home-built Panda 1.9 on Ubuntu Saucy: Graphical Issues

I’ve been trying to build and install Panda (a 1.9 cvs download, I think it was) on Ubuntu 13.10 (Saucy Salamander), and seem to be pretty much there, save for some graphical issues observed in certain sample programs:

In Tut-Disco-Lights, the scene initially works correctly; however, on activating per-pixel lighting the scene vanishes and the on-screen text is rendered as series of black blocks (see image below). Pressing the per-pixel lighting button again produces a blank window.

The shader-based shadow-mapping examples form the start show no scene and text that is either rendered as solid blocks or pale text.

None of these seem to output an error of any sort (excluding the largely-illegible broken text), and a quick hack to have the basic shadow-mapping tutorial print its shader and depth-texture errors instead of placing them on the screen produced no additional output.

I note that the only “known pipe type” printed to the console when a Panda program is run is glxGraphicsPipe.

This all seems to point to shaders being broken, which seems odd, since I haven’t noticed any other problems on this system and the tests that I’ve tried thus far have seemed to produce positive results.

Oddly, the shaderless shadow-mapping tutorial also produces strange results, albeit arguably less broken:

I think that I did include the NVidia CG library (nvidia-cg-dev), and didn’t note any errors related to it in the build output – but I could easily have done something incorrectly, or missed an error.

I did exclude various elements from the build, including ODE, PhysX, SpeedTree, FFMpeg, FMod, Maya and Max, VRPN, FFTW, ARToolkit, NPAPI, Awesomium, Carbon, Cocoa and FCollada.

Does anyone have any idea as to what might be going wrong?

A bump and a bit of explanation: I’m choosing to not use the build provided by JörnS in the sticky thread above, to a great degree because it apparently excludes Bullet, which I would like to have.

Hello Thaumaturge,

I’m happy to inform you that I plan to include Bullet into the builds for Trusty.

Hey, I’m glad to read it, and thank you – however I’d much rather not wait the few months between here and Trusty’s release (it should be coming out in April, am I correct?).

(For that matter, Saucy is working rather well for me thus far – better than 12.04 did, as I recall – so I’d rather stick with it for some time. ^^; )

If feasible I’d really like to get my build working. ^^;

Another bump (the last for this thread, I intend).

Does no-one have any insight on this?

(I have subsequently realised that I’ve probably placed this in the wrong sub-forum; “Compiling or Editing the Panda Source” or even perhaps just “General Discussion” may have been better choices. Sorry about that. ^^; )

I think I recently fixed this in a major Cg handling overhaul. Let me know if this is still an issue today.

First of all, my apologies for the delay in my response!

It looks as though the main issue described above has indeed been fixed–thank you! Indeed, it looks as though you may have also fixed another issue that I hadn’t yet posted about (I was encountering flickering in certain shaders). :slight_smile:

As to the issue that I mentioned last in my original post–the shadow tutorial program not working–that doesn’t appear to be fixed. Similarly, attempting to display shadows in the “Disco Lights” tutorial produces broken shadows.

However, I have a bit more insight into that, I believe: it looks as though, for some reason, storing the depth buffer in an offscreen buffer doesn’t work on my machine. Showing the buffer via a BufferViewer (such as used in some of the tutorial programs) reveals either a largely flat grey buffer, with some minor, arbitrary-looking variations in tone.

(For those cases in which I’ve wanted depth information in a shader (and I’ll admit that I haven’t yet looked at implementing proper shadows), I do have a work-around: I simply use the lerped screen-space z-coordinate of the vertex in question, storing it in an off-screen buffer if called for.)

Finally, I seem to have picked up two new issues:

(Note that these two issues don’t appear to overlap: they’re used by different levels in the game, and affect different top-level shader files.)

1) I’m getting a warning about an implicit cast from float4 to float3–which is strange, because the line indicated is the return statement of a function, and the return type is float4. Stranger still, the function in question doesn’t appear to be used in the top-level shader file indicated.

This is the error in question, I believe:

:shader(warning): Encountered warnings during compilation of /home/ian/Documents/My Game Projects/Adventuring/Adventuring/leafShader.cg:
./Adventuring/ruinFuncs.cg(38) : warning C7011: implicit cast from "float4" to "float3"
./Adventuring/ruinFuncs.cg(38) : warning C7011: implicit cast from "float4" to "float3"

The file “leafShader.cg” imports “ruinFuncs.cg” via a “#include” statement near the top of the former. This is the code around line 38 in “ruinFuncs.cg” (with line-numbers prepended):

30   float4 treeColour(in uniform sampler2D tex_0,
31                     in float2 uv,
32                     in uniform sampler2D  mossTex,
33                     in float mossVal,
34                     in float3 l_normal,
35                     in float3 lightDir)
36   {
37       float4 colour = tex2D(tex_0, uv)*(1.0 - mossVal) + tex2D(mossTex, uv*2)*mossVal;
38       return colour;
39   }

(Yes, a number of those parameters seem to be unused; that file got a little messy, I’m afraid. ^^; )

2) One of my CG shaders–and only one, it seems–is now failing to load. I don’t seem to be getting error output other than the message that indicates that “the program could not load”, which reads as follows:

:display:gsg:glgsg(error): Could not load program: /home/ian/Documents/My Game Projects/Adventuring/Adventuring/lightingShader.cg (The program could not load.)

(I have checked the path, I believe–it appears correct. Is it relevant that the error appears to be a GLSL error, while the shader is in CG?)

The shader in question is as follows, I believe:

//Cg

#include "Adventuring/ruinFuncs.cg"

void vshader(
    in float4 vtx_texcoord0: TEXCOORD0,
    in float4 vtx_position: POSITION,
    in float3 vtx_normal: NORMAL,
    in float4 vtx_color: COLOR,
    in uniform float4 attr_color,
    in uniform float4x4 mat_modelproj,
    in uniform float4x4 mstrans_world,
    out float4 l_texcoord0: TEXCOORD0,
    out float4 l_position: POSITION,
    out float4 l_color: COLOR,
    out float3 l_normal,
    out float4 l_screenVtxPos:TEXCOORD6
)
{
    l_position = mul(mat_modelproj, vtx_position);
    l_texcoord0 = vtx_texcoord0;
    l_normal = vtx_normal.xyz;//mul(itp_modelview, vtx_normal).xyz;
    l_screenVtxPos = mul(mat_modelproj, vtx_position);
    l_color = vtx_color.xyzw*attr_color.xyzw;
}

void fshader(
    uniform sampler2D tex_0,
    in float4 l_texcoord0: TEXCOORD0,
    in float3 l_normal,
    in float4 l_screenVtxPos:TEXCOORD6,
    in float4 l_color: COLOR,
    in uniform float4x4 mstrans_world,
    out float4 o_color: COLOR0
)
{
    float dist = abs(l_screenVtxPos.z);
    o_color = tex2D(tex_0, l_texcoord0.xy);
    o_color = lighting(l_normal, l_screenVtxPos, dist, l_color, mstrans_world, o_color);
}

As in the issue just before this, this file imports “ruinFuncs.cg” (the function “lighting” comes from there, I believe)–but the error message doesn’t mention that file.

By the way, updating and rebuilding prompts me to ask: have my changes to DirectDialog, DirectRadioButton and Transitions been looked at yet? It’s a minor thing, and I do imagine that you’re busy, I’ll admit, but it’s something that niggles at me when I rebuild and re-install–for one thing, I keep getting tripped up by forgetting to copy over my versions of the files, which causes some of my projects to not work properly. I then diff the three files (against the possibility that other changes have been made to the updated versions), and then (since they don’t seem to have been changed thus far) replace those from the repository with my own versions.

Hmm, does the nature of these issues change when you toggle basic-shaders-only?

As for the Cg warning, perhaps the implicit cast is happening with the returned value itself, ie. you are assigning the output of treeColour() to a float3 without an explicit .rgb swizzle mask or something?

I recall some changes to DirectGui that I thought I had applied, but maybe it just slipped off my radar - feel free to just bump it when it seems like I’ve forgotten about it. Can you link me to the relevant bug report?

By the way, if you don’t want to have to do that elaborate sequence every time you update, you can just “git commit” your changes to your local clone, which will cause git to automatically merge whenever you pull the latest changes from panda3d in. Alternatively, you can hit “git stash” before you pull and “git stash pop” after you pull which is basically a way of automating what you’re already doing.
Committing it also makes it easy to use something like “git format-patch origin/master” which automatically generates patch files for your local changes that can easily be submitted upstream.

One thing that has just occrred to me: the tutorial programs that I’m using are those provided with 1.8.1, I believe, and thus any changes since that version–including changes to the provided shaders–are presumably not present. If called for, I can try to download and run newer versions.

In case I’m doing something wrong, I’ll specify that I did this by adding the following to the start of the relevant “main” scripts, after whatever other PRC-related code was present:

loadPrcFileData("", "basic-shaders-only #t")

That said, doing so seemed to rectify the problem of the shader that was failing to load (the issue that I labelled “2” in my post above). My own PRC file, loaded at the start of my “main” script, disables “basic-shaders-only”, and I don’t believe that this has changed recently, so it was, presumably, working with that setting before I updated for this build (well, unless some other issue was causing Panda to switch to only using basic shaders despite this setting).

It doesn’t seem to have affected the other issues (the depth-buffer problem and the odd shader warnings), however.

As far as I can see, I’m not actually calling that function in the indicated file. o_0

Interestingly, on re-running one of the shadow-mapping tutorials (Tut-Shadow-Mapping-Advanced.py) to test the issues that I’m seeing there I discovered that the same warning seems to appear there, pointing to “shadow.sha”, on multiple lines. The specific error output is as follows, I believe:

:shader(warning): Encountered warnings during compilation of shadow.sha:
(34) : warning C7011: implicit cast from "float4" to "float3"
(31) : warning C7011: implicit cast from "float4" to "float3"
(31) : warning C7011: implicit cast from "float4" to "float3"
:shader(warning): Encountered warnings during compilation of shadow.sha:
(34) : warning C7011: implicit cast from "float4" to "float3"
(55) : warning C7011: implicit cast from "float4" to "float"
(55) : warning C7011: implicit cast from "float4" to "float"

I made three, one for each of the files changed (DirectRadioButton, DirectDialog, and Transitions), I believe. These should be them:
DirectDialog
DirectRadioButton
Transitions

Here’s the original thread on the topic, I believe, in case it’s helpful.

Ah, that looks handy, thank you. :slight_smile:

(I’ll take a look at it in more detail when I’m (hopefully) less horribly tired. I’ll confess that I’m not terribly familiar with GIT, and thus am not clear on some of the terms used–a little research is called for on my part! ^^; )

In case someone else has a similar problem, I’m reporting that, having revisited it more recently, I seem to have solved the issue of the shader that wouldn’t compile.

Simply put, it looks as though the problem was that “l_normal”–the normal vector that is an output of the vertex shader and an input to the fragment shader–had no semantic assigned to it. This doesn’t seem to have been a problem in 1.8, but I presume that 1.9 (or some third-party element included therein) is stricter about these things.

Interestingly, the shader only fails to compile when the semantic is omitted from the fragment shader; it compiles happily when the semantic is included in the fragment shader but omitted from the vertex shader, although it produces incorrect results in this case.

(And yes, I do feel a little silly for not having previously tried correcting this omission. ^^; )