Improve handling of multiple inclusion facets in OBJ files

[markcmiller86]

Description

Resolves #19736

This improves handling of Wavefront OBJ files with facets that have spaces in a g directive, indicating the facet is included in multiple groups. The old way would just silently fail to create any material metadata for the mesh. It was not obvious to users what happened or why. However, it turns out that the old way did handle multiple inclusion for the enumerated scalar that was defined. So, that functionality remains.

What is new is that we now still go ahead and create material metadata too except that the material object will treat spaces in any g directive as underscores. So g Mark Miller would be treated as g Mark_Miller in the material object and as g Mark Miller (two different set names) in the enumerated scalar object.

Type of change

• [x] Bug fix~~
• [ ] New feature
• [ ] Documentation update
• [ ] Other

How Has This Been Tested?

I tested by adjusting one of the WaveFront OBJ test files, cube1.obj like so...

mtllib test.mtl

g face1
usemtl Red
v 0.000000 2.000000 2.000000
v 0.000000 0.000000 2.000000
v 2.000000 0.000000 2.000000
v 2.000000 2.000000 2.000000
f -4 -3 -2 -1

g face2 mark
usemtl Green
v 2.000000 2.000000 0.000000
v 2.000000 0.000000 0.000000
v 0.000000 0.000000 0.000000
v 0.000000 2.000000 0.000000
f -4 -3 -2 -1

g face3
usemtl Blue
v 2.000000 2.000000 2.000000
v 2.000000 0.000000 2.000000
.
.
.

And, then read into VisIt and manipulated and displayed it. You can see a FilledBoundary and Mesh plot below and the SIL for the enum scalar under the Mesh plot. Note the differences in configuration of the set names. I think this is a better state to be in than silently failing. In addition, it should be obvious to a user that set names have been combined via _ char if they bother to look at the SIL controls.

Reminders:

• Please follow the style guidelines of this project.
• Please perform a self-review of your code before submitting a PR and asking others to review it.
• Please assign reviewers (see VisIt's PR procedures for more information).

Checklist:

• [x] I have commented my code where applicable.~~
• [ ] I have updated the release notes.
• [ ] I have made corresponding changes to the documentation.
• [ ] I have added debugging support to my changes.
• [ ] I have added tests that prove my fix is effective or that my feature works.
• [ ] I have confirmed new and existing unit tests pass locally with my changes.
• [ ] I have added new baselines for any new tests to the repo.
• [x] I have NOT made any changes to protocol or public interfaces in an RC branch.~~

[markcmiller86]

Will you add a test?

I'd like to but am rather busy with other high priority issues at the moment.