Skip to content

Conversation

@Javantea
Copy link

You need to take care about adding files from now on but that is normal.
Fix PyTinyObjLoader.load so that it returns meshes instead of not returning meshes.
These are the first patches toward getting Python rendering working which should be a lot of fun.

…t adding files from now on but that is normal.

Fix PyTinyObjLoader.load so that it returns meshes instead of not returning meshes.
@linux-foundation-easycla
Copy link

linux-foundation-easycla bot commented Oct 14, 2025

CLA Signed
The committers listed above are authorized under a signed CLA.

  • ✅ login: Javantea / name: Javantea (24be91e)

Copy link
Contributor

@kwokcb kwokcb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have left a comment about what I think the base issue which is the referenced mesh list is not being updated without changing the existing signature.

It is possible to add a new signature to return a Python list of Meshes but this should be additive in the base class wrapper.

.def_static("create", &mx::TinyObjLoader::create)
.def(py::init<>())
.def("load", &mx::TinyObjLoader::load);
.def("load", &load_meshes_wrapper_tuple);
Copy link
Contributor

@kwokcb kwokcb Oct 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm guessing this is an attempt to fix that the meshlist is not being updated since it's a referenced shared point list ? We should not change an existing signature to handle this.

I think the easiest fix in this case is to expose Python wrapper for MeshList in PyMesh.cpp. e.g:
py::bind_vector<mx::MeshList>(mod, "MeshList");
I think this was just a oversight.

As "load" in in the base class Python wrapper I think these derived class "load"s can be removed as well. There is one for CgltfLoader as well as TinyObjLoader.

Any new / user defined Python derived loaders will would also work properly.

To test this, the workflow of adding loaders to a handler should also be tested. There load and get are separated into two different methods. (BTW, Working via a handler is the desired pattern to follow to allow per loader extension handling.)

It would be good to have a unit test for this as well. e.g. of handler workflow:

import MaterialX as mx
import MaterialX.PyMaterialXRender as mxr

# Test obj, gltf should also be tested
location = "./resources/Geometry/plane.obj"
meshlist = [] # This would create a Python wrapper MeshList instead.
flipUVs = False

cgltf = mxr.CgltfLoader.create()
objl = mxr.TinyObjLoader.create()
# Individua loader test
loaded = objl.load(location, meshlist, flipUVs)

handler = mxr.GeometryHandler.create()
handler.addLoader(cgltf)
handler.addLoader(objl)

loaded = handler.loadGeometry(location, flipUVs)
handler.getGeoemetry(meshlist, location)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll give that a try. I'm much more flexible in changing signature when it is necessary but you have figured out what I could not on MeshList. Thanks for your help in looking at this issue that was blocking rendering in python (which is now working I might add, with a few more changes which will be coming soon). I like the idea of a unit test for this behavior.

@jstone-lucasfilm
Copy link
Member

Thanks for taking this work forward, @Javantea and @kwokcb, and indeed the idea of MaterialX rendering from Python is exciting!

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

Successfully merging this pull request may close these issues.

3 participants