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.
Best Of
Re: Render Studio: Appearances no property of Parts?
@martin_kopplow
There are many different competing uses of appearances in CAD. I've definitely used color coding of surfaces to show areas which are post-machined, or to highlight revised areas of a model to toolers, or to show which areas of a part are core/cavity/slides/lifters, or which areas are textured/polished/painted/treated a certain way. That's more of a schematic use of color, not a representative use.
For rendering or certain types of product definition, you may want your virtual model to look as much like the real thing will as possible.
I get that having 27 "Textured plastic" Appearances is a lot to wade through and irrelevant to some users. However I'm often specifying the texture of parts/tools for injection molding. If these Appearances are indeed accurate, they are very useful. My experience with other rendering tools is that the scale of textures like this are often hard to get right.
There's probably a better way that Appearances could have been structured by Nvidia/Onshape. With plastics, I would ideally like to pick the general type of resin (which will impact translucency etc), the nominal color, and then select a texture from known vendors/standards (e.g. Moldtech, Yick Sang, and VDI EDM numbers). The same tool with different resins will yield different real world appearances despite the texture being part of the tool.
The textured plastic ones you're showing assume an opaque PC and/or ABS type plastic as far as I can tell. If you want clear PC or PMMA with a texture, you'll have to do some more work. PC and PMMA have clear or cloudy versions, but nothing with a texture. This isn't how product designers think about these issues.
There are many different competing uses of appearances in CAD. I've definitely used color coding of surfaces to show areas which are post-machined, or to highlight revised areas of a model to toolers, or to show which areas of a part are core/cavity/slides/lifters, or which areas are textured/polished/painted/treated a certain way. That's more of a schematic use of color, not a representative use.
For rendering or certain types of product definition, you may want your virtual model to look as much like the real thing will as possible.
I get that having 27 "Textured plastic" Appearances is a lot to wade through and irrelevant to some users. However I'm often specifying the texture of parts/tools for injection molding. If these Appearances are indeed accurate, they are very useful. My experience with other rendering tools is that the scale of textures like this are often hard to get right.
There's probably a better way that Appearances could have been structured by Nvidia/Onshape. With plastics, I would ideally like to pick the general type of resin (which will impact translucency etc), the nominal color, and then select a texture from known vendors/standards (e.g. Moldtech, Yick Sang, and VDI EDM numbers). The same tool with different resins will yield different real world appearances despite the texture being part of the tool.
The textured plastic ones you're showing assume an opaque PC and/or ABS type plastic as far as I can tell. If you want clear PC or PMMA with a texture, you'll have to do some more work. PC and PMMA have clear or cloudy versions, but nothing with a texture. This isn't how product designers think about these issues.
For colorways, it's often the case with consumer products that the same basic parts/tools will be used to create different variants, where the only change is color and/or finishes. This can become a huge hassle in configuring and tracking BOMs, part numbers, etc. Here's an example I did in Onshape where I created a custom feature script to manage the color variants, so that it was easier to have central place to define color variants (much like I would like to do with an Appearance studio). Some parts were painted in color, and others were molded in color. There are 4 variants which include 4 colors for the main parts, and two colors for some of the molded trim parts.
S1mon
1
Re: Render Studio: Appearances no property of Parts?
I think that color coding for manufacturing is not necessariliy connected to rendering apearances. It could be useful, if colours in the modeling environment could be triggered by part properties, though. In one case I have to deal with, standard content has one colour assigned, and made to spec hardware another, wood shop items, transportation supports, and so on yet another. You get the idea: Whenever a certain property is present (label?), triggering an assigned colour setting would be helpful. I'm not sure how frequently this might be requested, though. Another case is that faces offset for 3D printing get color coded. That does in fact help checking if all the contact faces of AM parts have been considered. Those things are sure no universal standard, but may exist on a per company basis or just prove useful in everyday life.
When it comes to rendering, I find myself using certain appearances (from the library or edited) frequently, many others almost never. Projects usually have a limited number of materials or surface treatments each, so they repeat, and a studio and/or library to manage these does not sound too far off to me. In that case, I could apply render materials to a part while it is still in the modeling stage and possibly hit the ground running when setting up a rendering, for all instances would already have a (proven) appearance assigned, so no more trial and error and much less clicking around in overcrowded libraries with names or icons that are not actually human readble.
This, for example, makes no sense:
This isn't much better:
Re: Render Studio: Appearances no property of Parts?
I’ve mentioned this idea before, but I wonder if having an “Appearance Studio”, kinda like a Variable Studio, would be a good way to manage reusable appearances?
There’s also a related need for managing multiple color ways and color specifications for manufacturing. Ideally that would be connected to managing all the settings for rendering.
There’s also a related need for managing multiple color ways and color specifications for manufacturing. Ideally that would be connected to managing all the settings for rendering.
S1mon
1
Re: Vendor/Customer Sharing
@S1mon and @jonathan_b List views has more room to run and structure view will be like the other side of that coin (working on it) where related drawings are shown. Structure view will present your latest released products in a much more natural and intuitive way - where you will be able to navigate the levels of your product and browse to find what you are looking for. Recursive views (views looking within all subfolders) are a natural fit for both list and structure views and still remains on us to deliver. Where used is not meant as an easy consumption type view - it's meant to be used as a part of impact analysis when considering ramifications of changes to your products.
I wouldn't expect Arena to be the answer here either.
We'll have more to do in list and structure views than what's mentioned here - but this is really the start of component based views that make more sense and are document agnostic. Non-cad consumers of the information would expect to see and interact with views like this as opposed to only monolithic documents.
I wouldn't expect Arena to be the answer here either.
We'll have more to do in list and structure views than what's mentioned here - but this is really the start of component based views that make more sense and are document agnostic. Non-cad consumers of the information would expect to see and interact with views like this as opposed to only monolithic documents.
Re: Whats the correct workflow for modular parts from seperate models
Any parts reusable across assemblies can be in their own 'document' to make them easy to keep track of and clean. Also study "CONFIGURATIONS" to make things like bearing assemblies and handles.
Individual mountain bike designs would want to be in separate documents.
Iterations of the same design with different sizes can be contained in one document using configurations.
Individual mountain bike designs would want to be in separate documents.
Iterations of the same design with different sizes can be contained in one document using configurations.
