search

jmccormac / pySceneNetRGBD

Scripts showing how to work with the SceneNetRGBD dataset
GNU General Public License v3.0
178 stars 46 forks source link

Feature: Combined materials and some fixes. #14

Closed timethy closed 6 years ago

timethy commented 6 years ago

This Pull-Request contains a couple of things, and maybe you only want to include some of it:

  1. I think vt and vn was flipped (accoring to http://paulbourke.net/dataformats/obj/), and I added the output of vn indices as well.
  2. Mtllib files can be combined into one big mtl file with proper paths, so that materials are associated with the objects.
  3. To facilitate usage (and not break old usage) I added some flags using arparse.
  4. I allowed myself to re-organize a little code and unify spaces and tabs (to only spaces)

It would be great if you could have a look, and if you wish to only include some of the changes I'm happy to cherry-pick them out for you.

I'm not 100% sure if the normals are rotated correctly for submodels, so that is commented out for now (lines 101--108).

jmccormac commented 6 years ago

This PR looks great, thank you for contributing! I'm sure others will appreciate a cleaner scene generation script. I'm happy to merge everything everything here.

For the normals rotation, I have tried visualising some object shadows with point light source in blender with and without transforming the vertex normals, and the transformation fixes offset shadows in the case I looked at so I will tab that transformation in (pics attached below).

One issue I have started working on is backwards compatibility. I've just downloaded both ShapeNet.v2 (which I believe you are using) and ShapeNet.v1. I found that the x-z flip code still in this PR,

tmp = p[0]
p[0] = p[2]
p[2] = -tmp

was only required for v1 and for v2 this code actually rotates objects incorrectly. Have you checked the objects are rotated in your generated scenes match the SceneNet RGBD renders? I have locally added a --v1 flag to enable the above x-z flip transformation as I do not think it is required for v2 but it would be helpful if you let me know if the rotation is indeed required in your ShapeNet.v2 for some reason.

The vertex parsing code in this PR also has problems interpreting some ShapeNet.v1 objects which are not formatted correctly and only have one slash for faces (i.e. f v/vt v/vt v/vt) such as model 03761084/ee586138bb142e67178e7d331e641179/model.obj which has this format and only contains v and vt (no vn). I've allowed v1 objects like this to be properly interpreted in this fashion.

With normal rotation with_normal_rotation

Without normal rotation without_normal_rotation