@@ -309,8 +309,8 @@ Taking all these constraints into account, the line preparation reads:
309
309
return V_prev, V_curr, V_next, L[- 1 ]
310
310
311
311
312
- Using this baking, it is now realtively easy to compute vertex position from
313
- within the vertex shader. The only difficulty being to parameterize properly
312
+ Using this baking, it is now relatively easy to compute vertex position from
313
+ within the vertex shader. The only difficulty being to properly parameterize
314
314
the vertex such as to have all information to perform the antialiasing inside
315
315
the fragment shader:
316
316
@@ -347,7 +347,7 @@ the fragment shader:
347
347
gl_Position = vec4(2.0*p/resolution-1.0, 0.0, 1.0);
348
348
}
349
349
350
- Adn the fragment shader reads:
350
+ And the fragment shader reads:
351
351
352
352
.. code :: glsl
353
353
@@ -412,8 +412,8 @@ just to be able to handle miter and round joints properly in the fragment
412
412
shader. To be able to do this, we need to know from within the fragment shader
413
413
if a given fragment is inside the joint area or not. This requires a specific
414
414
parameterization that relies on having a different tesselation with 4×n
415
- vertices instead of 2×n. I won't explain all the details here but only provide
416
- the final result that you can found in `geom-path.py
415
+ vertices instead of 2×n. I won't explain all the details here, but only provide
416
+ the final result that you can find in `geom-path.py
417
417
<code/chapter-09/geom_path.py> `_.
418
418
419
419
If you look at the sources, you'll see I'm using a geometry shader, which is a
0 commit comments