GUI for GLUT Celestia

[Paolo]

I'm not an expert of OpenGL so...

is anyone able to evaluate the possible problems of implementing an OpenGL GUI like PUI for the GLUT version of Celestia ?

I knew that Mark was working on it about one year ago. But is a long time that no news are coming from him.

[Paolo]

I've played for a while with StarStrider and Stellarium.

Both of them have an own simple GUI and HUD not based upon the standard Windows controls.

I think that the GLUT Version of Celestia should be improved a bit using for instance a solution similar to the Stellarium one.

So I renew the question. Can someone evaluate the impact on the performance or any other problem that should arise implementing an OpenGL GUI for Celestia?

[Rassilon]

Personally you should be able to implement one using any library available...Its not impossible..just tedious....For someone like me its quicker to go my own route than try to figure out what someone else did....And I learn more about OpenGL in the process....I would recommend the same since you have little knowledge about OpenGL....You will thank yourself later because without knowing whats happening in the code it becomes difficult to debug....

To setup something like a GUI I could see it being quite easy and thats only because I did the above....My own thing....Steps as simple as trapping the mouse and where it clicks it interacts with a projected quad on the screen...A HUD...a button...whatever....

You set up a 2D drawing scheme and overlay anything from text to graphics as your GUI...Sort of like

Code: Select all

glDisable(GL_LIGHTING);
[Always turn off lighting when drawing a GUI]

glEnable(GL_TEXTURE_2D);
[You obviously need texturing]

glBindTexture(GL_TEXTURE_2D, FONT_TEX);
[You bind the texture to the quads that are about to be drawn]
[FONT_TEX is an unsigned int pointer pointing to the block of memory in your video card where the texture resides]

glDisable(GL_DEPTH_TEST);
[Disable depth testing which is the Z factor in X and Y...well since your doing 2D whats the point of testing your depth?]


glMatrixMode(GL_PROJECTION);

[Enter the projection matrix...Think film projector and things projected are 2D]
glPushMatrix();                              
[I guess the best explanation is it captures the current state making it static until its 'popped']

glLoadIdentity();
[This I know resets positioning...It wreaks havoc when done AFTER light placement and camera placement ONLY when in the same matrix mode of those mentioned]

glOrtho(0,fdWidth,0,fdHeight,-1,1);
[Set up your 2D drawing mode...As far as I know you can only set up Ortho in Projection matrix mode]

glMatrixMode(GL_MODELVIEW);
[Revert back to your Model view matrix while still within the currently pushed matrix mode...All of the above essentially forces modelview to display in 2D]
glPushMatrix();   
[Now we store the modelview...Pushmatrix I have noticed keeps from affecting all the rest of the drawn objects position so its essential to use it before each draw when using such things as state change]

glLoadIdentity();
[And reset it]


[Do your drawing code here]


glMatrixMode(GL_PROJECTION);                  
glPopMatrix();
[ Restore The Old Projection Matrix]
glMatrixMode(GL_MODELVIEW);
glPopMatrix();
[Restore The Old modelview Matrix
glEnable(GL_DEPTH_TEST);
[re-enable Z depth]



That is a basic example of how to set up drawing for something like menus...text...a HUD etc...You will understand these things better by actually [;aying around with sample projects and tutorials on OpenGL and begin to see what is actually going on behind the scenes....One thing that I realised that is very important about OpenGL is its just another form of painting a canvas...Each and every object drawn can have its own state independant of the other....Ive noticed that alot of games/projects when they set up a projection matrix and set the perspective to something global are actually applying this to ALL objects within the program when in reality this can be applied to ALL objects individually...If I can paint all objects blue or red why not one blue and one red....

So paolo my recommendation to you is to start from the beginning and reinvent the wheel...the axel...the engine that turns the wheel and evenually the car...otherwise you wont learn as much just using what already exists....

[Paolo]

Hi Rassilon

Thank you for the post. I've downloaded some NeHe examples and played around for a while some time ago. So I went exactly to your conclusions. I'm reinventing the wheels...

But the car with its engine already exists and is Celestia Core.

I would like to know if with my wheels (an openGL GUI) will make the car (Celestia) run fast and smooth or the computational overhead of the openGL pipeline wiill create some sort of problem.

[Rassilon]

GLUT might slow things down...Ive heard mixed things about it....I use freeglut in my project and things seem quick enough for my machine P4 but for others P3 and before it is not so....But that could have something to do with my coding and not GLUT....

PUI I know nothing about....Your best bet is to try it out and see what it does....Youve nothing to lose really...

[Paolo]

Thank you Rassilon. I'll try....

Now I'am little bit less busy so I can dedicate some time.
The initial question was born because before starting and wasting time I wanted to know if there is some big problem that I've missed.

Next step. Is anyone interested in helping?

More than one year ago I've started to implement something that I've called CELUI, but I'm rather so far from being able to apply it to Celestia.
So if somebody wants to help...