mesh_viewer error

[WASasquatch]

I wanted to do the live viewing thing so I followed the extended directions on the KSP forum for Windows 10, but I get this error when I run the mesh_viewer

Initialized GLEW
OpenGL 3.0 available
Vertex shader compile error in files:
    0: "string_vertex_header"
    1: "single-color-lit-per-vertex.vert"
GLSL Error:

varying vec3 v_Color;

Then it proceeds to spit out tons of code, and other errors.

Am I missing a dependency or is it something else?

Full command log:
console.log

[smcameron]

Looks like a problem with compiling the GLSL shaders. iirc, WSL on windows 10 uses software rendering for opengl. I notice it says opengl 3.0... and maybe it doesn't like the "varying" keyword, and maybe wants to use the newer "in" and "out" keywords? I had converted to opengl 3.0 awhile back, but reverted back to an older version of glsl because some older machines don't support it 3.0. Opengl 3.0 is *supposed* to support "varying", but maybe on WSL with the software opengl it doesn't work? Just a guess. If I'm right, and you want to convert all the shaders to opengl 3.0 style "in" and "out" instead of "varying", you could try applying this patch in reverse: https://github.com/smcameron/space-nerds-in-space/commit/774ebd19511c4820016a795e854de9c17cd4749b.patch That is, save that file to a text file, then apply it with: patch -p1 --reverse < patchfile.txt But I don't know if that will help. Also, since it's using a software renderer and presumably you're burning up all your CPUs with gaseous-giganticus at the same time, it might not perform very well.

…

-- steve

On Thu, Dec 9, 2021 at 3:40 PM Jordan Thompson ***@***.***> wrote: I wanted to do the live viewing thing so I followed the extended directions on the KSP forum for Windows 10, but I get this error when I run the mesh_viewer Initialized GLEW OpenGL 3.0 available Vertex shader compile error in files: 0: "string_vertex_header" 1: "single-color-lit-per-vertex.vert" GLSL Error: varying vec3 v_Color; Then it proceeds to spit out tons of codes and other errors. Am I missing a dependency or is it something else? Full command log: console.log <https://github.com/smcameron/space-nerds-in-space/files/7688304/console.log> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#316>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAF22FA77INDGZCID3KJ63UQEH2HANCNFSM5JXNNVDQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[smcameron]

On the other hand, looking at that console log, either there's a bug in my GLSL shader compiling error handling, or, WSL opengl is giving me back garbage in the error information, hard to tell which.

OTOH, on my (native linux) system, if I intentionally introduce an error into a shader, e.g.:

diff --git a/share/snis/shader/single-color-lit-per-vertex.vert b/share/snis/shader/single-color-lit-per-vertex.vert
index 8412f6c..eade48e 100644
--- a/share/snis/shader/single-color-lit-per-vertex.vert
+++ b/share/snis/shader/single-color-lit-per-vertex.vert
@@ -19,7 +19,7 @@ void main()                // The entry point for our vertex shader.
 {
        // Transform the vertex into eye space.
        vec3 modelViewVertex = vec3(u_MVMatrix * a_Position);
-
+xxx
        // Transform the normal's orientation into eye space.
        vec3 modelViewNormal = normalize(u_NormalMatrix * a_Normal);

That 'xxx' is not supposed to be there, then when I try to run mesh_viewer, I get this:

sRGB texture supported
Vertex shader compile error in files:
    0: "string_vertex_header"
    1: "single-color-lit-per-vertex.vert"
GLSL Error:
  33:  // Transform the normal's orientation into eye space.
  34:  vec3 modelViewNormal = normalize(u_NormalMatrix * a_Normal);
    : .^
  35: 
0:34(2): error: syntax error, unexpected VEC3, expecting ',' or ';'

That is, it reports that there's an error in the shader and puts an arrow pointing to the (non-comment) word immediately following the 'xxx', which seems more or less correct, and it gives me a sensible error message. So I'm sort of inclined to think the WSL opengl software implementation is not all that complete or robust and it's giving me back garbage for the compile error information.

Or, it may be that it's giving me back sensible error messages, but they don't start with the line numbers, which I'm depending on. Perhaps I assumed too much about the format of the errors that come out of the GLSL compiler code. i.e., this code, in shader.c:

 73                 rc = sscanf(tmp, "%*d:%d(%d)", &lineno, &charno);
 74                 if (rc == 2 && lineno > highest_error) {
 75                         print_glsl_code_context(shadercode, nshader_parts, lineno, charno);
 76                         highest_error = lineno;
 77                 }

[WASasquatch]

I think I'll set GG to 10 threads, that should give me 2 to hopefully run the mesh viewer decently enough (that's what I end up doing when I render in Terragen, set to 10 cores so I can browse the net or watch youtube/netflix).

I think I remember something about a compilation error regarding opengl, and then I reinstalled the offending dependency and ran the compilation again. Perhaps I unknowingly introduced a error. Now that all the dependencies should be ready to go I'm going to try a fresh make.

[WASasquatch]

No I seem to be getting the same or similar issue, though I did catch some infromation from the fresh compilation I don't think I caught before.

was@SKYNET-MASTER:/mnt/d/Linux/Gas/space$ make ./bin/mesh_viewer
  COMPILE shader.c
  COMPILE graph_dev_opengl.c
  COMPILE opengl_cap.c
  COMPILE snis_graph.c
  COMPILE check-endianness.c
  GATHER BUILD INFO
  COMPILE mesh_viewer.c
mesh_viewer.c: In function ‘main’:
mesh_viewer.c:978:3: warning: implicit declaration of function ‘feenableexcept’; did you mean ‘feraiseexcept’? [-Wimplicit-function-declaration]
   feenableexcept(FE_DIVBYZERO | FE_INVALID | FE_OVERFLOW);
   ^~~~~~~~~~~~~~
   feraiseexcept
mesh_viewer.c: At top level:
cc1: warning: unrecognized command line option ‘-Wno-gnu-folding-constant’
cc1: warning: unrecognized command line option ‘-Wno-extended-offsetof’
  COMPILE png_utils.c
  COMPILE turret_aimer.c
  COMPILE quat.c
  COMPILE mathutils.c
  COMPILE mesh.c
  COMPILE mtwist.c
  COMPILE material.c
  COMPILE entity.c
  COMPILE snis_alloc.c
  COMPILE matrix.c
  COMPILE stacktrace.c
  COMPILE stl_parser.c
  COMPILE snis_typeface.c
  COMPILE snis_font.c
  COMPILE string-utils.c
  COMPILE ui_colors.c
  COMPILE liang-barsky.c
  COMPILE bline.c
  COMPILE vec4.c
  COMPILE open-simplex-noise.c
  COMPILE replacement_assets.c
(cd mikktspace && make )
make[1]: Entering directory '/mnt/d/linux/gas/space/mikktspace'
  COMPILE mikktspace.c -c mikktspace.c
make[1]: Leaving directory '/mnt/d/linux/gas/space/mikktspace'
(cd ssgl && make USE_CUSTOM_STRLCPY=0 )
make[1]: Entering directory '/mnt/d/linux/gas/space/ssgl'
  COMPILE ssgl_sanitize.c
  COMPILE ssgl_sleep.c
  COMPILE ssgl_socket_io.c
  COMPILE ssgl_log.c
  COMPILE ssgl_get_primary_host_ip_addr.c
  COMPILE ssgl_get_gamelobby_port.c
  COMPILE ssgl_server.c
  LINK ssgl_server.o
  COMPILE ssgl_recv_game_servers.c
  COMPILE ssgl_connect_to_lobby.c
  COMPILE ssgl_register_gameserver.c
  COMPILE ssgl_register_for_bcast_packet.c
  ARCHIVE libssglclient.a
  COMPILE ssgl_gameclient_example.c
  LINK ssgl_gameclient_example.o
  COMPILE ssgl_gameserver_example.c
  LINK ssgl_gameserver_example.o
cp ssgl_gameclient_example lsssgl
make[1]: Leaving directory '/mnt/d/linux/gas/space/ssgl'
  LINK bin/mesh_viewer

from a function the compiler can't find.

[smcameron]

Nah, all that stuff is unrelated. feenableexcept() is related to debugging floating point NaNs and the '-t' option of snis_client for debugging floating point issues.

The shaders for SNIS are in share/snis/shader, and they are "compiled" at runtime by the OpenGl library to run on the GPU. They're not compiled when the C code is compiled. The problem is, SNIS is asking OpenGl to compile the shaders, and OpenGl is saying, "I don't like these shaders." but not really saying why it doesn't like them in a way that SNIS understands, or SNIS is being overly particular about the format of the messages. Could be that the error messages coming back from the WSL software implementation of OpenGL doesn't match what is produced by OpenGl on all the linux systems I've tried, but it's kind of hard to tell.

In any case, there's something about the shaders that it doesn't like. Since it claimed OpenGl 3.0, and the shaders are all written for OpenGl 2.1 (see this and the opengl version number decoder ring) that made me suspect that maybe it didn't like "varying", because when I changed the shaders to use "in" and "out" instead of "varying", I also had to change the opengl version to 3.0, because those keywords don't exist in opengl 2.1, hence why I pointed you to that patch. I had thought that OpenGl 3.0 should be able to compile 2.1 shaders, but maybe not, or maybe not in the case of the software based OpenGl on windows 10 WSL, I just don't really know.

The other thing I'll mention is I believe you have to run an X server in WSL as well, see for example: microsoft/WSL#2855 Maybe you already knew that, but you didn't mention it so I thought I should mention it.

[WASasquatch]

Alright. I'll have to try that patch out and see.

And yeah I have the X Server thingy installed and tested the "xeyes" which worked fine, and it does open the mesh viewer window, but of course it just crashes and closes.