OOP, UML and OpenGL

Hi,
I am tasked to make my code more modular, and redesign the code using UML methods( Unified Modeling Language).

  1. Does anyone know how to do UML with OpenGL? or does anyone have any samples to let me reference?

  2. This question is probably easier to answer, can anyone tell me, how to use OOP (Object Oriented Programming) with OpenGL? which parts should be in which classes? Or does anyone have any sample for me to see?

I’ll be grateful for your help. Thank you.

you are presented with a difficult task.

your first question is pretty ambiguous - difficult to understand. there are a dozen UML tools out there that given the correct classes and use-cases [UML terminologies] you can create stubs [“empty” code functions/classes], at best. that is, to the extent of my experience with UML anyway.

as far as making OpenGL code more object oriented, one would need object-oriented design and analysis. so as far as the second question goes, as long as you have an OO design, creating OpenGL code that’s OOP will come easily.

:regards:

Originally posted by IAstudent:
[b]Hi,
I am tasked to make my code more modular, and redesign the code using UML methods( Unified Modeling Language).

  1. Does anyone know how to do UML with OpenGL? or does anyone have any samples to let me reference?
  1. This question is probably easier to answer, can anyone tell me, how to use OOP (Object Oriented Programming) with OpenGL? which parts should be in which classes? Or does anyone have any sample for me to see?

I’ll be grateful for your help. Thank you.[/b]

Thanks for the reply.

How do you do a OO design then? Should I have classes for each different object I draw?

For example, I have 10 flowers and a tree and the ground to render.

I would have a class for drawing a flower, a class for drawing a tree, and a class to draw the ground?

Or should I have just one class that draws anything, provided I feed in the correct attributes, coordinates,etc?

Thanks for the attention!

breaking down the tasks into classes - that’s a great place to start.

but it’s not quiet object-oriented design [yet].

consider this [with your examples in mind]:

for the sake of keeping this short but thorough, let us ask the rhetorical question: is a flower a kind of tree? is a tree a kind of flower?

having to think about it, I think it’s a better idea to consider flowers and trees a kind of plant. so let’s declare the plant class

class plant
{
protected:
	float x, y, z;   // plant's 3D position

public:
	plant();
	
	void draw_plant()
	{
		// let's pretend that this function
		// just draws a stem and nothing
		// else.
	}
	
	void draw()
	{
		// call draw_plant to draw the plant.
		// [there is a point to having this
		// function, you'll see it later]
		draw_plant();
	}
		
	// ommitted functions
	
	~plant(); 
};

ok so with our plant class we have the means to draw a plant. being that a flower is a kind of plant, let’s extend the plant class.

class flower : public plant
{
public:
	// ...
	
	void draw_petal()
	{
		// draws a petal of the flower
	}
	
	void draw_flower()
	{
		// just as an example, maybe use a for-loop
		// to draw petals of the flower
		for (...)
		{
			glRotatef(...);
			draw_petal();
		}
	}
	
	void draw()
	{
		draw_flower();
		draw_plant();
		
		// together, the two functions draw the flower
		// and the stem
	}
	
	// ...
};

for the tree, you’d do pretty much the same thing, with a little difference:

class tree : public plant
{
public:
	// ...
	
	void draw_leaves()
	{
		// draws leaves
	}
	
	// ditto...	
	void draw_branches();
	void draw()
	{
		// you get the idea
		for (...)
		{
			draw_branches();
			draw_leaves();
		}
	}

	// ...
};

and to tie it all together, you can do something like this in your program:

// wherever you declared your variables
tree myTree[10];
flower myFlower[10];
// ...

// whatever function you use to draw the entire scene
for (int i = 0; i < 10; i++)
{
	myTree[i].draw();	// draws trees
	myFlower[i].draw();	// draws flowers
}

and with that you can cleverly change each “object” or “plant’s” position by changing their x, y, and z values.

the important thing to notice is, you’ve made each “thing” an “object”. and by identifying objects are the first steps in object-oriented design. next is their relationships/inheritance, and then their interactions. if this is new to you, definitely look it up - it’s great stuff and an interesting approach to programming.

i know this was long but i hope it is understandable.

:regards:

wow, thanks. your reply was certainly very informative and taught me alot. Hope you can help me again by answering my other questions?

  1. Now I understand how to draw objects that belong to the same base class, e.g. flower and tree. But how do I link objects that apparently have nothing in common? for example, a car and the grass on the ground?

  2. How about using buildlists in opengl, how do I make it OOP too? Do I have a class that just draws anything, and I just feed in the name of each buildlist?

  3. for texturing and lighting, is there any ‘clever’ way to make them OOP too?

I hope my questions aren’t too stupid. Thanks alot!

Originally posted by IAstudent:
wow, thanks. your reply was certainly very informative and taught me alot. Hope you can help me again by answering my other questions?
sure no problem :smiley:

  1. Now I understand how to draw objects that belong to the same base class, e.g. flower and tree. But how do I link objects that apparently have nothing in common? for example, a car and the grass on the ground?
    yes. there is this idea of “superclass”. I will refrain from using the word “object”, as to minimize on confusing ourselves. instead, I’m going to use “thing”.

everything is a kind of “thing” right? a car is kind of “thing”. the ground is a kind of “thing”. it may seem pointless but virtual superclasses [“empty” classes] are useful in relating objects.

  1. How about using buildlists in opengl, how do I make it OOP too? Do I have a class that just draws anything, and I just feed in the name of each buildlist?
    that’s definitely an option. some things are best left out of the object oriented model. making a buildlist MAY be one of those. then again, there’s nothing wrong with making a buildlist [itself] an object and just pass other objects in to be pre-drawn. hmm… interesting… :smiley:
  1. for texturing and lighting, is there any ‘clever’ way to make them OOP too?
    yes actually. especially with lighting. you can make light an object and then give that light object properties/operations. so in your project[s] you can do something like:

I hope my questions aren’t too stupid. Thanks alot! :smiley:
haha never!

hope that helps

:regards:

Hi, as again, your answers gave me a good feel about how things are done generally by experts and this made things a lot clearer for me. Thanks!!

More questions next time! hope u will still entertain me then…

have a nice day…