| Re: Can a CALL_EXTERNAL .dll create a window? [message #36272] |
Wed, 03 September 2003 09:03 |
Karl Schultz
Messages: 341
Registered: October 1999
|
Senior Member |
|
|
"Rick Towler" <rtowler@u.washington.edu> wrote in message
news:bioi8g$231e$1@nntp6.u.washington.edu...
>
> "Karl Schultz" wrote in message...
>>
>> "Matt Feinstein" wrote in message...
>>> Hi all--
>>>
>>> I'm trying to write a CALL_EXTERNAL .dll that does off-screen
>>> hardware-assisted OpenGL rendering.
>>
>> One (rather different) approach is to create an object of some sort that
> is
>> derived from an existing IDL graphics object and override its Draw
method.
>> You can override the Draw method in IDL .PRO code and have it do a
>> CALL_EXTERNAL to your C code that calls OpenGL. At this point, there is
>> already a window and GL context active that were created by IDL and are
> the
>> window and GL context that your OpenGL calls will be directed to. Of
>> course, this means you'll be using a window provided by IDL.
>>
>> I know this works because I recently hacked up a class derived from
>> IDLgrVolume that calls the Volume Graphics library (VGL -
>> http://www.volumegraphics.com/products/vgl/) to render a volume, instead
> of
>> using IDL's volume renderer. When I told the VGL to render, it just
> happily
>> used its OpenGL calls in the IDL window and context. The results were
>> pretty encouraging, but my time and trial VGL license expired. I've
been
>> thinking about tossing what I have into the user-conrtrib lib anyhow.
>>
>
>
> Hi Karl,
>
> When you get a chance, *do* put this into the user contrib site. It
sounds
> like a wad of fun just waiting to burn my time.
>
> -Rick
>
>
"It sounds like a wad of fun just waiting to burn my time."
So true. :-) It is fun, but there also may be some practical use for it.
If a person has a bunch of volume data and a pretty good investment in IDL
code to manage and display it, it might be worthwhile to get VGL and expand
what I've started to get some more volume visualization options while
staying in the IDL framework. VGL itself is pretty awesome.
The files are now in the Advanced Visualization section of the user contrib
lib. I almost wish we had an "Extreme Object Graphics" section, because it
would fit well there. You DO need to get VGL (see link above). You can get
a free trial version, but you have to register and wait for a human to
process it, so you may have to wait a day. And this code isn't finished or
polished, but it is a start. And a couple of demos should just work once
you've got VGL installed. I threw in some comments and a README, but it has
been awhile since I last executed the code.
Have fun,
Karl
|
|
|
|
| Re: Can a CALL_EXTERNAL .dll create a window? [message #36289 is a reply to message #36272] |
Sat, 30 August 2003 04:39  |
Matt Feinstein
Messages: 33
Registered: July 2002
|
Member |
|
|
In article <vkvgsj3q36nf1@corp.supernews.com>, Karl Schultz
<kschultz_no_spam@rsinc.com> wrote:
... after some interesting and helpful comments, Karl adds...
> You mention "off-screen hardware assisted rendering". I'm not sure that you
> are going to have much luck here. Most hardware accelerators are wired
> pretty tightly to the video system's frame buffer. I've not heard of many
> hardware accelerators that can render into off-screen memory. Do you want
> to render into a region that is in the video memory, but not in a displayed
> window? I guess I'm not sure how you are going to convert your on-screen
> hardware rendering context into an off-screen one. I'm not sure that
> Microsoft OpenGL will use hardware rendering when drawing to a
> device-dependent bitmap. I know that it reverts to software when writing to
> a DIB.
Actually, you -can- do this with the pbuffer extension, which is an ARB
extension to the wgl functions and is supported by all the graphics
board vendors. There is also, I think, an analogous glX extension. It's
true that if you use the 'DRAW_TO_BITMAP' pixel format property, then,
as you say, you get just the OpenGL 1.1 software renderer. But the
pbuffer extension lets you create an off-screen hardware accelerated
context with whatever pixel format you want (within limits). One of the
pbuffer extension functions lets you query the 'acceleratedness' of the
pbuffer, and you can confirm that it is, indeed, hardware-accelerated.
And it really does work-- the only catch, as I mentioned in my first
post, is that you have to start with an on-screen context.
Matt
|
|
|
|
| Re: Can a CALL_EXTERNAL .dll create a window? [message #36294 is a reply to message #36289] |
Fri, 29 August 2003 14:56 |
Rick Towler
Messages: 821
Registered: August 1998
|
Senior Member |
|
|
"Karl Schultz" wrote in message...
>
> "Matt Feinstein" wrote in message...
>> Hi all--
>>
>> I'm trying to write a CALL_EXTERNAL .dll that does off-screen
>> hardware-assisted OpenGL rendering.
>
> One (rather different) approach is to create an object of some sort that
is
> derived from an existing IDL graphics object and override its Draw method.
> You can override the Draw method in IDL .PRO code and have it do a
> CALL_EXTERNAL to your C code that calls OpenGL. At this point, there is
> already a window and GL context active that were created by IDL and are
the
> window and GL context that your OpenGL calls will be directed to. Of
> course, this means you'll be using a window provided by IDL.
>
> I know this works because I recently hacked up a class derived from
> IDLgrVolume that calls the Volume Graphics library (VGL -
> http://www.volumegraphics.com/products/vgl/) to render a volume, instead
of
> using IDL's volume renderer. When I told the VGL to render, it just
happily
> used its OpenGL calls in the IDL window and context. The results were
> pretty encouraging, but my time and trial VGL license expired. I've been
> thinking about tossing what I have into the user-conrtrib lib anyhow.
>
Hi Karl,
When you get a chance, *do* put this into the user contrib site. It sounds
like a wad of fun just waiting to burn my time.
-Rick
|
|
|
|
| Re: Can a CALL_EXTERNAL .dll create a window? [message #36296 is a reply to message #36294] |
Fri, 29 August 2003 14:23 |
Karl Schultz
Messages: 341
Registered: October 1999
|
Senior Member |
|
|
"Matt Feinstein" <nospam@here.com> wrote in message
news:o3sukvkfiasbfisit3j594ckbjo9eedi4a@4ax.com...
> Hi all--
>
> I'm trying to write a CALL_EXTERNAL .dll that does off-screen
> hardware-assisted OpenGL rendering. My first try crashes IDL pretty
> much immediately, so I'm trying to eliminate possibilites for bugs.
> This tends to be difficult, since you can't run a .dll by itself... &
> it would be good if I could get some help in focussing my efforts on
> likely suspects.
>
> The first suspect I can think of is that I have to create a Win32
> window in the .dll. The reason I have to do this is that to get an
> off-screen hardware assisted rendering context one -has- to begin with
> an on-screen hardware assisted rendering context, which, in turn,
> means that you have to create a window. Is there a fatal difficulty in
> doing this in an IDL CALL_EXTERNAL .dll? Or, better, is there some
> combination of window properties that make it OK?
>
> Any help here would be appreciated.
>
> Matt Feinstein
One (rather different) approach is to create an object of some sort that is
derived from an existing IDL graphics object and override its Draw method.
You can override the Draw method in IDL .PRO code and have it do a
CALL_EXTERNAL to your C code that calls OpenGL. At this point, there is
already a window and GL context active that were created by IDL and are the
window and GL context that your OpenGL calls will be directed to. Of
course, this means you'll be using a window provided by IDL.
I know this works because I recently hacked up a class derived from
IDLgrVolume that calls the Volume Graphics library (VGL -
http://www.volumegraphics.com/products/vgl/) to render a volume, instead of
using IDL's volume renderer. When I told the VGL to render, it just happily
used its OpenGL calls in the IDL window and context. The results were
pretty encouraging, but my time and trial VGL license expired. I've been
thinking about tossing what I have into the user-conrtrib lib anyhow.
Most of the complexity in this experiment was in the VGL interface. It is
pretty straightforward to just make a few GL calls, which is probably a
better example anyway.
One thing to think about is that you don't know the current OpenGL state
when you get to your code. If you change it too much, that could mess it up
for IDL because IDL doesn't expect user code to be changing OpenGL state.
So, that means saving and restoring any GL state that you change. (And this
sort of thing is FAR from "supported", so I wouldn't build a lot of things
on this approach.) Luckily, OpenGL has a pretty rich set of state saving
tools.
As far as which class to override goes, you'd have to experiment a bit. If
you pick IDLgrModel, you'll probably get a pretty clean state - that is, you
won't be getting a state that is set up for any particular primitive and
your risk of confusing IDL is less.
You mention "off-screen hardware assisted rendering". I'm not sure that you
are going to have much luck here. Most hardware accelerators are wired
pretty tightly to the video system's frame buffer. I've not heard of many
hardware accelerators that can render into off-screen memory. Do you want
to render into a region that is in the video memory, but not in a displayed
window? I guess I'm not sure how you are going to convert your on-screen
hardware rendering context into an off-screen one. I'm not sure that
Microsoft OpenGL will use hardware rendering when drawing to a
device-dependent bitmap. I know that it reverts to software when writing to
a DIB.
You *should* be able to create your own GL context and drawing target and
render into it from a DLL. If it were me, I'd make a small C dummy app that
calls it in order to get it up and running. Then get IDL to call it.
You also may want to look at the Mesa graphics library, the software
rendering OpenGL work-alike that IDL uses. There is a part of the library
called OSMesa (Off-screen Mesa) that will do OpenGL rendering into a memory
frame buffer. There will be some linkage issues to think about, since IDL
already uses OpenGL and Mesa.
Karl
|
|
|
|
| Re: Can a CALL_EXTERNAL .dll create a window? [message #36297 is a reply to message #36296] |
Fri, 29 August 2003 13:33 |
Matt Feinstein
Messages: 33
Registered: July 2002
|
Member |
|
|
In article <bio955$1p8m$1@nntp6.u.washington.edu>, Rick Towler
<rtowler@u.washington.edu> wrote:
> "Matt Feinstein" wrote in message...
>
>> I'm trying to write a CALL_EXTERNAL .dll that does off-screen
>> hardware-assisted OpenGL rendering. My first try crashes IDL pretty
>> much immediately, so I'm trying to eliminate possibilites for bugs.
>> This tends to be difficult, since you can't run a .dll by itself... &
>> it would be good if I could get some help in focussing my efforts on
>> likely suspects.
>
> Can I ask why you are doing your own GL rendering? I have toyed with this
> idea but I haven't been able to justify the effort.
We've found that there are advantages to 'exposing' the OpenGL pipeline
to IDL when you are doing image analysis. As a bonus, it's
educational-- people get familiar with OpenGL's terminology and states.
I guess that if you're making application programs or GUIs, it's a
somewhat different story.
>> The first suspect I can think of is that I have to create a Win32
>> window in the .dll. The reason I have to do this is that to get an
>> off-screen hardware assisted rendering context one -has- to begin with
>> an on-screen hardware assisted rendering context, which, in turn,
>> means that you have to create a window. Is there a fatal difficulty in
>> doing this in an IDL CALL_EXTERNAL .dll? Or, better, is there some
>> combination of window properties that make it OK?
>
> I hope someone from RSI will answer your question since few if any of us on
> the list can answer this one.
>
> I would take a stab that yes, you can create windows. Have you tried simply
> creating a window and destroying it? Write a main routine for this test
> function so you can run it as an .exe to make sure you are setting your
> calls up correctly. Then take it a step at a time.
I'll try that-- after the holiday, I guess...
> Also, why not a DLM?
>
CALL_EXTERNALs seem a lot easier.
Matt
|
|
|
|
| Re: Can a CALL_EXTERNAL .dll create a window? [message #36299 is a reply to message #36297] |
Fri, 29 August 2003 12:21 |
Rick Towler
Messages: 821
Registered: August 1998
|
Senior Member |
|
|
"Matt Feinstein" wrote in message...
> I'm trying to write a CALL_EXTERNAL .dll that does off-screen
> hardware-assisted OpenGL rendering. My first try crashes IDL pretty
> much immediately, so I'm trying to eliminate possibilites for bugs.
> This tends to be difficult, since you can't run a .dll by itself... &
> it would be good if I could get some help in focussing my efforts on
> likely suspects.
Can I ask why you are doing your own GL rendering? I have toyed with this
idea but I haven't been able to justify the effort.
> The first suspect I can think of is that I have to create a Win32
> window in the .dll. The reason I have to do this is that to get an
> off-screen hardware assisted rendering context one -has- to begin with
> an on-screen hardware assisted rendering context, which, in turn,
> means that you have to create a window. Is there a fatal difficulty in
> doing this in an IDL CALL_EXTERNAL .dll? Or, better, is there some
> combination of window properties that make it OK?
I hope someone from RSI will answer your question since few if any of us on
the list can answer this one.
I would take a stab that yes, you can create windows. Have you tried simply
creating a window and destroying it? Write a main routine for this test
function so you can run it as an .exe to make sure you are setting your
calls up correctly. Then take it a step at a time.
Also, why not a DLM?
-Rick
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
