3d rendering in vector format

[tcaduser]

We're trying to combine visit-users email list with GitHub issues. When replying on visit-users, please reply only to emails with a Subject line that includes [visit-dav/live-customer-response].

---

Are there any plans to support vector formats for 3D rendering? While the rasterized format looks good, there are issues with the size of the files that are generated, as well as how much the plot can be scaled. My primary focus is academic publishing.

[markcmiller86]

Hmmm...by vector format (as opposed to rasterized), are you perhaps referring to the use of volumetric primitives such as spheres, cones, planes, etc. and boolean combinations thereof to describe a 3D object? We do support Constructive Solid Geometry but we do so by teslleating the exterior surface. So, we don't wind up rendering the 3D primitives directly on the GPU though thats always been one of the directions we'd like to extend our CSG support.

Or, maybe you mean a closed surface STL or Wavefront OBJ files? We support those as well.

[tcaduser]

I mean a pdf, eps, or similar file for publication. It would be a 2d rendering of a 3d structure, fixed in perspective, but infinitely zoomable in a pdf of a journal article.

While my generated .png file is 1.6 MB, it blows up to about 200 MB as a raster eps, tiff file, or a photoshop png file.

[markcmiller86]

Ah, ok, I understand. Well, we used to support EPS from VTK but their support for that in earlier versions of VTK was spotty. It looks like they have new functionality for that now though.

That said, VisIt does support saving a window to a few 3D formats. I dunno but maybe one of those might be supported in your publication workflow? I think STL or PLY might be worth a try.

I have moved this issue back to the unreviewed state for team consideration during our next project meeting.

[tcaduser]

FWIW, paraview is using gl2ps to do their post script rendering: https://www.paraview.org/Wiki/ParaView/Vector_Graphics_Export http://geuz.org/gl2ps/

Unfortunately, I haven't been able to test it as I find paraview too difficult to use.

[markcmiller86]

Yeah. Thanks. Saw that when I went looking and found vtkGL2PSExporter.

[markcmiller86]

While my generated .png file is 1.6 MB, it blows up to about 200 MB as a raster eps, tiff file, or a photoshop png file.

BTW...didn't read this too closely on first pass...a raster EPS file is not generally a useful thing except maybe to conform to some publisher's file format requirements. Its certainly no better quality than the equiavlent resolution raster image file format (e.g. tiff, png, etc.).

And, you can always push up VisIt's raster resolution substantially to say 4K by 4K (ultra-hd) and save a PNG or tiff file of that using save image options which, if your default image was 1.6Mb, I would expect to be maybe 10-20x that size depending on compression, if any, used. In my experience, even though raster format is not optimal, a 4K x 4K image is plenty high enough resolution for any print publication.

[tcaduser]

I like using your software, but now that I am beginning to publish, I am finding that vector graphics would be the only tenable solution for creating publication quality graphics. I hope that you consider such a solution for the future.

I gave up on paraview a long time ago because their documentation was horrible, but it now appears that kitware is taking basic needs like documentation more seriously. I made a vain attempt to use Paraview about a month ago, because the reviewers were complaining about the graphics quality in the Visit png file I attempted to include.

Paraview software is still too still not aligned with how I think such a program should function, and I was unable to figure out how to even get my data in it.

This is the figure that I had to remove from my recent journal submission, because the reviewers could not make anything out of it, and I had no easy way of manipulating the uncompressed raster file of the image:

This is what it looks like when included into my pdf and scaled to a 3.5 inch column:

and this is what the interested reader would see if they tried to zoom into the pdf:

Having 2 png files in my manuscript caused the size to go up from 182K to 8 MB.

So to your point, a raster format is far from optimal, especially now that print publications in my field are primarily distributed electronically.

[markcmiller86]

Firsr that is a gorgeous images 🎉

Next, when I zoom into the first image, above, I get something like...

I am wondering if your workflow/tools are deciding to cut-down resolution of that image to either print or web resolutions and whether your have controls to prevent that? In PowerPoint, as an example, it can either maintain the native image resolution or you can have it resample the images. I suspect a similar thing is happening in your PDF workflow. The solution to this, from the publisher's perspective, IMHO, cannot always be to require a vector format because too much possible imagery to be included in publication would be rejected as a result.

[tcaduser]

Thanks, I got this image and another from my coauthor, in a distant timezone. I could not do much to edit them, because png's blow up once they are expanded in my computer's memory for manipulation.

The blurred image is more of a depiction of what could happen, once the image is published. If the article is accepted, the editorial office will require the upload of each figure as a separate eps, tif, or pdf. Some of their newer online resources state they will accept png as well. They will then edit the images and put together the final document.

The IEEE guidelines appear to use 300 dpi for rasterized color or grayscale images, and 600 dpi for rasterized line art images. Their instructions say they will scan a paper image if they have issues with the files provided, but they would give the opportunity to provide replacements.

From my brief experiments with paraview, it appears they default to vector graphics for text, and raster for 3d rendering (in the same eps file). This seems like a pretty good compromise, for most circumstances. For an image like the one I included, with relatively few shapes, I still think a vector graphic would be the best.

[tcaduser]

You can see a preprint of an earlier version of the manuscript here: https://www.techrxiv.org/articles/preprint/Element_Edge_Based_Discretization_for_TCAD_Device_Simulation/14129081/2

There is a noticeable delay when you go to page 6 to see the Visit rendered figures 9 and 10. Figure 10 is now removed from the latest revision.

[markcmiller86]

Added this issue