>Chris, > >I'm afraid your answer is confusing to me. Aren't you describing the >positions component? I believe that Steve is using an unstructured grid, >so the positions of the vertices of the hexahedrons are not regular. In >this case, if I understand correctly, the positions component is an array >of positions and the connections component is a list of offsets into the >positions array.
The positions need not be regular in any way. It was simpler to give an exemplar that had them. DX hexahedra need not be "cubic" in the purely geometric sense of sides having equal length. Topologically, they remain hexahedra even if they look like rhomboids or parallelpipeds or whatever. > >In this case I would expect that for position dependent data the data >should follow the ordering of the positions array, while for connection >dependent data it should follow the ordering of the connections. In turn >this ordering specifies which index varies fastest. Is this not correct? Position dependent data means that the listing order of data elements is the listing order of positions whether the positions are irregular, in which case they are explicitly listed, or implicit (as in regular array notation), in which case, DX uses C-style ordering to internally "list" the positions. Likewise, connection-dependent data is a list of data elements in the same order as the corresponding connection integer vectors. Thus, connection integer vector 0 corresponds to the first listed data item in the data array, and so on to item n-1 in both arrays. Note that connection integer vector 0 may look like: [23 145 1 4 20 456 29 5] if it describes a cube whose vertex indices in the positions list are those listed. However, examination of the actual cube described would show that the winding order (a 3D Peano curve) is preserved in the topological sense that skins the cube such that normals are pointing outwards. The one-to-one correspondence of data order with either positions order or connections order relieves users of the need to have a double indirection to an intermediate index. DX handles the lookup internally for you. In the bigger sense, the concept is that data has been sampled on a spatial subdomain. Think of the space as the independent variable and data as dependent and it helps get this concept across. Dependency of data has absolutely nothing to do with the relationship between positions and connections. Position vectors may appear in any order (the position-dependent data must then appear in corresponding order); connections are made up of integer indices into the positions array, whatever order that may be. So given a complete volumetric set of positions, one could choose to describe only the surface skin of that volume using triangle connections. In that case, you can see that the order of the positions would have no relation to the indices that must appear in the connections list (since many indices would never appear in that list). > >On second (third/fourth) reading it seems that you are saying that the >indices listed in describing the connections needs to come in a specific >order. You also say that this is to maintain the normals pointing >outward? I'm surprised that this isn't taken care of by dx... > >Shouldn't the 8! combinations be equivalent descriptions of a cube? > Nope. I believe there are only 24 proper descriptions of a cube. Start at any vertex and preserving the proper handedness you can go in any of 3 directions for your first move. Degrees of freedom drop off rapidly after that (since your second move must be a diagonal across a face, not across the volume). I cannot offer a proof of this assertion (that there are only 24) though. Any topologists reading this that can help out here? You can demonstrate this with a simple one cube .dx file (easy to construct). After you generate it, Import it, Color it, and Image it. In parallel, also use Normals to generate the normals component explicitly (DX makes implicit normals in the rendering operation but to see them, you must have them prior to entering Image), and Autoglyph to visualize them. Collect this with the Colored cube object. A proper cube has 6 normals centered on the faces and pointing outward. Now go back to your data file and arbitrarily mess up the connection list. Be sure to do Reset Connection in DX to force the cached Import to be cleared so you will reload the changed version. You will soon see "inward" pointing normals on faces that are wound incorrectly, as well as crushed warped degenerate cubes. If you had data that was position-dependent (not necessary for this test by the way), you will note that the data order and position order are not changed when you alter the connections array. Thus they remain correctly mapped. But the connections defining the volume can easily be incorrectly described resulting in a nasty looking object with perfectly mapped data. Chris Pelkie Vice President/Scientific Visualization Producer Conceptual Reality Presentations, Inc. 30 West Meadow Drive Ithaca, NY 14850 [EMAIL PROTECTED]
