"Invalid ShaderPtrSpec"?

Scripting Issues
, ,
1

Of recent, I’ve been seeing in my console output the following error message:

:display:gsg:glgsg(error): Invalid ShaderPtrSpec type 4 for shader input 'lightingLocations'

(And the same for another input.)

As best I recall, this has only fairly recently started popping up; I don’t know whether it’s due to something that I added recently to my project, or due to changes in my system, or to an update in Panda.

I’ve performed a search of the forum and taken a quick look at Panda’s code-base, and haven’t found mention of this error. (I even tried just looking up ‘"Invalid’ (i.e. with a leading pair of inverted commas).)

Presumably I’m doing something, well, invalid with some use of the shader-inputs somewhere, but it’s not clear to me whether this is on the Python-side or the shader-side, let alone specifically which applications of these inputs are causing the problem.

Does anyone have any insight on the matter?

2

Can you reduce it down to a minimal test case?

3

I mean, part of the problem is that I don’t know what’s causing it: those inputs are set in a number of places, and used in more than one shader.

If I knew enough about where it’s coming from to so reduce it, I’d likely have a better idea of what to experiment with.

That is: right now my main problem is simply in finding the origin of the error, so that I can investigate it further.

[edit]
I suppose that a potentially-useful starting-question might be: what is “ShaderPtrSpec type 4” in this context?

4

Number 4 corresponds to SPT_unknown, suggesting that there is some kind of a shader input not set correctly somewhere that the shader expects, but there could also be some memory corruption due to a bug.

To isolate it, it will probably help to hide the models that use each shader one by one, until you isolate it down to a specific shader, then hide the models that use that shader one by one until you find the right model.

You could also trace the places where you are setting that shader input and seeing if there is anything funny about any of those calls (or whether you might be missing one).

5

Good ideas, and thank you for them! :slight_smile:

Further, I’ve realised now from the context around this issue, that it may well be a less-crashy version of this old issue.

And indeed, with some investigation along the lines that you suggested, I believe that I’ve found the source of the problem, and fixed it!

Specifically, it seems that there was an edge-case of sorts: When constructing a “room”, I was initialising its lighting-data–usually a list of values with a fixed length–to an empty list.

(As is fairly common for me when initialising lists–an empty list is often a valid “ground state”, I feel.)

Theoretically, this empty list would then be replaced by actual, proper data as the room was constructed.

But in some cases this just didn’t happen for one reason or another–most commonly at the moment, because the location in which the “room” exists has yet to be constructed, leaving it “blank”.

And of course, since the shader was expecting an array of known, fixed length, there was a clash when it was given an array of zero-length…

I’ve corrected this simply by switching the initialisation from an empty list to a list of the appropriate length, but containing zero (or near-zero) values. Which seems to work! :slight_smile:

6

Ah! Good to know, thanks for the investigation! We should probably display a better error message here.

1 Like