Wireframe Mode
by Paul Scott · in Torque Game Engine · 09/10/2002 (11:48 am) · 4 replies
I've been working on creating a wireframe mode in the engine, as a debugging thing, and so far its not going so well.
I'm still trying to find my way around things. I need to find where the code that renders the world is, so that I can draw that as wireframe, but leave things like the hud, gui, etc intact.
I've got a hack up and running, by southern engineering:
in platformGL.h :
Now, this has some obvious drawbacks. Things are rasterized as lines, but the trouble is, Everything is rasterized as lines. All text is unreadable, the gui is invisible...
If I could divine where the code that renders objects that are part of the scenegraph, I could move those defs into Just the files that draw scenegraph stuff.
Once I get it working, it's going into dgl, and will be toggled via the console.
But for now... which files am I looking for?
I'm still trying to find my way around things. I need to find where the code that renders the world is, so that I can draw that as wireframe, but leave things like the hud, gui, etc intact.
I've got a hack up and running, by southern engineering:
in platformGL.h :
#define glBegin(a) glBegin( (a) ); glPolygonMode(GL_FRONT_AND_BACK, GL_LINE); #define glDrawElements(a,b,c,d) glDrawElements( (a),(b),(c),(d) ); glPolygonMode(GL_FRONT_AND_BACK, GL_LINE); #define glPolygonMode(a,b) glPolygonMode(GL_FRONT_AND_BACK, GL_LINE); #endif
Now, this has some obvious drawbacks. Things are rasterized as lines, but the trouble is, Everything is rasterized as lines. All text is unreadable, the gui is invisible...
If I could divine where the code that renders objects that are part of the scenegraph, I could move those defs into Just the files that draw scenegraph stuff.
Once I get it working, it's going into dgl, and will be toggled via the console.
But for now... which files am I looking for?
#2
First off, the ProjectBuilder project was not defining things line TORQUE_DEBUG, etc. So the debug build thought it was a relase build; got that fixed now.
Second, upon pressing f9 on a mac debug build, the colsole merely laments the lack of the functions it needs:
09/14/2002 (12:06 am)
looks like that code doesnt work on macs.First off, the ProjectBuilder project was not defining things line TORQUE_DEBUG, etc. So the debug build thought it was a relase build; got that fixed now.
Second, upon pressing f9 on a mac debug build, the colsole merely laments the lack of the functions it needs:
fps/client/scripts/default.bind.cs (300): Unable to find function GLEnableOutline fps/client/scripts/default.bind.cs (306): Unable to find function GLEnableOutline fps/client/scripts/default.bind.cs (307): Unable to find function setInteriorRenderMode fps/client/scripts/default.bind.cs (308): Unable to find function showInterior fps/client/scripts/default.bind.cs (314): Unable to find function setInteriorRenderMode fps/client/scripts/default.bind.cs (315): Unable to find function GLEnableOutline fps/client/scripts/default.bind.cs (0): Unable to find function show
#3
The code that enables the console function GLEnableOutline appears to be Windows specific (see module engine\platformWin32\winGL.cc). Maybe you could add the code to the equivalent Mac module? Sorry I can't help with this as I only develop under Windows at the present time.
As far as the other errors that you are receiving, have a look at this resource. You should be able to diff the scripts to see the modifications required.
Rich
09/15/2002 (8:16 am)
Paul,The code that enables the console function GLEnableOutline appears to be Windows specific (see module engine\platformWin32\winGL.cc). Maybe you could add the code to the equivalent Mac module? Sorry I can't help with this as I only develop under Windows at the present time.
As far as the other errors that you are receiving, have a look at this resource. You should be able to diff the scripts to see the modifications required.
Rich
#4
trouble is the buffer swap. We must hijack glDrawElements, glDrawArrays, and xxxSwapBuffers. The SwapBuffers func is used in the platform's OGLvideo file.
The prob is that the func used is aglSwapBuffers. To hijack it, we must include agl.h. On OSX, agl.h includes OpenTransport.h, which has a struct with a member func named new. The prob is that platform.h #defs new. I ran into a chicken & egg prob with this... not sure what the solution is.
But I've got an idea. Just occured to me, in fact. I think if I hack the oglvideo.cc file to use a different func, I can override that which will call aglSwapBuffers. This is possible because there is only one centralized call to the swapbuffers func, whereas there are myriad calls to the openGL drawing funcs.
09/17/2002 (9:11 pm)
ok, got most of it done, using the same function-swapping strategy as the win build.trouble is the buffer swap. We must hijack glDrawElements, glDrawArrays, and xxxSwapBuffers. The SwapBuffers func is used in the platform's OGLvideo file.
The prob is that the func used is aglSwapBuffers. To hijack it, we must include agl.h. On OSX, agl.h includes OpenTransport.h, which has a struct with a member func named new. The prob is that platform.h #defs new. I ran into a chicken & egg prob with this... not sure what the solution is.
But I've got an idea. Just occured to me, in fact. I think if I hack the oglvideo.cc file to use a different func, I can override that which will call aglSwapBuffers. This is possible because there is only one centralized call to the swapbuffers func, whereas there are myriad calls to the openGL drawing funcs.
Torque 3D Owner Phil Carlisle
Basically, its already done.
Phil.