Axes convention

honest_guvnor

A minor point but is it possible to change the axes convention on the view control since the negative y coordinate for the back to front direction has caused a small amount of confusion? The convention expected is x for left to right, y for bottom to top and z for back to front.

jakeramsley

Currently no.

jakeramsley

Currently no.

mevale

Z axe from back to front??  

First ask to CMM and NC machine manufacturers change the same way you ask, and then ask for change the CAD.
I don´t know who was the first to changed the CAD axes orientation (guess Pro/E) then ALL sheeps goes the same way.
You are a bad oriented victim.

michael3424

jakeramsley said:

Currently no.

And please stay that way!

honest_guvnor

The convention is the one used by analysis programs dating back to the 1960s and probably before that on paper. Some of these programs make different assumptions for the X, Y and Z coordinate directions and so the axes orientation is not optional. It is a minor issue having incorrect labels for front, top, back and bottom that adds a small barrier when communicating with others.

Obviously other areas have different axes conventions and the one currently adopted by onShape is probably the second most common. It is widely used where there is some sort of ground plane such as with CNC machines.

So the question is do onShape want to stick with a single fixed meaning for the words front, back, top, bottom on their view control or allow the user to set it? My guess is quite a few companies looking at using onShape would want it to follow the convention they use internally. It is currently in my "con" column but is only a minor concern.

andrew_troup

This is one of those questions which can be argued convincingly both ways: there is real merit in allowing the user to dictate the Cartesian (xyz) signage convention, but this could also present a major problem in a highly collaborative tool. It's conceivable that enabling customisation at such a fundamental level could result in users of the same model being seriously screwed up, due to radically different expectations of behaviours which are almost as deeply embedded as the direction of gravity.

I would personally rather see flexibility introduced into the tools of input (which is already in place in Onshape, to a degree) and output (to suit the different conventions of other disciplines, and other packages) and keep the convention *within* Onshape to a single, 'known devil'.

Imagine a mythical ship ... let's give it a fanciful name, like, perhaps,  "Costa Concordia" ... where there were some officers who defined port and starboard the opposite way round from their peers.
Regardless of who is "Right" in such situations, it seems to me more important that there be a single convention.

honest_guvnor

So long as the (x,y,z) axes are right handed there is no fundamental problem. The issue is that there are effectively two conventions being used: the mathematical one (x,y,z) which is fine and the conceptual one (back, top,...) which will be wrong in some cases. The latter would soon get ignored by experienced engineers but the inexperienced and managers may initially work to it because it is the more understandable. Since these are only labels it is trivial to allow them to be set which you would need to do anyway for other languages.

You cannot convert in a simple way if experienced engineers work to (x,y,z) and managers work to (front, top,...). You may be able to prompt or scan the model in some cases. Also you do not want to force people to mentally handle conversion while working away on their models. The point of adopting conventions is to make things easier and consistent.

andrew_troup

Here's a related point I just noticed today. When one of the construction planes is renamed (say from "Top" to "Floor"), subsequent references generated within Onshape to that plane are still referred (say when Extruding "Up to Surface") to the original name, ie "Top"

In this case, I think there is a strong argument which (at least superficially) seems to run in opposition to my last post in this thread.

I would argue passionately that renaming should be binding, and the original names expunged from that particular model. Falling back on the ship analogy: the sides of a ship are named from the point of view of the helmsman looking "forrard", whereas the sides of the conceptual engineering cube are (by long-standing convention - but not as long as the nautical one!) named from the point of view of someone ahead of the cube looking "aft"

Naval architects modelling a ship in (say) Solidworks, will resolve this effortlessly by renaming the "Right" view, and the Right construction plane, as "Port", the "Top" plane becomes "Waterline", and the front plane becomes "Station 0".

Everything will work out sweetly, despite the fact that it is actually the left side of a vessel which is the port side. However if the software keeps insisting on calling port "Right", then confusion is guaranteed. (It's even worse when modelling a land vehicle. What the software calls the left view is actually a view from, and of, the right hand side of the vehicle)

So I would argue for retaining the ability to customise the names of the construction planes, and then it's a relative no-brainer to respect that renaming, rather than keep two naming systems running in parallel as Onshape currently does.

The reason this does not contradict my previous post is that there remains, for ALL models, a more fundamental, consistent underlying convention which remains unchanged, namely the x y z sign convention.
The verbal names are an overlay, for the convenience of the user, IN THE CONTEXT of whatever they are modelling. And the names of construction planes should be considered part of this overlay, because they are by nature information-rich, and contextual.

jakeramsley

andrew_troup said:

Here's a related point I just noticed today. When one of the construction planes is renamed (say from "Top" to "Floor"), subsequent references generated within Onshape to that plane are still referred (say when Extruding "Up to Surface") to the original name, ie "Top"

This is a current bug in our system.  If you would like, we could create a ticket for you.

andrew_troup

@jakeramsley
I'm relieved to learn that's not intentional. By all means, add my name to the ticket, thanks

bill_23

The concept of the present axis if from 3rd century b.c.  It's called Trigonometry.

andrew_troup

Laying aside the minor issue of the labels on the (larger) view cube:

@honest_guvnor seems to be asking in the OP for a left-hand arrangement for the fundamental xyz axes.

If so, I would challenge his assertion, in his second post, that this is the most common arrangement.

I think it goes without saying that this must NOT be a user option: it has to be right, or left, for all users and models.

If he's happy with a right handed axis arrangement, it seems to me that his problem would be solved by permitting saved, named views (as a default for all new parts and assemblies). The user could then quickly reorient the model as desired, including every time it was closed.

Ideally, renaming the faces on the viewcube would also be possible.

I have argued elsewhere that permitting fundamental customisations can be problematic, in such a collaborative tool, but I don't see this as an instance of that. However, as the OP has suggested, these enhancements seem more like 'Nice to have' than "must have"

honest_guvnor

>> Laying aside the minor issue of the labels on the (larger) view cube:

But this is the problem. The user can already rename the planes if desired although that would cause even more confusion with the view control not lining up with the names of the planes.

>> @honest_guvnor seems to be asking in the OP for a left-hand arrangement for the fundamental xyz axes.

Not at all, as was stated in his 3rd post "So long as the (x,y,z) axes are right handed there is no fundamental problem." A left handed coordinate system would cause problems like negative volumes in the analysis programs.

Pretty much every diagram in every scientific book for centuries has the x axes point to the right, the y axis pointing upwards and the z axes pointing to the lower left corner. The OpenGL graphics system that onShape uses for it's graphics follows this convention. It is by far the dominant convention.

The convention adopted by onShape follows that used by most machining where (x,y) is parallel with the ground and z points upwards.This is fine if onShape is only looking to serve this target audience rather than being a general CAD program. But if they want to be a general CAD program they will need to generalise the meaning of front, back, top and bottom.

It would be best implemented as a default environment variable like is currently done for the mm or inches setting so that all new documents follow the user's convention. Naming the initial planes should also follow this setting.

andrew_troup

Sorry, guvnor, somehow I managed altogether to avoid digesting, possibly even reading, your 3rd post, which was perfectly clear. I could probably try and weasel out by pointing out that I was addressing your OP, but the point of a forum is surely to communicate, not prevaricate ...

Now that I understand you properly, I agree with you in every significant detail.
In particular, I would like to add my vote for the following remedies:

1) user to be able to determine which axis (x,y or z) was "Up" and which face (XY, XZ, YZ) was "Right" in the default isometric for their own "New" documents ... and also redefine these on a per-document basis (perhaps from a scrolling list of the most common choices, with "Other ... specify" to cover the remainder
2) user to be able to specify the names of the faces of the default view cube for their own "New" documents, and redefine on a per-window basis.
3) Saved, user-named views, capable (optionally) of automatically invoking "section view"

Does that list adequately address your points, @honest_guvnor ? (I realise I have gone beyond your specific recommendations)

honest_guvnor

andrew_troup said:

Does that list adequately address your points, @honest_guvnor ? (I realise I have gone beyond your specific recommendations)

It is the issue I would like to see addressed. Apart from it being a setting that is inherited for new documents rather than one that has to be set in each new document I have no strong preference for how it is implemented.