Archived

This topic is now archived and is closed to further replies.

mstein

engine hiearchy

Recommended Posts

Back when i first started dabbling with 3d graphics was a class in college and we made a Scene Graph Loader. Given a text file we would parse through it and build the scene. Our teacher told us it was bulky and would never be used in practice, but was a good way to learn about textures, lighting, transformations, even animation. My question is that I am getting back into graphics programming in general and was wondering how you all structure your "engines". Mainly, I have a class for lights, and texture management from my scene graph loader and I was curious as to if you all encapsulate things so as lights and textures into objects or if you do a more C-style non-OOP implementation. I am used to OOP and dividing things up into objects and such, its how I learned. I would like to keep my Light class and Texture classes, but want to know if its feasible for things like speed of the final product. Any insight and thoughts on this matter or anything related to it would be greatly appreciated.

Share this post


Link to post
Share on other sites
depends what you understand with lights

the location and settings of the light or lightmaps

and is there another good way to store it than objects?

i don t think so


and for the levels i store them in one class presorted to use trianglestrips to render them with the minimum of state changes

Share this post


Link to post
Share on other sites
well mainly right now, to use my Light object as an example. It pretty much acts like a wrapper for all light operations. I have not gotten into Lightmaps, so i will not get into that. I guess i am more comfortable doing:


  
myLight *lights[7];

.
.
.

lights[0]->enable();
lights[0]->setPosition(..);
lights[0]->setAmbient(...);

.
.
.

etc.

Share this post


Link to post
Share on other sites