I’ve bundled my thesis implementations and put them up for download on the thesis code page. The thesis text (and a small overview) can be downloaded from the thesis page itself.
I’d like to thank my promotor, suprvisors and readers for all their efforts, and hope my work and code will be useful for other NPR enthousiasts.
Today, I managed to perform contour/suggestive contour rendering in imagespace – thus working on a rendered diffuse shaded image. After using the Sobel edge detection filter to detect regular contours, I looked for an efficient algorithm to detect valleys and creases, in order to draw suggestive contours as well.
As the original paper from D. Decarlo indicates, I needed to exploit the fact that the algorithm should just work for smooth rendered images, whereas most valley detection algorithms are complicated because they provide noise robustness.
While a pixel in a valley is not necessarily the minimum intensity value in a neighborhood, it will be among a thin set of dark pixels that cuts across the neighborhood.If the valley is steep, the neighborhood will also contain significantly brighter pixels away from the valley; We can require a sufficient intensity difference that the surface must be turned meaningfully away.
The good news is that this method also detects regular contours, thus eliminating the need for the seperate sobel filter pass! GLSL code and results behind the cut.
Continue reading »
Using Vertex Buffer Objects to transfer my mesh data (vertices, normals, curvatures) directly into GPU memory using STATIC_DRAW_ARB pointers just tripled the performance of my GLSL shader implementation.
Running a heavy model (+300k vertices) drawn with contours and suggestive contours at 24 fps, average.
The presentation i’ll be giving tomorrow
After squashing a rather nasty bug this morning (GLSL shader memory alloc is tricky), I made some renders to demonstrate the algorithm.
The algorithm is an object-space algorithm. This has some implications: Operations are performed with direct vertex info. No intermediate rendering+signal filtering is done. Rendering it on the GPU makes it hard to control line width. This is the main disadvantage in using this algorithm over a CPU-implemented one. The main advantage is – of course – significant speedup in rendering.
The current version computes info for all vertices. I think I can speed things up a bit more by adding some additional tests in the vertex shader, which could signal the fragment shader that the fragment is unlikely to have contours. Whether or not the additional overhead of these tests is worth it, we’ll see. Pretty images behind the cut.
I don’t know what just happened to my shader, but this sure looks funky.
I’ve been trying to work out a good CPU-accelerated version the my suggestive contours algorithm during the last few weeks, and after working through some technical difficulties, I managed to compute and draw regular contour lines this afternoon:
Hard to see? I know, it looks craptastic.
But after an afternoon of reading tutorials, bulletin boards and newsgroups, I know why. And I think it’s going to help me write a better thesis, so this delightful saturday wasn’t completely wasted. Conclusions behind the cut.
Today I rewrote parts of Trimesh2′s Mesh Viewer to work with GLSL-shaders. I implemented a simple cartoon shader. This is still pretty basic, since it doesn’t involve sending information back and forth between OpenGL and the shader.
Still, here is the result.
Because my current Suggestive Contours/Suggestive Highlights implementation is written using OpenGL calls for rendering, it was best to start work on the vertex/fragment shaders for a GPU implementation in the OpenGL shading language (GLSL). This would reduce OS/Platform dependency too. Another option was using Nvidia’s Cg, which claims to be compatible with an OpenGL renderer too, but documentation about this was scarce Continue reading »
| Code is poetry. | Please,  |
Suffusion WordPress theme by Sayontan Sinha |
