Fri, 07/31/2009 - 16:28
Last days i decided to start using the Visual3d_Layer capabillity provided by OCC visualization package.After applying all the patches found in this forum (which by the way were helpfull), i found some unsolved issues.
1)SetLineAttributes did not change the linetype.
After digging a bit i found that by modifying the OpenGl_togl_begin_layer_mode.c file in call_togl_set_line_attributes function and removing ("if (layerType != type) {") check, then the linetype change takes place.
2)After changing the above i noted that my active plane trihedron(displayed by Viewer->DisplayPrivilegedPlane) had changed its linetype.I solved the above by adding glPushAttrib ( GL_ALL_ATTRIB_BITS ), in call_togl_begin_layer2d just before the glNewList call.Also a glPopAttrib() call is needed in call_togl_end_layer2d after the glEndList call.I used GL_ALL_ATTRIB_BITS in order to avoid any other state changes that may take place in the layer drawing.
3)DrawText works only with AHeight of value 12.In order to use different height i had to disable the trihedron or either create a dummy text with a non usable height value.I found out that the requested fonts, sometimes are created and some not.Because my application needed many different heights in text i decided to find the root of the problem.
After digging i found that the offending API is wglUseFontBitmaps and glGenLists in loadNewFont of OpenGl_tXfm.c .glGetError() after glGenLists returned 0x500 and 0x502.This made no sense beacause documentation of glGenLists states that in case of problem the returned display list base will be 0 (which in this case is not the fact).The most strange thing here is that glGetError cleared the problem bits and then wglUseFontBitmaps worked fine (all fonts can be loaded without problem...).For the moment i left it as is but i do not think that this is a clean solution.In any case somebody can try this since it gives back normal functionallity to DrawText.
Fotis
Mon, 08/10/2009 - 20:04
Hi Fotis,
as mentioned here - http://www.opencascade.org/org/forum/thread_10845/ - I had an example (or rather three examples/applications) of different behavior of DrawText and setting the text height. One worked just fine but had problems with displaying the ColorScale parallel to a Visual3d_Layer. For the second I had to make a dummy call to DrawText in order to set the text height (+ the ColorScale problem). In third case I couldn't make the app change the text height... So I tried the above solution (calling glGetErrot in loadNewFont). It worked for the third case but had no effect on the interference with the ColorScale...
Regarding glGetError, the MSDN says: "To allow for distributed implementations, there may be several error flags. If any single error flag has recorded an error, the value of that flag is returned and that flag is reset to GL_NO_ERROR when glGetError is called. If more than one flag has recorded an error, glGetError returns and clears an arbitrary error flag value. If all error flags are to be reset, you should always call glGetError in a loop until it returns GL_NO_ERROR."
There are three files in the OCC distribution calling glGetError:
OpenGl_togl_markercontextgroup.c
OpenGl_togl_redraw.c
OpenGl_txgl.c
None of them however takes place in a loop. This might be the reason why some error flags remain set...
Pawel
Mon, 08/17/2009 - 14:34
Hello Pawel
I have noticed what MSDN mentions about glGetError, so code in the three above files must be changed in order to be used correctly.But the opengl error flag is raised by glGenLists just before the wglUseFontBitmaps.You can check this by adding glGetError just before the glGenLists call and you will notice there is no error (single threaded environment and single opengl window).I have checked the sructures passed to glGenLists and they seem to be correct also.All the above let me believe that I fell in an undocumented issue of glGenLists which does not allow or has problem when it is been called inside the compilation of an Opengl display list which is the case and how the OCC implementation of overlays works.A possible solution would be to check if there is a display list compilation in place, and if so try to develop a mechanism that will bypass this issue.I will try to google a bit on the issue and post here if i will have any findings.
Fotis