Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modularization/Organization #42

Open
ox opened this issue Sep 6, 2018 · 3 comments
Open

Modularization/Organization #42

ox opened this issue Sep 6, 2018 · 3 comments

Comments

@ox
Copy link
Contributor

ox commented Sep 6, 2018

This is my first large-ish Python project that I've had to poke around, maintain, and extend. I was wondering what kind of strategies we can consider to split up the code a bit (gltf2usd.py is creeping up to 2k LoC). My goal would be to make it easier to keep track of control flow and to make it easy to find related and connected code blocks ("I want to fix an animation bug in joints. This module looks like it handles that.").

I'm leaning toward splitting parts of the GLTF2USD class into:

  • Textures(gltf_loader, usd_node)
  • Meshes(gltf_loader, usd_node)
  • Animation(gltf_loader, usd_node)

I would love to have them be "pure" functions but the Python USD kit seems to be written in a procedural style.

edit: I just noticed @kcoley's work in the refactorSkeletons branch. It seems to be cleaner

@kcoley
Copy link
Owner

kcoley commented Sep 7, 2018

@ox yes I agree with modularizing the codebase. The refactorSkeletons branch is progress towards that goal, splitting the glTF components into separate classes. In the branch, I moved those classes under a glTF2 sub module. gltf2loader.py then provides the objects to gltf2usd.py. This would hopefully make it much easier to implement changes and minimize the code needed in the main script. I also have an initial set of unit tests to help with preventing regressions.

So at the moment the branch is set up like this:

  • gltf2

    • Node.py
    • Skin.py
    • Animation.py
    • Texture.py
    • ...
  • tests

    • testGLTFLoader.py
    • ....
  • gltf2loader.py

  • gltf2usdUtils.py

  • gltf2usd.py

Let me know if you have any suggestions

@ox
Copy link
Contributor Author

ox commented Sep 11, 2018

@kcoley Yea that looks pretty good. I was poking around facebook's fbx2gltf and they process fbx files in an interesting way. First they convert fbx to a raw format, then convert the raw format to gltf. This would be analogous to how a compiler will transform code to an intermediary format, then transform that format to machine code in another step.

I think the refactor branch is slowly heading in that direction as the gltf2loader builds a code representation of the gltf file, which gltf2usd.py renders into USD. The branch is looking good. Is there an ETA for it being PR'd?

@kcoley
Copy link
Owner

kcoley commented Sep 26, 2018

I made many updates, but the changes were getting too big. I decided to merge what I have to master and make smaller changes from here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants