LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

openGL to labview

Hey guys,

Sorry that I dropped off the map for a few days, had some other projects to work on.  I am going to be testing JPeters VI found a few messages ago, and was curious about the Picture control that is suggested.  My understanding was that only the 3D Graphs and the 3D picture control was hardware accelerated.  How does using the picture control differe from the intensity plot in terms of performance?

Thanks,
Austin
0 Kudos
Message 31 of 38
(2,897 Views)
The picture control is not hardware accelerated other than whatever 2D acceleration happens underneath the OS level calls.  I spoke with a couple of other developers and our impression was that the intensity plot probably added a bit of overhead to putting pixels on the screen, like mapping to scale value, etc.
 
With the picture control you are literally drawing a picture on the screen so there isn't any of the extra overhead from the intensity plot.  I cannot really say if this is going to be faster than a texture quad in OpenGL, but I had pretty good results.
 
 
0 Kudos
Message 32 of 38
(2,886 Views)
If the 3d picture control uses mesa3d, it can support hardware acceleration. See http://mesa3d.sourceforge.net/FAQ.html , question 1.2. Most of this is X oriented.


I never understood: why isn't there a mesa3d wrapper that calls opengl? Or an opengl version with mesa3d API? Perhaps licensing issues?


Also, why does LabVIEW use mesa3d, and not opengl? Besides historical reasons... Both API's are very similar, so conversion, or even optional switching shouldn't be hard. (http://mesa3d.sourceforge.net/dispatch.html).


Regards,


Wiebe.
0 Kudos
Message 33 of 38
(2,881 Views)

If the 3d picture control uses mesa3d, it can support hardware acceleration.

The 3D picture control doesn't use Mesa3D, it uses OpenGL.  The old 3D picture control toolkit used Mesa3D iirc.  The reason it is not hardware accelerated is because we actually create a rendering context into a Windows DIB section and render onto that.  Ultimately, the DIB section is painted on the screen using GDI.  The reason we do it this way is because on Windows, you cannot draw lines, text, etc using GDI into a double buffered OpenGL context.  If we know that we have a dedicated window only for rendering 3D that would be one thing, but when you use the 3D picture control it is used along other controls, labels etc which draw using GDI.

I think that Mesa is only potentially hardware accelerated on XWindows, but I am not 100% sure about that.

Also, why does LabVIEW use mesa3d, and not opengl?

My guess is that it might be the same issue as what I described above.  We may choose to use Mesa instead of OpenGL because it integrates into a GDI based window a little easier.  Also, since Mesa is (generally) a software renderer; things can be a little more predictable because you don't have to worry as much about having a driver bug here or there. 

Really the only thing we are actually using Mesa for is rendering our 3D controls and perhaps a few other places mainly to do blending effects and the like.

0 Kudos
Message 34 of 38
(2,869 Views)

Can you send me some example codes to start with? I am using LV 7.1 and would like to draw a lots of points and refresh them regularly. And LV graphs are just too slow to do that. So I would like to use OpenGL for that. Thanks

 

0 Kudos
Message 35 of 38
(2,477 Views)

"sys" <x@no.email> wrote in message
news:1235441417296-858747@exchange.ni.com...
> Can you send me some example codes to start with? I am using LV 7.1 and
would like to draw a lots of points and refresh them regularly. And LV
graphs are just too slow to do that. So I would like to use OpenGL for that.
Thanks&nbsp;

Have you tried the LV7.1 opengl picture control add-on? It's at
http://zone.ni.com/devzone/cda/tut/p/id/4411 .

Although you'd get some overhead for putting all data through the picture
control pipeline, it would still be efficient. After all, the drawing will
probably be the most intensive, and that is handled by the GPU...

The data (points in your case) is cached. If I recall correctly, it is put
in a display list. So it's not send to the GPU over and over again. Then
again, if you update them often, you are forcing to send it...

I'd really recomment to make a wrapper dll to handle glut/opengl messaging
if you do decide on using "raw" opengl routines. I do have lots of
experiments, but the thread you are responing to is almost two years old.
So, this code is rusty...

Exactly how many points are we talking about? Do you need them in 2D, or 3D,
with or without perspective?

Regards,

Wiebe.


0 Kudos
Message 36 of 38
(2,468 Views)

Hi, all.

I have tried to understand the entire thread, but I got lost in some moment. I have spent several months trying to find the way to accomplish some tasks in a project, without success, and I think you may have the solution.

Well, my project consists of a 3D scene where it's displayed a robot arm. It has been represented using the 3D Picture Control. Every mechanical part of the robot is a VRML model (they're not simple geometries) that has been loaded and placed defining relationships between them, and I can control their relative movements with some controls placed on the control panel window.

The representation with the 3D Picture Control has been fairly easy and satisfactory, but now I need to add several advanced capabilities, such as collision detection (between the robot itself, with other objects and with the ground). Since the 3D Picture Control doesn't have these functions, I began to learn OpenGL.

I have found several problems:

1. I'm trying to execute a C program with OpenGL in LabView. I compile it into a dll and use the Call Library Function Node. I have also replaced the glutMainLoop of GLUT for glutMainLoopEvent of freeGLUT, following your instructions (at first, I only want LabView to enter the program, run one cycle program, and return to LabView diagram). But I found that LabView goes wrong when trying to run the program (well, more exactly, the first time I run, it goes OK; but the second, LabView crashes and closes itself).

2. Is it worth learning OpenGL or should I learn OpenSG since there are high level libraries based on it that detect collisions? More precisely, I've found on the internet a library, called CollDet, that seems to perform these calculations.

CollDet website:
http://cg.in.tu-clausthal.de/research/colldet/index.shtml

 

 

 

I paste here the code of the OpenGL program:


#include "stdafx.h"
#include <freeglut.h>

extern "C" __declspec(dllexport)int MyFunction();

void display(void)
{
    glClear(GL_COLOR_BUFFER_BIT);
    glColor3f(1.0,1.0,1.0);
    glBegin(GL_POLYGON);
        glVertex3f(0.25,0.25,0.0);
        glVertex3f(0.75,0.25,0.0);
        glVertex3f(0.75,0.75,0.0);
        glVertex3f(0.25,0.75,0.0);
    glEnd();
    glFlush();
}

void init(void)
{
    glClearColor(0.0,0.0,0.0,0.0);
    glMatrixMode(GL_PROJECTION);
    glLoadIdentity();
    glOrtho(0.0,1.0,0.0,1.0,-1.0,1.0);
}


void MyOpenGL()
{
    int    argc = 1;
    char*     argv[1] = {{""}};
    glutInit(&argc, argv);
    glutInitDisplayMode(GLUT_SINGLE | GLUT_RGB);
    glutInitWindowSize(250,250);
    glutInitWindowPosition(700,100);
    glutCreateWindow("My Window");
    init();
    glutDisplayFunc(display);
    glutMainLoopEvent();
}


int MyFunction()
{
    MyOpenGL();
    return 0;
}


Well, I hope you can help me.

Thanks in advance,
Francisco

0 Kudos
Message 37 of 38
(2,296 Views)

Well, I have to point out something:

 

I don't want to redisplay the model again in the OpenGL render window, because it's properly displayed in the 3D Picture Control; what I want is to pass geometric data to the C-OpenGL program, rebuilt in this program those mechanical parts that could collide, and use some kind of algorithm for collision detection between them. This code would run once every LabView processing cycle, and check whether there's collision or not.

 

My main question is about that algorithm: is there any in OpenGL?, is easy to find?... or is better to use OpenGS?

0 Kudos
Message 38 of 38
(2,266 Views)