Pictureframe obscures curve control points


#1

I’ve noticed this same behavior in several of my Rhino v5 files (currently using SR5, but noticed this with SR4 also). I have a curve that crosses over a pictureframe image. When I highlight the curve and hit F10 to display the control points, they are not visible - they appear to be behind the pictureframe image. If I highlight the curve and use either “bringforward” or “bringtofront”, and then hit F10 again, there is no change - the control points are still hidden by the pictureframe image. To determine where the control points are, I have to select a large region around the curve, get the control points highlighted and try to remember their approximate location. Then, I click around in the general vacinity of each control point to finally locate it and move it a bit.

There must be an easier method. How does one get the control points to always be on top of a pictureframe image? Modifying the drawing order doesn’t seem to work.

Thanks,

Mark


#2

Hi Mark and @BrianJ , this bug has been reported for a long time. _BringForward and _BringToFront doesn`t affect the controlpoints. It happens with other geometry on top too. (not only pictureframes) and makes manual tracing of 3d scans with curves more difficult.

c.


(Brian James) #3

Hi Mark,

I generally always make the transparency of the PictureFrame 50% and then lock it or use selection filters. I’m not sure about the status of this one in terms of being a bug and will have to check on that. As I understand it, PictureFrame is a special case but I get the same control point display as when applying a texture map to a planar surface and displaying the model in Rendered mode. In both cases I find 50% trans and locking is best. Does that help?


#4

Thanks Brian and Clement. I guess I overlooked the prior reporting on this issue. That’s too bad; I’ll have to try the 50% transparency as you suggest. Nice to know I’m not the only one with this issue.

Thanks again,

Mark


(Brian James) #5

Hi Mark and Clement,
I ran this by development and it doesn’t sound like a bug. I also don’t see it as a bug since a planar surface responds no differently in terms of occluding control points. That’s not to say this couldn’t be a feature request for PictureFrame of course. I’m just trying to figure out [quote=“clement, post:2, topic:1274”]
this bug has been reported for a long time
[/quote]
It might be that the behavior is assumed to be special for PictureFrames by users hitting this. I’m not finding an existing bug report in our system but if you think the behavior should be different, please explain as much as you can and I’ll file a feature request. For instance, is Xray mode what you’d like to see but only for PictureFrames?


#6

Thanks Brian, my report is less related to pictureframe objects. When i trace eg. a 3d scan and draw a silhouette curve in orthogional views, i usually draw a rough curve first, then use point editing to fine tune it. Naturally, you have to use BringToFront to see the curve at all during the editing process.

Once BringToFront is chosen for an object, it should imho apply to all parts of this object as it happens with other attributes. In the above case, i can see the curve but the points are either visible (outside of the silhouette) or invisible (inside of the silhouette) depending on curvature.

Does the example make it more clear ?

c.


(Brian James) #7

Thanks Clement for explaining more on this one. I see now that an object is occluding the control points while in a shaded mode. The pictureframe image is behind that as I understand it from your screen shot. Correct me if I’m misreading it please.

So this would be a feature request (or possible bug) that BringToFront does not effect ctrl pts. Let me know if I’m understanding correctly and I’ll file it. Can I also ask if Xray mode already does what you’d like without the BringToFront command?


#8

Hi Brian, the object i`m tracing in my example is a 3d mesh coming from a scan (no pictureframe involved). But this was just an example, the controlpoint occlusion happens with every shadable geometry. I see this more like a bug, if i change the layer or color of a curve, this does not exclude the controlpoints as they are part of the curve. The same rule should imho apply to BringToFront and BringForward.

On the other side i don`t see a practical use in the opposite. what is the benefit of having a curve drawn in front of everything but not it’s controlpoints ?

c.


(Brian James) #9

Hi Clement,

Can you attach a file please showing your typical set up? Also, were you able to try the Xray Display mode? I’d like to know if this is what you’d like to see if BringToFront worked as you expect.


#10

Hi Brian, XRay unfortunately does involve transparency. While this is one way to show the occluded controlpoints, it gets in the way after you´ve selected the controlpoint and drag it around. I need the shaded display and highlights visible during edits which is not the case with XRay. My example above showed only tracing a silhouette curve. Of course i trace other curves in orthogonal views as well, think of a car body or a helmet which gets into Rhino as a 3d scan.

For this work I need a shaded or rendered display because of the visibility of the highlights which make up the form. Switching between displaymodes just to select a few controlpoints which i´ve explicitely want to draw in front of everything is what i currently do but try to avoid. I sometimes use SelAll, to see all hidden controlpoints, then deselect what i don`t want to edit. Thankfully selected controlpoints are displayed in front regardless of the setting. Picking them when they are occluded is the problem.

If this is not considered a bug, please add my wish that BringToFront brings the curve controlpoints to front not only the curve itself. Maybe as a command option of BringToFront.

c.


(Brian James) #11

Thanks for sticking with this one Clement while I understood. I filed it as bug RH-20620. This report is not public at this time. If development sees it as a feature request the number will stay the same.


#12

Thank you Brian for filing it as a bug.

c.


#13

Brian,

Thanks for taking Clement’s input. I completely agree with his assessment and desire - BringToFront brings the curve AND the controlpoints to the front, not just the curve itself. I’m not clear why the controlpoints are even considered separate from the curve or object, to me they should always be at the same z-order as the object they define.

I’m sure this is somehow related to the new drawing engine in V5. In V4, the controlpoints always seem to be in front of any pictureframe object I have on my drawing. I never encountered this as an issue until I started using V5.

Thanks,

Mark