View Full Version : Rendering through a dll
03-17-2011, 11:34 PM
I have a commercial opengl based application but it does not provide 3D textures and thus I cannot do volume rendering in it. The application only exposes a specific set of routines through ATL COM based plugins but it does not expose the rendering context info or the device context info.
My questions are
1) can i make opengl calls to enable 3d texturing in the plugin even if i do not have the rendering context or the device context information through the plugin dll?
2) The support team for the commercial software recommend me to put my volume renderer into a plugin such that it finally generates an output image. This image is then applied as a texture on a fullscreen quad in the commercial software. I think this is not a proper way to do this sort of a thing. Can anyone suggest me a better approach? Even if this is a viable approach, can anyone give me pointers on how to generate an opengl application/renderer inside a dll?
03-18-2011, 06:40 AM
Since OpenGL works with a state machine, any call to any function within the current context will work for that context.
I don't think the second alternative is less pratical. I never needed to do such a thing, but I think you need to expose routines in the dll that will do the render regardless of the rendering context.
03-18-2011, 06:54 AM
If you need the context and/or HDC then have a look at wglGetCurrentContext and wglGetCurrentDC.
03-18-2011, 06:59 AM
It sounds like you are confused.
It doesn't matter from where you make GL calls. GL doesn't care. The only thing that matters is that you make the GL calls from a thread that has the current GL context and I am assuming you are not in a multithreaded situation.
Yes, just go ahead and use 3d textures. It requires GL 1.3 minimum.
03-18-2011, 08:32 PM
Thanks for the replies ppl. I will try to do it that way.
The only thing that matters is that you make the GL calls from a thread that has the current GL context and I am assuming you are not in a multithreaded situation.
I think I am in a multithreaded situation. So in this case how do I make sure that the current thread is the one containing the GL context?
03-21-2011, 02:26 AM
OK I managed to get my rendering on the host application frame. However, there is one issue. When I try to create the 3D texture using glTexImage3D, I get an access violation. ON further investigating, i find that the glTexImage3D fp is NULL. In my own applications, I can use glTexImage3D without any problem. I think the host application uses glew to get the extension and so in the initialization function, i call glewInit which deos not report any probelms. If i try to obtain the opengl version info / hardware info etc. using glGetString, it returns NULL for all these cases. What may be causing this behaviour? when I am pretty sure my card supports opengl 3.3 and glTexImage3D is a opengl 1.4 core feature which works fine in my own sample applications? Only in the plugin dll when I call this function, it is NULL? Any ideas why this may be? Is the host application responsible for this? Shouldnt glew give me the function pointer to glTexImage3D?
03-21-2011, 02:53 AM
It's possible, though not likely, that they are using a version of OpenGL32.dll that they wrote themselves, one that loads the real one manually. Some people have done this to interpose themselves between OpenGL and other things in their process that would like to access OpenGL. Check to see what DLLs are loaded, and whether the application ships with its own OpenGL32.dll or not.
03-21-2011, 03:55 AM
Hmm I dont see Opengl32.dll in the app folder nor do I see OpenGL32.dll linking to the main app in the dependency walker.
EDIT: I see opengl32.dll during profiling through dependency walker it is loaded through another dll.
One thing I note is that the opengl32.dll is linked not from my c:/windows/system32/ folder but from the
c:/windows/syswow64/ folder. Would this be causing the issue?
03-21-2011, 05:33 AM
Every time I saw that error was because glew was not initialized properly.
03-21-2011, 05:42 AM
Hmmm I am not sure how the main app is doing it however, to make sure, I re-call glewInit at the plugin dll attachment. I also call the relevant glew funcs to get information about the vendor/gl version etc. at the initialization but they all report NULL which clearly agrees to what u r saying.
How do I solve this?
03-21-2011, 05:48 AM
I know that in Unix systems the initialization order is not a problem, on Windows I had some problem depending when glew is initialized before glut. I don't know what window system you're using, but have you consider glew must be initialized before your window system?
03-21-2011, 06:53 AM
I am on Windows 7 64bit. I cant tell u much about this since I am doing my rendering in the plugin. I am not sure whether the CAD application is infact initializing glew correctly. I asked the support staff of the CAD application and they said the application is not intended for extension in this way and I should do something else which is quite surprising for me. What I understand is that the CAD application developers want to have the software accessible to a more general usage rather than a specific usage as I am intending to do. But even if they are doing it this way why not expose the hardware to the best available features rather than limiting to a specific subset.
03-21-2011, 07:02 AM
I also tried to manually obtain pointers without using the glew functions and that too gives glTexImage3D as NULL.
One thing I would like to ask is where is the function glTexImage3D implemented (i mean in which dll) I checked opengl32.dll using dependency walker and it does not contain it. glew32 will only hand in the pointer right so where will the implementation come from? Is there another dll that is linked behind the scene for glTexImage3D?
I read here http://msdn.microsoft.com/en-us/library/dd374386(v=vs.85).aspx and it says that wglGetProcAddress would return the address of the vendor specific extension but it does not tell me which dll this will come from.
OK the FAQ answers this very well here http://www.opengl.org/wiki/FAQ
When you run your program, opengl32.dll gets loaded and it checks in the Windows registry if there is a true GL driver. If there is, it will load it. For example, ATI's GL driver name starts with atioglxx.dll and nVidia's GL driver is nvoglv32.dll. The actual names change from release versions.
03-21-2011, 07:19 AM
yes, for example nvogl.dll for nVidia hardware or atioglxx.dll for ATI/AMD.
03-21-2011, 07:28 AM
Hmm then in this case I should be able to get the function pointer to glTexImage3D if I call wglGetProcAddress("glTexImage3D"); but this too returns NULL from the plugin. Can i obtain the pointer directly from the driver for my case nvidia's nvoglxx.dll? Is it possible that the main application registers itself as a GL driver and intercept the calls from my plugin to prevent me calling the gl driver functions?
03-21-2011, 09:23 AM
Guys I finally got it working. The cad application architecture does not create the gl context until the render routine is called and I was calling the glTexImage3D function way before that at the time of plugin load. This i came to know through glDebugger. Now its perfectly fine thanks to all those who have helped me with this.
03-21-2011, 12:10 PM
c:/windows/syswow64/ contains the 32 bit DLLs. You have a 32 bit program.
As for getting NULL, you don't have a GL context.
Try HGLRC wglGetCurrentContext(VOID);
Powered by vBulletin® Version 4.2.3 Copyright © 2016 vBulletin Solutions, Inc. All rights reserved.