Render Studio: Appearances no property of Parts?

martin_kopplow

I recently rendered an assembly that re-used parts and subassemblies I already rendered in another context. I was expecting these parts to already have their previously assigned appearance with them, but they didn't. Does that mean I have to reassign all the appearances each time I create a rendering of another combination of the same old parts? I feel that would be pretty un-onshapeish, wouldn't it?

If I have E.G. a door handle I use in many projects, I'd like it to bring in it's assigned appearance each time I add it to a new assembly and render. That'd be one of the key benefits of a render studio working on the very same data set as the CAD. Am I missing something?

Paul_Arden

Currently yes, the appearances assigned in Render Studio are independent from those used in Onshape and are not stored back onto the original parts. We are considering ways to achieve this but we don't have a timeframe for when we may resolve that. We know that it would be useful functionality to have in cases of broad part re-use. We'd have to do it in such a way that it could still be overridden though.

One exception is that if you don't assign or otherwise edit the initial appearances in Render Studio, they remain derived from what you have in Onshape (which are determined by a combination of the material assigned, if from the Onshape material library, and the appearance of the part). Once you modify or assign a new appearance that one will override what comes from Onshape.

martin_kopplow

In my experience, time required for rendering out a handful of possible applications of a selection of structural parts for a client presentation is about 10% setting up the assemblies of existing parts and initiate render, but 90% of assigning appearances time and again each time to every nut and bolt involved. Also, if I use a few dozen of instances of the same part in a rendering (think fasteners), I'd expect them to follow OS standards in that assigning an appearance to one instance would change the appearance of all related instances, just like assigning materials works within the modeling environment.

It is nice the initial appearances from onshape are derived, but we have almost no control over how that looks, at least not enough for a state of the art image. Apparently, there are appearances already stored with the part, so it would only be logical to write back modified definitions to this same place. That would really be a large leap forward in terms of productive usability.

Could we maybe create a render studio for a single part, assign proper appearances there, version it, and when the same part is later inserted into another render studio, use the appearance assigned earlier? Just thinking out loud. I'll go nuts if I have to do this over and over while deadlines are threatening ...

S1mon

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.

martin_kopplow

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:

I an average project, I'd probably use no more then say 20 appearance definitions. Having an appearance studio, where I could mix up the needed appearances, store them in tabs or tiles, then apply to my model, would be a huge time saver, I guess.

S1mon

@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.

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.

martin_kopplow

Fully agree. That is in fact one more reason to incorporate colour/appearance directly into the part properties: You get a new part number for every appearance. Use of colour for applications which I'd rather see in the context of markup or highlighting, is a different thing, and that said, we could possibly live with colours being assigned in a more or less ad hoc manner, to not limit flexibility. 

One more word on the textured plastic samples: I know we need these textures, I use them, too. It is the way of presentaion I question. Also, I also have the suspicion that they are not accurately scaled (not that we could even see that in the thumbnails). I second that we'd need a more analytical and targeted way to conjure up appearances we actually want or imagine, by configuring them from stuctured properies rather than choosing them from an overwhelming catalog. An appearance is something like a config of material and surface properties, in my thinking.