headers
Ryan May | 1 Nov 02:28
Picon
Gravatar

Mayavi graphical tearing

Hi,

I'm noticing some tearing of the graphics in the visualization window of
Mayavi as I interact with the window.  This is on an nVidia 6150-based
laptop running the 177.80 drivers on gentoo, currently running Mayavi
3.0.3 and Vtk 5.2.  Is anyone else noticing this problem?  It shows up
really "well" when running a surface visualization.  Disabling/enabling
Vsync does not affect the problem.

I did not have this problem at Scipy, but returning my system to the
relevant configuration (Mayavi 3.0.2 and 173.14.12 nvidia drivers) from
Scipy did not solve the problem.  I have not tried to install Vtk 5.0.4
(which is what I was running at Scipy), which could mean that it's the
source of the problem.  Before going to this trouble, I wanted to see if
anyone could verify the problem. I *can* say that none of the Vtk 5.2
python examples currently show the same problem; they're all perfectly
smooth.

Any thoughts?

Ryan

--

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Permalink | Reply | 6 comments |
headers
Prabhu Ramachandran | 1 Nov 05:09
Picon
Gravatar

Re: Trying to render a XyZ data

Marcos wrote:
> I have data from an archaeological excavation that I want to render using
> mayavi. I wrote a program that reads and excel file (with X, Y, Z columns). It
> filters the data in order to extract certain elements (by taxon) and tries to
> build a VTK StructuredGrid. I have been able to generate some output but I do
> not get anything in it except for some gibberish in the section titled <Appended
> Data>

If you want a readable XML file do this:

w = tvtk.XMLStructuredGridWriter(input=sg, compressor=None, 
data_mode='ascii', file_name=attr+'_EQ_'+cond+'.vts')
  w.write()

> The program is essentially voxelizing the data counting how many instances of a
> certain taxon occur within a dx·dy·dz area. The amount of voxels can be quite
> large (beyond what numpy arrays can handle).

OK, note that it will not be practical visualizing such large data since 
if numpy can't handle it there is no way TVTK/VTK will be able to either.

> Here is the code I have so far (the whole thing). I do not like the part where I
> say 'help here1'. I was trying to find a clever way to fill an array with points
> but I am not that familiar with numpy yet.
> 
> Any suggestions?

Don't have the time to read your whole example but a quick word of 
advice would be for you to look at the following example:
(Continue reading)

Permalink | Reply | 2 comments |
headers
Prabhu Ramachandran | 1 Nov 05:24
Picon
Gravatar

Re: Mayavi graphical tearing

Ryan May wrote:
> I'm noticing some tearing of the graphics in the visualization window of
> Mayavi as I interact with the window.  This is on an nVidia 6150-based
> laptop running the 177.80 drivers on gentoo, currently running Mayavi
> 3.0.3 and Vtk 5.2.  Is anyone else noticing this problem?  It shows up
> really "well" when running a surface visualization.  Disabling/enabling
> Vsync does not affect the problem.

What do you mean by tearing?

> I did not have this problem at Scipy, but returning my system to the
> relevant configuration (Mayavi 3.0.2 and 173.14.12 nvidia drivers) from
> Scipy did not solve the problem.  I have not tried to install Vtk 5.0.4
> (which is what I was running at Scipy), which could mean that it's the
> source of the problem.  Before going to this trouble, I wanted to see if
> anyone could verify the problem. I *can* say that none of the Vtk 5.2
> python examples currently show the same problem; they're all perfectly
> smooth.

I have an nvidia card a GeForce 5500 FX and am using v 169.12 of the GLX 
drivers that ship with Ubuntu 8.04, VTK-5.3 and things work fine.  I am 
not sure what is wrong.  One guess is that for some reason the 
reparenting of the VTK window into the wxPython widget is messing with 
the GL context as it happened with the intel depth buffer issue.

cheers,
prabhu
Permalink | Reply | 5 comments |
headers
Prabhu Ramachandran | 1 Nov 05:45
Picon
Gravatar

Re: Traits error with longs

Robert Kern wrote:
>> This is an error in the trait_types.py in the int_validate and long_validate
>> functions which basically check if the passed value is an instance of int
>> and long respectively leading to this problem.  A fix would be much
>> appreciated.  Thanks.
> 
> If you have a fix, please check it in.

I have a fix but I also have a question.  Since the 'i' trait in the 
example is declared to be an Int, is it correct to accept a long?  The 
problem is the logic is not symmetric in that if you have a Long trait 
it seems legal to set it to an int value but clearly not vice versa.

So what should be done in this case?  Should I just fix the range case 
and not fix the Int problem?

regards,
prabhu
Permalink | Reply | 5 comments |
headers
Prabhu Ramachandran | 1 Nov 06:28
Picon
Gravatar

Re: Question about how to translating the Mayavi2 user guide

ESN wrote:
> I set up a project for translating Mayavi2 documents on googlecode 
> http://code.google.com/p/mayavi2-cn/

Cool, thanks for doing this.

cheers,
prabhu
Permalink | Reply | 2 comments |
headers
Robert Kern | 1 Nov 07:03
Picon
Gravatar

Re: Traits error with longs

On Fri, Oct 31, 2008 at 23:45, Prabhu Ramachandran
<prabhu@...> wrote:
> Robert Kern wrote:
>>> This is an error in the trait_types.py in the int_validate and long_validate
>>> functions which basically check if the passed value is an instance of int
>>> and long respectively leading to this problem.  A fix would be much
>>> appreciated.  Thanks.
>>
>> If you have a fix, please check it in.
>
> I have a fix but I also have a question.  Since the 'i' trait in the
> example is declared to be an Int, is it correct to accept a long?  The
> problem is the logic is not symmetric in that if you have a Long trait
> it seems legal to set it to an int value but clearly not vice versa.

I think the logic, such as it was, was that upcasting is permissible
while downcasting isn't. Float accepts ints, too.

> So what should be done in this case?  Should I just fix the range case
> and not fix the Int problem?

I'd leave Int alone for now. I do agree that it is problematic, but I
think the root problem is that the most convenient and conventional
traits to use are these strict type-checking traits. I always thought
this was a mistake, but other voices won out at the Traits 2 design
meetings. We've made some pragmatic relaxations of this design (e.g.
Str accepts either str or unicode so that we could use Unicode builds
of wxPython without rewriting every piece of code we have), but I
think that we shouldn't tweak traits piecemeal if we can avoid it.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Prabhu Ramachandran | 1 Nov 08:14
Picon
Gravatar

Re: Traits error with longs

Robert Kern wrote:
>> I have a fix but I also have a question.  Since the 'i' trait in the
>> example is declared to be an Int, is it correct to accept a long?  The
>> problem is the logic is not symmetric in that if you have a Long trait
>> it seems legal to set it to an int value but clearly not vice versa.
> 
> I think the logic, such as it was, was that upcasting is permissible
> while downcasting isn't. Float accepts ints, too.

OK.

>> So what should be done in this case?  Should I just fix the range case
>> and not fix the Int problem?
> 
> I'd leave Int alone for now. I do agree that it is problematic, but I
> think the root problem is that the most convenient and conventional
> traits to use are these strict type-checking traits. I always thought

OK, done along with a simple test case as well.

> this was a mistake, but other voices won out at the Traits 2 design
> meetings. We've made some pragmatic relaxations of this design (e.g.
> Str accepts either str or unicode so that we could use Unicode builds
> of wxPython without rewriting every piece of code we have), but I
> think that we shouldn't tweak traits piecemeal if we can avoid it.

OK.

> Instead, we should make a consistent set of traits that basically do
> the Pythonic thing (or maybe the Kernic thing or Ramachandranic
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin Chilvers | 1 Nov 09:37
Picon

Re: Traits error with longs

G'day,

Robert Kern wrote:
> I'd leave Int alone for now. I do agree that it is problematic, but I
> think the root problem is that the most convenient and conventional
> traits to use are these strict type-checking traits. I always thought
> this was a mistake, but other voices won out at the Traits 2 design
> meetings. We've made some pragmatic relaxations of this design (e.g.
> Str accepts either str or unicode so that we could use Unicode builds
> of wxPython without rewriting every piece of code we have), but I
> think that we shouldn't tweak traits piecemeal if we can avoid it.

I think mine was one of those voices! The problem we had was that in Traits 1, we did what I 
consider to be unpythonic casting eg. Int and Float used to accept strings i.e. I could assign '2' 
to an Int trait.... try '2' + 2 at a Python prompt ;^) All it ends up doing is hiding errors... I am 
in favour of making the traits cast if it looks sensible from a pythonic point of view, but that 
looked dubious to me then, and it looks dubious to me now ;^)

> Instead, we should make a consistent set of traits that basically do
> the Pythonic thing (or maybe the Kernic thing or Ramachandranic
> thing). The Kernic philosophy being, "Type-specific traits are useful
> as post-conditions and just annoying as pre-conditions; coerce where
> sensible." These traits should be made the most convenient traits
> possible, such that the programmer is encouraged to use them
> everywhere and only use the strictly typed traits when that's really
> what's wanted. I would banish the strict traits to an
> enthought.traits.strict module.

As usual, I think we have the split between scientific/numeric code where it is nice to have casting 
and framework/object model code where errr, it generally isn't since it just hides errors that are
(Continue reading)

Permalink | Reply | 2 comments |
headers
Robert Kern | 1 Nov 09:57
Picon
Gravatar

Re: Traits error with longs

On Sat, Nov 1, 2008 at 03:37, Martin Chilvers <martin_chilvers@...> wrote:
> G'day,
>
> Robert Kern wrote:
>> I'd leave Int alone for now. I do agree that it is problematic, but I
>> think the root problem is that the most convenient and conventional
>> traits to use are these strict type-checking traits. I always thought
>> this was a mistake, but other voices won out at the Traits 2 design
>> meetings. We've made some pragmatic relaxations of this design (e.g.
>> Str accepts either str or unicode so that we could use Unicode builds
>> of wxPython without rewriting every piece of code we have), but I
>> think that we shouldn't tweak traits piecemeal if we can avoid it.
>
> I think mine was one of those voices! The problem we had was that in Traits 1, we did what I
> consider to be unpythonic casting eg. Int and Float used to accept strings i.e. I could assign '2'
> to an Int trait.... try '2' + 2 at a Python prompt ;^) All it ends up doing is hiding errors... I am
> in favour of making the traits cast if it looks sensible from a pythonic point of view, but that
> looked dubious to me then, and it looks dubious to me now ;^)

Sure, that example does. That's not what I consider "sensible" in my
rubric below. I don't want Int or Float to take just anything that
responds to int() or float(). They do need to accept, for example,
numpy scalar types that correspond to integers and floating point
numbers. And given the int/long unification, the trait that we use
when we want to specify an integer should just accept either.

>> Instead, we should make a consistent set of traits that basically do
>> the Pythonic thing (or maybe the Kernic thing or Ramachandranic
>> thing). The Kernic philosophy being, "Type-specific traits are useful
>> as post-conditions and just annoying as pre-conditions; coerce where
(Continue reading)

Permalink | Reply | 1 comment |
headers
Martin Chilvers | 1 Nov 10:41
Picon

Re: Traits error with longs

G'day,

Robert Kern wrote:
> Sure, that example does. That's not what I consider "sensible" in my rubric below. I don't want
> Int or Float to take just anything that responds to int() or float(). They do need to accept, for
> example, numpy scalar types that correspond to integers and floating point numbers. And given the
> int/long unification, the trait that we use when we want to specify an integer should just accept
> either.

No argument from me here - I just wanted to make it clear that the Traits 1.0 casting was even more 
unpythonic that the current situation ;^)

>>> Instead, we should make a consistent set of traits that basically do the Pythonic thing (or
>>> maybe the Kernic thing or Ramachandranic thing). The Kernic philosophy being, "Type-specific
>>> traits are useful as post-conditions and just annoying as pre-conditions; coerce where 
>>> sensible." These traits should be made the most convenient traits possible, such that the
>>> programmer is encouraged to use them everywhere and only use the strictly typed traits when
>>> that's really what's wanted. I would banish the strict traits to an enthought.traits.strict
>>> module.
>> As usual, I think we have the split between scientific/numeric code where it is nice to have
>> casting and framework/object model code where errr, it generally isn't since it just hides
>> errors that are hard to track down (the old classic and worst type of bug where a problem in
>> one spot, shows up somewhere completely different...)
> 
> IME, it just creates gratuitous fragility where there didn't need to be any. Most Python
> programmers, not just scientific/numeric programmers, get along really quite well without
> worrying about whether their integers are exactly ints or exactly longs. I've wasted much more
> time working around overspecified traits than it has ever saved me. This usually bites me in
> framework/object model code rather than scientific/numeric code.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane