ParaQ Applications: Difference between revisions
No edit summary |
No edit summary |
||
| Line 7: | Line 7: | ||
=== GeoViz Component === | === GeoViz Component === | ||
[[Image:Geoviz.png|thumb|left]] | <table> | ||
<tr> | |||
<td>[[Image:Geoviz.png|thumb|left]]</td> | |||
<td> | |||
"GeoViz", a set of VTK-derived classes created at Sandia, linked into a "vanilla" pqClient as a "component". There is a low level of integration in this example, since the GeoViz component encapsulates a separate, client-side-only pipeline that is independent of the ParaView Server layer. The next step is to get the GeoViz classes accepted into VTK so that the GeoViz view can be implemented in PVS, possibly as a compound filter. This suggests that the GeoViz "component" may ultimately be some combination of a factory method that adds a subgraph to the PVS, plus a user-interface component (i.e. a custom property sheet) that is designed to interact with the subgraph. | "GeoViz", a set of VTK-derived classes created at Sandia, linked into a "vanilla" pqClient as a "component". There is a low level of integration in this example, since the GeoViz component encapsulates a separate, client-side-only pipeline that is independent of the ParaView Server layer. The next step is to get the GeoViz classes accepted into VTK so that the GeoViz view can be implemented in PVS, possibly as a compound filter. This suggests that the GeoViz "component" may ultimately be some combination of a factory method that adds a subgraph to the PVS, plus a user-interface component (i.e. a custom property sheet) that is designed to interact with the subgraph. | ||
</td> | |||
</tr> | |||
</table> | |||
=== FluView === | === FluView === | ||
[[Image:Fluview.png|thumb|left]] | <table> | ||
<tr> | |||
<td>[[Image:Fluview.png|thumb|left]]</td> | |||
<td> | |||
A more realistic sample application using the GeoViz component (the data was randomly-generated). As before, the current iteration of the GeoViz component is unrealistically simple, since it is made of client-side VTK classes. This example does highlight the need for coordination between components - the intent is to tie the two GeoViz views together using some sort of linking or custom interactors. There is also an interesting performance issue, the app takes a long time to load, since there are two instances of the GeoViz component (and thus two instances of the 27 megabyte "blue marble" texture) to be loaded. These two instances should share the same input texture, which will have an impact on their ultimate incarnations as PVS graphs. The GeoViz component could leave-out the input reader altogether, and expose an API to allow it to be connected, or the factory function might be made more complex, allowing a "default" reader to be overridden externally. | A more realistic sample application using the GeoViz component (the data was randomly-generated). As before, the current iteration of the GeoViz component is unrealistically simple, since it is made of client-side VTK classes. This example does highlight the need for coordination between components - the intent is to tie the two GeoViz views together using some sort of linking or custom interactors. There is also an interesting performance issue, the app takes a long time to load, since there are two instances of the GeoViz component (and thus two instances of the 27 megabyte "blue marble" texture) to be loaded. These two instances should share the same input texture, which will have an impact on their ultimate incarnations as PVS graphs. The GeoViz component could leave-out the input reader altogether, and expose an API to allow it to be connected, or the factory function might be made more complex, allowing a "default" reader to be overridden externally. | ||
</td> | |||
</tr> | |||
</table> | |||
Revision as of 16:29, 13 February 2006
Overview
Following are a collection of screenshots, issues, and ideas raised in conjunction with a set of prototype "applications" built on the ParaQ framework. The goal is to explore what it means to build an application using ParaQ - does an application merely link with the ParaQ libraries, or is there some deeper level of integration? Is an application a separate executable, a dynamically-loaded plugin that reconfigures the user interface, or something else?
Prototypes
GeoViz Component
|
"GeoViz", a set of VTK-derived classes created at Sandia, linked into a "vanilla" pqClient as a "component". There is a low level of integration in this example, since the GeoViz component encapsulates a separate, client-side-only pipeline that is independent of the ParaView Server layer. The next step is to get the GeoViz classes accepted into VTK so that the GeoViz view can be implemented in PVS, possibly as a compound filter. This suggests that the GeoViz "component" may ultimately be some combination of a factory method that adds a subgraph to the PVS, plus a user-interface component (i.e. a custom property sheet) that is designed to interact with the subgraph. |
FluView
|
A more realistic sample application using the GeoViz component (the data was randomly-generated). As before, the current iteration of the GeoViz component is unrealistically simple, since it is made of client-side VTK classes. This example does highlight the need for coordination between components - the intent is to tie the two GeoViz views together using some sort of linking or custom interactors. There is also an interesting performance issue, the app takes a long time to load, since there are two instances of the GeoViz component (and thus two instances of the 27 megabyte "blue marble" texture) to be loaded. These two instances should share the same input texture, which will have an impact on their ultimate incarnations as PVS graphs. The GeoViz component could leave-out the input reader altogether, and expose an API to allow it to be connected, or the factory function might be made more complex, allowing a "default" reader to be overridden externally. |
