PDA

View Full Version : does opengl support object oriented paradigm



zeeee
06-12-2002, 07:26 AM
Hi ..
I have just started learning Opengl and I have a fundamental doubt.....I want to know if object orientation is supported in Opengl.
For example, while selecting an object from the viewscreen, can I directly access the object which it represents. In the sense, instead of pushing the name of the object into the namestack, by saying glPushName(objectname), can I instead push the pointer to the underlying object into the namestack ???
Thanx...

Robbo
06-12-2002, 07:55 AM
No, not at all - absolutely not. OpenGL does not `support' object oriented programming.

That is something that programmers do. All of my code is Object Oriented for all of my OpenGL applications.

GameMaker
06-12-2002, 08:04 AM
Since it is just a number, converting your base object to an unsigned 32 seems like it should work. As long as when you get the number back, you cast it back to your base object pointer.

GameMaker
06-12-2002, 08:05 AM
Oh, and as far as object oriented opengl...Robbo is right. Absolutely not supported.

zeeee
06-12-2002, 08:08 AM
Hi..
Thanx for the reply....Could u please let me know how object orientation can be implemented in opengl ??
My main problem is , I have around 50,000 objects. When a primitive is selected in viewscreen, the unique id of that primtive would be pushed into the namestack. Now, in order to access the object itself I would need to search through the 50000 objects to match the unique id. This would be very inefficient.
can u please suggest me if there is any other better way to do it....
Thanx.

GameMaker
06-12-2002, 08:16 AM
Well, if you know what your base object pointer is, then that IS your object. When I say "base object" I am refering to the class at the top of the hierarchy from which all of your objects inherit from. From this, you can call virtual functions on your specific object.

zeeee
06-12-2002, 08:38 AM
I have been thinking about typecasting but, the problem in doing that is twofold .. One, there are multiple base classes, so with just the unsigned int , I will not be aware of the object that I would need to typecast it to.
Secondly, I feel that is not a good idea to do direct typecasting and mess around with memory locations. This I feel is not object oriented bcoz something like this can be better done in C , where the compiler is more forgiving with respect to typecasting.
So, I am wondering if there is a way around this..
Thanx..

Robbo
06-12-2002, 12:24 PM
There is absolutely no way you should be passing in a pointer as a name (pushing and retrieving it). It is just a happy coincidence that your 32 bit pointer = a value you can push on the name stack.

If you want to be object oriented with your selection, you will need to loop through a list of candidates instances of some base class, looking at its name id:

class MyObjectBase {

public:

int m_glName;

};

for ( int c = 0; c < Size; c++ )
{
if ( Object [c].m_glName == SelectedName ) {
.... Object has been selected
}
}

I should say also that having 50,000 possible candidates is not a good idea. You really should be performing some kind of frustum culling, so only a subset of your 50,000 are sent through the picking render in the first case.

Hope this helps some.

chmod
06-12-2002, 09:52 PM
If you absolutely want to stick to your 50 000
objects, make sure the objects are ordered, and use a binary search perhaps to speed up your search.

Bob
06-13-2002, 01:16 AM
Yes, make sure you use the right saerch method. Don't store them in one huge linear list, like an array, and search element by element until you get a hit. For example, if you use C++, which I assume you do since you talk about base classes, use the map container in the STL library, and store the object id mapped to the actual object. With a 50000 object list, you (read, the map) should be able to get the correct object within an average of about 20 searches.

Should be something like this.



#include <map>
using namespace std;
struct myObject
{
...
};
map<unsigned int, myObject> mapIdToObject;

Robbo
06-13-2002, 04:35 AM
I guess the only problem with using the map there, is that the actual object itself will have no access to its integer name. It should of course use it when executing its `render' or `renderselectable' methods, in order to add the correct name to the name stack (this can of course be done higher up in the object that owns the map).

Moreover, storage of different classes in stl containers is only possible by creating sets of pointers to base classes, rather than of actual object instances.

JML
06-13-2002, 04:53 AM
Originally posted by Robbo:

I guess the only problem with using the map there, is that the actual object itself will have no access to its integer name. It should of course use it when executing its `render' or `renderselectable' methods, in order to add the correct name to the name stack (this can of course be done higher up in the object that owns the map).
Well, you could create a public member in the object that returns the unique integer tag value to use when putting it in a map...

Just my .02
Jean-Marc

GameMaker
06-28-2002, 12:10 PM
Robbo, I'm just wondering why you said not to pass in a pointer as the name? I'm not saying you are wrong ;-), I just want to understand why? As long as memory isn't being reorganized (as in a simple demo) that should work, right? I thought it was kind of a nifty way of doing it.



Originally posted by Robbo:

There is absolutely no way you should be passing in a pointer as a name (pushing and retrieving it). It is just a happy coincidence that your 32 bit pointer = a value you can push on the name stack.

If you want to be object oriented with your selection, you will need to loop through a list of candidates instances of some base class, looking at its name id:

class MyObjectBase {

public:

int m_glName;

};

for ( int c = 0; c < Size; c++ )
{
if ( Object [c].m_glName == SelectedName ) {
.... Object has been selected
}
}

I should say also that having 50,000 possible candidates is not a good idea. You really should be performing some kind of frustum culling, so only a subset of your 50,000 are sent through the picking render in the first case.

Hope this helps some.