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

add a button to unassign vrm model #948

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

lamystere
Copy link

Currently there is no way to remove a vrm model once one is loaded.

@Erimelowo
Copy link
Member

Why do you want a way to unassign VRM models? There should not be any advantage to not having one loaded.

@lamystere
Copy link
Author

lamystere commented Feb 27, 2024

Why do you want a way to unassign VRM models? There should not be any advantage to not having one loaded.

I was not able to switch to a different VRM model once one was loaded. It turned out slime was rejecting the vrm but this wasn't apparent since no error was shown in the gui or logs. Later I made updates to a VRM but slime doesn't seem to reload a file if the same path is submitted. Also when loading files with the same title (many are "untitled" or could be different revisions) it was not apparent whether the file had updated since the title flashes regardless if there's an error or not. Being able to clear the model would bring clarity to all of these minor annoyances. Editing the YML directly was the only way I could be sure a new VRM model was being loaded. One final very insignificant benefit is that the model json can take up a disproportionate amount of space in the settings YML, which might make sharing and troubleshooting it easier.

Side thought: If there's truly no reason to have a model unassigned, then why not have a default VRM model loaded from the start?

Another side thought: Sorry I thought I had linting set up correctly in vscode. I'll update that so the lint check passes soon.

@Erimelowo
Copy link
Member

if your problem is that you somehow can’t assign a new model normally, that should be fixed directly. Not by having this workaround of removing a model before reassigning a new one.

and there’s no default VRM model assigned because VRM models don’t all have the same bone lengths :p

@lamystere
Copy link
Author

if your problem is that you somehow can’t assign a new model normally, that should be fixed directly. Not by having this workaround of removing a model before reassigning a new one.

My point wasn't VRM issues, that was just an example story to highlight that it can be confusing, even for technical users, because the GUI is not informative. A button provides additional insight. The gui currently does not signal the success or failure of loading a new model. This can't always be inferred by the title changing. The CSS flash of the title provides a false sense of success since it happens regardless.

@Erimelowo
Copy link
Member

So the issue is that there's no validation of the VRM model to decide if the title should flash or not?
Why not just do that, and show an error message if the validation fails?

@lamystere
Copy link
Author

So the issue is that there's no validation of the VRM model to decide if the title should flash or not? Why not just do that, and show an error message if the validation fails?

That makes sense also. It just seems strange to me as a workflow to be able to add something but not remove it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants