Issue with Push/PopModelTransform and document object drawing

Rhino Developer
, , ,
1

Hi there,

I’m having an issue with DisplayConduit and using Push/PopModelTransform.

What I want to happen

  • I’m simulating the movement of a machine by animating it in the view port, and objects in the document are considered attached to a moving part of the machine.
  • So I want to render the document objects with a time-varying transformation.
  • Note, this is just a temporary mode of the plugin, (i.e. hit play, and it animates; hit stop and the conduit disables and the document is as it usually is).

What I’m doing

  • I create a DisplayConduit and override PreDrawObjects to call e.Display.PushModelTransform(myTransform); to move the document objects accordingly (which works as expected for the most part)
  • I override DrawForeground to call e.Display.PopModelTransform() to remove the transform so that other visual elements in Rhino don’t get transformed (like the XYZ frame in the corner of a viewport)
  • I override CalculateBoundingBox and include the transformed bounding boxes of all the document objects, with the intent of preventing the document objects from being clipped/culled.

What’s happening

  • Depending on the location of the camera, the model-transformed document objects will pop out of visibility (become culled?). It appears the culling for these document objects is using the non-model-transformed location of the document objects and ignores the result of the conduit’s CalculateBoundingBox

What I’ve tried

  • I’ve tried turning off depth testing, using e.Display.PushDepthTesting(false);
  • I’ve tried overriding ObjectCulling to never cull an object, using e.CullObject = false
  • I’ve tried disabling clipping planes, using e.Display.EnableClippingPlanes(false);

Is this behavior a bug? Any help would be much appreciated!

Kind regards,

Dustin

2

Hi @Dustin_Condon,

i remember doing somthing related with conduits and the most comfortable way was to use DrawObject(myTransform) in a loop where i just passed my changing animation transform and refreshed the current view.

_

c.

3

Thanks! @clement So what I’ve done to work around it is override ObjectCulling to always cull. Then in my PreDrawObjects I call DrawObject(…) on each document object with my transform. It appears to work. One downside I foresee is that this approach removes the culling step from drawing, because every object will get drawn regardless of where it is. I’m wondering if this might lead to lowered performance with more complex document objects. So I might leave this open until someone can confirm if my initial approach would be expected to work or not.

Kind regards,

Dustin

4

Hi @Dustin_Condon,

ObjectCulling allows you to hide objects which you don’t want to see while your conduit is active. So if you detect a (document) object and set e.CullObject = true in your ObjectCulling event, the conduit hides the object. There is also SetObjectIdFilter which you can use to determine for which document objects your conduit will work only.

It will impact performance the more objects you’re calling DrawObject for and the more views are showing the effect of your conduit.

I’ve read your initial post again and think that you probably just have a problem setting the clipping bounds of your conduit which makes your animated objects go out of visible bounds. Instead of passing each bounding box (the transformed one) to CalculateBounding box during each frame, have you tried to set up a larger (or large enough) bounding box once before the animation starts ? This has been much faster in my case compared to updating the conduits bounding box multiple times.

By default, a conduit does not cull anything from the doc unless you detect an object (eg. by object id) and then set e.CullObject = true in the event. It should also respect any clipping plane in the document unless you disable EnableClippingPlanes.

_

c.

5

Aha yeah that’s a good test. So using my initial method, I just tried setting one huge bounding box that definitely includes everything (minimum corner being -1.0e4 in each component, and maximum corner being 1.0e4 in each component). And the document objects still pops out of visibility when the camera leaves their untransformed locations. So it looks like document object culling/clipping ignores the bounding box. I suspect it’s a bug, unless there’s another way of controlling object clipping/culling that I’m missing.

6

Hi @Dustin_Condon,

are you actually replacing the bounding box or unioning to an existing one ? Can you see that your objects are drawn inside the large box from -1.0e4 to 1.0e4 ?

_

c.

7

In CalculateBoundingBox(CalculateBoundingBoxEventArgs e) I’m overriding it to just include my large bounding box like so:

(I realize that 1.0e4 is “huge” in this context, so I’ve increased it to 1.0e7 so it’s definitely large enough)

protected override void CalculateBoundingBox(CalculateBoundingBoxEventArgs e)
{
    const double r = 1.0e7;
    BoundingBox largeBb = new BoundingBox(-r, -r, -r, r, r, r);
    e.IncludeBoundingBox(largeBb);
}

And this is what I see (keep in mind all these images are with a fixed camera position, but the last image is zoomed)

Conduit Off

image
image1385×1163 101 KB

Conduit On: Camera frustrum still includes untransformed doc objects

  • Notice that untransformed drill bit is still in the camera’s frustrum because I haven’t moved the camera

image
image1382×1140 105 KB

Conduit On: Camera zoomed to not include some untransformed doc objects

  • Notice that since the camera is zoomed, the camera’s frustrum doesn’t include the top of the untransformed drill bit, which causes the corresponding transformed drill bit’s head to pop out of visibility

image
image1381×1138 31.8 KB

8

Hi @Dustin_Condon,

in which event are you drawing your own (blue) object ? (It should be PostDrawObjects)

btw. to rule out something is messing with your largeBd, draw it as well using DrawBoxCorners

_

c.

9

The issue happens regardless of if I draw my blue + red elements (which, yes, are drawn in PostDrawObjects). I’ve drawn the largeBb for sanity’s sake, and it appears to be what I’d expect.