Better unifying paraview and catalyst scripts will certainly eliminate an existing stumbling block and make testing and prototyping much easier.
Minor historical note for those exciting Trivial Pursuit Paraview edition games - the Catalyst portion of the current Exporter Panel arrived in 5.6. General exports were added in 5.7.
Final note, it would be good to build in a degree of separation between triggers and specific data products. Sure you will still be able to put a conditional and a special case code path into the generated catalyst script but that code might not be able to reuse the new infrastructure to inherit the nice new triggers and run modes.
Can you elaborate please? I am not sure I follow. Note, in this design triggers and data writers are indeed totally separate things. Digging in the details, an extract generator proxy has two separate proxy-properties, one for Trigger and one for Writer. Currently, I only one type of Trigger proxy, “Time”. The plan would be add support for more types in the future. Once we have more trigger proxy types, using a different trigger would be as easy as picking a different value for the “Trigger” property using a combo-box.
Good that will at least be a sufficient starting point for what I am thinking.
I’m coming at it from the angle of In Situ processing for irregular patterns. The simplest one being the longstanding “Do not do anything for the first N frames because the simulation output hasn’t changed from from the initial conditions. After that, do all of these exports.” More general ones are, “Don’t export anything unless foo happens. If it doesn’t happen, then the simulation setup happened to be uninteresting.” Or, “Now that foo happened, export these cached results and start exporting new results like so”.
If triggers were going to be tied tightly to individual writers, it wouldn’t be easy to implement these, especially in the case where you are extracting within a GUI session where scripting is secondary.
The design does not preclude programmable / Python triggers. You’d be able to use those once supported to add more complex types of triggers.
If triggers were going to be tied tightly to individual writers
Note there are triggers associated with individual extract-generators. At the same time, when you are saving a Catalyst script, you’re presented with a dialog that lets you set up global trigger params (see Generate Catalyst Script Options in the original post). Individual triggers are secondary to global trigger. The global trigger is evaluated first and it’s an easy way to control whether any of the extract generators are executed irrespective of individual settings.
In theory, yes. In practice, we encounter this issue with the current implementation. There will be some fine-tuning needed to enable updating extract generators from a Live session in the GUI. We can do that in a following iteration. I don’t think it’s going to be complicated.
Yeah, the view extracts are awkward. I guess you could show them at the same level as sources (same hack we use for fan-in).
That does not bother me. You won’t have these “by-standers” unless you specifically add them, so having these mostly passive pipeline objects shouldn’t be too confusing. And the “prime real-estate” they are taking up is a lot less than an entire new panel. From a GUI footprint perspective, integrating with the Pipeline Browser is the smallest impact we can do.
I don’t see the issue of having a sink in the pipeline that nothing can connect to. It just has no eyeball and all filters (and other extracts) are grayed-out when one is selected. That is pretty consistent with the rest of the GUI.
I don’t think the comparison between extracts and representations is a good one. Representations are the glue between a pipeline object and a view. They are an implementation detail that user’s don’t have to deal with (unless they dive into scripting). I don’t think the GUI considerations between the two match very well.
Good points. I think I am warming up to the idea. That does gracefully solve the issue mentioned earlier. Having a separate Extract Generators menu next to Sources, Filters also makes it easily discoverable rather than being hidden under some panel.
Okay, I’m sold! I’ll need to revisit some of the implementation but shouldn’t be too complicated.
Based on @Kenneth_Moreland’s suggestion, we should be able to easily update screenshot params from Live. In addition, we can just as easily add a “generate extracts now” button that works in “live” mode too where you can generate all (or selected) extracts for the current timestep irrespective of the settings on the extract generators.
I was actually thinking related to the views more than the Properties panel. I supposed there isn’t any state with the image output though so maybe it’s not relevant, at least for the exporter. For a Live connection though would it just deliver the images that are being produced or would it actually do something with the render view?
Now that I think about it, should there be the concept of locking a view based on the screenshot output? That may be too much for users but I’m concerned about setting the screenshot output, then modifying the view and finally exporting a script and the user not realizing that the screenshot isn’t what they intended. Maybe a thumbnail of the screenshot as a last second check during the export step could alleviate that? Just spit-balling here really fast without thinking this through too much, and not considering the work involved…
For a Live connection though would it just deliver the images that are being produced or would it actually do something with the render view?
In this pass, don’t think I’ll add support for viewing extracts generated in a Live session; only add ability to edit params for the extract generators in a Live session. We could indeed think of ways of supporting that, but that probably warrants its own discussion thread.
Now that I think about it, should there be the concept of locking a view based on the screenshot output?
+1…something that integrates with Preview mode would be good.
Maybe a thumbnail of the screenshot as a last second check during the export step could alleviate that?
One can use Generate Extracts Now or save Catalyst script and run using pvbatch to confirm that the extracts generated are as expected before doing an in situ run.
