I’m in love with the ray tracing capabilities in v5.7, but I am having an issue with the screenshot saving workflow. Basically, the problem is that to save a screenshot Paraview seems to require rendering the scene four times.
Actually making the rendering prior to trying to save a screenshot.
Another one when the window regarding the filename choice for the screenshot pops up.
One more when choosing the properties, like resolution and compression type.
A final one when the screenshot is actually saved.
This becomes a problem when I am raytracing the scene, which can take, let’s say, half an hour or an hour.
Is there a way to reduce the number of renderings?
Ah! Good point. We added the renders in Save Screenshot dialog to ensure that the user is seeing the results on screen for changes like border color etc. We cleary missed this case. While we could try to avoid #3, it’s not clear to me how we can avoid the others.
For now, the only workaround I can think of is using Python shell to use SaveScreenshot to save the screenshot that way.
@utkarsh.ayachit Additionally, we could add a settings option to not do render 2 or 3. I believe that the filename popup goes on top, thus doesn’t need a redraw. 3 (properties) goes right on top of 2. If it looks really poor, we could just clear the screen for 2 and 3.
I am not sure anyone would end up changing these, or even know that they exist. We already have too many settings :).
That is not correct. We have not re-rendered following popups since several releases now. This happens because, when the dialog is popped up, ParaView hides window decorations aka enters preview mode. This is done so the user sees the real aspect ration of the views otherwise annotations etc. may move around unexpectedly.
The whole point of 2 and 3 is to support WYSIWYG as much as possible. We had whole slew of complaints when that was not the case.
In general, rendering should not be several minutes slow except when using ray-tracing since the realism can add up runtime costs very quickly. Maybe we do low-res renders (or something like that) in that case. @Dave_DeMarle, thoughts?
There are a couple of related issues to tackle regarding saving images and ray tracing in interactive uses. Most important is the poor interaction of progressive rendering with accumulation and image stitching for saving bigger images than currently on screen. When we get a chance to solve those we’ll think hard about the preview mode.
