Menu
▾
▴
#864 gem can't load glsl shaders (win7-
pd 0.43.1-extended-20120228
gem
GEM: ver: 0.93.3
GEM: compiled: Nov 10 2011
when i try to load a shader ,for instance in examples/glsl/
i get this (the file is in the current directory ):
GEM: GLEW version 1.5.4
GEM: Start rendering
[glsl_geometry]: error reading file
[glsl_vertex]: error reading file
[glsl_fragment]: error reading file
[glsl_program]: Info_log:
[glsl_program]: Link info
---------
No shader objects attached.
[glsl_program]: Link failed!
GL: valeur non valide
seems like the file is seen but can't be read (encoding?)
Discussion
Anonymous
cannot reproduce this.
what is the install location of the files that cannot be opened...
all files are in:
W:\pd\extra\Gem\examples\10.glsl
i know, my install of seven is on w:
no space in path
last time it was the problem.
i already looked into permissions,and launching pd as administrator
turning verbose on gives :
i tried gem 92.3 on the same machine works ok. since that , all versions fail (on windows)
[glsl_fragment]: glsl_fragment Hardware Info
[glsl_fragment]: ============================
[glsl_fragment]: MAX_FRAGMENT_UNIFORM_COMPONENTS: 2048
[glsl_fragment]: MAX_TEXTURE_COORDS: 8
[glsl_fragment]: MAX_TEXTURE_IMAGE_UNITS: 32
tried W:\\pd\\extra\\Gem\\examples\\10.glsl\\tri2fan.geom and succeeded
error: [glsl_geometry]: error reading file
tried W:\\pd\\extra\\Gem\\examples\\10.glsl\\tri2fan.vert and succeeded
error: [glsl_vertex]: error reading file
tried W:\\pd\\extra\\Gem\\examples\\10.glsl\\tri2fan.frag and succeeded
error: [glsl_fragment]: error reading file
did i say it's 64 bits windows 7?
if that changes something.
can you read the shader-files with [textfile]?
i can read the shader file from notepad ,or notepad++
i tried this :
|read tri2fan(
|
|textfile|
|
|print|
i get this :
tried W:\\pd\\extra\\Gem\\examples\\10.glsl\\tri2fan.geom and succeeded
then i bang the |textfile|
and get no output.
so the problem is in handling of text files.
so i tried
text3d help works-
example in /4.data stuctures /6. file.pd works-
qlist works-
thanks
pierre-yves
fogot to precise now its pd 42.5 with gem 93.3
textfile example works if i rewind .... of course.
but .. i tried it on the shader file and it works bizarrely.
i had a freeze of pd. i will reboot now just to be sure nothing stays in the graphics card memory and i will retry...
...later
ok windows booted ok :-)
what happened is:
i loaded the shader into textfile , then rewind -then bang the textfile-
printout is void main()
then immediate freeze (patch windows freezed -menus react ok but no action (quit doesnt work,can't save..--help browser works but won't open a patch)
i tried both |read shader( and |read shader cr( same effect.
i tried other shader files too .
then i kill pd (and restart it because i like it )
and i test other things that fail :
example patch 10. glsl/ 01.simple texture (direct freeze )
event viewer doesn't say a lot .:W:\pd\bin\wish85.exe
0000: 54 00 6F 00 70 00 20 00 T.o.p. .
0008: 6C 00 65 00 76 00 65 00 l.e.v.e.
0010: 6C 00 20 00 77 00 69 00 l. .w.i.
0018: 6E 00 64 00 6F 00 77 00 n.d.o.w.
0020: 20 00 69 00 73 00 20 00 .i.s. .
0028: 69 00 64 00 6C 00 65 00 i.d.l.e.
0030: 00 00 00 00 ....
i know windows port is not the priority but if pd works ok it will bring a lot of people to opensource coding. i hope.
i use it on ubuntu linux and tried it on osx. but windows port needs some polishing.
I wish i could help more.
please tell me if i can test things i will .
it looks like there is some strange behaviour in textfile (and shader loading when the text contains these characters () or {}
i can list a shader in textfile (sending print)
---
--------- textfile or qlist contents: -----------
// Cyrille Henry 2007 uniform float K1 \;
uniform float K2 \;
uniform float K3 \;
uniform vec2 offset \;
void main() \{ gl_TexCoord[0] = gl_MultiTexCoord0 \;
gl_Position = ftransform() \;
\}
but not banging line by line if line contains () or {}
list: // Cyrille Henry 2007 uniform float K1
list: uniform float K2
list: uniform float K3
list: uniform vec2 offset
list: void main()
forever loop
Pd won't properly print curly braces. best to avoid that alltogether and just use
[textfile]
|
[t b]
|
[print]
to see whether it properly iterates.
but anyhow, it seems like it does...
thanks for your bug-report;
please note however, that Gem has a separate bug-tracker, at http://sourceforge.net/tracker/?group_id=64325&atid=507079
(this should be printed to the pd-console whenever Gem is loaded)
please use Gem's bug-tracker for Gem bugs.
Gem's sourceforge-project can be found at http://sourceforge.net/projects/pd-gem
not sure if it is a puredata or gem problem
textfile should /could properly print curly braces, no?
is the same code used to load a shader in gem?
because shaders use curly braces ,and this can't be changed .
thanks
thanks for your bug-report;
please note however, that Gem has a separate bug-tracker, at http://sourceforge.net/tracker/?group_id=64325&atid=507079
(this should be printed to the pd-console whenever Gem is loaded)
please use Gem's bug-tracker for Gem bugs.
Gem's sourceforge-project can be found at http://sourceforge.net/projects/pd-gem
it seems to be a Gem problem (and thus should actually ne reported at the Gem-tracker, sorry for that)
[textfile] can obviously read the fie fine, it's only [print] (or rather: Pd's print system in relation to tcl/tk) that has problems with curly braces.
i think i found the cause of the problem (and fixed it in git, so it should appear in the next (bugfix) release of Gem)
Gem is reading the the shader-files as "text", and checks whether it was able to read all the bytes from the file.
w32 will convert CRLF line-endings to CR, so for each line-ending, one byte goes missing and Gem (erroneously) thinks it was unable to read the entire file.
until there are binaries available, you could try to convert your shader-files from CRLF to LF, so no bytes go missing...
sorry for the inconvenience
no that's great !
i'm very happy you nailed it.
it's my first bug report with a solution
i'll try your workaround .