[vtkusers] I think this is the problem......
Jeff Lee
jeff at cdnorthamerica.com
Thu Mar 18 12:11:38 EST 2004
James C. Robinson wrote:
>Jeff,
>
>Many thanks for taking the time to reply. With all due respect, you are
>slightly missing the point. I have read the f#@kin' manual and, quite
>frankly, the users guide is a little light on detail. I don't know your
>level of expertise, but your assertion that things are very clear from the
>description of the objects is either saying (a) you are very smart (b) I am
>not so smart or (c) you have more knowledge (and a deeper understanding) of
>the whole graphics approach (and the vtk philosophy).
>
From your posts, I assumed you were a novice user and hadn't read the
available docs.
>Now, Scenario (a) is
>irrelevant and (c) backs up the point that I am making. Therefore, the only
>situation where it is relevant for you to make such an observation is where
>your opinion is case (b). I don't like the implication (well I don't really
>care, but why not take umbrage).
>
>I am many things Jeff, but I'm not dumb (perhaps a little lazy or
>demanding).
>
Pardon my light-heartedness, I didn't mean to damage your ego. Some
people just don't care to read manuals, but instead like to be spoon-fed
- it doesn't make them dumb, just lazy.
>I have the User's Guide and I have the online help (the doxygen
>man-pages seem only to detail the source). Let me give you an example of
>what I am talking about in relation to the explanations (taken verbatim from
>the documentation):
>vtkPolyDataMapper is a class that maps polygonal data (i.e., vtkPolyData) to
>graphics primitives. vtkPolyDataMapper serves as a superclass for
>device-specific poly data mappers, that actually do the mapping to the
>rendering/graphics hardware/software. It is now possible to set a memory
>limit for the pipeline in the mapper. If the total estimated memory usage of
>the pipeline is larger than this limit, the mapper will divide the data into
>pieces and render each in a for loop.
>VS
>vtkDataSetMapper is a mapper to map data sets (i.e., vtkDataSet and all
>derived classes) to graphics primitives. The mapping procedure is as
>follows: all 0D, 1D, and 2D cells are converted into points, lines, and
>polygons/triangle strips and then mapped to the graphics system. The 2D
>faces of 3D cells are mapped only if they are used by only one cell, i.e.,
>on the boundary of the data set.
>For the non-expert, this is like comparing apples and oranges.
>
The user guide clearly explains the fundamental approach and differences
between these objects(p. 89). This is why I suggested that you get the
guide, because it is a very valuable tool for getting started. I was
not trying to talk down to you, just trying to point you in the right
direction. Knowing now that you already have the user guide, is there
something about the way it is written that you missed that point?
>There must be
>concrete examples where one is more suitable to use than the other (and the
>implications of using one as opposed to the other)?
>
>Let me reiterate, I am using a 3rd party solution because I don't have the
>time, nor the desire to become an expert in matters graphical. It is a
>beautiful subject, but there are enough people in the business, so the
>likelihood of it keeping me alive is small. The goal that I want to achieve
>is pretty standard: FE mesh with material, scalar field and vector field
>values to view. The application is C++ (MFC) and will run on the PC/Windows
>platform. The mesh sizes are likely to range from 1000 - 50000 elements. I
>want to be able to cut, view flow on a plane, generate a streamtube and an
>isosurface. Surely there are a set of specific filter & pipelines most
>suited for this purpose.
>
>Some other users have responded positively to my suggestion of a user
>generated, organised documentation that reflects our experience.
>
>
Super idea - the wiki thing is good. But for now, if you have specific
questions or problems, a good working example which demonstrates the
problem will get you the most help.
Regards,
-Jeff
>Yours sincerely,
>
>Jim
>______________________
>
>James C. Robinson, PhD,
>Chartered Engineer,
>Kepler Simulation Systems Ltd.,
>42 Rivergrove,
>Glanmire, Co. Cork,
>Eire
>
>Tel: +353-21-4822028
>Tel: +353-87-2393010
>Fax: +353-21-4822028
>E-mail: j.robinson at kepler-systems.com
>______________________
>
>-----Original Message-----
>From: Jeff Lee [mailto:jeff at cdnorthamerica.com]
>Sent: 18 March 2004 14:47
>To: j.robinson at kepler-systems.com
>Cc: John Biddiscombe; Vtk Users
>Subject: Re: [vtkusers] I think this is the problem......
>
>Hi,
>There are indeed many ways to skin the proverbial cat, and it is easy
>for a novice to get lost. If you don't already have the vtk users and
>the VTK book guide, get them. Other available sources of info include
>vtk doxygen man-pages, mailing lists, and the examples. You won't get
>much sympathy from people on this mailing list if you just complain -
>i've seen your pictures and posts, and without some example programs
>that demonstrate your problems, nobody can help you. Cobble up some
>examples. As for your examples below, the user-guide contains basic
>pipelines for the things you describe, but for free you can look at the
>tcl/python/c++/java examples to see how the pipelines are set up. There
>are links from the man-pages to most examples/tests and even pictures of
>the output in many cases. In my opinion, it is very clear as to the
>differences in the filters you allude to below, just from reading the
>man-pages. RTFM.
>Regards,
>-Jeff
>
>James C. Robinson wrote:
>
>
>
>>John,
>>
>>Good to hear from you. I appreciate where you're coming from, but I don't
>>want to get into the world of patches etc. I want a working solution (my
>>issues are that of FE pure, mesh generation tailored for my problem,
>>designing the look and feel of the interface):- graphics is something that
>>
>>
>I
>
>
>>want to be able to take for granted - this is why I have opted for a 3rd
>>party solution.
>>
>>You see, you still haven't addressed (a) the issue of why we have so many
>>objects that replicate so many similar functionalities and (b) why at least
>>very specific explanations of these objects aren't given (preferably
>>referring to the other similar objects and clearly distinguishing why one
>>might want to use one as opposed to the other).
>>
>>Surely there is room for a very clear document that says explicitly, for
>>example:
>>Heading: Representation of finite element quadratic hexahedra mesh.
>> Topic 1: Displaying element materials. Take the following steps:
>>1. Use a vtkUnstructuredGridReader to take in the FE mesh as a file.
>>2. Now set the vtkUnstructuredGridReader as input to a vtkGeometryFilter(?
>>
>>
>I
>
>
>>don't think this is the best one, I will try a vtkDataSetSurfaceFilter
>>instead and see do things improve). Then use a vtkPolyDataMapper (I am
>>
>>
>going
>
>
>>to try a vtkDataSetMapper instead and see if this improve things|).
>>3. If using MFC C++ under windows, send your vtkPolyDataMapper output
>>through a vtkActor and add this to the vtkRenderer.
>> Topic 2: Displaying a scalar field. Take the following steps: etc.
>>
>>You see what I mean? There must be a simple pipeline type diagram that
>>
>>
>could
>
>
>>be supplied, with a tcl example code. NB: I would imagine that FE type
>>applications could form a substantial section of the user base. Why should
>>we have to keep experimenting all of us individually? It is a total waste
>>
>>
>of
>
>
>>time. If we are a real community (of users) we should be able to create a
>>structure (on the web) where such valuable info is stored. We could have a
>>proforma document to fill in and submit. I feel the suggestion of just
>>
>>
>going
>
>
>>to the mail list and doing a search is a total cop out. There must be
>>thousands e-mail, all very weakly titled and not in a structure that would
>>make it easy to find anything specific.
>>
>>All your comments (put downs, wake up calls etc.) are welcome.
>>
>>Regards,
>>
>>Jim
>>
>>______________________
>>
>>James C. Robinson, PhD,
>>Chartered Engineer,
>>Kepler Simulation Systems Ltd.,
>>42 Rivergrove,
>>Glanmire, Co. Cork,
>>Eire
>>
>>Tel: +353-21-4822028
>>Tel: +353-87-2393010
>>Fax: +353-21-4822028
>>E-mail: j.robinson at kepler-systems.com
>>______________________
>>
>>-----Original Message-----
>>From: John Biddiscombe [mailto:jbiddiscombe at skippingmouse.co.uk]
>>Sent: 18 March 2004 13:12
>>To: j.robinson at kepler-systems.com
>>Subject: Re: [vtkusers] I think this is the problem......
>>
>>JIm,
>>
>>The sad news is that you're going to have to bite the bullet and use trial
>>and error like all of us to learn the "best" way to do things!
>>
>>When you discover stuff that needs improving, submit patches for docs or
>>other to the bug tracker. It's all one can do. We (developers) try our
>>
>>
>best,
>
>
>>but we only usually fix the stuff which we need at any particular moment.
>>
>>JB
>>
>>
>>----- Original Message -----
>>From: "James C. Robinson" <j.robinson at kepler-systems.com>
>>To: "Vtk Users" <vtkusers at vtk.org>
>>Sent: Thursday, March 18, 2004 12:12 PM
>>Subject: [vtkusers] I think this is the problem......
>>
>>
>>
>>
>>
>>
>>>Dear All,
>>>
>>>I still haven't resolved my overall problems (getting v4.4 to work the
>>>
>>>
>>>
>>>
>>same
>>
>>
>>
>>
>>>as v4.0, implementing the quad hexes etc.) but I am starting to realise
>>>
>>>
>>>
>>>
>>part
>>
>>
>>
>>
>>>of the problem. VTK is not documented well enough (at least the online
>>>help). You see, there are many objects which seem to overlap in
>>>functionality (e.g vtkGeometryFilter, vtkExtractUnstructuredGrid,
>>>vtkDataSetSurfaceFilter). How is one supposed to know which one to use?
>>>
>>>
>>>
>>>
>>The
>>
>>
>>
>>
>>>descriptions are not detailed enough to indicate why one should be used as
>>>opposed to another, why they are derived off different objects but seem to
>>>achieve a lot of the same thing?
>>>
>>>Undoubtedly I am once again displaying my ignorance, but I am really only
>>>concerned with making my application work. My objective in using vtk was
>>>that it seemed to have specifically tailored functionality that fit in
>>>easily with FE analysis. To a great extent it is true, but it is in the
>>>finer detail that I am feeling let down.
>>>
>>>My objective is to view a 3D 20 noded (quadratic) hexahedral mesh, with
>>>material, pressure and flow velocity data. I have a MFC C++ (v6) version
>>>that almost works, where I can view and cut the mesh anyway I want. I can
>>>view the flow vectors (as arrows) on any plane, I can view an iso
>>>
>>>
>>>
>>>
>>(pressure)
>>
>>
>>
>>
>>>surface, I can even create a streamtube (although this does lock up).
>>>However, I am running into trouble with the v4.2-4.4 VTK releases - I
>>>
>>>
>>>
>>>
>>can't
>>
>>
>>
>>
>>>control the transparency of my objects etc. I may be using the wrong
>>>filters.... But how am I supposed to know. Surely there must be a
>>>
>>>
>>>
>>>
>>definitive
>>
>>
>>
>>
>>>"best way" to view such a mesh and manipulate in the manner that I want.
>>>
>>>Your sin desperation...
>>>
>>>Jim
>>>
>>>______________________
>>>
>>>James C. Robinson, PhD,
>>>Chartered Engineer,
>>>Kepler Simulation Systems Ltd.,
>>>42 Rivergrove,
>>>Glanmire, Co. Cork,
>>>Eire
>>>
>>>Tel: +353-21-4822028
>>>Tel: +353-87-2393010
>>>Fax: +353-21-4822028
>>>E-mail: j.robinson at kepler-systems.com
>>>______________________
>>>
>>>
>>>
>>>_______________________________________________
>>>This is the private VTK discussion list.
>>>Please keep messages on-topic. Check the FAQ at:
>>>
>>>
>>>
>>>
>><http://public.kitware.com/cgi-bin/vtkfaq>
>>
>>
>>
>>
>>>Follow this link to subscribe/unsubscribe:
>>>http://www.vtk.org/mailman/listinfo/vtkusers
>>>
>>>
>>>
>>>
>>_______________________________________________
>>This is the private VTK discussion list.
>>Please keep messages on-topic. Check the FAQ at:
>>
>>
><http://public.kitware.com/cgi-bin/vtkfaq>
>
>
>>Follow this link to subscribe/unsubscribe:
>>http://www.vtk.org/mailman/listinfo/vtkusers
>>
>>
>>
>>
>>
>>
>
>
>
>
>
--
Jeff Lee
Senior Software Engineer
Computational Dynamics North America Ltd
21 Lafayette Street, Suite 230
Lebanon NH 03766 USA
fax: 603 643 9994
phone: 603 643 9993 x109
http://www.cd-adapco.com
More information about the vtkusers
mailing list