Capture display conduit [VB.Net]

I have some geometry drawn in a display conduit, from which I want to generate a decent quality image (usable for presentations, i.e. not pixelated).
How can I capture the display conduit stuff, and change the size/quality of the image?

I’ve used viewcapturetobitmap (command wise and in code), and looked here: View capture to file image quality - #3 by rachelre
which explains how to change the size of the image, but when I use options like changing the size, my conduit is not captured in the image file.

Hi Stuart,

I am not able to repeat the behavior you describe. Perhaps I don’t have enough information? How can I repeat this?

Thanks,

– Dale

Hi Dale,

It looks like view capture to clipboard, with options, captures my conduit if I override Post Draw Objects or Draw Foreground.
If I override Draw Overlay as the main drawing sub, the conduit is only captured when view capture to clipboard is used without options.

Can you explain a little about which situations the different draw subs are most applicable for?
From this: http://wiki.mcneel.com/developer/rhinocommonsamples/displayconduit
I’m guessing it’s something to do with depth writing/testing?

I now have the issue that whilst the geometry is captured OK, I have some 2D text that I draw in the top right corner of the viewport, which is reproduced multiple times if I change the size of the image I’m capturing. If I double the height and width, I get 4 lots of text across the image. Do I simply need to draw this text using the 3D world coords rather than 2D screen coords?

Draw Overlay is only called when Rhino is in feedback mode (during operations like getting a point).
http://4.rhino3d.com/5/rhinocommon/html/T_Rhino_Display_DisplayPipeline.htm

This is why your conduit is not being called.

Ah yep. Thanks. Unfortunately I’m still struggling to get my text output correct.

I currently draw some 2D overlay text in the viewport, as in this example: Rhino - Overlay Text Display Conduit

However if I change the resolution, I get more than one of each lot of text, and it’s not scaled like the geometry is (see images).
How can I adjust the location of this text so that it displays once, at the correct distance from edge of my output image?

ViewCaptureToBitmap (no options):

-ViewCaptureToBitmap with scale set to 3:

I’ve tried changing the position of the 2D text by giving the conduit the resolution, and calculating the text position from these values instead of e.Viewport.Bounds, but then no text displays in the captured image.

Hi Stuart,

Can you post your sample code that isn’t working?

– Dale

Hi Stuart,
The problem is that ViewCaptureTo… is generating multiple frames and stitching them together to create a final large image. 2D screenspace text is one of the hardest things to get right in this case.

You can test to see if you are in this mode if the display pipeline’s IsPrinting property is set to true. (ViewCaptureTo… code is exactly the same as the printing code.)

I don’t have a good way for you to determine what subportion of the overall drawing is being generated at this time. I’m looking to see if there is any good way for you to get at this information.

Hi Steve,

Thanks for this.

As capturing the geometry seems to work OK, I’ve implemented a workaround - by making a note of the screen coords for the text, the text can be drawn into a bitmap image, and overlayed on the bitmap generated from capturing the geometry.
Seems to work well enough.

Hi Steve and/or Dale-

I was curious to know a bit more about this situation. I am using the DisplayConduit to develop a HUD system, and it’s working just fine, although I do know that our clients are interested in having the ability to output screenshots at a higher resolution, so I am running into precisely the problem that Stuart is having with the elements being drawn then tiling according to the desired output scale (I can see that IsPrint is false for the overrides I have tried, which are DrawForeground and DrawOverlay). Is this potentially something that I could overcome using a different approach to ensure that the elements I am drawing get picked up at different scales?

thanks!

My comments above are the only fix that I know of at the moment (checking the IsPrinting property)

Hi Dave,

When you say the following:

which ‘elements’ exactly are tiling? I found geometry drawn with the DisplayConduit worked fine for different resolutions, it was only 2D stuff like text that tiled.

Hi Stuart-

Thanks for responding. All of my 3D geometry is tiling, regardless of type. I have tried using the different event handlers through the Display Conduit (e.g. DrawForeground, DrawOverlay, PreDrawObjects, PostDrawOPbjects), and lines/meshes, other geometries all seem to tile when upping the scale on ViewCapture commands. I must not be engaging with the Display Conduit correctly…do I need to do anything more than call the various e.Display.Draw… methods? Any advice is welcome.

Dave

For example, when using the DrawForeground event handler for a class that inherits the DisplayConduit, IsPrinting returns false…I can’t seem to find the place to execute my e.Display.Draw(whatever) method where IsPrinting is set to true.

Hi @stevebaer, i’ve just ran into the conduit capture problem again on Mac which at some point was fixed on Windows 6 and higher. My conduit is an override of:

Rhino.Display.DisplayConduit

it draws some text & polylines in the DrawOverlay and PostDrawObjects channels. If i try to capture the view (non scaled) like so:

view = scriptcontext.doc.Views.ActiveView
size = scriptcontext.doc.Views.ActiveView.ActiveViewport.Size
bitmap = view.CaptureToBitmap(size, False, False, False)

the bitmap is captured properly, however all conduit drawn elements are missing on RH 7.9 Mac. It works fine on windows RH6 SR35 and RH7 SR9.

Please let me know if you need an example script, i can send via PM.

thanks,
c.

Are you saying this works fine for Rhino 7.9 on Windows, but does not work on Mac?

Hi @stevebaer, yes. At least this is what i found right out of the box with a Mac Mini M1 and RH7.9.

Edit: I now updated BigSur and the problem disappeared / it captures as expected.

_
c.

Ok; I doubt there is anything we can do for this situation

1 Like