<p>If you read introductory material to 2D computer graphics (perhaps somewhat older material), they will likely start by telling you about the distinction between “raster graphics” and “vector graphics”.</p>
<ul>
<li>Raster graphics: The data being processed is an array of pixels which form an image.</li>
<li>Vector graphics: The data being processed is a set of geometric shapes, represented as data structures that list points of the shape (e.g. the corners of a rectangle), plus additional information about the color and other “style” details of how the shape should be displayed.</li>
</ul>
<p>In the modern day, computer graphics frequently involves a mix of both techniques — starting with a vector data set of some sort, converting it to pixels, then applying further processing to those pixels. This is particularly true in 3D graphics.</p>
<p>“The geometry” refers to <strong>the shapes and points of the vector data</strong>. In 3D graphics, this data is very often a <a href="https://en.wikipedia.org/wiki/Triangle_mesh" rel="nofollow noreferrer">triangle mesh</a>, because that is a particularly uniform yet general format for approximating the shapes of arbitrary surfaces. In a triangle mesh, all of the points are <strong>vertices</strong> of the triangles.</p>
<p>The geometry often <em>has</em> normals, texture coordinates, and other data relating to each vertex, but when we talk about “the geometry” we're talking about the characteristics of the shape itself, as a shape. When working with the geometry in the form of a triangle mesh, you have concerns like</p>
<ul>
<li>Is there an appropriate level of detail (number of vertices used to approximate complex curved shapes)?</li>
<li>Are there errors, like gaps in the surface that are visible from some angles, or redundant vertices or triangles?</li>
<li>Are the “bones” of a model (modifiers to the positions of groups of vertices) correctly set up to allow its shape to be animated?</li>
</ul>
<p>When considering these problems, the other <strong>vertex attributes</strong> (normals, texture coordinates, colors, etc.) are relevant only as information that needs to be preserved or remapped appropriately; they aren't themselves affecting the answers to the questions. They're not <em>defining</em> the geometry.</p>

CC BY-SA 4.0
2024-08-01T16:35:46.443Z
Awesome, thank you for the response Kevin! :)
arm.u
CC BY-SA 4.0
2024-08-01T15:09:33.630Z
2024-08-01T15:09:33.630Z
Kevin Reid
<p>What does the term &quot;geometry&quot; refer to in graphics programming?</p>
<p>I commonly hear the term when people are referring to data. And my understanding is that it's usually a generic term to refer to data that's used in the rendering process such as vertices, normals, texture coordinates, etc.</p>
<p>Or is there some other meaning, more specific meaning?</p>

CC BY-SA 4.0
2024-08-01T10:48:54.553Z
It's referring to the sets of points representing your scene. For instance meshes made out of triangles. Or spheres/torii/fractals and other interesting sets which you can find the intersection with by using ray-tracing and ray-marching.
lightxbulb
CC BY-SA 4.0
2024-08-01T16:36:32.577Z
@lightxbulb ahh I see, thank you for the response!
arm.u
<terminology>
What does the term "geometry" refer to in graphics programming?
arm.u
# What does the term "geometry" refer to in graphics programming?

(Asked by: username_0 on 2024-07-31)

What does the term "geometry" refer to in graphics programming?

I commonly hear the term when people are referring to data. And my understanding is that it's usually a generic term to refer to data that's used in the rendering process such as vertices, normals, texture coordinates, etc.

Or is there some other meaning, more specific meaning?

**Tags:** terminology

> **Comments:**
> **username_1**: It's referring to the sets of points representing your scene. For instance meshes made out of triangles. Or spheres/torii/fractals and other interesting sets which you can find the intersection with by using ray-tracing and ray-marching.  
> **username_0**: @username_1 ahh I see, thank you for the response!  

---

## 1 answers

### Answer by username_2 on 2024-08-01. Score: 0 | Accepted answer

If you read introductory material to 2D computer graphics (perhaps somewhat older material), they will likely start by telling you about the distinction between “raster graphics” and “vector graphics”.

* Raster graphics: The data being processed is an array of pixels which form an image.
* Vector graphics: The data being processed is a set of geometric shapes, represented as data structures that list points of the shape (e.g. the corners of a rectangle), plus additional information about the color and other “style” details of how the shape should be displayed.

In the modern day, computer graphics frequently involves a mix of both techniques — starting with a vector data set of some sort, converting it to pixels, then applying further processing to those pixels. This is particularly true in 3D graphics.

“The geometry” refers to **the shapes and points of the vector data**. In 3D graphics, this data is very often a [triangle mesh](https://en.wikipedia.org/wiki/Triangle_mesh), because that is a particularly uniform yet general format for approximating the shapes of arbitrary surfaces. In a triangle mesh, all of the points are **vertices** of the triangles.

The geometry often *has* normals, texture coordinates, and other data relating to each vertex, but when we talk about “the geometry” we're talking about the characteristics of the shape itself, as a shape. When working with the geometry in the form of a triangle mesh, you have concerns like

* Is there an appropriate level of detail (number of vertices used to approximate complex curved shapes)?
* Are there errors, like gaps in the surface that are visible from some angles, or redundant vertices or triangles?
* Are the “bones” of a model (modifiers to the positions of groups of vertices) correctly set up to allow its shape to be animated?

When considering these problems, the other **vertex attributes** (normals, texture coordinates, colors, etc.) are relevant only as information that needs to be preserved or remapped appropriately; they aren't themselves affecting the answers to the questions. They're not *defining* the geometry.

> **Comments:**
> **username_0**: Awesome, thank you for the response username_2! :)  

---

