Skip to content

Conversation

@JoshuaMKW
Copy link
Contributor

This would be useful to have for fast selection support amongst other potential utilities so I've added a simple calculation for it.

JoshuaMKW and others added 9 commits January 17, 2024 19:42
This reverts commit 58c4e7a.
Seems like a case of a platorm-dependent recursive include getting
what is needed from atomic on windows, but not on different implementations.
Include <atomic> in a few places to get this to build on Linux
@Sage-of-Mirrors
Copy link
Owner

Hey, apologies for not getting back to this for so long. Is this still something you would like to contribute?

@JoshuaMKW
Copy link
Contributor Author

Hey, apologies for not getting back to this for so long. Is this still something you would like to contribute?

I think it is a useful thing to expose through API for various reasons, the most obvious one being a form of determining user selection (I'm of course aware that J3DUltra supports pixel perfect selection nonetheless). Another useful application this could provide is a collision approximator to filter out bogus interactions before doing more exotic collision detection by e.g. a .col model.

So yes, I think it'd be within the interests of J3DUltra to merge this and support the feature.

@LagoLunatic
Copy link
Contributor

Does this implementation currently support adjusting vertex positions for the joints they're rigged to? Or are only unrigged models supported?

I currently do a hack to try to estimate a model's visual bounding box automatically by looking at vertex positions, but vertexes that are rigged to only a single joint being stored as relative to the origin makes this pretty inaccurate a lot of the time. If J3DUltra had a proper implementation that took this into account it would be very useful.

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.

4 participants