<p>No, there is not really a way to do that.</p>

<p>A geometry shader invocation requires an input primitive and generates 0 or more output primitives. <strong>Without an input primitive, there is not really a way to actually <em>invoke</em> the geometry shader</strong>. Of course you can stretch the limits of the geometry shader's maximum number of output primitives for each input primitive (don't know the practical limits right now, should be on the order of thousands maybe). So you maybe could generate 1024 triangles for each point, but you always have to have <em>some</em> input primitives.</p>

<p>What you <em>don't need</em> however is an actual notion of geometry. You don't really have to render 3D points at any reasonable location, they could as well have just some abstract index or texture coordinates or whatever as attributes and not necessarily a meaningful 3D position. <strong>Noone dictates what attributes your vertices have. And you can even render vertices <em>without any</em> attributes</strong>. But you have to render <em>some</em> primitives to invoke the geometry shader on them, even if those primitives don't have any actual attributes (how you then compute your output geometry in the geometry shader is a different question, though).</p>

<p>But what you actually did, rendering a point for each grid cell and generating the marching cubes triangles for that cell from it, is exactly the straight-forward approach. Of course what attributes this cell contains is up to you, it could be a 3D position, a texcoord into a 3D texture, whatever, but those are the grid cells you render. Purely semantically spoken, you don't actually "discard" those points and then "replace" them by triangles, you "convert" each point into a set of triangles. That's exactly what the geometry shader is for and there's nothing "hacky" or "improper" about it. <strong>Noone says the geometry shader has to generate the same output primitive type as was input to be "proper"</strong>.</p>

<hr>

<p>What you can do to achieve a largely input-less way of rendering your voxel grid (and this might be what you were actually asking for) would be to just draw a set of attributeless points. This means you don't need any attribute arrays at all and just disable them all and invoke a simple <code>glDrawArrays</code> with the number of cells you need. Then in the vertex shader or the geometry shader you can generate the necessary 3D grid cell index with a little index magic from the input vertex ID (i.e. <code>gl_VertexID</code>, which is the only information you have) and then compute your marching cubes geometry from a lookup into the 3D volume texture (or whatever datastructure).</p>

<p>So, in retrospect I should relativate my statement from the beginning: <strong>You can't generate primitives without any input <em>primitives</em>, but you can generate them without any input <em>geometry</em></strong>.</p>

CC BY-SA 3.0
2015-08-04T18:58:03.393Z
2015-08-04T19:20:23.330Z
2015-08-04T19:20:23.330Z
Christian Rau
<p>A few years ago I tried to implement <a href="http://http.developer.nvidia.com/GPUGems3/gpugems3_ch01.html">this GPU Gem</a> in OpenGL to generate 3D procedural terrain using <a href="https://en.wikipedia.org/wiki/Marching_cubes">Marching Cubes</a>. The article suggests to implement Marching Cubes in a geometry shader to maximum efficiency. This means I need to run the shader once for every voxel in the domain, and it'll generate the entire geometry in that cell.</p>

<p>One problem I stumbled upon was how to get the geometry shader running without actually having anything to render outside of that shader. My solution (which seemed rather hacky) was to render a point in each cell, discard it with the geometry shader and emit my triangles instead. I never found a proper solution and this workaround remained in the final code.</p>

<p>So, is there anyway to tell OpenGL to start a rendering pass from the geometry shader without any input geometry? Or will I always have to send some dummy points to the GPU to get things running.</p>

<opengl><geometry-shader>
Is there any way to generate primitives in a geometry shader without any input geometry?
Martin Ender
# Is there any way to generate primitives in a geometry shader without any input geometry?

(Asked by: username_0 on 2015-08-04)

A few years ago I tried to implement [this GPU Gem](http://http.developer.nvidia.com/GPUGems3/gpugems3_ch01.html) in OpenGL to generate 3D procedural terrain using [Marching Cubes](https://en.wikipedia.org/wiki/Marching_cubes). The article suggests to implement Marching Cubes in a geometry shader to maximum efficiency. This means I need to run the shader once for every voxel in the domain, and it'll generate the entire geometry in that cell.

One problem I stumbled upon was how to get the geometry shader running without actually having anything to render outside of that shader. My solution (which seemed rather hacky) was to render a point in each cell, discard it with the geometry shader and emit my triangles instead. I never found a proper solution and this workaround remained in the final code.

So, is there anyway to tell OpenGL to start a rendering pass from the geometry shader without any input geometry? Or will I always have to send some dummy points to the GPU to get things running.

**Tags:** opengl, geometry-shader


---

## 1 answers

### Answer by username_1 on 2015-08-04. Score: 16 | Accepted answer

No, there is not really a way to do that.

A geometry shader invocation requires an input primitive and generates 0 or more output primitives. **Without an input primitive, there is not really a way to actually *invoke* the geometry shader**. Of course you can stretch the limits of the geometry shader's maximum number of output primitives for each input primitive (don't know the practical limits right now, should be on the order of thousands maybe). So you maybe could generate 1024 triangles for each point, but you always have to have *some* input primitives.

What you *don't need* however is an actual notion of geometry. You don't really have to render 3D points at any reasonable location, they could as well have just some abstract index or texture coordinates or whatever as attributes and not necessarily a meaningful 3D position. **Noone dictates what attributes your vertices have. And you can even render vertices *without any* attributes**. But you have to render *some* primitives to invoke the geometry shader on them, even if those primitives don't have any actual attributes (how you then compute your output geometry in the geometry shader is a different question, though).

But what you actually did, rendering a point for each grid cell and generating the marching cubes triangles for that cell from it, is exactly the straight-forward approach. Of course what attributes this cell contains is up to you, it could be a 3D position, a texcoord into a 3D texture, whatever, but those are the grid cells you render. Purely semantically spoken, you don't actually "discard" those points and then "replace" them by triangles, you "convert" each point into a set of triangles. That's exactly what the geometry shader is for and there's nothing "hacky" or "improper" about it. **Noone says the geometry shader has to generate the same output primitive type as was input to be "proper"**.

---

What you can do to achieve a largely input-less way of rendering your voxel grid (and this might be what you were actually asking for) would be to just draw a set of attributeless points. This means you don't need any attribute arrays at all and just disable them all and invoke a simple `glDrawArrays` with the number of cells you need. Then in the vertex shader or the geometry shader you can generate the necessary 3D grid cell index with a little index magic from the input vertex ID (i.e. `gl_VertexID`, which is the only information you have) and then compute your marching cubes geometry from a lookup into the 3D volume texture (or whatever datastructure).

So, in retrospect I should relativate my statement from the beginning: **You can't generate primitives without any input *primitives*, but you can generate them without any input *geometry***.


---

