Sign in to follow this  

Responsibilities of geometry objects?

This topic is 4272 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've been working on a Pythonic game engine called Spineless (http://spineless.sourceforge.net/) for a long while now, and I'm currently in the process of cleaning up various older, lower level parts of it. The area that's causing most headache at the moment is geometry, and I'd really welcome some comments, ideas, suggestions, anything. At the moment, the geometry package is a bit of a mess, because it's not clear what the responsibilities of geometry objects are. Potential responsibilities relating to geometry: * Generating parametric geometry objects (such as a sphere from radius or box from width, height and depth) * Providing geometric information such as bounding radius, surface area and inertia tensor * Generating vertices, normals and multi-channel texture coordinates at various resolutions * Generating render primitives (which are just containers for the various vertex arrays / buffers) * ODE integration (for collision detection) I can see two sensible approaches for the geometry package: * Minimal, low level, only depends on math Geometry is responsible for object creation, providing geometric information and creating vertices only * Maximal, high level, lots of dependencies Geometry is responsible for all or most of the potential responsibilities listed above The current implementation is almost maximal but doesn't provide for example multiple texture coordinate channels. Geometry object interface is also a bit messy and IMO a low-level geometry package would be cleaner. Other responsibilities of geometry could be handled outside the geometry classes. You can see the current implementation at http://svn.sourceforge.net/viewcvs.cgi/spineless/trunk/source/spineless/geometry/ The various Python files there are different geometry objects (with the exception of geometry, which is the base class).

Share this post


Link to post
Share on other sites
I don't really see anything terribly wrong with your approach. It is convenient to put all of the functionality you described in your geometry class.

If you want your engine to be a little more modular, I would leave the render primitive generation up to your renderer, and your physics information generation up to your physics engine. I would be inclined to separate the parametric object generation as well, and put it in another class, if not for the sake of 'good design', then just to keep things a little more separate and easily distinguishable. This would also be beneficial in that if you add a new primitive, you don't have to change the base class that everything relies upon (thus avoiding a huge re-build).

If you're never going to need the modularity, however, you're probably better off just keeping things the way they are and moving on to something else.

Good luck with your project.

Share this post


Link to post
Share on other sites

This topic is 4272 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this