Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.First time visiting? Here are some places to start:
- Looking for a certain topic? Check out the categories filter or use Search (upper right).
- Need support? Ask a question to our Community Support category.
- Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
- Be respectful, on topic and if you see a problem, Flag it.
If you would like to contact our Community Manager personally, feel free to send a private message or an email.
honest_guvnor Member Posts: 5 ✭
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 Member, Moderator, Onshape Employees, Developers Posts: 651Currently no.Jake RamsleyDirector of Quality Engineering & Release Manager onshape.com6
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.
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.
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.
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.
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.
I'm relieved to learn that's not intentional. By all means, add my name to the ticket, thanks
@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"
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.
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)
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.