Does RenderMonkey have a bug in TEXCOORD stream mapping for GLSL?

Question

For clarity, I start with my question:

Is it possible to use (in the shader code) the custom attribute name which I set for the TEXCOORD usage in the (OpenGL) stream mapping in RenderMonkey 1.82 or do I have to use gl_MultiTexCoord0? (The question might be valid for the NORMAL usage too, i.e custom name or gl_Normal)

Background:

Using RenderMonkey version 1.82. I have successfully used the stream mapping to map the general vertex attribute "position" (and maybe "normal"), but the texture coordinates does not seem to be forwarded correctly. For the shader code, I use #version 330 and the "in" qualifier in GLSL, which should be OK since RM does not compile the shaders itself (the OpenGL driver do).

I have tried both .obj and .3ds files (exported from blender), and when checking the wavefront .obj-file, all texture coordinate information is there, as well as the vertex positions and normals.

If it is not possible, the stream mapping is broken and there is no point in naming the variables in the stream mapping editor (besides for the vertex position stream, which works), since one has to use the built-in variables anyway.

Update: If using the deprecated built-in variables, one has to use compatibility mode in the shader e.g

#version 330 compatibility
out vec2 vTexCoord;

and, in the main function:

vTexCoord = vec2(gl_MultiTexCoord0);

(Now I'm not sure about the stream mapping of normals either. As soon as I got the texture coordinates working, I had normal problems and had to revert to gl_Normal.)

Here is a picture of a working solution, but with built-in variables (and yes, the commented texcoord variable in the picture does not have the same name as in the stream mapping dialog, but it had the same name when I tried to use it, so it's OK.):

Answer 1

You could try to use the generic vertices's attributes, see http://open.gl, it's a great tutorial ;) (but I think it imply you'd have to rewrite the code to manual handle the transformations...)

Answer 2

#version 330

layout(location = 0) in vec3 bla_bla_bla_Vertex;
layout(location = 2) in vec3 bla_bla_bla_Normal;
layout(location = 8) in vec3 bla_bla_bla_TexCoord0;

This is a working solution for RM 1.82