Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (581)
games submitted by our members
Games in WIP (500)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Geometry api design  (Read 1317 times)
0 Members and 1 Guest are viewing this topic.
Offline lhkbob

JGO Knight


Medals: 32



« Posted 2009-05-06 02:46:41 »

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 Smiley

Offline cylab

JGO Knight


Medals: 34



« Reply #1 - Posted 2009-05-06 11:27:44 »

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

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/topics/once-again-fast-mappedobjects-implementation/18852/view.html

Mathias - I Know What [you] Did Last Summer!
Offline lhkbob

JGO Knight


Medals: 32



« Reply #2 - Posted 2009-05-06 23:07:03 »

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).

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 605
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #3 - Posted 2009-05-07 01:29:10 »

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:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
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);

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline lhkbob

JGO Knight


Medals: 32



« Reply #4 - Posted 2009-05-07 08:02:25 »

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.

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

xsi3rr4x (55 views)
2014-04-15 18:08:23

BurntPizza (53 views)
2014-04-15 03:46:01

UprightPath (66 views)
2014-04-14 17:39:50

UprightPath (49 views)
2014-04-14 17:35:47

Porlus (66 views)
2014-04-14 15:48:38

tom_mai78101 (90 views)
2014-04-10 04:04:31

BurntPizza (151 views)
2014-04-08 23:06:04

tom_mai78101 (247 views)
2014-04-05 13:34:39

trollwarrior1 (204 views)
2014-04-04 12:06:45

CJLetsGame (211 views)
2014-04-01 02:16:10
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!