View3D Auxiliary Programs

[j-c-cook]

The README describes how to run the View3D VS3file VFfile programs, but none of the other auxiliary programs.

For example, ViewGr, ViewEm, ViewHT, VS3fix, VFbintxt. See the attached document detailing the purposes of the additional auxiliary programs.

UsingView3D.pdf

Can we readily provide support for these function calls?

[jasondegraw]

@j-c-cook Of those other programs, the only one that I have the source to is ViewHT. See viewht.c in the src directory. It's not been a regular part of the build and has only been intermittently built. As for the others, those may be lost. The oldest version of the source code I have access to doesn't include any of those programs.

I'm not sure how helpful most of those programs would be even if we had the source, but I guess the answer is "yes, but possibly not readily":

1. ViewGr: There are a number of viewer scripts (SketchUp and Blender) and programs around, they just don't happen to live here. The scripts could be pulled in here from the various repos that they currently live, the primary reason that hasn't happened is that someone would need to verify that they still work.
2. ViewEm: The main program run with emit=1 in the input will write out grey results, so the program could be reconstituted from what we have.
3. ViewHT: viewht.c needs to be added to the build, potentially debugged, and ideally there'd be some testing added to make sure it still works.
4. VS3fix: I'm not sure I'd characterize the description of what this one does as "fixing" the input, so I'd need to be convinced that this one is a good idea. I'd think that the solution to having non-planar quads would be to... make them planar?
5. VFbintxt: The main program run with out=0 in the input will write text outputs, so the program could be reconstituted from what we have.

The ranking in terms of difficulty I'd put on them is: 2 and 5 tied for hardest, 3 next, and then 1 is the easiest.

[j-c-cook]

For the ViewGr, I was thinking something simple. A made an interactive plot for the cube.zip. (Its an html interactive, github doesn't allow html format so I zipped it. I have found that the html files render quicker in Chrome than Firefox.) I also created a static plot for the cube, vs3_plot.pdf. An additional interactive plot with more complex geometry is the html in Sauna.zip.

I like the idea of making use of the C api from a viewer script like SketchUp to render the shapes described in the vs3 files.

I'll come back to ViewGr and then possibly other auxiliary programs when I can find time. Thanks.

[jasondegraw]

Nice visualizations, thanks for sharing. If you're most interested in viewing, then the Sketchup plugin is here:

https://github.com/jasondegraw/View3D-SketchUp

Since SketchUp isn't as free as it used to be, I haven't used it in a while. The Blender plugin is here:

https://github.com/NREL/View3D-3.2

Since there's no need for calculations, my approach previously has been to leave the C out of the viewing equation and just write up code to parse the input.

In case anyone is wondering, yes, there are way too many separate repos. I need to unify them.

[j-c-cook]

The code I wrote to read a vs3 file and then visualize it is located in the viewgr.py module and have provided an example using your cube.vs3 file.

I thought future development could go a couple of ways forward:

1. Create a Python package with the name View3D that contains wrappers that provides for direct function access from Python itself. There could be modules that specifically handle access to different auxiliary functions, and in some cases (like possibly ViewGr) the code could be written in Python, e.g. ViewGr. I assume this option would at some point include further development of this library, given that not all of the auxiliary methods are present.
2. The development could all be done in Clang. In addition to the current executable, View3D, that is created upon build, other auxiliary programs could have their own executable's.

I think both options have their own pros and cons.