Freestyle 1.4.0 has been released!

[Mads Andersen]

Improvements mostly targeted at hard surface modeling.

A big thanks to PuzzledPaul who has really inspired the features in this release!

Enjoy!
/Mads

- Added snapping to any vertex when holding the shift key. Works for both the free move gizmo and the directional move gizmo. By holding both the shift key and the control key updating is retained.

- Move Direction tool introduced.

- The old Rotate tool has been renamed Rotate Direction, and a new Rotate tool has been added.

- The old Scale Uniform tool has been changed into the new Scale tool.

- Made sunglasses a little less necessary. When using the Move, Extrude, Extrude Region, Bump and Stellate tools with a custom movement, only a single movement gizmo is shown at the selection center.

- Added flatten tool.

- Changed Cut.Count to Cut.Pieces.

- A number of the tools now have prettier Tool Settings panels.

- Trying out a new GUI layout.

- Improved the mouse and keyboard APIs.

- The direction vector gizmo is now hidden until interaction with it is actually implemented.

- Fixed bug in intersection test when multiple geometry items overlap in the viewport.

- Fixed bug in vertex and edge intersection test when geometry item was transformed (especially annoying when rotated).

- Fixed rendering bug in KeyStrokeField.

- Fixed bug caused by hovering the mouse over an edge that is subsequently collapsed (reported by puzzledpaul).

- Fixed bug causing the top of the viewport to not receive mouse events (reported by puzzledpaul).

- Fixed rendering bug in NotificationBox.

- Fixed child handling bug in AvailableCell causing dragged mouse button presses to not work properly on buttons.

- Fixed bug that made it hard to grab dividers in SplitViews.

- Fixed bug that left key press state inconsistent when alt-tabbing away from the Freestyle window.

[puzzledpaul]

Phew .. I feel knackered just looking at this lot ... you been putting double rations of spinach in your breakfast

... next thing'll be wearing underpants over your trousers and flying around with a big cape on ...

pp

[Mads Andersen]

Already got a couple of minor issues reported so I guess I'll keep those underpants tucked away for now

[puzzledpaul]

There’s lots to comment on with these changes, but have only had limited plays (been sunny here) ... so these'll have to do for now.

Say user selects a 3x2 region of faces on a sphere
Invokes extrude region normal… and gets a single widget (ok, it changes for the custom option … but still one)
User alters distance / inset etc (maybe changes to custom … still loses distance but keeps inset)
Anyway, assuming just used normal + inset

Then uses rotate (region) … sunglasses … can’t cope, so goes back to extrude (normal) …
And now got individual widgets for each face as opposed to how it was before.

… presumably it should revert to the same state as if it was a fresh extrude op?

Still can’t see the need for (full / complete) widget implementation when using any single one does the same job as any other … just clutters up the workspace imo.

(Am assuming the logic / reasoning is to show user the axis / plane for each face .. ie ‘at the point of application’ of the tool – but you’re also asking user to imagine the effect when using a remote axis … as in custom target rotate… I’d have thought just an axis display would’ve been sufficient … if you really must have something for each face + a single global rotate blob?)

Snapping is a big +
… but I don’t see a way of defining an axis between a couple of verts … and then being able to transfer that axis to act thro’ another (user definable point) … imagine a circular hatch on spacecraft where its hinges are not aligned to xyz.
User picks up hinge axis from hatch diameter elements / geom … but then wants to transfer same to correct hinge location?
Maybe some way by which user can click on both widgets and then move them together?


Imo, the second info panel on rhs is just a waste of modelling window real estate … possibly brought on because of splitting various commands into 2 … which I also think is unnecessary (excepting scale, possibly)

I wondered if there’s a case to be made to make the 2 widgets slightly different, so’s user can differentiate between them more easily … and also, when they (initially) appear on top of each other at the origin, its rather confusing as it seems there’s only one.

Have you considered just using a single widget for all options - including target / vector stuff – that allows user to ‘pull out’ (say) the necessary additional functionality when needed … rather than having to access additional stuff via dialog / panels?

Eg For rotate (say) … user Alt clicks on middle blob … and ‘pulls out’ another blob … with ‘trailing string’
This second blob can then be used to define the second point for an axis … with the displayed string being the axis display?

Yes, there’d be no xyz arrows with this for ortho adjustment … but (smaller?) ones could appear as soon as the scouts ship blob is pulled from its mother ship … or, maybe … not have any at all and user again uses mother ship arrows in conjunction with alt (or whatever modifier key) to adjust scout ship blob position only ... if so, could the situation above (moving both points together) also be accomplished in a similar way ... maybe clicking on axis display somehow?

Re the UI – imo there’s already too much wasted space on the single lhs panel … for the info that’s actually being offered to user … let alone having a rhs one too.

Dunno if this is possible, but I was wondering if mid-point snapping on an edge is available some how?
Suitably implemented, this’d offer user a quick / easy way of defining such an axis / vector?

Sorry if above sounds unduly negative … I think there’s a lot of potential here … but it needs ‘teasing out’ … and this is just from my pov, of course … you don’t have to (and prob won't) agree

pp

[Mads Andersen]

Hey PuzzledPaul,

Thanks a lot for taking another look! I don't think you're negative at all, I love that your remarks are very constructive. I definitely agree that the features and workflow of Freestyle needs a lot of teasing out, and you're helping me a lot with this!

I can't reproduce your first example. With Extrude Region I only get one gizmo all the time, and with Extrude I do get 6 rotate gizmos (because the selection is no longer a single region), but undoing back to the Extrude tool restores a single gizmo as it should. I've tryed different things, but I can't get the behaviour you describe

I agree that the number of gizmos can still be way over the top, I'll continue trying to make them less excessive.

I don't understand how custom target rotate requires the user to imagine the effect? I agree it would be nice if the rotation axis was extended through the target, but the little piece that is shown is correct for every vertex being rotated.

Yes Rotation still does not have snapping. For the Rotate Direction tool it would be very nice to be able to set a start position and an end position, meaning that the rotation angle is the angle defined by the vectors from the rotation pivot to the two positions. This way existing geometry could be used effectively to set up an exact rotation angle.

The hatch example should be pretty easy to do when I get snap points added. If I allow them to be created from a selection, they can handle the "center of diameter" case, and then when you set up the custom target rotate you can snap to the snap points.

The rhs panel is a little much. I feel pretty inspired in the GUI department, so I think 1.5.0 will see some big changes in this area. I hope it will be possible to use Freestyle as one big viewport, only calling up the other panels when needed.

I really like the idea of pulling out the necessary stuff from a gizmo, making interacting with the panel unnecessary

No midpoint snapping yet, wanted the first snapping implementation to be simple

[puzzledpaul]

Only came this time re about flatten (was going to edit my previous post) ... so will comment on your above some other time.

Doesn't seem to be any way to specify the normal of a face as a flatten axis - have I missed something?

eg select a couple of faces on a sphere, sharing a common edge ... and flatten these to the same plane as (say) another (unselected, neighbouring) face ...in wings, this'd be a mmb flatten op ... select face to define plane / axis and same again to specify the point thro' which plane passes.

Oh, btw... re 'pulling strings / stuff out' ... can't remember the circumstances, but holding shift + clicking on an axis arrow (rather than middle blob for snapping) ... resulted in a yellow 'string' from middle blob to a new snapping point being displayed ... geom adjustment went a bit haywire tho'

pp

[Mads Andersen]

No, there's no simple way to flatten to an arbitrary polygons normal yet.

The "pulling strings" is a feature of snapping when using a directional gizmo. Because they are constrained along a line typically they will not go through the vertex that they are snapping to, but to give some feedback I draw a line from the coordinate of the gizmo to the coordinate of the vertex being snapped to. This line will be perpendicular to the gizmo.

There's a slight issue with directional snapping because the arrow head is not actually at the coordinate, but offset (the orange blob is the real coordinate), so switching between snapping and not snapping results in a jump in the gizmo location, however I find this a minor thing.