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

Introduce ScaledTriMesh shape #36

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Ralith
Copy link
Contributor

@Ralith Ralith commented Jun 10, 2021

Allows reuse of collision geometry between scaled objects, e.g. encoded in a GLTF file.

I think this change is more or less complete, albeit untested, but I'd like to discuss some questions before moving forwards:

  • Should the transformation be more general? Translation/rotation can be expressed elsewhere, but maybe someone wants to skew? GLTF at least doesn't support anything beyond translation + rotation + nonuniform scaling, but there's not much downside to an arbitrary transform matrix here.
  • Should the transformation be less general? Uniform scaling could in theory allow sharing of the quadtree, as well as the actual geometry, although this would require additional refactoring to realize, likely involving changes to QBVH and perhaps its existing users. Losing support for some cases of GLTF is a shame, but maybe nobody uses nonuniform scaling much in practice?
  • Is any of this worth the extra code? Downstream code can always just make another TriMesh with whatever vertices it likes. Collision geometry usually isn't that big, especially for repeated objects. The composite shape abstraction makes the implementation pretty concise, but even so...

@Ralith Ralith force-pushed the scaled-trimesh branch 2 times, most recently from 5a7aa0f to c44f26c Compare June 10, 2021 00:42
@MOZGIII
Copy link

MOZGIII commented Aug 23, 2021

Can we merge this?

@Ralith
Copy link
Contributor Author

Ralith commented Aug 23, 2021

It should be tested first, and I'd like to see the discussion points addressed. Especially given that the QBVH isn't shared, I'm not sure it's worth the trouble vs. just duplicating geometry as needed.

@Jasper-Bekkers
Copy link

Should the transformation be more general? Translation/rotation can be expressed elsewhere, but maybe someone wants to skew? GLTF at least doesn't support anything beyond translation + rotation + nonuniform scaling, but there's not much downside to an arbitrary transform matrix here.

My usecase is exactly this, our data comes from regular gltf files and so we inherit their transforms and need to pass those onto runtime systems like the physics system. Switching to uniforrm scaling wouldn't help us.

Is any of this worth the extra code? Downstream code can always just make another TriMesh with whatever vertices it likes. Collision geometry usually isn't that big, especially for repeated objects. The composite shape abstraction makes the implementation pretty concise, but even so...

We're actually running into this - having to runtime duplicate triangle data just to get a scaled clone of the TriMesh, having this upstreamed / merged would benefit us for sure.

@Ralith
Copy link
Contributor Author

Ralith commented Jan 27, 2023

We're actually running into this - having to runtime duplicate triangle data just to get a scaled clone of the TriMesh

The question is, is doing that duplication causing you any concrete problems?

@Jasper-Bekkers
Copy link

We're actually running into this - having to runtime duplicate triangle data just to get a scaled clone of the TriMesh

The question is, is doing that duplication causing you any concrete problems?

Yes. We have transforms changing at runtime, including scale. It's both CPU and memory overhead we want to avoid.

@Jasper-Bekkers
Copy link

Any update on this?

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