Visualization Working Group
To Do List as of 31 January 2008.
Extend 2D Drawing Capabilities.
Allow more primitives to be placed in 2D space.
Useful for presenting color scales, legends, etc.
Integrated visualization of field lines.
Electric, magnetic, maybe even gravitational.
Initial explorations using stream line techniques, initially in Open Inventor, shown at Lisbon.
Will eventually include at least minimal solution for all vis drivers (e.g., handled at base vis level rather than by driver-specific features).
Jane has lead.
New trajectory model: model by what interaction type created particle.
Somewhat similar to drawByOriginVolume, but this is drawByOriginProcess (or just drawByProcess for short).
New trajectory model: model hue by particle type and at same time model intensity by momentum.
New trajectory filter: show random subset of trajectories.
To handle the issue of very large numbers of trajectories.
So, for example, I could ask to just show 1 out of 5 trajectories
New trajectory filter: filter by fraction of primary energy (rather than by absolute energy).
New trajectory filter: filter by how many generations from primary
(eg., show me only primary, secondaries and third generation, but no further).
New trajectory filter: filter by destination volume and by whether deposited energy there.
Capture and handle ctrl-c to return to idle prompt during visualization.
End the event loop or the RayTracerX process but don't end the entire Geant4 session.
OpenGL driver that makes PS without any graphics window.
Full support for visualization of boolean shapes.
Some Solids Cannot be Modeled by G4Polyhedron.
Existing commands such as sectionPlane and cutAwayPlane either work for only some drivers or just do not give the result that most users want.
See John and Evgueni’s proposal, summarized Oct 05 as:
Reimplement existing functionality, including:
Improved algorithms for Boolean processing;
Caching of normals (for speed);
Offer the option of user-supplied normals (for space saving and speed);
Add a new Boolean operation – cut – that creates open polyhedra for cutaway views;
Improved visualization tools for voxel geometries.
Filtering of geometry according to attributes.
This is the geometry compliment to /vis/filtering/trajectories.
Already have this as geometry "culling", but only works for culling by visibility, daughter visibility and density – plus, if mother opaque, covered daughter volumes. Could be generalized along the lines of the trajectory filters.
HepRep browsers currently let one make such cuts on the client side.
Asymmetric scaling: support in more drivers (at least HepRepFile and DAWN).
Background color: support in more drivers (at least HepRepFile and DAWN).
Window location: support in more drivers (currently only have in OGLIX and OGLSX).
Extend to HepRepFile, DAWN, OGL*Xm, OGLWIN32, Open Inventor.
2D and 3D text: support in more drivers (currently only have in DAWN and OpenGL).
Nearly done (needs attention): Open Inventor. How do you position it? 2D or 3D?
Empty implementations: HepRep, VRML1/2.
Smooth shading: support in more drivers.
Is this correctly handled in Open Inventor?
Label trajectories or hits with G4Atts.
For drivers that do not natively support such labeling, as only the HepRep viewers now support. Would use the new 3D Text primitives. Would require new commands to select which attributes to display.
Control of auxiliary edges: support in more drivers.
Such edges are also known as "Soft Edges."
Command to control this is currently implemented only in OpenGL and in DAWNGUI.
Enhance interoperability of the different visualization drivers,
i.e.. - using one driver to set camera parameters/visibility in another.
e.g., use WIRED to select view and visibility, then have G4 generate a DAWN prim file that contains the appropriate visibility and have DAWN render this with the appropriate camera parameters.
Similarly, could drive RayTracer from WIRED.
Could similarly derive vis parameters from FRED or Motif version of GL.
Point is to use a fast, rotatable viewer to drive one of the slow, high quality renderers.
Simplest solution is to have WIRED write out a G4 macro that sets camera position, etc. G4 user could then just run the macro by hand.
More elaborate solutions would involve not just setting vis parameters but also vis attributes (e.g., using one driver to edit vis attributes that are then used by another driver).
Support dynamic loading of visualization drivers.
Probably difficult, but worth a feasibility study.
Web-based DAWN rendering service.
Accept that some users are not going to have DAWN on their own machine.
So one could set up a web based service. You fill out a form to tell it where to find your .prim file, you fill out some other parameters that are the equivalent to running the DAWN setup GUI on your local machine, and you tell it your email address. You then hit the submit button and walk away.
Some time later, you get an email that tells you where to pick up your completed eps file.
Could also have options to process the file through DAWNCUT or DAVID.
Could even generate more views that you had asked for after the first one (if it has spare capacity).
Complete immediate mode for HepRep browsers such as HepRApp or FRED.
Full implementation would require Corba. Difficult, and introduces dependency on some corba implementation.
Might be able to refine current pseudo-immediate option in which client continually looks for new file on disk so that new image is displayed almost as soon as Geant4 produces it.
Create HepRepFile to DAWNFILE converter, and vice-versa.
Hierarchical VRML (rather than current flat VRML).
i_mode: To be removed at release 10.0.
Handled better by Trajectory Modeling Options since release 8.0.
It was officially deprecated at 8.0 including a warning message to users.
We WILL remove it at 10.0, whenever that is.
Will not break user code, but may make user code behave differently, since this parameter will be ignored.
Make the rich trajectory points include an attribute of "remaining energy" at that point.
John will work on it.
Makoto says he doesn't want to allow it late because it sets a bad example for others who are getting things in too late. Prefers to have it wait until next release.
Add testing of Visualization to the Release Procedure.
Extend geant4/tests/test201 to include vis commands that draw to those vis drivers that involve writing a file, such as HepRep, DAWNFILE, VRML and ASCIITree (as opposed to the immediate mode drivers).
Then just need to diff these resulting files against a reference. Include both geometry and transients.
Note that we also have something within vis called test19, but there has never been an attempt to make test19 complete. It has only been developed a on a “need-to-test” basis. -
Evaluate, Improve and Extend Visualization Examples
and clean up use of visualization within all novice examples.
Move anything not very basic to extended examples.
Perhaps move vis tutor part of N03 to extended examples.
Make more examples use standard trajectory, so that they can take advantage of new features such as modeling and filtering.
Contribute to Geant4 Image Archive.
Include not only final images but also prim, heprep and vrml files.
Prepare Tutorials for RayTracer, VRML and ASCITree.
Use structure parallel to SLAC tutorials on OpenGL, DAWN and WIRED.
Extend OpenGL Tutorial to discuss Motif Modes.
Extend DAWN Tutorial to discuss immediate mode (DAWN rather than DAWNFILE), add DAVID and DAWNCUT.
Might use the following example from Bill Lockman's mail of 4/7.
Slice of the vacuum chambers from 4490 to 4500 mm obtained by running
dawncut 0 0 1 4500 gary.prim > gary_cut4500.prim
dawncut 0 0 -1 -4490 gary_cut4500.prim > gary_cut4490_4500.prim
I've enclosed the gary_4490_4500.eps file, obtained by azimuth=polar=0, magnification=25, selecting viewing mode=line, and coordinate axes.
Extend Vis Tutorials to Show More Commands:
such as culling, sectionPlane and the detailed use of /vis/viewer/add/volume
(to limit number of volumes drawn, specifying by name and/or by depth and specifying clipping volume).
Make a Tutorial about VisUserAction.
G4LogoVisAction is a good illustration. Needs a mention in the documentation.
HepRep1: Need to add initial scale and view angle hints to the HepRep standard.
Then make HepRep1 driver produce this hint.
Users probably want their detector to fit, but not necessarily all trajectory points to fit.
Simplify/clarify "Configure -build" questions about Vis Drivers.
At least make more clear that can have things like DAWNFILE without having to say yes to immediate mode DAWN.
Might make the vis part of the dialog begin by saying:
"You will automatically have available. xxx, yyy, zzz..
Do you want optional additional visualization drivers?"
Remove need to set WIN32_SESSION to "Configure -build" with OpenGL on Windows.
Need to do this at present to force the G4INTY variable.
From ./Configure -build, one has to do this by replying yes to the question about:
Why should this be necessary?
Why do we have differerent OpenGL variables for Windows and non-Windows.
System already knows if it is windows or not based on the G4SYSTEM variable.
Even if we do need the Windows versus non-Windows G4 vis variables behind the scenes, why do we need to expost this to the user? In particular, why have them use different OpenGL /vis/open commands on the different operating systems?
Should just always be /vis/open OGLxy, with no Win32 in there.
Provide guidance to users on how to make OpenGL windows refresh on uncovering.
This is not strictly a Geant4 Visualization issue, but it is a ubiquitous issue for our users.
Configure -build on Mac with OpenGL gives annoying, non-fatal warnings, such as:
Creating/replacing object files in /Applications/geant4/lib/Darwin-g++/libG4OpenGL.a ...
ar: creating archive /Applications/geant4/lib/Darwin-g++/libG4OpenGL.a
ranlib: file: /Applications/geant4/lib/Darwin-g++/libG4OpenGL.a(G4OpenGLImmediateWin32.o) has no symbols
ranlib: file: /Applications/geant4/lib/Darwin-g++/libG4OpenGL.a(G4OpenGLImmediateWin32Viewer.o) has no symbols
ranlib: file: /Applications/geant4/lib/Darwin-g++/libG4OpenGL.a(G4OpenGLImmediateXm.o) has no symbol
Configure -build on Windows with OpenGL gives annoying, non-fatal warnings, such as:
Making dependency for file src/G4OpenGLStoredSceneHandler.cc ...
src/G4OpenGLStoredSceneHandler.cc:144:31: macro "max" requires 2 arguments, but only 1 given
src/G4OpenGLStoredSceneHandler.cc:144:40: macro "max" requires 2 arguments, but only 1 given
Implement /vis/scene/add/title [<title="Geant4">] [<size>] [<x>] [<y>] (2D)
Implement /vis/scene/add/date [<size>] [<x>] [<y>] (2D)
Once Scorers have Generic Hits, make sure Vis Handles them Well