Visualization Done Since Geant4.8.0
(excludes internal improvements too obscure for end users)
for editing vis attributes of geometry volumes.
as first attempt of drawing same transients to multiple visualization drivers
(not reliable in all cases - work continues)
third of what is now three options for trajectory modeling
Added 2D Text
to show current set of available drivers, models and filters
needed for movies
Generating G4Atts in G4PhysicalVolumeModel.
Can specify this in the vis attributes for specific volumes.
Tells OpenGL X viewer that next time it updates, it should also print to file (Vector PostScript).
Added trajectory time-slicing.
Key feature for making movies.
Takes each step and breaks it down into as many vis primitives as required to allow selection in 0.1 ns steps (user selectable). Added to modeling, used at least by OpenGL.
Added /vis/ogl/set/startTime and endTime
Used for movies.
Used for movies.
Used for movies.
Augmented /vis/scene/add/volume to include intersection of clipping volume
Used for movies.
Add attribute based trajectory drawing & filtering, and attribute based hit filtering.
Provides many requested features:
Filter by momentum range.
Model colour by momemtum range.
Filter based on user-supplied attributes.
Added command /vis/viewer/set/explodeFactor.
Redrawing Events on Switching to a Different Vis Driver.
Needed to allow same transients in two different vis drivers, both for use case of users who has set up two drivers in advance (e.g., please send each event to OpenGL plus DAWNFILE), or for user who scans many events in one driver (e.g. OpenGL) and then decides to send one interesting event to a different driver (e.g. DAWNFILE).
Solution will be based on changes in run management to allow keeping events.
John has lead.
Visualization of Field Lines (electric, magnetic, maybe even gravitational).
Initial explorations using stream line techniques, initially in Open Inventor.
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.
Parallel Geometry requires enhancements to visualization.
John has lead.
Allow use of G4RichTrajectory without requiring user to recode.
Currently have to write user tracking action and instantiate non-default, rich trajectory.
Would be nice to instead just have command such as:
Note that for case where want rich trajectory but only for specific trajectories, can apply trajectory filtering in conjunction with rich trajectory.
G4SmoothTrajectory is Not Smooth Enough.
Needs more auxiliary points.
Or save enough information to recompute additional steps.
Currently have to write user tracking action and instantiate non-default, smooth trajectory.
Would be nice to instead just have command such as:
i_mode: Remove at release 9.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 9.0, whenever that is.
Will not break user code, but may make user code behave differently, since this parameter will be ignored.
Improve Boolean Operations.
Some Solids Cannot be Modeled by G4Polyhedron.
Generic Sections and Cuts would be more useful if had new boolean operation “Cut” instead of “Subtract”.
Note that existing commands such as sectionPlane and cutAwayPlane either work for only some drivers or just do not give the result that most users want.
G4BREPSolid is currently visualized only as its bounding box.
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;
Complete the implementation of polyhedron representations of all Geant4 shapes.
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.
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).
Requested by Steve Sekula.
New Trajectory Filter: filter by how many generations from primary
(eg., so me only primary, secondaries and third generation, but no further).
Requested by Steve Sekula. Vis hypernews item 341 would benefit from this.
New Trajectory Filter: filter by destination volume and by whether deposited energy there.
Use case described in vis thread 146 as follows:
I would like to draw only trajectories of events, that hit my sensitive detector and deposit energy there. So to say, I would like to trigger DrawTrajectory method from inside ProcessHits method of my SensitiveDetector.
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.
Requsted by Bruce Faddegon.
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.
HepRepFile, DAWN, OGL*Xm, OGLWIN32, Open Inventor.
Text: support in more drivers. Currently 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.
Pick to Show Attributes in OpenGL:
Might make OpenGL window pickable using the same trick I used to make Tektronix emulator windows pickable back in SLD. Have to get report of where on screen user picked, then regenerate picture and see when they cross this point.
Significant effort. John may add to his “big jobs” list.
DAWN Rendering Web 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).
Control of Auxiliary Edges (also known as Soft Edges): support in more drivers.
Command to control this is currently implemented only in OpenGL and in DAWNGUI.
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.
Support Interoperability of the Different Vis 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).
Allow Dynamic Loading of Vis Drivers.
Probably difficult, but worth a feasibility study.
Complete Immediate Mode for HepRep to WIRED 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.
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 lke 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