-
Notifications
You must be signed in to change notification settings - Fork 18
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
Blocks don't correctly apply their instance transforms when exported #80
Comments
Hi, this can be fixed by changing this line:
to
But ideally it would be great if it supported instancing, to not duplicate the geometry of the blocks in the glTF file. |
Instancing support can be added without making any large changes using a dictionary similar to how you reuse materials, with the rhino object's id as the key and the mesh index returned by I added this to my fork here: |
This issue has been fixed in the glTF-IO project I need to update the README here saying primary development is occurring over on McNeels fork |
Thanks, looks like you moved there recently, after I forked this repo. Instancing would indeed need to be more complicated if you want to preserve the nested block structure. In our case we just need the size reduction and performance of reusing buffers for the same objects. So this method is like if you exploded the blocks but then for each unique object you created a block that contains only that object. Not having all roots at the origin should also help improve the quantization step of compression (as long as the block geometry wasn't accidentally created far away from the origin and the instances are moving it closer). |
I'll see if I can cherry pick commits, the main problem is that I have made changes you don't want in the project (see #81), so have to be careful not to commit those. Another thing, not very important but, found the code doesn't follow consistent formatting style (for example, some if statements have a space before the parenthesis and some don't) and the default auto-formatting changes too many lines that wouldn't want to include in a commit. |
Btw, I also changed it so that the geometry is always stored in meters, no matter the units used in the Rhino document. This is to follow the gltf spec, but also has other advantages if you can assume the gltf files are always in meters. |
The repo at the McNeel org doesn't have issues enabled, would be great if it did. I'd like to comment why the code for |
Yes, the formatting is an issue, not just with this but across the board at McNeel. I've been fixing the indenting as I modify the files but I'm usually pretty hesitant to blow out all the git history in one go. The meters suggestion is a good point. I should probably add that as a export since some use cases may want something modeled small to appear large. I enabled issues in glTF-IO repository. If you open an issue in glTF-IO about the glTFLoader I can explain the choice there. One improvement is to make the glTF-IO have two sets of projects. The first configured for the Rhino build and the second configured so users can build and debug. |
@visose Is your fork still shareable? I was also expecting block instances to come through as node instances of a single mesh. |
https://discourse.mcneel.com/t/block-location-was-incorrect-after-convert-to-gltf/147856
The text was updated successfully, but these errors were encountered: