[vtkusers] I think this is the problem......
James C. Robinson
j.robinson at kepler-systems.com
Thu Mar 18 11:22:56 EST 2004
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). 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). 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. 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.
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
>
>
>
>
More information about the vtkusers
mailing list