One possible thing to pay attention to is whether the object they are displaying (or the view they are using) is unusually large or small (e.g. zoomed way in or way out). I think we have numerical difficulties when we get beyond 1E-8 or 1E+8

I ran into this too with 3.4.0 but not with 3.3.x. If I run 3.4.0 with -noconfig then it does not happen either. I'm attaching a tar/gz of my config files it helps reproduce. It happens to me with files like curve3d.silo.

bjw_visit_config.tar.gz

This may also be relevant. I run on a Windows laptop with RealVNC, connected to the RZ. There, I ssh to rzgenie and run on a compute node. The VNC application scrapes the pixels back to my laptop.

Thank you @BradWhitlock!

It looks like you have the following in your config file:

<Object name="axes3D">
                    <Object name="Axes3D">
                        <Field name="visible" type="bool">false</Field>
                        <Field name="triadLineWidth" type="float">0</Field>
                    </Object>
                </Object>

The triadLineWidth is set to zero, which causes them to disappear.

I don't understand how this information was written to the config file; it isn't possible to set the triad line width to zero with the GUI. I also don't understand why this is treated any differently than 3.3.x. Will discuss with the team.

VisIt uses the _LineWidth enum in avt/Plotter/LineAttributes, (which is 0-origin) for most state objects that have a need for a line width attribute.
The file has conversion methods between the _LineWidth and int (LW_0 converted to 1, LW_1 converted to 2, etc).
I honestly cannot recall the full reasoning behind all this complexity, unless it had something to do with wanting to constrain the number of allowed values since the QvisLineWidthWidget constructs pixmaps for each allowed width.

Perhaps if the Axes3D state object's triadLineWidth was of type lineWidth instead of float, then VisIt would translate it properly.

I don't know what changed in 3.4 that would have caused this to be a new issue, nor if it is within VisIt or VTK.
Axes3D didn't change.

Perhaps the triadLineWidth should be changed to type lineWidth ?

Is there a reproducer for this on the OCF?

It may be the case that getting rid of the visit configuration files may solve this issue.

It may be the case that getting rid of the visit configuration files may solve this issue.

If so, that should be easily testable perhaps by manually creating the relevant parts of a config file and confirming both the bug and the fix.

If that confirms reproducibility as well as a work-around, I would declare the issue resolved...except maybe checking whether its still possible for a user to create a config file with the bad value in it from a current version of VisIt.

I may have been the one who originally reported this. I am able to reproduce with Visit 3.4.0 on RZ even with the -noconfig argument. I've tied and gotten the same result with Exodus, Mili, and VTK databases. In my test case, I added a bounding box to a legend (causing it to disappear behind(?) the bounding box a la #19124), and then the triad lines also disappeared. I am using Visit over X11 to a Windows 10 machine. Opentext Exceed is the X Server. I've attached a printout of glxinfo.

glxinfo_grier1_rztrona_01122024.txt

I tried the same thing running in RZVNC and interestingly, the legend background did work i.e. the legend is still visible behind the solid color bounding box. But the triad lines still disappeared.

Also attached are an Exodus database that I tested with: merge_4.zip

#19614 has data that reproduces this.

Simple steps to repro:

1. $ bin/visit -o testdata/silo_hdf5_test_data/curv3d.silo
2. Add Pseudocolor plot of d
3. Pull up annotation attributes and go to 3D tab
4. Check "Set triad manually"
5. Change line width to something else and then back to 1
6. Click apply and triad lines are gone.