Keywords: materials, instances

Summary

This demo shows how to utilize material overrides at the object and instance level. The scene features multiple static and dynamic instances of the same car with each instance overriding the body paint color assigned in the base geometry. This introduces more options for efficiently sharing base geometry across instance with unique material attributions.

Related Materials

The following demos, manuals and tutorials can provide additional information about the topics at the focus of this demo:

  • Related Demos

    • Many demos utilize object-level material overrides.

  • Related Manuals

  • Related Tutorials

  • N/A

Details

Similar to the object-level material overrides, this demo focuses on overriding materials on a per-instance basis.

Important Files

The main GLIST imports the geometry of the car from the geometry/sedan_subaru.obj file. This OBJ file has the following material requests:

Material list for the car via object_tool:
$ object_tool --input_filename=geometry/sedan_subaru.obj --materials
Reading input OBJ file ...
Reading in geometry file: geometry/sedan_subaru.obj
    Part count   = 3
    Facet count  = 661
    Vertex count = 413

Material summary tool:
    sedan_body (assigned to 449 facets)
    tire (assigned to 176 facets)
    glass (assigned to 36 facets)

The material database for this scene (see materials/demo.mat) defines these 3 materials as well as the background. The sedan_body material is associated with a spectrally constant diffuse gray via the Ward BRDF model. There are then 3 additional materials defined:

  1. blue_paint,

  2. green_paint, and

  3. red_paint.

The main GLIST file for this simulation is the geometry/cars.glist file, which is where the per-instance material overrides are performed.

The geometry/cars.glist file.
<geometrylist>
  <object>
    <basegeometry>
      <obj>
        <filename>sedan_subaru.obj</filename>
      </obj>
    </basegeometry>
    <staticinstance name="parked_blue_sedan">
      <assign id="blue_paint">green_paint</assign>
      <translation>
        <point><x>0</x><y>0</y><z>0</z></point>
      </translation>
    </staticinstance>
  </object>
  <object>
    <basegeometry>
      <obj>
        <filename>sedan_subaru.obj</filename>
        <assign id="green_paint">sedan_body</assign>
      </obj>
    </basegeometry>
    <staticinstance name="parked_blue_sedan">
      <assign id="blue_paint">green_paint</assign>
      <translation>
        <point><x>-2.5</x><y>0</y><z>0</z></point>
      </translation>
    </staticinstance>
    <staticinstance name="parked_red_sedan">
      <assign id="red_paint">green_paint</assign>
      <translation>
        <point><x>+2.5</x><y>0</y><z>0</z></point>
      </translation>
    </staticinstance>
    <dynamicinstance name="forward_red_sedan">
      <assign id="red_paint">green_paint</assign>
      <motion type="delta">
        <filename>$SCENE_DIR/geometry/forward_car.mov</filename>
      </motion>
    </dynamicinstance>
    <dynamicinstance name="backward_blue_sedan">
      <assign id="blue_paint">green_paint</assign>
      <motion type="delta">
        <filename>$SCENE_DIR/geometry/backward_car.mov</filename>
      </motion>
    </dynamicinstance>
    <dynamicinstance name="circling_green_sedan">
      <motion type="generic">
        <options starthidden="false" endhidden="false"/>
        <filename>$SCENE_DIR/geometry/circling_car.ppd</filename>
      </motion>
    </dynamicinstance>
  </object>
</geometrylist>

The GLIST adds the car OBJ to the scene in various ways:

  • The first <object> entry instances the OBJ in the middle of the scene. The sedan_body color is gray and there are no object- or instance-level material overrides. Hence, the car appears gray.

  • The second <object> entry utilizes both object- and instance-level material overrides.

    • The base geometry overrides the sedan_body (gray) material with the green_paint material. Hence, any instances of the car will now be green.

    • The first two instances are static and those override the green_paint material with red_paint and blue_paint. Note that these instance-level overrides are applied after the object-level overrides. If they attempted to override the sedan_body material they would fail because that material was previously replaced at the object level.

    • The next two instances are dynamic and use the DeltaMotion model, and they also override the green_paint material with red_paint and blue_paint.

    • The final instance is also dynamic but uses the FlexibleMotion model. This instance does not override the green_paint, hence the car appears to be green.

Each of the <staticinstance> and <dynamicinstance> entries for this car include an <assign> element that reassigns the original sedan_body material to one of the 3 "paint" materials mentioned above.

Important
 The <assign> can be used for any of the materials in the car, not just the body material.

Setup

Single-Frame (Still) Simulation

To run the single-frame simulation, perform the following steps:

  1. Run the DIRSIG demo.sim file

  2. Load the resulting demo-t0000-c0000.img file in the image viewer.

Multi-Frame (video) Simulation

To run the multi-frame simulation, perform the following steps:

  1. Run the DIRSIG video.sim file

  2. Load the resulting demo-t0000-c0000.img, demo-t0000-c0001.img, etc. files in the image viewer.

Results

Single-Frame (Still) Simulation

The single-frame simulation produces a single image frame. The car should appear in the scene with the diffuse gray paint, but each of the static and dynamic instances utilize per-instance overrides to change the gray paint on a per-instance basis.

demo
Figure 1. Output of the single-frame simulation.

Multi-Frame (video) Simulation

The imaging instrument is setup to use the "file per capture" output schedule. As a result, the simulation produces 21 separate image files for the 21 captures. The animation below was created from these 21 frames.

The output of the simulation shows the various vehicles moving.