Opengl .net

[Maggie Szydlowski]

Onlyjust thought to check. The other dev that got it to work is using NSight 2018.7. I just tried it and it works, I still get the .net error but it continues fine. So I can use that for now, hopefully you can find the issue in NSight 2019.

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.

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.

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 am trying to embed the OpenGL window (as given in NI Example "solarsystem.vi".There is Render Dest control with which a display can be changed to "Scene" i.e, OpenGL window and "Scene Display" which is LabVIEW window.)

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.

The original Vulkan website was designed for the launch of a cutting edge new API that would, initially, have limited official materials and community content. The old website performed that role admirably, but Vulkan has come a long way and we now have a large and increasing amount of tools, libraries, educational material, and news to showcase that a single page website cannot handle. The new website allows us to gather all these currently disparate internal and community resources in a single, easily navigable place.

Our primary goal with the new vulkan.org site was to place key resources prominently to allow developers to quickly and easily find what they need. With this in mind, each page has buttons in the banner leading straight to the most essential and popular resources. If you need the Vulkan Specification, SDK or Guide you can just jump straight there, no digging needed.

In these days of social distancing, game developers and content creators all over the world are working from home and asking for help using Windows Remote Desktop streaming with the OpenGL tools they use. NVIDIA has created a special tool for GeForce GPUs to accelerate Windows Remote Desktop streaming with GeForce drivers R440 or later. Download and run the executable (nvidiaopenglrdp.exe) from the DesignWorks website as Administrator on the remote Windows PC where your OpenGL application will run. A dialog will confirm that OpenGL acceleration is enabled for Remote Desktop and if a reboot is required.

After missing their original target of transitioning to Intel Gallium3D by default for Mesa 19.3 as the preferred OpenGL Linux driver on Intel graphics hardware, this milestone has now been reached for Mesa 20.0.

The Khronos Group announces the release of the Vulkan 1.2 specification for GPU acceleration. This release integrates 23 proven extensions into the core Vulkan API, bringing significant developer-requested access to new hardware functionality, improved application performance, and enhanced API usability. Multiple GPU vendors have certified conformant implementations, and significant open source tooling is expected during January 2020. Vulkan continues to evolve by listening to developer needs, shipping new functionality as extensions, and then consolidating extensions that receive positive developer feedback into a unified core API specification. Khronos and the Vulkan community will support Vulkan 1.2 in a wide range of open source compilers, tools, and debuggers by the end of January 2020. Driver release updates will be posted on the Vulkan Public Release Tracker.

NVIDIA Nsight Systems 2019.6 is now available for download. This release expands graphics trace on Windows by adding support for Direct3D 11, WDDM CPU+GPU queues, and OpenGL. On Linux, new features include support for CUDA 10.2, simultaneous CLI sessions, DWARF unwind and capture by hotkey.

3a8082e126