On Mon, 05 May 2008 21:38:45 +0530 Prabhu Ramachandran wrote: [...] > Varun Hiremath wrote: > >> I'm unable to read any block, except the first, in multiblock > >> PLOT3D files. > >> I can reproduce this bug with any multiblock PLOT3D file having more > >> than one block. For instance we can consider the test case I prepared > >> for bug #400406 (see [1] and [2]). > > Mayavi2's current plot3d support is very basic and does not support any > multi-block data.
Well, I would say it supports it partially, in the sense that it reads multi-block data, but is only able to load the first block... [...] > >> [2] > >> http://bugs.debian.org/cgi-bin/bugreport.cgi/vtk-multiblockPLOT3D-bug-test.tar.gz?bug=400406;msg=5;att=1 > > The test data is useful thanks. You're welcome. > I'll keep a copy just so it can be used > when I get to implementing the multi block support. I hope that this can happen soon, because MayaVi2 is really unusable for me, until it can read multi-block PLOT3D files. [...] > >> I would like to have a means to decide which grid blocks will be loaded > >> (e.g.: I want to load block 1, 2, and 4, but not the remaining two), > >> so that a number of PLOT3D:tiny.xyz, tiny.q objects are automatically > >> created, each one corresponding to one of the requested grid blocks > >> (e.g.: three objects are created, corresponding to blocks 1, 2, and 4). > > The trouble with this approach is that it breaks down when you have 100 > blocks. How do you view 100 of them? Anyway, this is something that > would require some thought and work. OK, let's tell the truth, the whole truth, and nothing but the truth! What would be really great to have (a dream, actually) is the possibility to select which blocks to load from a PLOT3D file (say, blocks #1, #2 and #4) and have them as children of the data source. E.g.: * TVTK Scene 1 * PLOT3D:tiny.xyz, tiny.q * Modules * ContourGridPlane * data block #1 * Modules * Surface * data block #2 * data block #4 * Modules * Surface Then, the user could select one block (say, block #4 only) or the whole data source, and create filters and modules in single clicks that would apply to the selected block or to all loaded blocks, respectively. Automatic data ranges (for contours, color maps, and so forth) would be computed by taking into account the selected block only or all loaded blocks, respectively, unless the user asks for global data range. In the above example, assume the scalar minima and maxima are: block #1: min = 0.1 max = 0.5 block #2: min = 0.3 max = 3.1 block #4: min = 6.5 max = 7.8 Then the automatic data range would be (0.1, 7.8) for the ContourGridPlane, while (0.1, 0.5) and (6.5, 7.8) for the two Surface modules, but the user would have an option to switch to global data range, so that he/she could have block #4 Surface data range set to (0.1, 7.8), in case he/she wants to, without having to manually enter the numerical values! I am aware that the above could be tricky and burdensome to implement. If it turns out to be really too hard (even for visualization gurus like you!), my original request is an second-choice simpler approach. I'll repeat it here, just to be sure what I'm referring to is clear enough: | I would like to have a means to decide which grid blocks will be loaded | (e.g.: I want to load block 1, 2, and 4, but not the remaining two), | so that a number of PLOT3D:tiny.xyz, tiny.q objects are automatically | created, each one corresponding to one of the requested grid blocks | (e.g.: three objects are created, corresponding to blocks 1, 2, and 4). Obviously the objects corresponding to the load blocks could well be represented as children of one single data source object: * TVTK Scene 1 * PLOT3D:tiny.xyz, tiny.q * data block #1 * Modules * Surface * data block #2 * data block #4 * Modules * Surface and an option to compute automatic data ranges from the whole set of loaded data, rather than from the current block, would be really useful. I really hope one of these two possible approaches can be implemented soon. -- http://frx.netsons.org/doc/index.html#nanodocs The nano-document series is here! ..................................................... Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4
pgpDpq1nX9xhN.pgp
Description: PGP signature
