Geometry api design

Game Play & Game Design
#1

In a graphics engine I’m working on, I have 2 types of geometry:

  1. indexed arrays modeled after opengl’s vertex arrays/vbo options
  2. an OO style where you can add faces/move vertices

Option 1 was very straightforward to implement, but it’s not the easiest to use because you have to manipulate raw primitives. This isn’t really a problem for geometry created in an 3d suite and it can render very quickly.

However, to make it easier to programmatically specify geometry I wanted to provide #2 in my engine, too. I’m stuck between 2 representations:
a. The geometry has a list of positions/normals/texcoords and each face can have indices into those lists
b. The geometry is a list of faces, which hold onto vectors for positions, normals and texcoords

I’m leaning towards style b but I wanted to get opinions, or be convinced that an OO representation of geometry is pointless :slight_smile:

#2

That’s a tough one. Normally I would argue, that an OO representation of geometry (broken down to faces) is pointless, since in most games you either will use models or generate stuff, where the additional effort of directly outputting raw data is usually negligible in relation to the generation algorithm. In my opinion this is always true for static geometry.

The point that makes me think about this is “move vertices”. This could be quite cumbersome in a raw value api. But actually I can’t think of a use case for this. When working with non-static geometry I either split the geometry in parts (“Shapes”), so that I can add/move/remove parts of my geometry or I regenerate the whole thing based on parametric changes on the underlying data.

In a nutshell: if you can think of a sensible use case for this, go for it, otherwise consider OO style geometry (down to faces) pointless.

P.S.
For acessing (pseudo-) objects in a raw data buffers, see the mapped object approach http://www.java-gaming.org/index.php/topic,18852.0.html

#3

The mapping approach is a good idea and I like the points you made. You’ve got me convinced that it’s not worth the effort at the moment (since I’m not interested in doing any of the use cases I can think of where an OO style is particularly useful).

#4

I’m using my own interpretation of the Builder pattern here.

You simply just keep adding vertices/colors/normals, and then build() it, either as different VertexArrays or VBO, or as a single interleaved VA / VBO, or indexed, or interleaved + indexed, etc.

the builder knows upfront which vertex attributes to expect, by specifying that in the constructor, like:


public GeometryBuilder(int vDims, int cDims, boolean texCoords, boolean normals)

gb.newVertex();
gb.setVertex(x, y)
gb.setVertex(x, y, z)
gb.setVertex(x, y, z, w)
gb.setColor(r, g, b)
gb.setColor(r, g, b, a)
gb.setTexCoord(u, v)
etc etc
result = gb.build(interleaved, indexed);
#5

Interesting, I didn’t know of that approach and it fits really well with what my goals were. I probably won’t add it, since I went in and made everything work with indexed geometry, but I’ll keep it in mind in the future.