openGL to labview

[Barbara Dillenburger]

Hi all,
I have plenty of openGL code that I would like to integrate with labview.
I can think of (and tried) two options:
1) Can I integrate a dll in labview to open an external window with glut
and draw my GL stuff in it, or does labview not allow me taking control
over a window?
2) I imported a GL-dll with initializing/drawing code into labview 8.2
but could not figure out how to tell it where to draw these things Like
glFlush() or something? Creating some sort of output from gl and wiring
it up with something in labview?.
I am grateful for any suggestions or even example code..
Thanks
Barbara

[tst]

Do you have anything to with the person who posted this post? If yes, it would be best to keep the posts to a single thread.

[Wiebe@CARYA]

"Barbara Dillenburger" <barbara.dillenburger@vanderbilt.edu> wrote in message news:45d4e358$1@PYROS.natinst.com...
Hi all,
I have plenty of openGL code that I would like to integrate with labview.
I can think of (and tried) two options:
1) Can I integrate a dll in labview to open an external window with glut
and draw my GL stuff in it, or does labview not allow me taking control
over a window?



The downside of GLUT is that it doesn't return to the main proccess. FreeGLUT does. If you use GLUT, LabVIEW will hang as soon as you call glutMainLoop();


You don't have to use glut. You can get a window handler to any LabVIEW window (can even be a diagram). Use FindWindow API's on windows. Then, enable the window for OpenGL, and get a DC. Pritty much just like any C application. You can even call all the OpenGL functions from LabVIEW.


LabVIEW does allow you to take control over a window. If you use CreateWindow (CreateClass, etc..) from LabVIEW, it will create the window just the same as any other programming language. But the window messages are sent to a window proc. The difficult part is to get does messages in LabVIEW. You could create a LV dll, and get the dll function proc address and use it as winproc.




2) I imported a GL-dll with initializing/drawing code into labview 8.2
but could not figure out how to tell it where to draw these things Like
glFlush() or something? Creating some sort of output from gl and wiring
it up with something in labview?.



You need a window handler, and get it's device context. Enable it for OpenGL, and make the context current. Then anything you draw with OpenGL will be drawn to the window.




I am grateful for any suggestions or even example code..
Thanks
Barbara

[Barbara Dillenburger]

great, this is exactly what I was looking for! Thanks very much!
Barbara


Wiebe@CARYA wrote:
>
>
>
> "Barbara Dillenburger" <barbara.dillenburger@vanderbilt.edu
> <mailto:barbara.dillenburger@vanderbilt.edu>> wrote in message
> news:45d4e358$1@PYROS.natinst.com...
> Hi all,
> I have plenty of openGL code that I would like to integrate with
> labview.
> I can think of (and tried) two options:
> 1) Can I integrate a dll in labview to open an external window with
> glut
> and draw my GL stuff in it, or does labview not allow me taking control
> over a window?
>
>
>
> The downside of GLUT is that it doesn't return to the main proccess.
> FreeGLUT does. If you use GLUT, LabVIEW will hang as soon as you call
> glutMainLoop();
>
> You don't have to use glut. You can get a window handler to any LabVIEW
> window (can even be a diagram). Use FindWindow API's on windows . Then,
> enable the window for OpenGL, and get a DC. Pritty much just like any C
> application. You can even call all the OpenGL functions from LabVIEW.
>
> LabVIEW does allow you to take control over a window. If you use
> CreateWindow (CreateClass, etc..) from LabVIEW, it will create the
> window just the same as any other programming language. But the window
> messages are sent to a window proc. The difficult part is to get does
> messages in LabVIEW. You could create a LV dll, and get the dll function
> proc address and use it as winproc.
>
>
>
>
> 2) I imported a GL-dll with initializing/drawing code into labview 8.2
> but could not figure out how to tell it where to draw these things Like
> glFlush() or something? Creating some sort of output from gl and wiring
> it up with something in labview?.
>
>
>
> You need a window handler, and get it's device context. Enable it for
> OpenGL, and make the context current. Then anything you draw with OpenGL
> will be drawn to the window.
>
>
>
>
> I am grateful for any suggestions or even example code..
> Thanks
> Barbara

[AustinMcElroy]

I would like to expand upon this topic due to some issues that I am having.  I have large intensity plots that I need to display (a 2D matrix with floating point intensity values)  and I have found that Labview really takes a while to do this.  I have also found in the forums that Labview graphics are done in Mesa 3d (Open GL clone w/o video card support) which does NOT use the video card hardware to render the control panel items (intensity plots, buttons, ect).  I would, therefore, like to utilize my video card to do the matrix display instead of the CPU.  OpenGL surely appears to be the way to go. 

I have done a DLL that does the following: GLUT -> New window -> glDrawPixel to display the matrix but ran across the problem that Wiebe pointed out, glut does not allow a user to re-enter the main loop or close out the DLL once glutMainLoop() is called.   Basically, I could only pass the DLL one  matrix worth of data and that was it. 

Now to my actual questions to Wiebe:

You said that I can get the Labview window handlers using FindWindow APIs, which I can understand.  How do I enable OpenGL for that window?  Also, you said "get a DC", what does this mean?

I will probably have some more questions for this thread after I get to working with FindWindows and freeGlut.  Thanks for the huge point in the direction to freeGLUT, I thought I was stuck with GLUT and glutMainLoop!

Thanks,
Austin McElroy

[Wiebe@CARYA]

If you are using glut to create a window, you don't need to enable the window (created by glut), or to get a dc. This is handled by glut. This mechanism is different under Linux and MacOS, so glut handles it because it's platform independent.


If you want to draw to another window, you have to make sure opengl understands this windows pixel format (or that the window understands the opengl pixel format). This is done with ChoosePixelFormat and SetPixelFormat. ChoosePixelFormat enumerates all possible modes, SetPixelFormat sets it to the selected one. This is a really though nut to crack, because there are lots of options, and some are critical. However, if you don't have stange pixel formats, you can use any opengl example to see how it's done (or any opengl book). http://nehe.gamedev.net/ is a great source.


Nothing in windows can draw directly onto a window. you always need a device context (DC). You can get one (for opengl) with wglCreateContext (which is a wrapper around the windows CreateContext api). Then it is there, you need to tell opengl that you want to draw to that particular device: wglMakeCurrent (again a wrapper around MakeCurrent).


Regards,


Wiebe.

[AustinMcElroy]

Hey Wiebe,

Thanks for your help and getting me in the right direction.  I have made a TON of progress.  I can now open windows at will from labview and write to them using the OpenGL standard.  I would be willing to post some of my code for those that need it; it is my own as well as pieced togther from the web and the book, "Beginning OpenGL Game Programming" by Dave Astle and Kevin Hawkins (sorry for the name dropping, but this is a GREAT OpenGL book).  Everything was done in C++ which are then called from Labview.  The only realy problem that I am having is a huge memory leak that I was hoping you might have some knowledge on.  Basic process for what I am doing:

10 Open up a new window using my labview C++ DLL
20 Enter While loop
30 Call another DLL that does a bunch of processing
40 DLL from step 3 also renders to the window opened in step 1
50 Goto  20

The issue that I am having is that every time that the DLL is executed,  memory doesn't seem to be deallocated.  Basically each time the DLL in line 30 is called, it takes 15 MB from RAM.  This issue did not happen before I started calling OpenGL in the DLL so it has something to do with OpenGL and labview and the DLL format.  I have followed examples from misc. places and the same basic code (render using a texture, then do a swapbuffer on the device context of the window set up in line 10, and delete the texture) that I am using to render does NOT cause memory issues when in .exe format. 

So my question is, are you familiar with this issue and is there a way to close this memory leak?

[jpeters]

There are a few things that I would like to point out, and I also have a request

Use FindWindow API's on windows. Then, enable the window for OpenGL, and get a DC.

You generally do this using the SetPixelFormat function, but you should NEVER do this on a window that LabVIEW "owns", like a front panel or a diagram.  You should only do this if you are the one that created the window via CreateWindow or some other api

Our drawing code uses Windows GDI, which can be quite incompatible with some GL pixel formats (I think all hardware accelerated ones).  So it seems that if this works, that you could and probably will, make your window draw in strange ways.

Someone said that LabVIEW uses the Mesa3D library.  This is somewhat true, but not ALL of our controls use it.  I think that our intensity display is just straight GDI, no mesa involved.

What functions are you using to draw using OpenGL?  If you are using things like glDrawPixels or rebuilding a texture for a quad each time you update the data, I wonder how much you are actually benefitting from OpenGL in the first place. glDrawPixels is not known to be the fastest function out there, and although I haven't done any benchmarks, I don't know how much faster it will be than a simple pixel drawing in GDI.  Likewise, if you are sending texture data down to the card all the time, I can't imagine that that is the speediest thing either.

Needless to say, I would like to see your results...

Jeff Peters

LabVIEW R & D

[AustinMcElroy]

Hello jpeters,

When I first started doing this project, I was opening a labview VI and writing to that window.  As you stated, this was a bad way to go about it.  I created a window using an .exe file that would also call the VI that I needed.  Unfortunately, I was not able to write to the window that I created this way, probably due to permissions that I don't have knowledge of.  My final idea was to write a DLL that I could use via the DLL node which would open a window.  I imported height, width, and a "Show Window" value that I can use to destroy and size the window.  I can write to this window using my 2nd DLL which is highly optimized data processing code.

As it stands now, I am using data stored in system memory to texture a Quad and rotate it, among other things.  The biggest problem we have with Labview is displaying our images such that each data point corresponds to one pixel.  We are working with fairly large floating point matrices and labview seems to get very bogged down if we try to expand the intensity plot to anything approaching 1:1.  The thought was that offloading some of the operation to the video card would speed things up.  I will be testing the code on a better computer tomorrow, as I wrote it all on my TC1100 tablet PC with a Geforce 440 with 32MB of memory.  I am pleased with the results so far, but it won't really be a fair test until I get a video card with more memory than the image I am rendering. 

Thank,
Austin

[jpeters]

I assume that you will not be able to post your code, or that it is pretty complex so that posting it might not make much sense.  But a few questions if you don't mind...

How big is your data?

How big is your intensity graph (in pixels?)

Are you regenerating the texture for every value change on the graph or are you only updating it periodically?

You said that you were "rotating" the quad... is this a requirement?

Have you looked into using the 3D picture control? It creates a hardware accelerated 3D window that you can use.  You don't program it using OpenGL, but instead use an object oriented scenegraph api.