13.06.2013 Views

A GPU-Based Approach to Non-Photorealistic Rendering in the ...

A GPU-Based Approach to Non-Photorealistic Rendering in the ...

A GPU-Based Approach to Non-Photorealistic Rendering in the ...

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

esult was so stylized, no orientation of graftals would be<br />

necessary. Unfortunately, this was not <strong>the</strong> case.<br />

Close exam<strong>in</strong>ation of Mignola’s work showed that <strong>the</strong><br />

small marks used for surface details were not at all randomly<br />

oriented or distributed – while lack<strong>in</strong>g depth, <strong>the</strong>y all<br />

followed <strong>the</strong> 2D orientation of <strong>the</strong> surface <strong>the</strong>y were placed<br />

along. This is most easily seen <strong>in</strong> Figure 4. The scale<br />

“graftals” placed along <strong>the</strong> tail of <strong>the</strong> mermaid are oriented <strong>in</strong><br />

2D <strong>to</strong> match <strong>the</strong> curve of <strong>the</strong> tail. This orientation means<br />

graftals must be generated based on surface geometry.<br />

We <strong>the</strong>n attempted <strong>to</strong> use an approach more directly<br />

related that that outl<strong>in</strong>ed by Hertzmann and Zor<strong>in</strong>. We tried<br />

generat<strong>in</strong>g graftals at edges, parallel <strong>to</strong> <strong>the</strong> screen but with<br />

one edge set <strong>to</strong> an edge on <strong>the</strong> mesh. Unfortunately, <strong>the</strong><br />

orientation <strong>to</strong> <strong>the</strong> screen made self-<strong>in</strong>tersection a significant<br />

problem. Without any time-consum<strong>in</strong>g self-<strong>in</strong>tersection<br />

prevention, <strong>the</strong>re was no way <strong>to</strong> guarantee surface details<br />

wouldn’t disappear <strong>in</strong><strong>to</strong> geometry – especially with randomly<br />

placed graftals.<br />

Due <strong>to</strong> scope and time constra<strong>in</strong>ts, we were unable <strong>to</strong><br />

attempt o<strong>the</strong>r solutions.<br />

3.4. Shadow Outl<strong>in</strong><strong>in</strong>g<br />

As with surface graftals, shadow outl<strong>in</strong><strong>in</strong>g proved more<br />

difficult than orig<strong>in</strong>ally expected.<br />

Orig<strong>in</strong>ally, we had <strong>in</strong>tended <strong>to</strong> use edge-aligned<br />

graftals, as described above, <strong>to</strong> provide variation along<br />

shadow edges. The self-<strong>in</strong>tersection problems of surfaceoriented<br />

graftals, however, were also a problem with<br />

shadow-bound<strong>in</strong>g graftals.<br />

We moved on <strong>to</strong> attempt <strong>to</strong> use textured strokes <strong>to</strong><br />

def<strong>in</strong>e edges. While self-<strong>in</strong>tersection was still an issue, it was<br />

more manageable with controlled stroke-width.<br />

To determ<strong>in</strong>e if an edge was shadow-bound<strong>in</strong>g, we<br />

simply used <strong>the</strong> same dot product used <strong>in</strong> <strong>the</strong> render<strong>in</strong>g<br />

equation <strong>to</strong> calculate light <strong>in</strong>tensity at a po<strong>in</strong>t. As with <strong>the</strong><br />

<strong>in</strong>tensity clamp<strong>in</strong>g used for <strong>the</strong> shad<strong>in</strong>g, we used α as a<br />

cu<strong>to</strong>ff. If <strong>the</strong> <strong>in</strong>tensity on one edge-connected face was<br />

greater than α and <strong>the</strong> <strong>in</strong>tensity on <strong>the</strong> o<strong>the</strong>r was not, that<br />

edge was a shadow-bound<strong>in</strong>g edge. Intensity was calculated<br />

us<strong>in</strong>g <strong>the</strong> usual formula:<br />

Intensity = dot(light direction, face normal)<br />

The problems arose with actually f<strong>in</strong>d<strong>in</strong>g a shadowbound<strong>in</strong>g<br />

edge. With an outl<strong>in</strong>ed edge, <strong>the</strong>re is no<br />

<strong>in</strong>terpolation between po<strong>in</strong>ts – that is, <strong>the</strong> outl<strong>in</strong>e will always<br />

be made of discrete, straight l<strong>in</strong>e segments. But with shad<strong>in</strong>g,<br />

<strong>the</strong>re is <strong>in</strong>terpolation between vertices, and even texture<br />

lookups <strong>to</strong> modify <strong>the</strong> vertex normal if normal mapp<strong>in</strong>g is<br />

used. All of this additional normal <strong>in</strong>formation is only<br />

accessible <strong>to</strong> <strong>the</strong> fragment shader. S<strong>in</strong>ce we did all<br />

implementation of <strong>the</strong> stroke-generation on <strong>the</strong> vertex<br />

shader, <strong>the</strong>re was no way <strong>to</strong> get shadow-boundaries smoo<strong>the</strong>r<br />

than <strong>the</strong> edges of <strong>the</strong> triangulated mesh. In some cases,<br />

depend<strong>in</strong>g on triangulation, this led <strong>to</strong> a zigzagg<strong>in</strong>g stroke<br />

down <strong>the</strong> front of <strong>the</strong> mesh, which did not actually follow <strong>the</strong><br />

shad<strong>in</strong>g.<br />

Without any sort of <strong>in</strong>terpolation across triangles, <strong>the</strong>re<br />

was no way <strong>to</strong> avoid this jaggedness.<br />

4. Results<br />

Edge strok<strong>in</strong>g has been implemented on <strong>the</strong> <strong>GPU</strong> us<strong>in</strong>g<br />

<strong>the</strong> VBO solution described above. Any OBJ model can be<br />

loaded <strong>in</strong><strong>to</strong> an Edge Mesh, passed <strong>to</strong> <strong>the</strong> <strong>GPU</strong> <strong>in</strong> a VBO, and<br />

rendered with all edges as strokes. With outl<strong>in</strong>e-cull<strong>in</strong>g<br />

implemented, only <strong>the</strong> outl<strong>in</strong>e edges of <strong>the</strong> model are drawn.<br />

These strokes have UV coord<strong>in</strong>ates def<strong>in</strong>ed, and can be<br />

drawn with textured strokes. (Figure 5)<br />

The “fill” of <strong>the</strong> model is a separate render pass with a<br />

different GLSL shader program. The black shadows are<br />

shaded us<strong>in</strong>g <strong>the</strong> fragment shader, as described above <strong>in</strong><br />

section 3.2. This shad<strong>in</strong>g is placed beh<strong>in</strong>d <strong>the</strong> strokes.<br />

(Figure 6)<br />

Attempts <strong>to</strong> render surface-graftals failed, due <strong>to</strong> <strong>the</strong><br />

difficulty of plac<strong>in</strong>g graftals along a surface without us<strong>in</strong>g<br />

any direction field detection algorithms and without self<strong>in</strong>tersection<br />

problems.<br />

Attempts <strong>to</strong> render shadow-bound<strong>in</strong>g strokes failed as<br />

well. While <strong>the</strong> narrowness of <strong>the</strong> strokes prevented any<br />

significant self-<strong>in</strong>tersection, <strong>the</strong> <strong>in</strong>ability <strong>to</strong> get any f<strong>in</strong>er<br />

resolution than <strong>the</strong> triangle edges also led <strong>to</strong> zig-zagg<strong>in</strong>g<br />

shadow boundaries.<br />

Figure 5: At <strong>to</strong>p, all edges are drawn. At bot<strong>to</strong>m, only outl<strong>in</strong>e<br />

edges are drawn.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!