Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: OOD question for Instance-Model relationship  (Read 1849 times)

0 Members and 1 Guest are viewing this topic.

Groogy

  • Hero Member
  • *****
  • Posts: 1469
    • MSN Messenger - groogy@groogy.se
    • View Profile
    • http://www.groogy.se
    • Email
OOD question for Instance-Model relationship
« on: May 16, 2012, 02:02:22 pm »
Hi!

Well I am working away on my game under code-name Ymir I just realized something I did not like at all. My relationship between an instance and model is very straightforward. The instance has an aggregate to the model and calls the models render function.

What I am asking for is more or less a better design to this than I already have in place. The problem there is right now is that the model classes can easily grow very, very, very large(speaking from experience).

I'll write the code in ruby as I feel it's much easier to write and to give a good impression of the whole easily.
The following code is a simplification of a instance-model node hierarchy.
class Instance
  def initialize( model_mesh )
    @model_mesh = model_mesh
    @transformation = Ymir::Transform3D::Identity
  end

  # ... more code, like state modifying methods...

  def render( shader )
    @model_mesh.render( shader, @transformation )
  end
end

class ModelMesh
  def initialize( data, vertex_layout )
    @vao = generate_vao
    @num_triangles = data.size / 4
    # And all other OpenGL stuff to setup here

    # Retrieve the attribute locations from the vertex_layout
    # and bind them to the vao
  end

  def render( shader, transformation )
    shader.bind()
    bind_vao( @vao )
    # Bind buffer objects
    draw_arrays( Triangles, 0, @num_triangles )
    # Unbind buffer objects
    shader.unbind()
    bind_vao( 0 )
  end
end

Though what I am thinking is that you want to separate code and data. The ModelMesh class is logically more or less a pure data class and should only have code to manipulate this data(like modifying the mesh or opengl states associated with this mesh and so on). But render should/could be moved outside to another class responsible for just that, rendering of meshes.

Now a fast naive thought would be that Instance would be responsible for this but not really, Instance is a instanciation of a model so it only knows the information and instructions for this instance. Which would be more or less states like transformation and etc.

I am thinking to create a new class just responsible for rendering called RenderTechnique. Though where would it be placed? Should Instance own an instance of this class and use it to render model mesh? Or should it be outside? How would it relate then in a more bigger scale? This is where I get uncertain. Is there any common design pattern I've missed that would help me out here? This is most probably the design I will go with but I am still interested in hearing in opinions on other things like why I should keep it in the model class and so on.

For reference you can see it as this: Sprite = Instance, Texture = Model
Though in SFML the Sprite itself now how to draw itself using the given Texture.
I can do it just as SFML of course and have it in Instance. But I am developing a 3D game where I will want to be able to switch between different rendering techniques easily depending on context (Different shaders, Normal Batching, Instancing and so on). It's possible with having everything in Instance/Model but it will get pretty big in the end and having this functionality moved out to a new set of classes it get's easier to switch and the separate classes become much smaller.

Also don't be afraid to just say "You are over-thinking this, just do it like SFML does it" :)
Because I usually do. But I like to think or talk about things like this ;)
And sorry for the wall of text ^^
« Last Edit: May 16, 2012, 03:41:24 pm by Groogy »
Developer and Maker of rbSFML and Programmer at Paradox Development Studio

 

anything