This has been implemented and then reverted because of file format compatibility issues. Don't expect this to happen any time soon.

That sounds very sad... Lacking such basic feature, but holding onto file format which does not support it? I understand there can be some issues between versions, but even autocad always had multiple format versions, so users can choose if they need compatibility or new features.

AutoCAD has hundreds of people maintaining it, SolveSpace has one. Make your conclusions.

Actually, this is simplier than it was when I was doing this. So, this is not so hard to implement, and... In NoteCAD I still have no such feature :)

Lacking such basic feature, but holding onto file format which does not support it? I understand there can be some issues between versions,

To be more clear, the problem is not that the current file format inherently cannot support a feature like "sketch on face". It can. But the maintenance overhead is very high, and testing is so complex, that I find it hard to justify shipping that feature with the existing format.

I remember using this feature some time ago, and it was amazing and speed up things a lot. Would be nice to have it back one day.

A library of tests (including UI interactions) would be something worth improving.

Also, do you have a way to donate to the project?

I think this doesn't require any extra functionality to be embedded.
This is might be a mere automatic "create a point on a surface -> create a workplane at this point -> constrain an angle of every point on the workplane relative to the plane (normal) ..." macro

All necessary components supported by .slvs are already present. The only difficulty I can imagine, is fighting with the browser...

Here is the challenge as I understand it:

A workplane in solvespace is represented by a point and a "normal". I put that in quotes because it's not a vector perpendicular to the plane as one might expect. A "normal" in this case is a quaternion used to represent the u,v basis vectors for the sketch plane. It is also possible to extract a conventional N vector from it. The reason for this is that 2d points in a sketch are stored with only 2 coordinates (u,v), they are not 3d points constrained to a plane. This all works fine until we try to define a workplane from a "face".

Faces are represented by... a point and a normal vector (hacked by storing it in 3 elements of a quaternion). Aside from causing much confusion for me, a face does not have enough information to construct U,V basis vectors for the workplane.

IIRC there are ways to define the u,v determinidtically but it is still arbitrary and can probably do strange thing at times.

It is unfortunate that faces dont use the full quaternion normal, we have enough information to do that when faces are created.

So how do we create a u and v vector perpendicular to a given face normal vector?

What @phkahler said. Or put simply a "face" does not have a fixed orientation in its plane - in other words it is free to "spin" in its plane.

A workplace can not "spin" - it is fixed at a particular angle in its plane.

So a face does not hold enough information to uniquely define a workplane.

This #1054 (comment) is also a very good explanation from SoveSpace's original author.

So what we need to do is create a new face type where it stores an oriented normal. Then we go to all the places where faces are created and have them create this new face type. Existing sketches will still work because the old face types are still supported in the code even if no new ones are created. We'd also have to introduce a new point-on-face constraint that uses the new face definition. Even after all of that, I'm not sure compatibility would be preserved - what about sketch regeneration? We'd be creating the new face types during regeneration, so the constraints would have to be updated or would that happen automatically?

It also seems like all the ways to copy faces (FACE_ROT_WHATEVER) would need new variants that rely on the oriented normals.

And all this trouble for a (small?) usability improvement of selecting a face and pressing SHIFT-W instead of selecting a point and two lines from the face... I'm not sure it is worth it. And if we select the orientation "randomly" or with some heuristic someone will always complain.

Thinking about it more, IF regeneration can successfully convert all the old face definitions to a new one, the only reason to keep the old ones would be for linked files. Does Solvespace regenerate on opening a file?

Another advantage to replacing all the faces with a new one like this is a reduction in code. All those different face types in entity.c exist because the face normal is a unique type, rather than just having a handle to a point and a regular normal. Circle entities have no special handling because they're just a "circle" with a reference to a point and normal. An oriented face could be the same way and the normal would get transformed the same way as any other normal.

Yet another advantage may be in new construction tools. I'm still toying with ideas for representing extrusion along a path, and it seems keeping track of a "face" at the end of each segment of such an extrusion is important. I also want to keep track of the normal at the end of each segment so was thinking of defining faces there even if only the end faces are visible. Using an oriented face in these locations would also provide a way to define twist at the end of an extruded section - not that I want to tackle that, but it does seem like a really good thing to have.

On the downside, to get regular 3d normal vector from a quaternion involves some math and I wonder if there may be issues with numerical precision as a result of using a more complex representation. The expressions for constraining a point to a plane would be significantly more complicated, but that's why we have a computer right? ;-)

I might try some of this stuff on a branch after 3.1 just to see how much trouble it really is.

For a loft (twisted /and scaled/ extrusion along a path) "fully oriented" faces will certainly be needed.

It's often desirable to have a sketch on a skewed plane. Currently only orthogonal workplanes are allowed. Related: #103

Currently only orthogonal workplanes are allowed.

Not at all #453 (comment)

Also #1207

@ruevs Ah alright, it worked, but it's very tedious to manually reach for workplane menu item compared to a shortcut. It's also very hard to align new workplane with a model plane.

I think SHIFT+W should take into account the mode (2D or 3D) user is currently in. Should I fill a separate issue for that?

@hinell There may be some confusion here. Once you have an extrusion, select a point and 2 non-parallel lines/edges and press Shift->W to create a workplane. This can be used on pretty much any flat face.

This particular issue "Start sketch on selected face" is only meant to make it even easier by just selecting the face and pressing Shift->W.

@phkahler Yeah, quite tricky, but it works, thanks. I've found it in the third-party documentation already: Sketch in New Workplane.

The process is still tedeious though so this issue may be still relevant.

@hinell that reference is just a reformatted (and outdated 2017) version of the reference https://solvespace.com/ref.pl
Just search for "new workplane" ;-)

I looked into this a bit and found this function and the one below it to be informative. These return the normal (vector) for a given face. There are several face types and how they each store the normal is different. Example:
FACE_NORMAL_PT - stores a vector in the entities numNormal (which is defined as a quaternion BTW).
FACE_XPROD - used for sides of extrusions, stores a line in numNormal and uses a cross product with the group translation vector to calculate the normal. Rather hideous but effective dontcha think?
the others either translate (do nothing) with the vector stored in numNormal, or rotate it.

Oddly, the most common faces are going to be the sides of extrusions and these are generated as FACE_XPROD which has enough information to create a full set of U,V,N basis vectors for a new sketch plane.

The other face types must all derive from a sketch plane or the rotation of one. From a numeric point of view the sketch plane will be from a previous group, so it's constant (can be normalized) weather that's a vector or a quaternion. I'm assuming the expression form of the normal is what's used in constraints, so imagine the algebraic expressions from FACE_XPROD then being used in a point-on-face constraint!!! It seems even more crazy to do that type of thing with quaternions, but maybe it would work just fine.

And all this trouble for a (small?) usability improvement of selecting a face and pressing SHIFT-W instead of selecting a point and two lines from the face... I'm not sure it is worth it. And if we select the orientation "randomly" or with some heuristic someone will always complain.

+1 on this, this would be really usefull to speedup creating things. I'd argue that when a face is used, it could be possible to just select two of it's lines at random and a point on it and it is still better with some simple heuristic that might not always be what you want, than not having it at all.

Doing this "automatic" picking of two lines and a point when a face is used whould speed up the process for most of the cases and for the few where it doesn't yield the expected result you can still use the "manual", current, way and select the lines and point yourself.

I'd argue that when a face is used, it could be possible to just select two of it's lines at random and a point on it and it is still better

One of the most important times to have this feature is when someone extrudes a circle to form a cylinder and there are NO lines on the face to select for creating a workplane. We'll not be doing anything hacky ;-)