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

ScreenShooter improvements #442

Open
schulzch opened this issue Sep 5, 2019 · 16 comments
Open

ScreenShooter improvements #442

schulzch opened this issue Sep 5, 2019 · 16 comments
Assignees

Comments

@schulzch
Copy link
Member

schulzch commented Sep 5, 2019

IMHO, the ScreenShooter module has several design and usability quirks. In the following I will try to list a few issues and possible solutions:

Relation to the graph

The module is disconnected from the rest of the graph and requires a "view"-param to be set. This leads to some trickery in terms of code and usablity

One solution would be to convert the module to a View, so that it is very clear which parts of graph are recorded, i.e., everything to the right.

ALT+PRINT screenshots are "faster" sometimes

If code runs slow, the GUI becomes really difficult to use below 15FPS. In those cases ALT+PRINT becomes more usable than the ScreenShooter, i.e., ALT+PRINT -> Paint -> Save As is faster than searching for ScreenShooter::filename -> edit path ->ScreenShooter::trigger.

An easy fix would be to split "trigger" into "Save" and "Save As", and open a dialog respectively. See tiny file dialogs. Problem with <1FPS screenshots remain unsolved - this would probably require threading and caching.

External triggering and animation

Some modules and plugins (ask @straubar and @braunms) want to trigger screenshots externally, either for recording animations or for recording during rendering (partially solved by making this thing a View?). It would be nice if there is only "one solution" to do this in terms of code.

@braunms
Copy link
Contributor

braunms commented Sep 5, 2019

Related issue #441

@straubar
Copy link
Member

My suggestion would also be to make the ScreenShooter a view. This makes it much more intuitive and at the same time gets rid of those evil render hooks. Additionally, giving the ScreenShooter view an additional input which offers another module a callback function to trigger the recording of a screenshot, would allow us to put all functionality into a single module.

As to the issue of changing the filename, I would add parameters to the ScreenShooter that allow for a continuous numbering of output files to prevent overwriting. This also makes editing the filename field at runtime superfluous for most cases.

@geringsj
Copy link
Contributor

The ScreenShooter will be obsolete with the screenshot capabilities in the new megamol.exe frontend introduced by PR #561 accompanied by screenshot-trigger integration via Lua and GUI.

Feature and backwards compatibility requests should go to #641.

@geringsj geringsj mentioned this issue Oct 29, 2020
25 tasks
@pramathe
Copy link

pramathe commented Feb 15, 2021

I've encountered several problems, when I wanted to produce a screenshot series:

  1. Trigger screenshot service via *.lua file - produce a screenshot series
    With hint of @reinago I've added a loop at the end of the *.lua file, see here:
    phase_sep_test_3.txt

The data can be found here:
[edit: Removed path to internal filesystem.]

The first screenshot is okay - but showing the menu bar:
coal8 0000

The 2nd screenshot doesnt show my particles any more, but Log Console and Parameter gui came up again:
coal8 0001

  1. Hiding: Menu bar, Parameter GUI, Log console
    How to force hiding all stuff I dont want to see on the screenshot via *.lua file?

  2. truncated png files
    The png files written by screenshot service are truncated.

  3. Resolution
    @gralkapk said that actually the only way to specify resolution of the screenshot is by window size in file: megamolconfig.lua
    But this seems to have no effect. I have a screen with resolution: 3440 x 1440 (21:9)
    I've set the following in megamolconfig.lua:
    mmSetConfigValue("*-window", "x5y35w1920h1080")
    The written png files had a resolution of 2580 x 1080

  4. OSPRay renderer does not wait for accumulation to finish
    The screenshot service doesnt wait for OSPRay renderer to finish accumulation. If I want high quality pictures I have to increase the value of parameter:
    mmSetParamValue("::OSPRayRenderer_2::SamplesPerPixel",[=[8]=])
    But this dramatically increase cpu resources and hence the time until rendering finished

@braunms
Copy link
Contributor

braunms commented Feb 15, 2021

Hi, concerning your second point:
You can prevent the LogConsole window to pop up on errors and warnings by disabling the option "Force Open" in the menu of the Log Console window.
You can hide all GUI windows by starting your project and then hide all windows and the menu via the "Windows"-menu. Then save your project including the GUI state (see option "Save GUI State" in file dialog above "Save" button)!

@geringsj
Copy link
Contributor

  1. Resolution
    @gralkapk said that actually the only way to specify resolution of the screenshot is by window size in file: megamolconfig.lua
    But this seems to have no effect. I have a screen with resolution: 3440 x 1440 (21:9)
    I've set the following in megamolconfig.lua:
    mmSetConfigValue("*-window", "x5y35w1920h1080")
    The written png files had a resolution of 2580 x 1080

mmSetConfigValue semantics are a mmconsole feature that is not yet supported by megamol.exe.
Porting of mmconsole config files is in the works. Window resolution can be set via CLI on startup or via mmSetFramebufferSize in a Lua script.

@pramathe
Copy link

Window resolution can be set via CLI on startup or via mmSetFramebufferSize in a Lua script

Thanks for the hint! Can you pls give an example?

@braunms braunms self-assigned this Feb 15, 2021
@pramathe
Copy link

your project including the GUI state (see option "Save GUI State" in file dialog above "Save" button)!

Aaah, okay. I was not aware of the option "Save GUI State", and therefore missed this information in my saved project file. Thanks!

@braunms
Copy link
Contributor

braunms commented Feb 15, 2021

@pramathe Just for clarification: Do you start MegaMol using megamol.exe or do you use mmconsole.exe?

@pramathe
Copy link

@pramathe Just for clarification: Do you start MegaMol using megamol.exe or do you use mmconsole.exe?

I use megamol.sh, so megamol.exe

@geringsj
Copy link
Contributor

Thanks for the hint! Can you pls give an example?

CLI: --window wxh+x+y, e.g. ./megamol.sh --window 100x100 for a window of size 100 x 100 pixels. also see ./megamol.sh -h

Lua: mmSetFramebufferSize(width, height), e.g. mmSetFramebufferSize(100, 100).

@pramathe
Copy link

Thanks for the examples!
On Ubuntu 20.04 I tried: mmSetFramebufferSize(1920,1080) and ended up with this error:

1|OpenGL_GLFW_Service: WindowManipulation::set_framebuffer_size() could not enforce window size to achieve requested framebuffer size of w: 1920, h: 1080.
Framebuffer has size w: 2580, h: 1080
Requesting shutdown.
1|OpenGL_GLFW_Service: WindowManipulation::set_framebuffer_size() could not enforce window size to achieve requested framebuffer size of w: 1920, h: 1080.
Framebuffer has size w: 2580, h: 1080
Requesting shutdown.

@pramathe
Copy link

But CLI option works fine!

@geringsj
Copy link
Contributor

Ping @moritz-h for Linux GLFW support

@geringsj
Copy link
Contributor

2. truncated png files
   The png files written by screenshot service are truncated.

Can you provide one such truncated screenshot file, maybe with a screenshot of the corresponding MegaMol window? It would also be helpful to have a minimal Lua project example to reproduce this.

@pramathe
Copy link

Under the following link you can find a *.lua file, a small test data set, a screenshot of my megamol window, and two truncated png files generated by the screenshooter service:
https://tubcloud.tu-berlin.de/s/dca4aoNaLFy9sBz

I launched megamol on Ubuntu 20.04 by the following command:
./megamol.sh --window 1920x1080 mmpld_save.lua

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

No branches or pull requests

5 participants