shader noobi question

Scripting Issues
41

let me see what happens if im using python. its maybe just related to c++.

42

there i got this error:

Known pipe types:
  wglGraphicsPipe
(all display modules loaded.)
:display:gsg:glgsg(error): An error occurred while compiling shader!
Vertex shader failed to compile with the following errors:
ERROR: 0:1: '<' : syntax error parse error
ERROR:  compilation errors.  No code generated.
:display:gsg:glgsg(error): at 413 of c:\panda3d-1.7.0\panda\src\glstuff\glShaderContext_src.cxx : GL error 1281

its maybe really related to something in the glsl file.

would be really cool if you guys could fix this for windows.

43

i wont to try anything anymore, i spended now nearly 3 hours into to get a glsl file to run. althought, i knowed it would end up in nothing. that is quite stupid. so please fix this for windows. im sure this shader would work on linux. and im sure im not the only one with this problem.

44

I’m not on a windows system myself. You might want to file a bug report at bugs.launchpad.net so that it doesn’t get forgotten, and mention it in the bugthread.

45

Ooh, I did just find a bug in there. The bug is in the declaration of Shader::get_text():

  INLINE const string   get_text(const ShaderType &type = ST_none) const;

And the way it is used in glShaderContext_src.cxx:

const char* text = _shader->get_text(type).c_str();

The problem is that get_text() is defined to return a “const string” and not a “const string &” (this is probably just a simple typo). This means that it returns a concrete string object, not a reference to its internal string object; and so it constructs and copies a new temporary string when it is called, and returns that temporary string.

But in glShaderContext, we take the return value and immediately call c_str() on it, without saving it in a local string variable first. So the temporary string object destructs immediately after that statement, thus invalidating the result of c_str(). It may be that in certain environments the result of c_str() will remain in memory for long enough for it to be compiled, but there’s no guarantees of that; and that appears to be what krid has been running into.

I can check in a fix. For 1.7.1, I don’t want to change the function prototype (since that would invalidate the ABI compatibility requirement, even though it doesn’t count yet), so I’ll check in a fix to glShaderContext to store the string locally. But long-term, I’ll check in a fix to get_text() to return a reference instead of a concrete.

David

46

Great, many thanks!

For the record, there’s no problem in 1.7.0 being completely incompatible with 1.7.1. Due to the panda3d_1_7_0 symbol being renamed into panda3d_1_7, it’s incompatible anyways, so we might as well put as many ABI-breaking changes as possible in there.

47

Yeah. I just want to practice being ABI-compatible. :slight_smile:

David

48

cool,
where can i download this fix?

49

If you’re willing to build your own Panda, you can check out the cvs source and build it. Otherwise, you can wait for the next nightly build to become available, or wait for 1.7.1 to be released.

David

50

i have never build it, so im giving it a try. but i think the quickest way would be, if you say me, which lines in which files needs to be fixed. so far i can imagin its just a tiny change.

btw. when do you plan to release 1.7.1?

51

That’s up to rdb, but probably within a couple of weeks.

David

52

cool, hurry up rdb! :smiley:

53

If anyone interested here is today’s cvs build
zed.ee/panda/Panda3D-1.7.0.exe

zed.ee/panda/BuildLog.htm

It’s confirmed, issue in this thread is resolved