<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hey David,<div class=""><br class=""></div><div class="">You raised some good points - see below.</div><div class=""><br class=""></div><div class="">Bob</div><div class=""><br class=""><div class="">
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Robert M. O'Bara, MEng.<br class="">Assistant Director of Scientific Computing<br class=""><br class="">Kitware Inc.<br class="">28 Corporate Drive<br class="">Suite 101<br class="">Clifton Park, NY 12065<br class=""><br class="">Phone: (518) 881- 4931</div><div class=""><br class=""></div></div><br class="Apple-interchange-newline"><br class="Apple-interchange-newline">
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On Feb 25, 2017, at 6:53 PMEST, David Thompson <<a href="mailto:david.thompson@kitware.com" class="">david.thompson@kitware.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><blockquote type="cite" class="">...<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• Introduce “default colors” for various model entity types (vertices, edges, faces, volumes, etc..) - For example being able to say all edges by default are to be blue while all faces should be white<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• The ability to specify the color for the specific model entity <br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• The ability to tell default color from explicit color<br class=""><NewModelColorPanel.png><br class=""><br class="">The Upper Left Image is the current Model Tree Display - the main problems I have with this is the following:<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• You can’t tell if the model entities colors are white (or in this case unset) - also the fact that the colors have actually been assigned randomly as their defaults<br class=""></blockquote><br class="">Agreed.<br class=""><br class=""><blockquote type="cite" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• The icon is suppose to indicate if its a volume, face, edge, vertex, model, group, etc… We never did follow through with this patter and as a result the icon doesn’t have a lot of meaning<br class=""></blockquote><br class="">I would prefer to keep them because<br class=""><br class="">1. I suspect we are about to get icons for the different entity types shortly ("Filter By" feature)<br class=""><br class="">2. Because some sessions (e.g., exodus) present tessellations on groups or other entity types that may not be intuitive, the "Filter By" feature will benefit from tree views where the entity type is shown using the same icon.<br class=""><br class=""></div></div></blockquote><div><br class=""></div>I was thinking of the Exodus Session - what do you think of having the Exodus Session create faces for each side set and a volume for each element block? This way the session looks like all the other ones? In the future we could create an operator that would create proper partitioned model faces (as well as creating model edges and vertices) What do you think?</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">3. It is a fast and simple change once we actually have the icons.<br class=""><br class=""></div></div></blockquote>If we did stick with icons then we should provide the ability for a workflow to be able to swap them out - for example in Hydrology the edge symbol could be made to look like a coast line. The one thing is that they should be B/W images)<br class=""><blockquote type="cite" class=""><div class=""></div></blockquote><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• Setting the color of a session or model doesn’t have an effect on rendering the geometry<br class=""><br class="">...<br class=""><br class="">The third option removed the icon and used a simple circle to indicate color. This is expanded on the right side where Vol 1 is explicitly green and Vol 2 is explicitly yellow. Vols 3 and 4 are inheriting the default blue color of Element Blocks indicated by the hashed circle.<br class=""></blockquote></div></div></blockquote><blockquote type="cite" class=""><div class=""><div class=""><br class="">I like it. However, note that the Exodus reader creates those groups ("Node Sets", "Side Sets", "Element Blocks") explicitly since they are part of the file. The "Topology View" won't always have those same groups. The "Entity List View" will, and it will be easier to attach functions that set color defaults to them compared to the Exodus session groups.<br class=""></div></div></blockquote>My suggestion above would address this.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">Since I believe CMB defaults to the "Entity List View," this should be fine.<br class=""><br class="">Where did you want the "default" or "inheritable" colors stored? As application settings (which then belong in CMB, not SMTK), per-session settings, per-model settings, per-group settings (which is what you have shown, but we do not currently create default groups and assign entities there)?<br class=""><br class="">If we use the "set entity property" operator to store the default colors (as well as per-entity colors), then it will be easier for the VTK adaptor to assign per-block colors. This would be easiest if we set default colors as properties on the model since CMB currently creates a VTK adaptor per model and groups all entities of the same type into one block of its output multiblock dataset (making it easy to discover the default color given only the VTK dataset).<br class=""></div></div></blockquote><div><br class=""></div>I think that the default colors should be stored in the model’s SMTK file - the application would have a preference for what the application would set the default colors would be for new models being created. I guess we could have in the future a per session set of default colors.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>David</div></div></blockquote></div><br class=""></div></body></html>