Modeling real-world concepts (like tiles, textures, shaders, etc) is one way to do it. At the same time, my 'best' objects, e.g., the most useful ones, are those that don't actually exist in the real world but instead embody some sort of concept that allows you to cope with the problem better. An example of this is the interpolator in the Engenuity series.

Object-oriented design is only a tool. If it hinders your progress, discard it. It is merely en vogue nowadays to be completely object oriented, so don't feel compelled to follow it exactly.

And don't let it suck you into analysis paralysis: there is no substitute for learning the how and when's of design by hard experience, which you can only get by making mistakes.

Doesn't sound bad to me, but I got an F in graphics class when I took it. Hehehe.

Quote:Original post by antareus
Doesn't sound bad to me, but I got an F in graphics class when I took it. Hehehe.

Gees how the hell did you manage that? I got an A or an A+ in a similiar class.
Too much partying and not going to lectures?[wink]

Quote:Original post by ace_lovegrove
Previously i have got classes to render their own relevent vertices. Im keen on writing a rasterizer class. I was thikning i could render using some sort of polymorphic collection priniciple in a linked list. so i could run thru the list and render everything etc.

this any good?

ace

Yes, it's markedly superior to direct scene-graph rendering. I'd personally use a vector instead of a linked-list and call the 'rasterizer' a Shader, but the core idea is the same.

There are shader objects that know how to setup the rendering engining to produce the desired effect, and how to actually render vertices. You submit pairs of shaders and vertex list to the graphics engine (I use a IShader*, a IVertexData*, an offset and a length). The graphics engine can then sort based on the shader, this minimizes the rendering state changes and can ensure other things such as rendering transparent meshes last. You can prepare the graphics engine once then render multiple times if the shader doesn't change.

If you have a scene with ten instances of the same model, this will automatically render the scene effeicently, rendering all thier heads, then all thier arms, etc... together, rather than rendering an entire guy then the next guy.


In this layout the pixel shader would be part of a particular shader object - maybe a special one to do water surface effects.