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

Export current scene as mp4 #38

Closed
bhoov opened this issue Oct 27, 2024 · 5 comments · Fixed by #89
Closed

Export current scene as mp4 #38

bhoov opened this issue Oct 27, 2024 · 5 comments · Fixed by #89
Assignees

Comments

@bhoov
Copy link
Collaborator

bhoov commented Oct 27, 2024

We are very close to a full pipeline for Manim development. Crucially, we are missing the final step of actually exporting a scene as an e.g., mp4 of some quality (a thought I came up with as I was writing the "sales pitch demo" #37 for this extension)

At the minimum, we want to expose a command that lets users choose the following from the manimgl tool:

  1. Image quality (low, med, hd, uhd)
  2. fps

(happy to discuss more advanced options like Gif?, Transparent?, background color?, etc., but I was hoping to appeal to the broadest user that would care about the quality of the mp4 they were generating)

Finally, let the user choose which file to save the output video to

@Splines
Copy link
Member

Splines commented Oct 27, 2024

UI: File picker

For the file picker, see this API. We could use that to let users specify a location where to save their file.

UI: Trigger export

Users somehow have to trigger the export command. Invoking it from the command palette is probably not the best choice.

  • For the export, I could imagine a gutter icon (similar to the breakpoint) showing on lines where the class is started, e.g. class MyScene(Scene):. Unfortunately, the VSCode issue for on click events on the gutter icon was closed without a solution. The new issue to track this is here. In the meantime, there's also the option to provide a Export scene to the context menu that appears when you right-click on the line numbers or the area where the breakpoints live. See the contribution menus (editor/lineNumber/context).
  • Another option for how to realize the export in the UI would be to show a codelens over classes, e.g. like we do right now with Preview Manim Cell.
  • Manim scene detection: Just checking for inheritance of Scene or InteractiveScene is not sufficient, see my comment here.

UI: Define settings for export

Users could define settings in a multi-step quick pick. If that gets too long, we might want to use a custom webview view even if that is discouraged by VSCode. But they don't specify what you should use instead then since they also advise against using multi step quick picks to create wizards (see my comment). And in the Webview UI toolkit there are some nice elements that we could use like a dropdowns, checkboxes etc.

@Splines
Copy link
Member

Splines commented Oct 28, 2024

Maybe you could also vote for this issue at VSCode since they look for issues with high votes to organize their backlog. I think it'd be really cool to be able to use onClick events for gutter icons. With this we could add buttons like the "debug button" as envisioned by bhoov here.

@Splines
Copy link
Member

Splines commented Nov 2, 2024

(happy to discuss more advanced options like Gif?, Transparent?, background color?, etc., but I was hoping to appeal to the broadest user that would care about the quality of the mp4 they were generating)

After just revisiting this again: Yes, I think it'd be cool to have a general feature for export. But it's probably really tedious if we want to support every option that manimgl supports for export. And then in the future, other options might be added.

So what do you think about this approach: provide a very basic UI where the most important settings (image quality and fps) can be set. Then, let the user click on a button like Generate command that will open a new terminal and in it just paste the command. The user can then press enter to export the scene.

This approach has some advantages:

  • Even if manimgl supports more flags in the future, users might just append them at the time they have generated the very basic command. The main advantage I see with our UI is that users will be able to select the output file location from a file browser (which is sometimes tedious to do in the shell).
  • We save ourselves some (or a lot of) work compared to also implementing the export progress notification and parsing the output for this again. This is just an advantage from the dev perspective and should have the least weight (but then of course we're just a small team, which should also be taken into account).

So far I was always pro-UI à la "Let us support a terminal-free workflow". But totally terminal-free is unrealistic I guess. Users will have to interact with it anyways:

  • see Manim error messages
  • Interactively try things out in the IPython shell, e.g. see if a Python snippet works.

And for the export, I actually see the advantages of the terminal as being very flexible and giving the power to the user. But of course, maybe I'm just making up an excuse to not implement all the shell parsing ;)

Let me know what you think. I just want to avoid the situation where we get PRs like "Add this or that as export option", which would be a bit annoying IMHO as I'd rather invest my time in getting the core things right, which is the preview itself (and niceties centered around it). Maybe we should then develop a policy, e.g. that we close such PRs because we only support image quality and fps via the UI.

@bhoov
Copy link
Collaborator Author

bhoov commented Nov 11, 2024

I fully approve this workflow. It is more than sufficient for a v0.1.0 release.

If we wanted to get fancy down the road, we could automatically parse the manimgl --help docstring to populate the checkboxes (which would help solve your fears of PRs like "Add this or that as export option"), but most options would need to hide behind an "advanced options" dropdown: they do not add to the simple experience we want to create.

@Splines Splines self-assigned this Nov 13, 2024
@Splines
Copy link
Member

Splines commented Nov 17, 2024

we could automatically parse the manimgl --help docstring to populate the checkboxes

Ah, good idea haven't thought about that. However, in the end it's not as easy as just populating checkboxes based on this. Every single step needs custom validation and custom tuning, e.g. sometimes allow users to input a number greater than x, sometimes a number in a range, sometimes with decimals, sometimes without, sometimes allow a string with a dot in the end, sometimes not, sometimes add a custom validation text, sometimes enable/disable a step based on a previous input etc.

That's just to say that every new option we would like to add there needs custom care and maintenance efforts. I just don't want to spend too much time on this and tailor to every user and every obscure export setting that Manim might offer. The few essential ones like quality and fps, yes, but I don't envisage to expand on this in any way ;) Users still have the option to add their custom flags in the terminal in the pasted command.

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

Successfully merging a pull request may close this issue.

2 participants