-
-
Notifications
You must be signed in to change notification settings - Fork 35.5k
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
JSONLoader binds duplicate of all geometry to first bone #8261
Comments
This is still an issue, but I've found an ok workaround. Since the duplicated geometry always gets assigned the default lambert shader that is always included when using the Maya Exporter. As long as all the objects that are intended to be kept have a material other than the default in Maya, you can insert
into the loader code which will make any material with the default lambert invisible. |
Hmm, this goes a little bit over my head at the moment... |
hello,are you Ok? |
Hello @evantron3000 I wanted to have a look into this issue if it is still necessary. Is it possible to provide an update link of the resource you are trying to load ? The link in your fiddle is now a dead link. I also want to check if it is still an issue in r85. Thanks |
The Maya exporter was removed with #13145 I suggest to export your model as |
It looks like when using the JSONLoader in r74, the first named bone in an exported Maya scene gets a duplicate of all the geometry.
Here's a JSFiddle that shows my current code and the issue.
In this example I have 2 boxes. Each box is bound to a single bone, and each of those bones has keyframes that animate the position and rotation. There is another bone that has no geometry bound to it, and has keyframes that make no change to its position or rotation.
The stationary bone is called "joint1" in Maya. The bones that actually have geometry bound to them are called "joint2" and "joint3". If I were to rename the stationary bone "joint4" the result would be a duplicate of both boxes attached to the currently animating "joint2".
The text was updated successfully, but these errors were encountered: