LabVIEW
OpenGL/DirectX based hardware accelerated rendering environment
@AsianSensation wrote:
Hello,
I am working on a robot that will map environments with a flash LIDAR and a high resolution camera.
My current part of the project consists of writing a rendering engine that can display the mapped environment in an external window.
I have already written an OpenGL renderer that can read text and picture files from a directory, and create a rendition from that. But I would like a much more streamlined process for this.
I have used .dll's before, in the form of activeX (the libraries for my flash LIDAR), and .net (libraries for the Microsoft Kinect). I would like to convert my OpenGL rendering engine into a .dll that can be accessed in labview.
This .dll would ideally be constructed (create the rendering window), then I would use invoke function to pass arrays of data to it as parameters.
I believe this would work best with a .net assembly because I can maintain an instance of the object that I create and call functions of that object.
With the invoke library call, it seems as if I cannot create a persistent object that I can update.
What are your opinions on this? What would be the best method of doing this? Has someone already done this? (I haven't found anything, but that doesn't mean it doesn't exist)
Also for anyone with experience in rendering, is it possible to write an OpenGL rendering engine in C#? Can you write a .net assembly in C++?
Would it be beneficial to write a directX rendering engine in C# so I can access it as a.net assembly?
I would be surprised if you could not do persistent objects with a function interface. After all OOP like C++ or ActiveX or .Net are on a low level just functions too, but usually with an implicit first object parameter (leaving out static or singleton classes for now).
With that out of the way, which path to go has a lot to do with what you are familiar with and the complexity of your intended project. If your expertise is mostly with .Net then trying to come up with a standard C library that can be called with the Call Library Node is most likely not the ideal solution. It can certainly be done (standard C provides anything necessary to do any possible programming problem) but it requires quite a bit of explicit management of things, that higher level programming languages like C++ or C# take partly care of automatically.
On the other hand if you ever plan to go multiplatform, ActiveX and .Net are a clear no-go! They don't port easily and even with Mono existing you will fight continously with version differences and imperfections. Also if you want to squezze the last bit of performance out of the code, standard C may offer possibilities that are harder to control in higher languages but you should also not forget that more performance improvements are done in C++ compilers nowadays than in their C counterpart, mostly because C++ allows the compiler to deduce certain states that it can't as easily get from C code without potentially creating invalid instructions in corner cases.
So if you know it will be Windows only and your familiarity is with .Net I think it would be best to create a .Net assembly and use that in LabVIEW. The nice thing about this approach is that a versatily interface description is standard in a .Net assembly and integrating such an assembly in LabVIEW then gets mostly a point and click exercise, without to many ways of getting things wrong because of datatype mismatches and such. But this ease is bought by adding in the background a whole bunch of complexity to your application, with the .Net runtime engine and the absolutley non-trivial interaction between this and the LabVIEW runtime. That is all hidden from you and you usually do not have to worry about it, but it is there and if things somehow go wrong somewhere you have very limited possibilities to even look in this hidden complexity, lets not talk about changing anything in there to make it work better for your problem.
If you need to potentially go multiplatform or your expertise is greater in C(++), the Call Library Node interface is probably the better choice. Its interface is a normal C function interface but that does not prevent you from accessing C++ objects. You just will have to make and export a C function for every object method and property you want to access, or even better yet create dedicated functions that combine as many object method and property accesses as are feasable for a specific task. The Call Library Node is more cumbersome and error prone, since you don't have a strict .Net assembly interface description as part of the shared library. So you need to do more manual work when configuring the individual Call Library Nodes, therefore you want to minimize the number of calls into your shared library that you have to write VIs for.
But it certainly can be done with the Call Library Node too.
That all said, have you looked at the 3D Picture Control functions? They basically wrap an OpenGL interface that is integrated in LabVIEW but on a higher level than the normal OpenGL API is. It may be to limited to write anything like a renderer but it may be a start to look at.
I'm sorry, but I have not a lot to add to my previous post. I have dabbled with OpenGL both from C and Java but not really embedding it into LabVIEW. It is a rather complex piece of software and integrates tightly with the windows API in the OS, similar to LabVIEW but on an even deeper level to get access to the GPU memory for fast rendering and such. As such I'm sure there are several extra challenges in integrating OpenGL into LabVIEW, not the least since LabVIEW already interfaces to Mesa internally which is another software only OpenGL implementation.
I believe that LabVIEW is truely not the right playground to do OpenGL experiments without a fundamental understanding of both OpenGL itself and advanced C programming techniques. OpenGL has very specific needs in terms of how to initialize it and all, and before you can create a standalone OpenGL application in C(++) it's probably a sure way into trouble to start trying to get this to work inside LabVIEW.
