sketcher_rel_accuracy: why?

Well, the documentation on that one slipped thru the cracks; one hit in Help that tells you nothing and one hit in KB that says it was added for WF.

What it appears to do is set a "snap aperature". In a test part with a bounding box of a few units try setting it to a large number, i.e. 10, and create a sketch with a few reference projections (points and curves).

If that's all it is a little more thought could have gone into naming.

=======================

David,

I have an idea about the possible intent behind this variable that I am going to check next week when I'm back in front of my Pro/E. Have you ever tried to make a small feature in a large sketch, only to get a message 'Section regeneration failed, highlighted entity is too small', or something along these lines? That has happened to me several times when trying to create a sketch by using edges of another feature(s) as a loop: the parts of the loop created by small corner fillets on the 'parent' feature were refusing to regenerate. The workaround was to zoom in very close on a portion of a sketch. Then the sketch regenerated without a hitch. Maybe PTC has created this variable to allow proper regeneration of sketch features which are too small in relation to overall sketch size and fail to regenerate under default sketcher accuracy setting?

"David Janes" ...

I believe the default value is "2", btw. While in sketch mode, Sketch menu / Options / Parameters (bottom of the page).

========================

Hey, that would have been a great name ~ sketcher_snap_aperature. I would have been looking for a *bigger* number, not going for something like .01 or .001, which is what relative accuracy LEADS you to believe that this option controls. Talk about stuff that could qualify for an "Eschew Obfuscation" Award!! But, if it's just an aperature, why wouldn't the pick_aperature_radius cover it!?! Maybe they wanted to separate the two? Why?

: In a test part with a bounding box of a few units try setting it to a large number, i.e. 10, and : create a sketch with a few reference projections (points and curves). : : If that's all it is a little more thought could have gone into naming. : Thought, yes, *any* would have helped. As opposed to deliberate attempts to mislead.

David Janes

: > This isn't a trick or academic question. I've spent months trying to track : down : > the cause of an intermittent loss of snapping to references in sketcher. : In the : > last month, I tracked it to a config.pro option by preventing the usual : > config.pro(s) from loading by renaming, so using all default values. : >

: > Since then, I've gone periodically and not very systematically through a : default : > config.pro file, moving settings from the 'bad' one to the inoffensive : one, for : > customization purposes and to see if any had the effect of causing the : sketcher : > anomaly. : >

: > Well, I finally found it last night, the mysterious sketcher_rel_accuracy. : I : > commented out the option (highlight it, RMB 'Comment') and finally got : back the : > default value of '1' and got the sketcher snapping going properly. But, : beware, if : > you set it to a value, like .1 or .01, you'll probably lose snapping to : references : > in sketcher. Maybe it was meant as a handy way to turn if off with 'Intent : > manager' still on, who knows. : >

: > David Janes : : David, : : I have an idea about the possible intent behind this variable that I am : going to check next week when I'm back in front of my Pro/E. Have you ever : tried to make a small feature in a large sketch, only to get a message : 'Section regeneration failed, highlighted entity is too small', or something : along these lines? That has happened to me several times when trying to : create a sketch by using edges of another feature(s) as a loop: the parts of : the loop created by small corner fillets on the 'parent' feature were : refusing to regenerate. The workaround was to zoom in very close on a : portion of a sketch. Then the sketch regenerated without a hitch. Maybe PTC : has created this variable to allow proper regeneration of sketch features : which are too small in relation to overall sketch size and fail to : regenerate under default sketcher accuracy setting? : : : -- : Alex Shishkin : :

: Yeah, that's exactly what I was hoping this option was meant to address. But, apparently, it was misnamed. It has nothing to do with addressing that situation. Since I was mislead into applying a *smaller*, relative accuracy type value, instead of the larger (1 or higher for a sketcher pick aperature), I found out the hard way that it has nothing whatsoever to do with accuracy. Not in typical English language, engineering/science/math parlance, anyway.

David Janes

Dunno, but the functions probably don't overlap and it might be speculated that the developers for one module don't overlap with another. (Wonder if D-Cubed has anything to do with the sketcher development?)

There's a strange behavior that I didin't mention before because it's difficult to describe, or even to figure out what's happening. If you have an unconstrained sketch entity (in a datum sketch, for instance) and set the option to a large value, when you modify the datum sketch (add a curve) the solver moves the existing curve trying to solve some constraint for each end point (I guess if there's a valid constraint that can be applied within the limits of the variable). It's weird, I sure not an intended workflow...but my point is that there's more to the workings than would be satisfied by the normal pick aperature.

=============================

In any case, do you know if the value represents the same units as in pick_aperature_radius, one one-thousandth of screen size? So, if your screen resolution were 1024 x 768, a sketcher_relative_accuracy value of 10 would make a 'snap' zone about 10 pixels wide. Or is some other unit of size used, in other words, how big is 2 or 20?

David Janes

Dunno. It's doesn't appear to be related to pick_aperature_radius, nor is the pick ap value used for object selection in sketch mode. I guess there's some similar, possibly hard coded, value that's being used.