- 
                Notifications
    
You must be signed in to change notification settings  - Fork 408
 
Fix cmake rebuild for MaterialXRenderGlsl. Fix PyTinyObjectLoader.load. #2619
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
base: main
Are you sure you want to change the base?
Conversation
…t adding files from now on but that is normal. Fix PyTinyObjLoader.load so that it returns meshes instead of not returning meshes.
| 
           
 
  | 
    
There was a problem hiding this 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); | 
There was a problem hiding this comment.
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)There was a problem hiding this comment.
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.
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.