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.
How to work with an automotive standard coordinate system and the view cube display correctly
martin_kopplow
Member Posts: 505 PRO
After I tried a few simpler designs, I want to design an automotive piece now. It is going to be trailer me and a friend plan to build.
I would want the coordinate system to follow automotive standards, and at the same time I'd like the view cube to be displayed or labeled correctly. I found nothing about it the in the help and learning center, though.
In the automotive world, as a convention, zero is on the center of the front axle, Z is up, X is pointing back and Y is pointing to the right. Even if the gaming industry and some weird sim packages are using tons of different methods, that's the way it is done in pro vehicle design.
Example of conventional vehicle coordinate system:
Now back to Onshape: The axis system alone could be made to match up with the coordinate system in Onshape and the labeling on the view cube.
Example:
But what about the labeling on the view cube? As you can easily see, if the labeling is to reflect the view on a 1st angle basis (an assuption which is supported by the Top label) Front and Right are not matching the vehicle axis convention. In fact, there is no way the view could ever be oriented so that the labels on the cube would be accurate on a vehilcle design, for the cube would need to be rotated 90° by the Z-axis to match the front orientation and Right would need to be Left. What we see here, is an architectural labeling convention. That's confusing.
Can the labeling on the cube be made to match the automotive coordinate convention?
0
Answers
The custom views do not seem to change the labels on the view cube, as the most prominent representation in the GUI, though, do they? If I share some vehicle model with someone else who is remote, or give a presenation on site, the person will still be confused trying to navigate using the cube, then.
CNC mills and architecture tend to have Z-up:
I always try to have the default view of any part or assembly be the one that is most descriptive. With the ways that the views are labeled, the "front" "left" "right" and "back" don't always correspond to what we might call them. If I have a vehicle pointing towards the "front" plane, then the "right" view is actually looking at what I would think of as the left side of the vehicle (as viewed from the driver/rider/passenger perspective).
I also try to think very carefully where the origin will be so that it's least likely to move around. Some industries want certain coordinates to always be positive, although I think this may be less of an issue as it once was.
The most important thing is to agree on a convention within your company and stick to it.
The custom views do not seem to change the labels on the view cube, as the most prominent representation in the GUI, though, do they? If I share some vehicle model with someone else who is remote, or give a presenation on site, the person will still be confused trying to navigate using the cube, then.
Here's an improvement request about that.
Here's another about changing the default view cube/coordinate system.
That would certainly be a workaround, though I believe this is not about what is easiest to implement, but easiest to work with. Importing on a mate connector still leaves the most ambiguous view labels in place. So, my favourite solution would be the user defined world coordinate system, be it based on template or settings. We already make similar decisions for things like units, and I can imagine defining the coordinate system in a very similar context.