Visualization Working Group

To Do List as of 5 February 2007.

 

Redrawing Events on Switching to a Different Vis Driver.

Added in release 4.8.2.  Uses event keeping.

Minor enhancements anticipated as users exercise the new code.

John has lead.

-

Parallel Geometry enhancements to visualization.

Added in release 4.8.2

Minor enhancements anticipated as users exercise the new code.

John has lead.

-

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.

-

G4SmoothTrajectory is Not Smooth Enough.

Fixed just this month by John Allison.  Anticipate inclusion in next release.

-

Improve Boolean Operations.

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;

-

Improve visualization tools for voxel geometries.

-

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.

-

i_mode: To be removed 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.

-

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.

-

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.

-

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

dawn 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:

G4UI_BUILD_WIN32_SESSION

G4UI_USE_WIN32

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)

-

Implement /vis/scene/add/logo2D

-

Implement /vis/scene/add/text2D

-

Once Scorers have Generic Hits, make sure Vis Handles them Well