🔒 Locked

Designing and using an interface for rendeable objects and related sadness

Started by AbsolutDew Jan 5, 2007 at 12:12 AM 4 replies 700+ views

Original Post

Jan 5, 2007 at 12:12 AM

Wondering how others might have done this, or something similar. I'm also very interested in how you might relate game objects to nodes in a scene graph. I created an IRenderable interface because I want to be able to have lots of different representations of objects (ie. mesh, billboard, primitive, whatever). Cool, now I have IObject, a concrete Object, and RenderableObject. Then, somewhere I ended up with something like:


for each visible IObject in scene
  object->render() // ahh render is not a member of IObject

So then I made IRenderable a member of IObject and did something like this:


for each visible IObject in scene
  IRenderable r = object.Renderable();
  if(r) r->Render();

And then...


IRenderable::Render()
{
  SetTransform(WorldTransform()) // Ahhh WorldTransform is not a method of IRenderable
}

I mean, each of those situations has possible solutions but they always smelled bad to me and I ended up abandoning the approaches. There were other problems too but those particular cases came to mind for this post.

dgrantkp

Jan 5, 2007 at 1:30 AM

Unfortunately an object scene graph does not fit very naturally with most scene rendering these days since objects can be made up of many different types of materials that should be executed at completely different stages in the rendering pipeline. This is why, for example, D3DX and other 3D api's break meshes up into subsets that share the same attributes- this is more canonical and generally the most useful for most rendering engines.

So depending on what you are trying to achieve, you can probably keep your scene graph for a logical representation of your game world. But it needs to be able to come apart and be reorganized into mesh subsets for rendering on demand. You will find you need to do such things as sorting transparent subsets to draw from back to front, or later batching certain subsets together to minimize expensive state changes in the API when you draw complex scenes.

If you are only trying to achieve something very simple, then instead design your application around specific knowledge of a couple different hard-coded materials. This will greatly simplify the work needed to write a loop that draws the subsets. But beware, you will need to completely rewrite the renderer to make it more generic should you choose to do more complex rendering later.

Demus79

Jan 5, 2007 at 5:13 AM

Well, you could consider that your IObject knows where to render itself and renderable objects know only how to render themselves.

So why not an approach where the objects tells to the renderable where to render? I don't see any problem with that.

Object->Render();IObject::Render(){   Renderable->SetTransform(WorldTransform());   Renderable->Render();}

I suggest that the IObject has the render method since, sometimes rendering the I_Renderable isn't so simple. For example, Skin&Bone systems require a bit more work than just setting 1 matrix.

Cheers!

AbsolutDew

Jan 6, 2007 at 3:39 PM

Thanks for the comments guys. Anyone else wanna share their approaches in designing a basic game object?

Passing the WorldTransform to the object felt kinda funny since I don't think the Renderable should really know anything about where it's being rendered. Your solution works but it just felt funny to me on a conceptual level which is why I went looking for something else.

dgrantkp

Jan 6, 2007 at 10:28 PM

Quote:
Original post by AbsolutDew
Thanks for the comments guys. Anyone else wanna share their approaches in designing a basic game object?

Passing the WorldTransform to the object felt kinda funny since I don't think the Renderable should really know anything about where it's being rendered. Your solution works but it just felt funny to me on a conceptual level which is why I went looking for something else.

You're spider sense is working right AbsolutDew. ;) Basically it is not quite right because rendering is not really centered an object, it is centered on the scene that you are trying to draw and there is a lot of room for variation within that.

My trick in situations like this is to engineer by function instead of object. This is much more adaptable to experimentation and really helps you understand your requirements (parameters) as the project changes. Gather the functions into classes that make sense after you have a system you are satisfied with.

Bob Janova

Jan 7, 2007 at 8:10 AM

My basic game classes/interfaces:

interface IRenderable { void Render(Renderer r);}interface IGameObject { Vector Location {get;set;} Primitive[] CollisionHull {get;} Model Model {get;} // includes rendering hull and transform int UID {get;set;} void Update(long ticks); void CollidesWith(IGameObject other);}interface IActiveObject : IGameObject { Vector Velocity {get;set;} int Mass {get;set;}}class BaseObject: IGameObject, IRenderable { // lots of implementation stuff}

Thus a renderable thing isn't necessarily an in-game obejct (think about the HUD, a scoreboard etc), and an in-game object isn't necessarily renderable (killboxes, lights with no model, next objective markers for the AI etc).

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.