refresh clippingbox in drawviewportwires

My new additions to Human include tools for drawing geometry to an apparently fixed position in the viewport. I thought I was doing the right thing by adding the position of the transformed geometry to the clippingbox from within DrawViewportWires - now I realize that clippingbox is being accessed once and not refreshed as I orbit (meaning the actual geometry position is changing.)

Is there any way to force an update of whatever is calling the ClippingBox on my component from within DrawViewportWires - rather than simply setting it once during SolveInstance?

Replies to This Discussion

Permalink Reply by Andrew Heumann on March 26, 2014 at 7:20pm

bump...

Permalink Reply by David Rutten on March 27, 2014 at 9:00am

I thought I was doing the right thing by adding the position of the transformed geometry to the clippingbox from within DrawViewportWires

You thought wrong. This is one of those rare cases where you do not want to affect the clipping planes of the viewport.

Since this geometry doesn't have a fixed position in world space, as both the position, orientation and scale of said geometry is camera dependent.

You are right in thinking that clipping boxes get cached by Grasshopper. Computing the boundingbox of a Brep or Mesh may be a time intensive operation, so I'm caching this stuff. You can erase the cache by raising the PreviewExpired event, but that will have far reaching performance impacts.

The best approach is to not affect the clipping box in any way and just handle the drawing of all your stuff for every viewport directly.

David Rutten

david@mcneel.com

Permalink Reply by Andrew Heumann on March 27, 2014 at 9:57am

Thanks David, that's what I was afraid of.

Can you explain a little more what you mean by "handle the drawing of all your stuff for every viewport directly"?

Permalink Reply by David Rutten on March 27, 2014 at 11:24am

Rhino viewports host a graphics pipeline (usually OpenGL, sometimes GDI, maybe DirectX in the future too) which is how a 3DM file goes from geometry in memory to pixels on the screen. This pipeline does a boatload of things for every viewport redraw, and as a programmer you can 'hook into' it and either change the way Rhino draws some of the normal stuff, or you can draw completely new stuff.

Bongo is an example of a plugin which does the former. When you scrub the bongo timeline it doesn't actually transform any objects as that would involve a massive amount of traffic to and from the Rhino document (not to mention the problem of events and undo buffers etc). Instead before Rhino draws every object, Bongo jumps in, adjusts the display transform matrix to reflect the animated state of that object and then lets Rhino get on with drawing the geometry.

Grasshopper isn't interested in changing the way Rhino draws its own stuff, it only wants to draw more stuff. Stuff that isn't in the Rhino document and thus stuff that Rhino knows nothing about (that is the reason that you cannot select or render Grasshopper previews).

You have to do the same thing as Grasshopper, but you cannot use the Grasshopper automated drawing routines as that code assumes that the geometry it is caching and drawing doesn't look different depending on where the camera is. Since you cannot use my code, you'll have to write your own.

This code should be called from within the DrawViewportMeshes or DrawViewportWires methods that you're overriding, but then you have to figure out the camera and frustum properties and then draw your objects onto the camera Near plane so they are in front of everything else.

David Rutten

david@mcneel.com

RSS