-
Notifications
You must be signed in to change notification settings - Fork 16
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
Add Smith2018ArticularContactForce
and Smith2018ContactMesh
as extension components
#884
Comments
02f1e94 is related to this issue (forgot to tag it) |
adamkewley
added a commit
that referenced
this issue
Jun 13, 2024
Verified with @sabrinahoermann that this is now capable of editing the relevant models. I'll add some basic tests to ensure they stay in and then close this. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Reported by @sabrinahoermann
She's making/editing a model that's related to this repository from @clnsmith:
And that, internally, uses
jam-plugin
(in binary form), from here:Which isn't loadable in OpenSim Creator, because OSC is built from source on Windows/Mac/Linux from a not-necessarily-release version of OpenSim (binary plugins typically are only guaranteed to work with a specific version of OpenSim).
The proposed fix for this is to add the source code for the jam plugins directly into OpenSim Creator as "extension" or "non-standard" OpenSim components. This will mean that any
.osim
files in the wild that happen to use those components will work in OpenSim Creator without having to support a plugin architecture.The reason why OpenSim Creator doesn't support plugin loading (and, imo, shouldn't) is because OpenSim isn't necessarily ABI-stable over time (only API-stable). It's very hard to maintain a binary plugin architecture across multiple platforms, architectures, etc. - even modern language platforms resort to shipping source code that's compiled on the target machine (which would be hard for us, because I really don't want to ship a C++ compiler alongside OSC).
If users desire a long-term plugin architecture then I would recommend someone develops one in (e.g.) python, so that application builders don't have to worry about porting every plugin to every native architecture.
The text was updated successfully, but these errors were encountered: