Bug when reading common dae for collision and texture

[osrf-migration]

Original report (archived issue) by Maurice Fallon (Bitbucket: mauricefallon).

The original report had attachments: image_simulation_issue.png

---

This simple SDF uses one file for both the collison and visual elements:

#!xml
<?xml version='1.0'?>
<gazebo version='1.2'>
<model name="diy_box">
<static>true</static>
<link name='chassis'>
      <pose>0 0 0 0 0 0</pose>
      <collision name='collision'>
        <geometry>
	    <mesh>
	     <uri>model://diy_box/meshes/diy_box.dae</uri>
	    </mesh>
        </geometry>
      </collision>
<visual name='visual'>
  <geometry>
    <mesh>
     <uri>model://diy_box/meshes/diy_box.dae</uri>
    </mesh>
  </geometry>
</visual>
</link>  
</model>
</gazebo>

Gazebo creates the collision element properly and in the Gazebo viewer correctly renderers the image BUT simulated camera images don't render the visual element. Instead its replaced by a black and yellow replacement texture.

I think that the file mustn't be being properly read because the following workaround works, using this SDF file:

#!xml
<?xml version='1.0'?>
<gazebo version='1.2'>
<model name="diy_box">
<static>true</static>
<link name='chassis'>
      <pose>0 0 0 0 0 0</pose>
      <collision name='collision'>
        <geometry>
	    <mesh>
	     <uri>model://diy_box/meshes/diy_box.dae</uri>
	    </mesh>
        </geometry>
      </collision>
<visual name='visual'>
  <geometry>
    <mesh>
     <uri>model://diy_box/meshes/diy_box_copied_file.dae</uri>
    </mesh>
  </geometry>
</visual>
</link>  
</model>
</gazebo>

... where the diy_box_copied_file.dae is just a copy of the original file.

I'd imagine this is a trivial bug in whatever reads these files.

[osrf-migration]

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

---

• Edited issue description

[osrf-migration]

Original comment by Thomas Koletschka (Bitbucket: thomasko).

---

Any update on this? Without a fix most of the models in the gazebo_models database are pretty useless for perception unless we modify them locally to use the workaround technique as described by Maurice.

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

I think this has been fixed by pull request #225. @thomasko Can you verify if it's still a problem?

[osrf-migration]

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

---

• changed state from "new" to "on hold"

Until 2.0

[osrf-migration]

Original comment by Thomas Koletschka (Bitbucket: thomasko).

---

Hmm sorry @scpeters never saw your tag ... I just tested the new models and it's a problem with them (even when using the new fix_texture_loading branch).

[osrf-migration]

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

---

See pull request #339

[osrf-migration]

Original comment by Thomas Koletschka (Bitbucket: thomasko).

---

Works for me.

[osrf-migration]

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

---

• changed state from "on hold" to "resolved"

Fixed in pull request #339

[osrf-migration]

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

---

• set version to "all"

[osrf-migration]

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

---

• changed state from "resolved" to "closed"