[Work Log] Work Log - Four days of OpenGL Debugging
Status
- Server is now running, connecting, receiving and decoding messages successfully.
- Matlab client is constructing, sending messages, and destroying successfully.
Since we've sent our first message and saved it to a file, we no longer need matlab to debug the server, using the --dbg-load-message flag.
OpenGL crashing
In render_util.cpp -> render_silhouettes(), crash is occurring somewhere in these lines.
39 GLenum draw_buffers[2] = {GL_COLOR_ATTACHMENT0, GL_COLOR_ATTACHMENT1};
(gdb) list
40 glDrawBuffers(2, draw_buffers);
41
42 glClearColor(0.0,0.0,0.0,0.0);
43 glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
44 glEnable(GL_DEPTH_TEST);
45 DBG_GL_ETX();
The dreaded "invalid operation"
I'm guessing opengl isn't in a valid rendering state yet; we may not have bound the fbo, or forgot to enable a rendering program.
yep, fbo wasn't bound.
now running to completion, but result is NaN.
Probably because we're using random numbers for our curves. Lets grab some real curve data and re-run. We'll probably need to visualize the silhouette output soon.
added function wacv-2012/get_wacv_result.m.
Code to get curves and send them to server:
tmp = get_wacv_result(2);
tmp = cellfun(@(x) [x; ones(1,size(x,2))], tmp, 'UniformOutput', false);
socket = construct_render_client('localhost', '12345')'
send_curves(socket, tmp);
result = send_curves(socket, tmp);
destroy_render_client(socket)
Got first dumps. issues
- all black, no content
- reversed wrong aspect ratio
Possible causees for 1.
- bad camera files
- bad code for converting intrinsic matrix to opengl
- bad curves?
2 seems most likely. Can debug 1 and 2 by trying old camera object and see if they work; if so, compare matrices with new matrices.
Possibly the mods I made to the multi-view likelihoods are the culprit. I'm using raw matrices now instead of cmara objects in obj.add_view() and Camera_view_wrapper.
Added command-line option "--dbg-save-frames". Writes all rendered views to disk as "dump_1.png, dump_2.png,...". Only the most recent 10 are kept at any time.
re-running using turntable camera; passing intrinsic and extrinsic matrices to likelihood.
Renders are still black.
Forgot to set white color?
No; its in the render_silhouette function.
Found something: wacv results were aritficially centered on zero. fixed.
Did matlab test on modelview and projection matrices and curve points -- z coordinate falls outside of [-1 1]. Beyond far plane.
reason: not negating z-coordinate in test code.
changing gears. running matlab test on original input modelview and projection matrices.
Modelview looks okay. Projection is way off.
- intrinsic matrix?
- NDC matrix?
- bounds?
Intrinsic looks reasonable.
probably NDC/bounds issue
Bug in ndc math
projecting outside from far plane
needed to flip axes to handle convention mismatch.
Now getting something, but the positions are looking weird.
was re-negating ppo; already flipped during convention resolution.
now getting decent results, but off-center and smaller:
rough original to rendering offsets: up by 56, left by 115.
non-uniform scaling; width is smaller than height.
Projecting plant base using
(a) intrinsic and extrinsic matrices from matlab
(b) modelview and projection matrices pulled from opengl
results:
(a) projects to the right place (tested using image and pixelstick)
(b) NDC coordinates look okay. I manually remapped (scale and offset), and they look okay.
Since NDC look okay, the remapping must be wrong. glViewport issue? I'm manually setting it, but maybe it needs to be set for each shader?
Or maybe it's a geometry shader issue? I'm using different modelview and projection matrices now.
=--
Found it (Sunday night) -- Somehow the viewport transformation is getting reset. Possibly viewport is a shader-specific state that needs to be set each time?
now centered, need to diagnose silhouette issues:
TODO (new)
- rename matlab "render_client" code to "likelihood_client"
- rename likelihood_server/sampler2.cpp to something not nonsense.