Thanks Kimberley
We have an issue to improve this. When and Arc Entity is offset, a “Curve” entity is create. The curve won’t be editable in the same way as an arc nor will it retain any attributes like radius.
As a work around, try using the Arc tool, with the existing center inference as the start, to draw another arc with a longer radius.
Cheers!
~Bryce
Why not use a different logarithm. If you hover over any curved entity .
take any two line segment on that curve providing they are one line segment
apart. The centre is then perpendicular to the centres where the meet.
Simple.
What you think
Daniel
I suspect that only works for circular arcs?
But we only need it for circular arcs any other kind of arc does not have a
centre
When you offset an arc and a curve is created, SU doesn’t know that the curve entity is derived from an arc. As far as SU is concerned, curves are just connected sets of edges that select as one entity.
The proper fix here is to upgrade the offset tool to handle arcs properly and create other arc entities.
I would agree with that.
I would like to see pushpull on Groups. If you scale a group it stretches the texture. you have to go into edit mode and push pull. would be handy for lengthening walls and panel etc
texture[quote=“kimberleydesigner, post:26, topic:17625”]
If you scale a group it stretches the texture. you have to go into edit mode and push pull. would be handy for lengthening walls and panel etc
[/quote]
you could convert (right click) the group to a component then (right click) scale definition to make good the texture
Actually I did not know about that PCMoor. Nice tip. Never had need for it LOL but nice to know. Thanks
With regard to the inference system and the rotate tool - I now find it really difficult to position the initial rotation point:
The prior method (SU15) would lock the protractor to rotate on the axis provided when [shift] was held over a surface, but the actual protractor could be moved about the model and snapped to points. The new method (SU16) can result in the actual tool being off-screen somewhere and making it really hard to confirm that the select base line is what you want.
I think that the current method would work if the relative rotation axis only set it’s self when [shift] was used on a plane - then you could navigate to another place, use other inference guides to place the cursor then use the down arrow to recall the ‘saved’ plane to rotate against.
I also think that it’s a mistake to include the RGB axis in the pink reference - if the plane locked on to with [shift] is R,G or B then it shouldn’t over-write the stored reference and shouldn’t change to pink (it should just go bold); the down arrow cycle should still remember the last pink inference.
Thanks for the feedback! Regarding: [quote=“gadget2020, post:30, topic:17625”]
now find it really difficult to position the initial rotation point:
[/quote]
Can you post an example of this?
You are correct that if you use an arrow key to lock a plane for the protractor, you have to go select your magenta edge after placing the center. We can look trying to remember an edge separately from a surface. Just note that usually that edge needs to be parallel to your chosen surface.
If you only want to lock the plane orientation but move the protractor elsewhere you now need to use the down arrow key. We consciously decided to change the plane-only locking that shift used to Provide. There are two reasons for this. First, moving this functionality to the down arrow key greatly expands the use of inferencing in all the planar tools (rotate tools, circle, polygon, rotated rectangle, etc…). Second its easier to document that holding shift locks all inferences that can be locked. We realize that this will require a shift in people’s habits but its vastly more functional.
Note: We’re also looking into places where the magenta coloring can be confusing when it coincides with axis directions.
Well that answers my question too.
I’ll have to mock something up: [prt sc] doesn’t work when I’m holding [shift]…rotation.skp (1.7 MB)
Using the standard [shift] or [down-arrow] inference on rotation will not work for “scene 1” (bug? can’t snap to mid points?)
Using the standard inference on rotation will put the tool cursor off-screen on “scene 2”
Aha! OK you can get it to work, but you must do the following:
I would really like to be able to move the mouse between these steps - it would make things a lot simpler.
Quick (potentially stupid) clarification question: “Rotation point” = center of rotation?
yup
(and some other text to make it to 20 chars)
Ok thanks! For Scene 1, Instead of holding shift for your first step, press and release the down arrow key to capture only the plane orientation. This will give you the option to place the center anywhere in your model.
Your steps, which start with holding shift, will feel really buggy because your center of rotation (the mid point of the segment on the brow component) is not in slanted plane on the yellow component. This could easily result in the tool being off screen and you having to use the “do no move the mouse” trick.
For Scene 2, you can accomplish this two ways.
It must be just getting my head round a different way to do things; need to rest my hand on the other side of the keyboard.
(Scene2 was about the cursor going off-screen rather than the specific angle)
However I still think if you constrain to the green/red/blue axis (/plane), it shouldn’t turn pink.
…And that there are a couple of minor ‘glitches’ with constraining using [shift] to a plane - no mid-point snap and inference guide not showing if the cursor is off-screen.
Seem to be having a little trouble with locking the inference. If I lock the orientation of say the rotation tool to a surface, it works fine, but when I attempt to lock the orientation to a different surface, the orientation locks to that of the original surface, not the new one. I’m probably doing something wrong, but I can’t figure out what it is.
I hover the control over the surface so it snaps to that surface’s orientation, hit the down-arrow. Works fine the first time, but won’t work when I try to lock the orientation of the tool to a different surface. It insists in re-locking to the orientation of the original plane.
We plan to fix this
This is a limitation with locking to a surface. Its not new and occurs in all other tools. Still I’ll file a request to add it.
If you have a chance, can you post a video of the off screen cursor? I want to make sure I understand this correctly.
Thanks!
Pressing the arrow keys act as a toggles. Meaning you press once to lock and the 2nd press unlocks. Try pressing twice over your 2nd surface.
Admittedly this can be confusing. I will ask if perhaps we can implement a timer or something where you can just lock a additional surface by pressing down again.