visualpython-users

Re: [Visualpython-users] Ubuntu 9.10 (Karmic) installation/fix: WARNING!!

[Bruce S. <Bru...@nc...>]

There are no licensing issues with flower128.tga (I took that picture of cactus 
flowers myself), and I don't know why it would be missing.

Bruce Sherwood

Guy K. Kloss wrote:
> Hi Gary,
> 
> the symptoms you've mentioned indicate that something else went (massively) 
> wrong, as I doubt that any "normal" Python process or anything that the Visual 
> library can do would result in such effects. Maybe it's got to do with your 
> graphic card's drivers. Anyway, whatever process *you* start should usually 
> *only* be able to affect user space things. But your descriptions go way 
> beyond what a graphics based application generally would do.
> 
> I have just checked again here, and all demos I've checked worked. Well, 
> stonehenge.py did not, but that was only due to the fact that the file 
> "flower128.tga" is not present in the samples directory. I don't know, maybe 
> it was removed due to licensing issues or just forgotten. But also all surface 
> textures worked here.
> 
> It would however be good to track down what your problem is. Maybe not as much 
> for VPython as for your own system's sake. Have a look at /var/log/messages 
> and /var/log/syslog what might have happened and led to the crash. Also check 
> whether other OpenGL based applications show similar effects.
> 
> Hope these were some hints on tracking down the cause,
> 
> Guyt
> 

Re: [Visualpython-users] Ubuntu 9.10 (Karmic) installation/fix: WARNING!!

[Guy K. K. <g....@ma...>]

Hi Gary,

the symptoms you've mentioned indicate that something else went (massively) 
wrong, as I doubt that any "normal" Python process or anything that the Visual 
library can do would result in such effects. Maybe it's got to do with your 
graphic card's drivers. Anyway, whatever process *you* start should usually 
*only* be able to affect user space things. But your descriptions go way 
beyond what a graphics based application generally would do.

I have just checked again here, and all demos I've checked worked. Well, 
stonehenge.py did not, but that was only due to the fact that the file 
"flower128.tga" is not present in the samples directory. I don't know, maybe 
it was removed due to licensing issues or just forgotten. But also all surface 
textures worked here.

It would however be good to track down what your problem is. Maybe not as much 
for VPython as for your own system's sake. Have a look at /var/log/messages 
and /var/log/syslog what might have happened and led to the crash. Also check 
whether other OpenGL based applications show similar effects.

Hope these were some hints on tracking down the cause,

Guyt

-- 
Guy K. Kloss
Institute of Information and Mathematical Sciences
Te Kura Pūtaiao o Mōhiohio me Pāngarau
Massey University, Albany (North Shore City, Auckland)
473 State Highway 17, Gate 1, Mailroom, Quad B Building
voice: +64 9 414-0800 ext. 9585   fax: +64 9 441-8181
G....@ma... http://www.massey.ac.nz/~gkloss

Re: [Visualpython-users] Ubuntu 9.10 (Karmic) installation/fix: WARNING!!

[Gary P. <gar...@gm...>]

I meant Guy Kloss' instructions.  Sorry, poor proofreading.

On Wed, Nov 18, 2009 at 10:48 PM, Gary Pajer <gar...@gm...> wrote:

> I'm running Kubuntu 9.10 and python 2.6.4 on a Thinkpad T41 which sports
> the dreaded Radeon Mobility 7500 video set.
>
> I followed            instructions exactly, then began to try example
> programs.
>
> doublependulum worked fine.
>
> The next one I tried was stonehenge.  I got an error that visual.text could
> not be found.
> Then I tried stars, and got an error that newaxis was not defined.  Uh oh.
> Not good.
> I also tried gyro and gas.   The visual.text error came up more than once.
>
> Then I noticed that some icons were missing from my system, replaced by
> question marks.  I figured I should at least logout/in, perhaps restart X,
> perhaps reboot.  So I logout via the KDE menu, and the system drops into a
> character terminal login screen ... unusual ... but I can't log in.  Any
> user name entered resulted in the login prompt returning.  No password
> prompt.  I tried other "terminals"  (alt-f2, etc) same result.  I could get
> no useful response doing anything I could think of.  Out of ideas, I powered
> down.
>
> On restart, a filesystem check started, but ended in failure: filesystem
> could not be mounted.  It did give me a "rescue" terminal session of some
> sort, and I was able to run fsck.  A couple dozen errors were found and
> repaired.  Things like orphaned inodes, broken chains,  I don't remember
> exactly, but I'm sure you get the idea.  I don't know if there is any
> permanent "damage".
>
> I wish I could give you more information, but there's not much more to
> tell.  If you think there might be clues left behind, I'll gladly look for
> them.
>
> -gary
>
>
>

[Visualpython-users] Ubuntu 9.10 (Karmic) installation/fix: WARNING!!

[Gary P. <gar...@gm...>]

I'm running Kubuntu 9.10 and python 2.6.4 on a Thinkpad T41 which sports the
dreaded Radeon Mobility 7500 video set.

I followed            instructions exactly, then began to try example
programs.

doublependulum worked fine.

The next one I tried was stonehenge.  I got an error that visual.text could
not be found.
Then I tried stars, and got an error that newaxis was not defined.  Uh oh.
Not good.
I also tried gyro and gas.   The visual.text error came up more than once.

Then I noticed that some icons were missing from my system, replaced by
question marks.  I figured I should at least logout/in, perhaps restart X,
perhaps reboot.  So I logout via the KDE menu, and the system drops into a
character terminal login screen ... unusual ... but I can't log in.  Any
user name entered resulted in the login prompt returning.  No password
prompt.  I tried other "terminals"  (alt-f2, etc) same result.  I could get
no useful response doing anything I could think of.  Out of ideas, I powered
down.

On restart, a filesystem check started, but ended in failure: filesystem
could not be mounted.  It did give me a "rescue" terminal session of some
sort, and I was able to run fsck.  A couple dozen errors were found and
repaired.  Things like orphaned inodes, broken chains,  I don't remember
exactly, but I'm sure you get the idea.  I don't know if there is any
permanent "damage".

I wish I could give you more information, but there's not much more to
tell.  If you think there might be clues left behind, I'll gladly look for
them.

-gary

Re: [Visualpython-users] VPuDig, V 42, Is 5, Tim Smith and *speed*

[John B. <jb...@te...>]

In general, I seem to have passed through this same points/speed bottleneck 
and am now trying to get my points-packing program C++ version to use OpenGL 
rendering.  If there's any applicability to Tim Smith's problem, there are 
VPython and C++ versions of this (source is obvious in the Python/VPython; 
source for the C++ is included) program (not yet the C++ OpenGL, which I'm 
still fighting) here :

http://tetrahedraverse.com

The C++ program with source (and other stuff, including Martin Kraus' 
live.jar and a pointfield-viewer called Graph3D by a man named Hart) package 
is behind the wee tiny line of text ("NEW! Windows..."etc.) just under the 
"Tetrahedraverse" label,
and the VPython original program that does all those points (any number, 
user-entered) and renders them is at :

http://208.131.134.190/tverse/engine/engindex.htm

(Which is behind "tetrahedraverse" :: "ball packing" :: "my own packing 
program" )

If you're going to pack (use; render; calculate about; do-something-with) a 
million or more points, you're going to need something faster than either 
VPython *or* Python.  Speed was one of the two main reasons I had to learn 
enough C++ to port my Python program into that language (I was *not* about 
to try to port it to Assembly, the only thing faster than C).
The other reason was public acessibility: I wanted to allow at least Windows 
users to download the (Windows, console) program and be able to run it right 
away, with no installation of anything otherwise necessary.  (To run a 
VPython program, the potential user has to have a Python/VPython 
installation locally on his computer.)

If anything in either of my point-packing programs is useful to you, Tim, 
you're welcome to them and their source.  I, too, have to deal in many 
thousands of points.
(The VPython original displays the point field moving/packing-itself in 
'crosseyed' stereo 3D....)

John Brawley


----- Original Message ----- 
> Message: 2  (And others in this thread...................)
> Date: Tue, 17 Nov 2009 11:20:42 +0800
> From: "Tim Smith (25121)" <tk...@mi...>
> Subject: [Visualpython-users] speed
> To: <vis...@li...>
> Message-ID:
> <277...@mu...>
> Content-Type: text/plain; charset="us-ascii"
>
> Something I've noticed with vpython is speed doesn't seem to scale up.
> In my model I found 1000 points has a render time of 17, 10,000 points
> has a render time of 170, and 50,000 point has a render time of 445.
> Once I go over the 10,000 point mark performance starts to go down
> exponentially.
> What I'm wondering, is I'll potentially have to render 1,000,000 points
> for one of my projects, is vpython unsuitable for my task and is there a
> faster python 3d library out there? I've been really impressed with how
> fast vpython has enabled me to produce from very detailed models, how
> ever working with such slow objects is going to drive me a little batty
> eventually.

[Visualpython-users] Problems with VPython 5.12 on Fedora 11 64

[Seth M. <sm...@ps...>]

Hello all,

First, I would like to thank you very much for your time.

I am having some issues with the installation of VPython on Fedora 11 
(64 bit).

So that you know what I have done so far, I have installed 
gtkglextmm-devel and libglademm24-devel, as well as tkinter, so I don't 
believe I am running into issues due to dependencies.  I also added '# 
include <boost/type_traits/add_reference.hpp>' in 
/usr/include/boost/python/detail/translate_exception.hpp as prescribed.  
I also made the soft link from libboost_thread-mt.so.1.37.0 to 
libboost_thread.so in /usr/lib64 so that make could link properly (it 
might be helpful to add this to INSTALL.txt).

In order to get VPython to properly compile, I had to make this change 
in Makefile and src/Makefile:  In the definition of PYTHON_INCLUDES, 
'${prefix}/lib' was changed to '/usr/lib64/'.  Without this change, make 
did not know where to search for numpy.

Additionally, in Makefile, at line 305, I had to unindent the line 
"@list='$(bin_SCRIPTS)'; for p in $$list; do \" in the definition of 
install_binSCRIPTS.  I'm not really sure why this was necessary (it was 
stumbled upon by accident), but without this there was an error in the 
final step of installation, around where it prints 'test -z 
"/amphome/smm553/.vpython/bin" || mkdir -p -- 
"/amphome/smm553/.vpython/bin"' to the screen.

When we were still running Fedora 10, VPython installed and ran fine 
after making these changes.  However, now that we have upgraded to 
Fedora 11, VPython appears to install properly, but when I try to run a 
script I get this error:

VPython ***CRITICAL ERROR***: 
../../Download/applications/visual-5.12_release/src/gtk2/render_surface.cpp:88: 
render_surface: failed to initialize any OpenGL configuration, Aborting.

The only thing that I can see that is different between Fedora 10 and 11 
here is that the boost library that I had to link to in Fedora 10 was 
libboost_thread-mt.so.1.34.0, not libboost_thread-mt.so.1.37.0.  I have 
also tried installing VPython using the Fedora 11 rpm from this link: 
http://www.users.csbsju.edu/~jcross/vpython/.  Again, it successfully 
installs but gives the same error at run time as when I install from 
source.

Is this an error that anyone has seen before?  If so, what can I do to 
get VPython to run?
Thank you for your time.

Seth Morton
Chemistry Graduate Student, Penn State University

Re: [Visualpython-users] speed

[Scott D. D. <Sco...@Ac...>]

Bruce Sherwood wrote:
> I don't expect any such change any time soon; a factor of 2 isn't going to make 
> a big observable difference in the world of mouse responsiveness, nor is there 
> someone available to make this change quickly. Your problems are with factors of 
> 10 and 100, not 2.
> 
> Bruce Sherwood
> 
> Tim Smith (25121) wrote:
>> In my case I could perform my computations on a faster remote server,
>> and provide the computed dataset to the model. is changing this
>> difficult?

My experience with exploratory display of too much data is that sampling
the data down to smaller sizes actually works quite well.  Pull in
points with a probability of .001 if you have to; if it looks too
sparse, back off.

--Scott David Daniels
Sco...@Ac...

Re: [Visualpython-users] speed

[Bruce S. <Bru...@nc...>]

I don't expect any such change any time soon; a factor of 2 isn't going to make 
a big observable difference in the world of mouse responsiveness, nor is there 
someone available to make this change quickly. Your problems are with factors of 
10 and 100, not 2.

Bruce Sherwood

Tim Smith (25121) wrote:
> In my case I could perform my computations on a faster remote server,
> and provide the computed dataset to the model. is changing this
> difficult?
> 
> -----Original Message-----
> From: Bruce Sherwood [mailto:Bru...@nc...] 
> Sent: Wednesday, 18 November 2009 9:17 AM
> To: Tim Smith (25121)
> Cc: vpusers
> Subject: Re: [Visualpython-users] speed
> 
> I just realized that there is a factor of 2 inefficiency in Visual,
> actually. 
> Visual attempts to apportion half the time to computation and half the
> time to 
> rendering, as you can see if you set scene.show_rendertime = True. This
> is 
> important: If the computational thread is starved, the objects don't get
> 
> changed. If the rendering thread is starved, the scene doesn't reflect
> the 
> computational changes.
> 
> I think it's the case that Visual doesn't change this equal time sharing
> even if 
> the computational thread has come to the end of the computation. So
> there could 
> in principle be a factor of two improvement in the navigation of a scene
> whose 
> objects are not changing, if this were implemented in Visual.
> 
> Bruce Sherwood
> 
> Bruce Sherwood wrote:
>> There is one other approach you could use.
>>
>> Make the scene invisible while you create the objects. Then make it
> visible. If 
>> there are lots of objects, it will take a long time to render the
> scene, and you 
>> certainly won't be able to navigate smoothly. But you could have a
> second window 
>> with a rudimentary sampled version of the display. Let a click in the
> second 
>> window toggle the visibility of the first (main) window. Click to make
> the first 
>> window invisible, then navigate in the scene in the second window to
> get the 
>> camera the way you want it, then use this information to modify the
> positioning 
>> of the camera for the first window, and finally click in the second
> window to 
>> make the first window visible with the new viewing angle. Something
> like that.
>> The 1/3 factor you're seeing isn't necessarily inefficiencies in
> VPython's 
>> having to get things from Python. The little calculation I did is only
> a rough 
>> estimate.
>>
>> Bruce Sherwood
>>
>> Tim Smith (25121) wrote:
>>> That's very interesting Bruce, The quadro nvs285 I have in my
>>> workstation is only rated at 1.5 million triangles per second (I'm
>>> horrified btw, I asked our IT department what card was in this pc and
> I
>>> was told it was a fast quadro), meaning 29,000 sphere's would be the
>>> maximum I could render and have reasonably smooth motion, I'm finding
> I
>>> get 1/3 of that in actual fact when I do tests.
>>>
>>> -----Original Message-----
>>> From: Bruce Sherwood [mailto:Bru...@nc...] 
>>> Sent: Tuesday, 17 November 2009 11:50 PM
>>> Cc: vis...@li...
>>> Subject: Re: [Visualpython-users] speed
>>>
>>> I'm pretty much out of my depth here, but Guy Kloss's nearly
>>> simultaneous and 
>>> very interesting post about speed suggests that there is no royal
> road
>>> to speed 
>>> + rapid creation. For that matter, there's only so much you can get
> out
>>> of 
>>> today's graphics cards.
>>>
>>> For example, the NVIDIA Quadro FX 4600 (about $1400) is rated at 250
>>> billion 
>>> triangles per second (http://www.deskeng.com/articles/aaajxm.htm).
>>> Suppose a 
>>> small sphere is approximated by 4 triangles facing you. Then the card
>>> would take 
>>> a second to display 60 billion small spheres. To have good mouse
>>> navigation 
>>> capabilities you would need to be able to redraw the scene in about a
>>> thirtieth 
>>> of a second in response to a mouse move, which means that you could
>>> rotate and 
>>> zoom only about 2 billion spheres. And that's assuming that no
>>> computation is 
>>> being done: you generate the 2 billion spheres once, and then wait to
>>> react 
>>> quickly to a change in camera position.
>>>
>>> A midrange card like the $600 Quadro FX 1700 does only 190 million
>>> triangles per 
>>> second, which implies about 2 million navigable spheres.
>>>
>>> Bruce Sherwood
>>>
>>> Tim Smith (25121) wrote:
>>>> Hmm. Would I benefit from writing the application purely in c++ (not
>>> my
>>>> preferred option)?
>>>> I'm treading a line between speed and flexibility of pumping out
>>> various
>>>> models, and speed of interpreting the model itself. If the model is
>>>> frighteningly slow to interact with then I'm sunk, but if it takes
> me
>>>> too long to produce a new model I'm also sunk.
>>>>
> ------------------------------------------------------------------------
>>> ------
>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>>> 30-Day 
>>> trial. Simplify your report design, integration and deployment - and
>>> focus on 
>>> what you do best, core application coding. Discover what's new with
>>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>>> _______________________________________________
>>> Visualpython-users mailing list
>>> Vis...@li...
>>> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>>>
>>>
> **********************************************************************
>>> IMPORTANT - This email and any attachments may contain confidential
> or privileged information intended solely for the intended recipient and
> / or copyrighted material.  If you are not the intended recipient you
> must not use, interfere with, disclose, copy or take any action with
> reliance on this email or any part of it. If you have received this
> email in error please advise the sender via return email and delete or
> destroy all copies of this email and attachments.  Any claim to
> confidentiality or privilege is not waived or lost by reason of mistaken
> transmission of this message.  Any unauthorised use, copying or
> distribution is prohibited.  Minara Resources Limited does not warrant
> that this email or any attachments are free of viruses and cannot
> guarantee the accuracy, reliability or completeness of this email and
> any attachments.
>>> This footnote also confirms that this email message has been swept by
>>> MIMEsweeper for the presence of computer viruses.
>>>
>>> www.clearswift.com
>>>
> **********************************************************************
>>
> ------------------------------------------------------------------------
> ------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day 
>> trial. Simplify your report design, integration and deployment - and
> focus on 
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Visualpython-users mailing list
>> Vis...@li...
>> https://lists.sourceforge.net/lists/listinfo/visualpython-users

Re: [Visualpython-users] speed

[Guy K. K. <g....@ma...>]

On Wed, 18 Nov 2009 14:06:18 Bruce Sherwood wrote:
> The little calculation I did is only a rough estimate.

Don't forget, the raw rendering speed they're stating on the manufacturer's 
side is something for data, etc. being all present *within* the graphics board 
already. So it's the raw rendering speed. But as you're facing a system with 
many more interactions and interconnects (the machine's RAM, the bus, some 
management, etc.) you're likely to suffer some degradation from that raw 
rendering figure.

It's like with a car engine's power rating. I think in the US this is measured 
straight off the engine, without a car attached. But in a real situation the 
power has to flow through the gear box, drive shafts, differential, etc. down 
to the wheels. The power that reaches the road is definitely less than what 
the engine generates.

Guy

-- 
Guy K. Kloss
Institute of Information and Mathematical Sciences
Te Kura Pūtaiao o Mōhiohio me Pāngarau
Massey University, Albany (North Shore City, Auckland)
473 State Highway 17, Gate 1, Mailroom, Quad B Building
voice: +64 9 414-0800 ext. 9585   fax: +64 9 441-8181
G....@ma... http://www.massey.ac.nz/~gkloss

Re: [Visualpython-users] speed

[Tim S. (25121) <tk...@mi...>]

In my case I could perform my computations on a faster remote server,
and provide the computed dataset to the model. is changing this
difficult?

-----Original Message-----
From: Bruce Sherwood [mailto:Bru...@nc...] 
Sent: Wednesday, 18 November 2009 9:17 AM
To: Tim Smith (25121)
Cc: vpusers
Subject: Re: [Visualpython-users] speed

I just realized that there is a factor of 2 inefficiency in Visual,
actually. 
Visual attempts to apportion half the time to computation and half the
time to 
rendering, as you can see if you set scene.show_rendertime = True. This
is 
important: If the computational thread is starved, the objects don't get

changed. If the rendering thread is starved, the scene doesn't reflect
the 
computational changes.

I think it's the case that Visual doesn't change this equal time sharing
even if 
the computational thread has come to the end of the computation. So
there could 
in principle be a factor of two improvement in the navigation of a scene
whose 
objects are not changing, if this were implemented in Visual.

Bruce Sherwood

Bruce Sherwood wrote:
> There is one other approach you could use.
> 
> Make the scene invisible while you create the objects. Then make it
visible. If 
> there are lots of objects, it will take a long time to render the
scene, and you 
> certainly won't be able to navigate smoothly. But you could have a
second window 
> with a rudimentary sampled version of the display. Let a click in the
second 
> window toggle the visibility of the first (main) window. Click to make
the first 
> window invisible, then navigate in the scene in the second window to
get the 
> camera the way you want it, then use this information to modify the
positioning 
> of the camera for the first window, and finally click in the second
window to 
> make the first window visible with the new viewing angle. Something
like that.
> 
> The 1/3 factor you're seeing isn't necessarily inefficiencies in
VPython's 
> having to get things from Python. The little calculation I did is only
a rough 
> estimate.
> 
> Bruce Sherwood
> 
> Tim Smith (25121) wrote:
>> That's very interesting Bruce, The quadro nvs285 I have in my
>> workstation is only rated at 1.5 million triangles per second (I'm
>> horrified btw, I asked our IT department what card was in this pc and
I
>> was told it was a fast quadro), meaning 29,000 sphere's would be the
>> maximum I could render and have reasonably smooth motion, I'm finding
I
>> get 1/3 of that in actual fact when I do tests.
>>
>> -----Original Message-----
>> From: Bruce Sherwood [mailto:Bru...@nc...] 
>> Sent: Tuesday, 17 November 2009 11:50 PM
>> Cc: vis...@li...
>> Subject: Re: [Visualpython-users] speed
>>
>> I'm pretty much out of my depth here, but Guy Kloss's nearly
>> simultaneous and 
>> very interesting post about speed suggests that there is no royal
road
>> to speed 
>> + rapid creation. For that matter, there's only so much you can get
out
>> of 
>> today's graphics cards.
>>
>> For example, the NVIDIA Quadro FX 4600 (about $1400) is rated at 250
>> billion 
>> triangles per second (http://www.deskeng.com/articles/aaajxm.htm).
>> Suppose a 
>> small sphere is approximated by 4 triangles facing you. Then the card
>> would take 
>> a second to display 60 billion small spheres. To have good mouse
>> navigation 
>> capabilities you would need to be able to redraw the scene in about a
>> thirtieth 
>> of a second in response to a mouse move, which means that you could
>> rotate and 
>> zoom only about 2 billion spheres. And that's assuming that no
>> computation is 
>> being done: you generate the 2 billion spheres once, and then wait to
>> react 
>> quickly to a change in camera position.
>>
>> A midrange card like the $600 Quadro FX 1700 does only 190 million
>> triangles per 
>> second, which implies about 2 million navigable spheres.
>>
>> Bruce Sherwood
>>
>> Tim Smith (25121) wrote:
>>> Hmm. Would I benefit from writing the application purely in c++ (not
>> my
>>> preferred option)?
>>> I'm treading a line between speed and flexibility of pumping out
>> various
>>> models, and speed of interpreting the model itself. If the model is
>>> frighteningly slow to interact with then I'm sunk, but if it takes
me
>>> too long to produce a new model I'm also sunk.
>>>
>>
------------------------------------------------------------------------
>> ------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>> 30-Day 
>> trial. Simplify your report design, integration and deployment - and
>> focus on 
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Visualpython-users mailing list
>> Vis...@li...
>> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>>
>>
**********************************************************************
>> IMPORTANT - This email and any attachments may contain confidential
or privileged information intended solely for the intended recipient and
/ or copyrighted material.  If you are not the intended recipient you
must not use, interfere with, disclose, copy or take any action with
reliance on this email or any part of it. If you have received this
email in error please advise the sender via return email and delete or
destroy all copies of this email and attachments.  Any claim to
confidentiality or privilege is not waived or lost by reason of mistaken
transmission of this message.  Any unauthorised use, copying or
distribution is prohibited.  Minara Resources Limited does not warrant
that this email or any attachments are free of viruses and cannot
guarantee the accuracy, reliability or completeness of this email and
any attachments.
>>
>> This footnote also confirms that this email message has been swept by
>> MIMEsweeper for the presence of computer viruses.
>>
>> www.clearswift.com
>>
**********************************************************************
> 
>
------------------------------------------------------------------------
------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
30-Day 
> trial. Simplify your report design, integration and deployment - and
focus on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users

Re: [Visualpython-users] speed

[Bruce S. <Bru...@nc...>]

I just realized that there is a factor of 2 inefficiency in Visual, actually. 
Visual attempts to apportion half the time to computation and half the time to 
rendering, as you can see if you set scene.show_rendertime = True. This is 
important: If the computational thread is starved, the objects don't get 
changed. If the rendering thread is starved, the scene doesn't reflect the 
computational changes.

I think it's the case that Visual doesn't change this equal time sharing even if 
the computational thread has come to the end of the computation. So there could 
in principle be a factor of two improvement in the navigation of a scene whose 
objects are not changing, if this were implemented in Visual.

Bruce Sherwood

Bruce Sherwood wrote:
> There is one other approach you could use.
> 
> Make the scene invisible while you create the objects. Then make it visible. If 
> there are lots of objects, it will take a long time to render the scene, and you 
> certainly won't be able to navigate smoothly. But you could have a second window 
> with a rudimentary sampled version of the display. Let a click in the second 
> window toggle the visibility of the first (main) window. Click to make the first 
> window invisible, then navigate in the scene in the second window to get the 
> camera the way you want it, then use this information to modify the positioning 
> of the camera for the first window, and finally click in the second window to 
> make the first window visible with the new viewing angle. Something like that.
> 
> The 1/3 factor you're seeing isn't necessarily inefficiencies in VPython's 
> having to get things from Python. The little calculation I did is only a rough 
> estimate.
> 
> Bruce Sherwood
> 
> Tim Smith (25121) wrote:
>> That's very interesting Bruce, The quadro nvs285 I have in my
>> workstation is only rated at 1.5 million triangles per second (I'm
>> horrified btw, I asked our IT department what card was in this pc and I
>> was told it was a fast quadro), meaning 29,000 sphere's would be the
>> maximum I could render and have reasonably smooth motion, I'm finding I
>> get 1/3 of that in actual fact when I do tests.
>>
>> -----Original Message-----
>> From: Bruce Sherwood [mailto:Bru...@nc...] 
>> Sent: Tuesday, 17 November 2009 11:50 PM
>> Cc: vis...@li...
>> Subject: Re: [Visualpython-users] speed
>>
>> I'm pretty much out of my depth here, but Guy Kloss's nearly
>> simultaneous and 
>> very interesting post about speed suggests that there is no royal road
>> to speed 
>> + rapid creation. For that matter, there's only so much you can get out
>> of 
>> today's graphics cards.
>>
>> For example, the NVIDIA Quadro FX 4600 (about $1400) is rated at 250
>> billion 
>> triangles per second (http://www.deskeng.com/articles/aaajxm.htm).
>> Suppose a 
>> small sphere is approximated by 4 triangles facing you. Then the card
>> would take 
>> a second to display 60 billion small spheres. To have good mouse
>> navigation 
>> capabilities you would need to be able to redraw the scene in about a
>> thirtieth 
>> of a second in response to a mouse move, which means that you could
>> rotate and 
>> zoom only about 2 billion spheres. And that's assuming that no
>> computation is 
>> being done: you generate the 2 billion spheres once, and then wait to
>> react 
>> quickly to a change in camera position.
>>
>> A midrange card like the $600 Quadro FX 1700 does only 190 million
>> triangles per 
>> second, which implies about 2 million navigable spheres.
>>
>> Bruce Sherwood
>>
>> Tim Smith (25121) wrote:
>>> Hmm. Would I benefit from writing the application purely in c++ (not
>> my
>>> preferred option)?
>>> I'm treading a line between speed and flexibility of pumping out
>> various
>>> models, and speed of interpreting the model itself. If the model is
>>> frighteningly slow to interact with then I'm sunk, but if it takes me
>>> too long to produce a new model I'm also sunk.
>>>
>> ------------------------------------------------------------------------
>> ------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>> 30-Day 
>> trial. Simplify your report design, integration and deployment - and
>> focus on 
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Visualpython-users mailing list
>> Vis...@li...
>> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>>
>> **********************************************************************
>> IMPORTANT - This email and any attachments may contain confidential or privileged information intended solely for the intended recipient and / or copyrighted material.  If you are not the intended recipient you must not use, interfere with, disclose, copy or take any action with reliance on this email or any part of it. If you have received this email in error please advise the sender via return email and delete or destroy all copies of this email and attachments.  Any claim to confidentiality or privilege is not waived or lost by reason of mistaken transmission of this message.  Any unauthorised use, copying or distribution is prohibited.  Minara Resources Limited does not warrant that this email or any attachments are free of viruses and cannot guarantee the accuracy, reliability or completeness of this email and any attachments.
>>
>> This footnote also confirms that this email message has been swept by
>> MIMEsweeper for the presence of computer viruses.
>>
>> www.clearswift.com
>> **********************************************************************
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users

Re: [Visualpython-users] speed

[Bruce S. <Bru...@nc...>]

There is one other approach you could use.

Make the scene invisible while you create the objects. Then make it visible. If 
there are lots of objects, it will take a long time to render the scene, and you 
certainly won't be able to navigate smoothly. But you could have a second window 
with a rudimentary sampled version of the display. Let a click in the second 
window toggle the visibility of the first (main) window. Click to make the first 
window invisible, then navigate in the scene in the second window to get the 
camera the way you want it, then use this information to modify the positioning 
of the camera for the first window, and finally click in the second window to 
make the first window visible with the new viewing angle. Something like that.

The 1/3 factor you're seeing isn't necessarily inefficiencies in VPython's 
having to get things from Python. The little calculation I did is only a rough 
estimate.

Bruce Sherwood

Tim Smith (25121) wrote:
> That's very interesting Bruce, The quadro nvs285 I have in my
> workstation is only rated at 1.5 million triangles per second (I'm
> horrified btw, I asked our IT department what card was in this pc and I
> was told it was a fast quadro), meaning 29,000 sphere's would be the
> maximum I could render and have reasonably smooth motion, I'm finding I
> get 1/3 of that in actual fact when I do tests.
> 
> -----Original Message-----
> From: Bruce Sherwood [mailto:Bru...@nc...] 
> Sent: Tuesday, 17 November 2009 11:50 PM
> Cc: vis...@li...
> Subject: Re: [Visualpython-users] speed
> 
> I'm pretty much out of my depth here, but Guy Kloss's nearly
> simultaneous and 
> very interesting post about speed suggests that there is no royal road
> to speed 
> + rapid creation. For that matter, there's only so much you can get out
> of 
> today's graphics cards.
> 
> For example, the NVIDIA Quadro FX 4600 (about $1400) is rated at 250
> billion 
> triangles per second (http://www.deskeng.com/articles/aaajxm.htm).
> Suppose a 
> small sphere is approximated by 4 triangles facing you. Then the card
> would take 
> a second to display 60 billion small spheres. To have good mouse
> navigation 
> capabilities you would need to be able to redraw the scene in about a
> thirtieth 
> of a second in response to a mouse move, which means that you could
> rotate and 
> zoom only about 2 billion spheres. And that's assuming that no
> computation is 
> being done: you generate the 2 billion spheres once, and then wait to
> react 
> quickly to a change in camera position.
> 
> A midrange card like the $600 Quadro FX 1700 does only 190 million
> triangles per 
> second, which implies about 2 million navigable spheres.
> 
> Bruce Sherwood
> 
> Tim Smith (25121) wrote:
>> Hmm. Would I benefit from writing the application purely in c++ (not
> my
>> preferred option)?
>> I'm treading a line between speed and flexibility of pumping out
> various
>> models, and speed of interpreting the model itself. If the model is
>> frighteningly slow to interact with then I'm sunk, but if it takes me
>> too long to produce a new model I'm also sunk.
>>
> 
> ------------------------------------------------------------------------
> ------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day 
> trial. Simplify your report design, integration and deployment - and
> focus on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
> 
> **********************************************************************
> IMPORTANT - This email and any attachments may contain confidential or privileged information intended solely for the intended recipient and / or copyrighted material.  If you are not the intended recipient you must not use, interfere with, disclose, copy or take any action with reliance on this email or any part of it. If you have received this email in error please advise the sender via return email and delete or destroy all copies of this email and attachments.  Any claim to confidentiality or privilege is not waived or lost by reason of mistaken transmission of this message.  Any unauthorised use, copying or distribution is prohibited.  Minara Resources Limited does not warrant that this email or any attachments are free of viruses and cannot guarantee the accuracy, reliability or completeness of this email and any attachments.
> 
> This footnote also confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
> 
> www.clearswift.com
> **********************************************************************

Re: [Visualpython-users] speed

[Bruce S. <Bru...@nc...>]

I'm pretty much out of my depth here, but Guy Kloss's nearly simultaneous and 
very interesting post about speed suggests that there is no royal road to speed 
+ rapid creation. For that matter, there's only so much you can get out of 
today's graphics cards.

For example, the NVIDIA Quadro FX 4600 (about $1400) is rated at 250 billion 
triangles per second (http://www.deskeng.com/articles/aaajxm.htm). Suppose a 
small sphere is approximated by 4 triangles facing you. Then the card would take 
a second to display 60 billion small spheres. To have good mouse navigation 
capabilities you would need to be able to redraw the scene in about a thirtieth 
of a second in response to a mouse move, which means that you could rotate and 
zoom only about 2 billion spheres. And that's assuming that no computation is 
being done: you generate the 2 billion spheres once, and then wait to react 
quickly to a change in camera position.

A midrange card like the $600 Quadro FX 1700 does only 190 million triangles per 
second, which implies about 2 million navigable spheres.

Bruce Sherwood

Tim Smith (25121) wrote:
> Hmm. Would I benefit from writing the application purely in c++ (not my
> preferred option)?
> I'm treading a line between speed and flexibility of pumping out various
> models, and speed of interpreting the model itself. If the model is
> frighteningly slow to interact with then I'm sunk, but if it takes me
> too long to produce a new model I'm also sunk.
> 

Re: [Visualpython-users] speed

[Tim S. (25121) <tk...@mi...>]

Hmm. Would I benefit from writing the application purely in c++ (not my
preferred option)?
I'm treading a line between speed and flexibility of pumping out various
models, and speed of interpreting the model itself. If the model is
frighteningly slow to interact with then I'm sunk, but if it takes me
too long to produce a new model I'm also sunk.



-----Original Message-----
From: Bruce Sherwood [mailto:Bru...@nc...] 
Sent: Tuesday, 17 November 2009 11:49 AM
To: Tim Smith (25121)
Cc: vis...@li...
Subject: Re: [Visualpython-users] speed

I would say that your measurements clearly show that VPython is
unsuitable for 
your task. The basic problem is that VPython is designed to facilitate
the 
creation of navigable animations, which means that rendering must be
done within 
a fraction of a second to permit responsive navigation with the mouse.
Since 
this rendering is being done in C++, not in Python (though the Python
objects 
must be referenced from the C++ code), it seems unlikely to me that some
other 
engine would give you the interactivity you're looking for, but maybe
someone 
reading this list can recommend an application that can do what you
need.

The only thing that can reduce the render time would seem to be to make
the 
spheres extremely small, so that there is little to render.

Sorry!

Bruce Sherwood

Tim Smith (25121) wrote:
> Something I've noticed with vpython is speed doesn't seem to scale up.
> In my model I found 1000 points has a render time of 17, 10,000 points
> has a render time of 170, and 50,000 point has a render time of 445.
> Once I go over the 10,000 point mark performance starts to go down
> exponentially.
> What I'm wondering, is I'll potentially have to render 1,000,000
points
> for one of my projects, is vpython unsuitable for my task and is there
a
> faster python 3d library out there? I've been really impressed with
how
> fast vpython has enabled me to produce from very detailed models, how
> ever working with such slow objects is going to drive me a little
batty
> eventually.
>

**********************************************************************
IMPORTANT - This email and any attachments may contain confidential or privileged information intended solely for the intended recipient and / or copyrighted material.  If you are not the intended recipient you must not use, interfere with, disclose, copy or take any action with reliance on this email or any part of it. If you have received this email in error please advise the sender via return email and delete or destroy all copies of this email and attachments.  Any claim to confidentiality or privilege is not waived or lost by reason of mistaken transmission of this message.  Any unauthorised use, copying or distribution is prohibited.  Minara Resources Limited does not warrant that this email or any attachments are free of viruses and cannot guarantee the accuracy, reliability or completeness of this email and any attachments.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.clearswift.com
**********************************************************************

Re: [Visualpython-users] speed

[Guy K. K. <g....@ma...>]

The weekend before last I gave a presentation at (the first) Kiwi PyCon on 
live data plotting and visualisation. I have mainly focused on (2D and 3D) 
plotting tools, but due to its unique features also included Visual Python 
into the mix.

One of these unique features was speed. When it comes to the rendering of 
individual, unrelated objects, I have not seen anything faster than Visual. 
Some tools (maybe Mayavi) may be faster (or as fast) on structured data (that 
is e. g. vector fields in a cartesian array), but whenever I had to 
individually create and manage many data points, Visual was just the best in 
speed as compared with the other tools I'm familiar with.

Having said that, Mayavi also provides an API that tries to be (somewhat) 
compatible to Visual (I think to Visual 3.x). But it wasn't nearly as fast as 
Visual. If you for example run the doublependulum.py example from both, you'll 
be amazed how speedy the pendulum swings by, and that's just with less than 10 
rendered objects. But there also performance can be increased by setting the 
environment variable ETS_TOOLKIT=qt4 (to use the Qt4 backend, it's using "wx" 
by default). Still, speed is not nearly as fast, due to the fact that Mayavi 
goes through these abstraction layers:

	Python -> Traits -> VTKPython -> VTK -> OpenGL

And Visual goes

	Python -> C++ -> OpenGL

Of course, Mayavi has got grand additional nifty features due to that, but 
they do hinder execution speed quite significantly.

My slides of the talk are here:

http://www.slideshare.net/XEmacs/python-data-plotting-and-visualisation-
extravaganza

And a paper is soon to be available in The Python Paper Monograph Series issue 
for the Kiwi PyCon proceedings (see http://pythonpapers.org)

Guy

-- 
Guy K. Kloss
Institute of Information and Mathematical Sciences
Te Kura Pūtaiao o Mōhiohio me Pāngarau
Massey University, Albany (North Shore City, Auckland)
473 State Highway 17, Gate 1, Mailroom, Quad B Building
voice: +64 9 414-0800 ext. 9585   fax: +64 9 441-8181
G....@ma... http://www.massey.ac.nz/~gkloss

Re: [Visualpython-users] speed

[Bruce S. <Bru...@nc...>]

I would say that your measurements clearly show that VPython is unsuitable for 
your task. The basic problem is that VPython is designed to facilitate the 
creation of navigable animations, which means that rendering must be done within 
a fraction of a second to permit responsive navigation with the mouse. Since 
this rendering is being done in C++, not in Python (though the Python objects 
must be referenced from the C++ code), it seems unlikely to me that some other 
engine would give you the interactivity you're looking for, but maybe someone 
reading this list can recommend an application that can do what you need.

The only thing that can reduce the render time would seem to be to make the 
spheres extremely small, so that there is little to render.

Sorry!

Bruce Sherwood

Tim Smith (25121) wrote:
> Something I've noticed with vpython is speed doesn't seem to scale up.
> In my model I found 1000 points has a render time of 17, 10,000 points
> has a render time of 170, and 50,000 point has a render time of 445.
> Once I go over the 10,000 point mark performance starts to go down
> exponentially.
> What I'm wondering, is I'll potentially have to render 1,000,000 points
> for one of my projects, is vpython unsuitable for my task and is there a
> faster python 3d library out there? I've been really impressed with how
> fast vpython has enabled me to produce from very detailed models, how
> ever working with such slow objects is going to drive me a little batty
> eventually.
>

[Visualpython-users] speed

[Tim S. (25121) <tk...@mi...>]

Something I've noticed with vpython is speed doesn't seem to scale up.
In my model I found 1000 points has a render time of 17, 10,000 points
has a render time of 170, and 50,000 point has a render time of 445.
Once I go over the 10,000 point mark performance starts to go down
exponentially.
What I'm wondering, is I'll potentially have to render 1,000,000 points
for one of my projects, is vpython unsuitable for my task and is there a
faster python 3d library out there? I've been really impressed with how
fast vpython has enabled me to produce from very detailed models, how
ever working with such slow objects is going to drive me a little batty
eventually.

**********************************************************************
IMPORTANT - This email and any attachments may contain confidential or privileged information intended solely for the intended recipient and / or copyrighted material.  If you are not the intended recipient you must not use, interfere with, disclose, copy or take any action with reliance on this email or any part of it. If you have received this email in error please advise the sender via return email and delete or destroy all copies of this email and attachments.  Any claim to confidentiality or privilege is not waived or lost by reason of mistaken transmission of this message.  Any unauthorised use, copying or distribution is prohibited.  Minara Resources Limited does not warrant that this email or any attachments are free of viruses and cannot guarantee the accuracy, reliability or completeness of this email and any attachments.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.clearswift.com
**********************************************************************

Re: [Visualpython-users] degenerate curve case

[Bruce S. <Bru...@nc...>]

Thanks. Can you pass along the program that generates this error?

Bruce Sherwood

Tim Smith (25121) wrote:
> Hi, I’ve run into a problem with one of my models, I get the following 
> error (can’t paste text it crashes and won’t let me highlight text)
> 
> <<crash.JPG>>
> 

Re: [Visualpython-users] instructions: VPython for Ubuntu Karmic

[Andrew M. <amo...@de...>]

Ah...okay, that explains it.  I was used to getting a warning
indicating that my card didn't support Pixel Shader.  With my
new-to-me card, I expected that it would support PS 3.0, but it does
not.  Strange that no warning appeared, but I understand it now.

On Mon, Nov 16, 2009 at 12:19 PM, Bruce Sherwood
<Bru...@nc...> wrote:
>
>  From the download page at vpython.org (and also found in the materials
> section of the Visual documentation):
>
> Materials such as wood
>
> Materials such as wood will work with graphics cards that support Pixel
> Shader 3.0 ("PS 3.0"). See
> http://en.wikipedia.org/wiki/Pixel_shader#Hardware. Some materials may
> work with graphics cards that support PS 2.0, but other materials may
> need to be manually disabled; see instructions in the site-settings.py
> module in the Visual package in your site-packages folder. If the
> graphics hardware does not support pixel shaders, the material property
> is ignored. If you think you should be able to use materials but have
> trouble with their display or performance, we highly recommend upgrading
> your video card drivers to the latest version.
>
> Other features new in Visual 5, such as transparency and local lights,
> work with all graphics cards.
>
> Bruce Sherwood
>
> Andrew Morrison wrote:
>>
>> I'm happy that my Vpython module now works, although I am unable to
>> use the textures.  Is there anything in the new boost modules that
>> would prevent the textures from showing up, or is it more likely a
>> problem with my graphics card?   This installation was the first
>> chance I've had to try the textures, so I'm lost on what to look for
>> in terms of configuration.
>>
>> Thanks again!
>>
>> Andrew
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>> trial. Simplify your report design, integration and deployment - and focus on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Visualpython-users mailing list
>> Vis...@li...
>> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>

Re: [Visualpython-users] instructions: VPython for Ubuntu Karmic

[Bruce S. <Bru...@nc...>]

 From the download page at vpython.org (and also found in the materials 
section of the Visual documentation):

Materials such as wood

Materials such as wood will work with graphics cards that support Pixel 
Shader 3.0 ("PS 3.0"). See
http://en.wikipedia.org/wiki/Pixel_shader#Hardware. Some materials may 
work with graphics cards that support PS 2.0, but other materials may 
need to be manually disabled; see instructions in the site-settings.py 
module in the Visual package in your site-packages folder. If the 
graphics hardware does not support pixel shaders, the material property 
is ignored. If you think you should be able to use materials but have 
trouble with their display or performance, we highly recommend upgrading 
your video card drivers to the latest version.

Other features new in Visual 5, such as transparency and local lights, 
work with all graphics cards.

Bruce Sherwood

Andrew Morrison wrote:
> 
> I'm happy that my Vpython module now works, although I am unable to
> use the textures.  Is there anything in the new boost modules that
> would prevent the textures from showing up, or is it more likely a
> problem with my graphics card?   This installation was the first
> chance I've had to try the textures, so I'm lost on what to look for
> in terms of configuration.
> 
> Thanks again!
> 
> Andrew
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users

Re: [Visualpython-users] instructions: VPython for Ubuntu Karmic

[Andrew M. <amo...@de...>]

On Sun, Nov 15, 2009 at 6:50 PM, Guy K. Kloss <g....@ma...> wrote:
> All the lines beginning with a "$" are prompts on the command line. So use
> your favourite console to do these tasks according to these steps below.
> Hopefully the fixed libboost packages will move soon to karmic-updates, but as
> long as they are not there, yet, please follow these instructions.
>
>  * Add the repository that contain the fixed Boost libraries, you'll probably
>   be prompted for your password on this call:
>
> $ sudo add-apt-repository ppa:ajmitch
>
>  * Update your local repository content list and install the update(s):
>
> $ sudo aptitude update
> $ sudo aptitude full-upgrade
>
>  * If you haven't done so, yet, install the VPython package from Ubuntu, named
>   python-visual:
>
> $ sudo aptitude install python-visual
>
>  * Test the install by using one (some) of the samples, e. g.
>   doublependulum.py:
>
> $ cd /usr/share/doc/python-visual/examples/
> $ python doublependulum.py
>
> Hope that helps,


Guy,

Thanks for the simple, straightforward instructions.  I was able to
install the boost libraries.

I can also confirm the error reported here:

https://bugs.launchpad.net/ubuntu/+source/boost1.38/+bug/457688/comments/14

and that I was able to fix it by installing the
libgtkglextmm-x11-1.2-dev package and all its dependencies.  I see you
suggested that this be reported as a separate bug of python-visual,
which I see was done here:

https://bugs.launchpad.net/ubuntu/+source/python-visual/+bug/482928

I'm happy that my Vpython module now works, although I am unable to
use the textures.  Is there anything in the new boost modules that
would prevent the textures from showing up, or is it more likely a
problem with my graphics card?   This installation was the first
chance I've had to try the textures, so I'm lost on what to look for
in terms of configuration.

Thanks again!

Andrew

[Visualpython-users] instructions: VPython for Ubuntu Karmic

[Guy K. K. <g....@ma...>]

All the lines beginning with a "$" are prompts on the command line. So use 
your favourite console to do these tasks according to these steps below. 
Hopefully the fixed libboost packages will move soon to karmic-updates, but as 
long as they are not there, yet, please follow these instructions.

 * Add the repository that contain the fixed Boost libraries, you'll probably
   be prompted for your password on this call:

$ sudo add-apt-repository ppa:ajmitch

 * Update your local repository content list and install the update(s):

$ sudo aptitude update
$ sudo aptitude full-upgrade

 * If you haven't done so, yet, install the VPython package from Ubuntu, named
   python-visual:

$ sudo aptitude install python-visual

 * Test the install by using one (some) of the samples, e. g.
   doublependulum.py:

$ cd /usr/share/doc/python-visual/examples/
$ python doublependulum.py

Hope that helps,

Guy

-- 
Guy K. Kloss
Institute of Information and Mathematical Sciences
Te Kura Pūtaiao o Mōhiohio me Pāngarau
Massey University, Albany (North Shore City, Auckland)
473 State Highway 17, Gate 1, Mailroom, Quad B Building
voice: +64 9 414-0800 ext. 9585   fax: +64 9 441-8181
G....@ma... http://www.massey.ac.nz/~gkloss

Re: [Visualpython-users] a fix for Ubuntu Karmic is available

[Guy K. K. <g....@ma...>]

On Thu, 12 Nov 2009 08:46:33 Guy K. Kloss wrote:
> good news! Andrew has tracked down a fix by backporting a patch from 
> Boost.Python's Py3k development to the current Boost 1.38 libraries as
>  they're  present in the current Ubuntu release (Karmic, 9.10).

Please, do not mail Andrew directly on this issue. He's a friendly guy, and 
very helpful. But he's *not* involved with VPython at all, just aided in 
tracking down the issues in Boost.Python as he's got some expertise there.

If yo've got something towards the existing *Boost* bug, add a comment to this 
bug report:

https://bugs.launchpad.net/ubuntu/+source/boost1.38/+bug/457688

In all other cases involving VPython directly (or rather the Ubuntu python-
visual package), open a new bug report or see if an existing one fits your 
description.

Guy


-- 
Guy K. Kloss
Institute of Information and Mathematical Sciences
Te Kura Pūtaiao o Mōhiohio me Pāngarau
Massey University, Albany (North Shore City, Auckland)
473 State Highway 17, Gate 1, Mailroom, Quad B Building
voice: +64 9 414-0800 ext. 9585   fax: +64 9 441-8181
G....@ma... http://www.massey.ac.nz/~gkloss

Re: [Visualpython-users] basic questions

[Bruce S. <Bru...@nc...>]

You may find it interesting and useful to set scene.show_rendertime = True. It 
will show you the "cycle" time (how many milliseconds between runnings of the 
rendering thread) and the "render" time (how many milliseconds it takes to 
render the scene). Since you find zooming and rotating to be very slow, 
presumably you'll see very large cycle times and very large render times.

I don't recognize the description you give of "wild" rotations. You might try a 
very small data set first. It's possible that what's happening is that in the 
very long time interval between renders you're making very large mouse movements 
corresponding to very large rotations, with long delays before the effect is 
seen, so the viewing is basically out of control.

Bruce Sherwood

Tim Smith (25121) wrote:
> I pulled out one dataset we may use of 208,352 spheres ( I will try
> points soon). The initial scene renders quickly but zooming and panning
> of the image is very slow.
> When I say it's wild, it seems like my scene is rotating on a huge axis,
> where I want my scene to flip and spin while staying in the centre of
> the screen. Right now when I right click and drag down my model flys off
> the display and does a big circle till it comes back around on the
> screen. Could this be todo with the data set I'm rendering ??
> 
> 
> -----Original Message-----
> From: Bruce Sherwood [mailto:Bru...@nc...] 
> Sent: Saturday, 14 November 2009 12:29 PM
> To: vis...@li...
> Subject: Re: [Visualpython-users] basic questions
> 
> VPython implements a second "rendering" thread which about 25 times per
> second 
> interrupts your computations to create a 3D image (using OpenGL) from
> the 
> current attributes of the objects, and the current (mouse-determined)
> "camera" 
> viewing angle. A complete rendering is done each time (25 per second)
> even if no 
> object has changed nor the camera has moved. For this reason performance
> with 
> very large numbers of objects is likely to be poor, but it's easy enough
> to test 
> simply by creating a very large number of objects. You could make the
> window 
> invisible while computing, so as not to be interrupted by rendering, but
> once 
> you make the window visible you may see poor performance for zooming and
> rotating.
> 
> The cheapest object to render is "points" which makes 2D disks or
> squares 
> positioned at 3D locations. It is moreover an array object, with a list
> for the 
> positions of the points.
> 
> Please say more about your question regarding zoom and rotate. What is
> "wild" 
> about using the mouse to rotate or zoom the camera for looking at the
> scene?
> 
> There is documentation on mouse manipulations in the Visual help
> available on 
> the Help menu in IDLE. Under Windows, Events, & Files see Mouse Events.
> Also, in 
> the contributed section of vpython.org are some example programs that do
> fancy 
> things with the mouse. And see the Tutorial on the first page of the
> help for 
> the basics on using the mouse to zoom and rotate.
> 
> Bruce Sherwood
> 
> Tim Smith (25121) wrote:
>> 1.      Can vpython handle large datasets? I'm considering using it
> for 
>> a project modelling a large geographical body, I might need to plot 
>> 1,000,000 points or more.
>>
>> 2.      What would be the best object to use ?
>>
>> 3.      Is there a tutorial on mouse manipulation so I can zoom in and
> 
>> out and rotate my object? The default behaviour seems a bit wild
> 

Re: [Visualpython-users] basic questions

[Tim S. (25121) <tk...@mi...>]

I pulled out one dataset we may use of 208,352 spheres ( I will try
points soon). The initial scene renders quickly but zooming and panning
of the image is very slow.
When I say it's wild, it seems like my scene is rotating on a huge axis,
where I want my scene to flip and spin while staying in the centre of
the screen. Right now when I right click and drag down my model flys off
the display and does a big circle till it comes back around on the
screen. Could this be todo with the data set I'm rendering ??


-----Original Message-----
From: Bruce Sherwood [mailto:Bru...@nc...] 
Sent: Saturday, 14 November 2009 12:29 PM
To: vis...@li...
Subject: Re: [Visualpython-users] basic questions

VPython implements a second "rendering" thread which about 25 times per
second 
interrupts your computations to create a 3D image (using OpenGL) from
the 
current attributes of the objects, and the current (mouse-determined)
"camera" 
viewing angle. A complete rendering is done each time (25 per second)
even if no 
object has changed nor the camera has moved. For this reason performance
with 
very large numbers of objects is likely to be poor, but it's easy enough
to test 
simply by creating a very large number of objects. You could make the
window 
invisible while computing, so as not to be interrupted by rendering, but
once 
you make the window visible you may see poor performance for zooming and
rotating.

The cheapest object to render is "points" which makes 2D disks or
squares 
positioned at 3D locations. It is moreover an array object, with a list
for the 
positions of the points.

Please say more about your question regarding zoom and rotate. What is
"wild" 
about using the mouse to rotate or zoom the camera for looking at the
scene?

There is documentation on mouse manipulations in the Visual help
available on 
the Help menu in IDLE. Under Windows, Events, & Files see Mouse Events.
Also, in 
the contributed section of vpython.org are some example programs that do
fancy 
things with the mouse. And see the Tutorial on the first page of the
help for 
the basics on using the mouse to zoom and rotate.

Bruce Sherwood

Tim Smith (25121) wrote:
> 1.      Can vpython handle large datasets? I'm considering using it
for 
> a project modelling a large geographical body, I might need to plot 
> 1,000,000 points or more.
> 
> 2.      What would be the best object to use ?
> 
> 3.      Is there a tutorial on mouse manipulation so I can zoom in and

> out and rotate my object? The default behaviour seems a bit wild

------------------------------------------------------------------------
------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008
30-Day 
trial. Simplify your report design, integration and deployment - and
focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Visualpython-users mailing list
Vis...@li...
https://lists.sourceforge.net/lists/listinfo/visualpython-users

**********************************************************************
IMPORTANT - This email and any attachments may contain confidential or privileged information intended solely for the intended recipient and / or copyrighted material.  If you are not the intended recipient you must not use, interfere with, disclose, copy or take any action with reliance on this email or any part of it. If you have received this email in error please advise the sender via return email and delete or destroy all copies of this email and attachments.  Any claim to confidentiality or privilege is not waived or lost by reason of mistaken transmission of this message.  Any unauthorised use, copying or distribution is prohibited.  Minara Resources Limited does not warrant that this email or any attachments are free of viruses and cannot guarantee the accuracy, reliability or completeness of this email and any attachments.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.clearswift.com
**********************************************************************