Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Debug lines are black #60

Closed
vvs- opened this issue Jun 7, 2015 · 13 comments

Comments

Projects
None yet
5 participants
@vvs-
Copy link
Contributor

commented Jun 7, 2015

Happened after VAO merge.

@cochrane

This comment has been minimized.

Copy link
Contributor

commented Jun 8, 2015

Are they still used? Do they even work at all? If yes, then I don't know why.

@Lwmte

This comment has been minimized.

Copy link

commented Jun 8, 2015

Not sure what exactly "lines" mean, but now I have problem with Bullet debug drawer (r_coll console command) - all lines are now red, while previously it had Bullet-specific coloring (green for static/kinematic bodies, white for dynamics and red for dynamics with disabled deactivation).

@vvs-

This comment has been minimized.

Copy link
Contributor Author

commented Jun 8, 2015

Yes, that's what I meant: r_boxes, r_coll etc. But they are black for me, not red. It's strange that colors are different with different drivers.

@TeslaRus

This comment has been minimized.

Copy link
Contributor

commented Jun 8, 2015

In my case all lines colors are red + in last commit I fix one terrible bug: wrong lines number in debug renderer render function;

@cochrane cochrane self-assigned this Jun 8, 2015

@vvs-

This comment has been minimized.

Copy link
Contributor Author

commented Jun 13, 2015

The colors in shaders are of type vec4, but in debug drawer they use vec3. That doesn't make sense to me.

@vvs-

This comment has been minimized.

Copy link
Contributor Author

commented Jun 13, 2015

Ok. Changing debug drawer to use stencil shader instead of room shader made color of the lines white 😄 I guess that room shader required textures to produce colors, while stencil shader have its' color hardcoded.

@cochrane

This comment has been minimized.

Copy link
Contributor

commented Jun 13, 2015

Correct. The stencil shader is hardcoded to white.

@vvs-

This comment has been minimized.

Copy link
Contributor Author

commented Jun 13, 2015

So, the problem is that there is no shader presently that can use debug drawer colors. And the room shader is not suitable either.

@vvs-

This comment has been minimized.

Copy link
Contributor Author

commented Jun 13, 2015

That patch fixed it:

diff --git a/shaders/stencil.fsh b/shaders/stencil.fsh
index 565d611..d8c174c 100644
--- a/shaders/stencil.fsh
+++ b/shaders/stencil.fsh
@@ -1,8 +1,9 @@
 // stencil.fsh
 // Does the most simple drawing possible, because all information is discarded
 // anyway and only the stencil buffer used.
+varying vec4 varying_color;

 void main(void)
 {
-    gl_FragColor = vec4(1);
+    gl_FragColor = varying_color;
 }
diff --git a/shaders/stencil.vsh b/shaders/stencil.vsh
index 9f68c28..00af288 100644
--- a/shaders/stencil.vsh
+++ b/shaders/stencil.vsh
@@ -1,6 +1,7 @@
 // stencil.vsh
 // Does the most simple drawing possible, because all information is discarded
 // anyway and only the stencil buffer used.
+varying vec4 varying_color;

 attribute vec3 position;

@@ -8,5 +9,6 @@ uniform mat4 modelViewProjection;

 void main(void)
 {
+    varying_color = gl_Color;
     gl_Position = modelViewProjection * vec4(position, 1.0);
 }
diff --git a/src/render.cpp b/src/render.cpp
index 050175f..55befcc 100644
--- a/src/render.cpp
+++ b/src/render.cpp
@@ -1069,7 +1069,7 @@ void Render_DrawList_DebugLines()

     if(!debugDrawer.IsEmpty())
     {
-        const unlit_tinted_shader_description *shader = renderer.shader_manager->getRoomShader(false, false);
+        const unlit_shader_description *shader = renderer.shader_manager->getStencilShader();
         glUseProgramObjectARB(shader->program);
         glUniform1iARB(shader->sampler, 0);
         glUniformMatrix4fvARB(shader->model_view_projection, 1, false, renderer.cam->gl_view_proj_mat);
@cochrane

This comment has been minimized.

Copy link
Contributor

commented Jun 13, 2015

Yes, but it's ugly. It makes one shader responsible for two completely different things and it returns old fixed vertex attributes (gl_Color) back into the whole deal after I had just gotten them out.

Is this so important to you? If yes, then go ahead with that patch. I probably won't have time to fix this thing correctly today (which would require a new shader, and changing the debug drawer to use vertex array objects).

@vvs-

This comment has been minimized.

Copy link
Contributor Author

commented Jun 13, 2015

It was meant just as an example. Of course it would be better if you fixed it properly.

@cochrane

This comment has been minimized.

Copy link
Contributor

commented Jun 14, 2015

I got a fix for that, tested and everything, on my computer… and I can't push it because my internet connection can't deal with hot weather. Or cold weather. Or pretty much anything. I'm typing this on my iPad using LTE. Really sorry for the delay, but it should be done before the evening.

The solution is pretty much what vvs- said, just as a new file and putting it all in a vertex buffer and vertex array. By the way, sorry for being such an asshole in the posts above, looking back those sound way harsher than I intended.

Just for curiosity's sake: You asked about vec3 and vec4 colors. The gl_Color predefined attribute is always vec4. If you specify a vertex array with only three components, OpenGL automatically creates the fourth and sets it to 1 (this also applies positions and even texture coordinates, which OpenGL also specifies as vec4 for truly arcane reasons. Normals are always vec3 though). This convenience is not something we have with custom attributes; there the types have to match or we get undefined results (which often make for the best screenshots). No matter what else is going on, we always have to write a vec4 to gl_FragColor. In OpenGL 3.2, we can also define our own fragment outputs instead of just gl_FragColor, but I think those have to be vec4 at all times, too.

@vvs-

This comment has been minimized.

Copy link
Contributor Author

commented Jun 14, 2015

By the way, sorry for being such an asshole in the posts above, looking back those sound way harsher than I intended.

Actually, I don't see anything rude at all. It's business as usual, I'm accustomed to such style at work. That's how things get done 😏

@cochrane cochrane closed this in 8181355 Jun 14, 2015

@stohrendorf stohrendorf added the Engine label Jul 1, 2015

@stohrendorf stohrendorf added this to the TR1 milestone Jul 1, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.