s a way, but whether you consider it easy depends on how your geometry is =
already structured. First off, you can define color tables that asso=
ciate to ranges of region id numbers. You can define multiple color =
tables, but you'd have to manually toggle which one is active by setting t=
he "regionid_colortable" attribute on the _GLOBAL object.
That won't, however, let you specify different shaders or separat=
e material properties. So forget everything I just said about color =
tables. In order to manage separate shaders, you have to define a se=
parate assembly hierarchy (minimally just one combination object) for each=
set of attributes.
The way to do this is basical=
ly take your model, comprised of various groups, regions, and primitives. =
Create a shallow copy of your top-level object (e.g. "cp gray_tank g=
reen_tank"). For each custom component above the region level, eithe=
r create a copy or add an intermediate combination and set your properties=
on that object. For example, I want my green_tank to be green but w=
ant the wheels to be black. I already made a copy of green_tank, so =
I can set color on that object to green (mater green_tank). Next, sw=
ap out the wheels (cp wheels green_wheels ; rm tank wheels ; mater green_w=
heels ; g tank green_wheels). Now I have a gray_tank and a green_tan=
k with separate shaders, separate colors, separate material properties, bu=
t with the same underlying geometry including region ids.
Note that a technique similar to this is often done for rep=
orts or other visualizations where a copy of the top-level object is made =
and a shader is only applied to that top-level copy. You can s=
et an override flag that will make that shader apply to all objects in the=
hierarchy underneath. Simple way to turn a whole tank into glass or=
add a cutaway view.