Add ability to output color information in obj files.

[brugger1]

Is your feature request related to a problem?

Here is the e-mail request from Daniel Ross motivating the request.

From: Ross, Daniel rossdb@ornl.gov Sent: Wednesday, August 14, 2019 6:17 AM To: Brugger, Eric brugger1@llnl.gov Subject: Visit image saving

Eric, It has been a while since I contacted you I was hoping you could point me to some documentation on how to export the image produced from data into a obj file with the coloring still applied. We have received the funding to upgrade our Virtual reality cave and the next generation will be using Unity or Unreal engine to push the images into Virtual reality. Of course both packages mainly use mainstream CAD/CAM software and don’t have a plugin for visit. However, it would be handy to be able to output the results into something I can then render in either Unity or Unreal engine. I have been able to save the image produced int a obj file but it does not contain any of the coloring which is actually needed to show heat distribution. However the png and jpeg are literal photos that lack any dimensional aspect and are useless in a virtual environment.

Thanks for your help

Daniel

Impact

• [ ] High - User productivity significantly improved
• [X] Medium - User productivity partially improved
• [ ] Low - User productivity trivially improved

[biagas]

Our current writer (using vtkOBJWriter) cannot do this. vtkOBJExporter may do this, but it requires a different mechanism than the writers. The input is taken from a render window, not a dataset. I would have to see specification of OBJ files to even understand how color information should be stored.

[markcmiller86]

This update added color support in the reader. I suspect we can do something equivalent to the writer though I don't know where the color information would get associated with the VTK dataset objects passed to the writer.

[biagas]

Color information isn't associated with the dataset. Scalars are mapped to colors by the Mapper before rendering. Or the Actor has a single color stored in its Property if coloring isn't from scalars.

[markcmiller86]

Color information isn't associated with the dataset

What about material colors? We have ways for databases to specify colors to associate with materials (Silo and WavefrontOBJ already do this) upon read. Can't we pass material color information (which either comes from the database on read or which gets defined in VisIt during display of colors either by default material color or by user adjusting coloring in filled boundary plot) along to an export operation?

I guess I was trying to say that with the exception of how to associate colors with the dataset during export, I think the format details are known and already demonstrated with examples in our test suite.

[mclarsen]

Simple exapmple of a .mtl file: https://people.sc.fsu.edu/~jburkardt/data/mtl/mtl.html

Another option would be to output texture coordinates (1D) associated with the vertices that correspond to the color map location (i.e., normalized scalar value). That would allow the end user to apply any color map in whatever tool they are working with.

[markcmiller86]

So, an mtl file is what the reader currently uses to read color information too.

I hadn't considered this approach, @mclarsen. Are you saying that the right answer is to allow the user to issue two sep. saves...one for the obj data to a .obj file and the other to export a VisIt color table to a .mtl file? Well, wait, that won't work either because the .obj file needs to be annotated with references to colors in the .mtl file.

So, as @biagas I think has described, the trick is getting the color values (or their indices into the color map) associated with each vertex (or facet) out to the file. That association happens so deep down in our rendering processes that it suggests this operation is more like a save than an export.

[mclarsen]

You would need both. I am going to change my suggestion to be in favor or texture coordinates, since it much more flexible. They can map whatever they want on the the mesh.

[mclarsen]

The texture coordinates can be written in obj file, so no writing additional files.

[aowen87]

What is the final consensus here? It looks like there are 3 options mentioned:

1. Use vtkOBJExport, which requires a render window instead of a dataset.
2. Update VisIt's OBJ writer so that it handles materials similarly to the reader, which seems to be assigning "groups" that allow color associations (@markcmiller86 did I get that right?)
3. Use texture coordinates. This one isn't quite as clear to me as the former two, but it sounds like this is a feature that you can add to obj files (?). How would this work when loading the OBJ files into other programs, like powerpoint? Does it choose default colors? Does the user get to choose the colors?

[markcmiller86]

My two cents...

First, I think we need to decide...is this a Save Window... operation or an Export Database... operation? If answer is Save Window, I think option 1, vtkOBJExport is probably right way to go...just integrate it into our window saving logic. That may be easier said than done. OTOH, if Export Database is right answer, then integrating into OBJ plugin writer is correct way to go in which case its option 2 and/or 3.

Based on my description of the differences in these two operations, I would vote for Save Window because this user is asking about visually relevant attributes of the data...their colors. Though the particular attribute of object coloring does kinda sorta fall in the gray area...is it part of the database or is it part of the rendering? Its sometimes both.

[aowen87]

That makes sense to me. I'm going to remove the reviewed label so that we can discuss this more in our next meeting.

[markcmiller86]

VTK sort of defines (at least) two kinds of file outputs, exporters and writers.

The exporters appear to be concerned with what amounts to writing a scene graph (surface geometry, colors, textures, light sources and lighting, camera, etc.). Their main input is a vtkRenderWindow.

The writers are concerned with writing a (geometric) data object (mesh, variables, etc.). Their main input is a vtkDataObject.

In VisIt, we also kinda sorta define these same two operations except we call the former window Saves and the latter database exports. So, hows that for confusing 😕 😃.

I agree with @biagas that VTK's exporter classes seem like the right way to go here. However, as currently implemented in VisIt, our window Save classes also still operate from a vtkDataObject which is either a fully rendered image or the data object that gets handed to mappers and go through our rendering infrastructure to be rendered.

We don't have any of our window Save stuff integrated with the render window which is where it would need to be to use vtkOBJExporter.

Here is what I would suggest. We can probably expedite a solution here that would...

• insert the required mtllib <filename>.mtl and usemtl <colorK> lines to the exported OBJ file (perhaps written optionally and controlled through an export option)
• allow the user to separately export a .mtl file representing the colors used in the filled-boundary plot (maybe directly from the plot attrs themselves.

Designed correctly, the <filename> and <colorK> entries in the exported obj file would just line up with the exported .mtl file and it would be workable.

Longer term, we should add a new ticket to re-work our window Save architecture to integrate it more tightly with the render window.

[markcmiller86]

@mclarsen I wonder if you could help me understand a bit deeper how textures could play a role here? In particular, since our OBJ exporter uses VTK's vtkOBJWriter, does the description at that link suggest to you in any way how to proceed to ensure a companion .mtl file gets written during the write?

What I think I need to do is define a texture (which I don't really understand) (maybe that is encoded somehow as a PNG file?) and then also define for each point in the mesh a texture coordinate for that point that results in utilizing the correct coloring. But, I need to understand things more deeply than that. Would appreciate any hints/guidance you can offer.

[markcmiller86]

I've experimented with round trips from OBJ input that includes colors and texture coordinates to OBJ saves and exports with existing code base.

• We appear to only read texture coords and then produce from these scalar variables. I don't see any means for texture coordinates to be output either via saves or exports.
• If the input OBJ file has multiple groups (e.g. wholly separate objects/pieces), saving results in one .obj file per group and .visit file. However, exporting keeps them all in one file.
• I only ever see two groups (and two colors) in the Subset plot of the Groups variable whereas the SIL controls shows the completed (and correct) list of groups.