visualpython-users

[Visualpython-users] Installing Vpython.beta16 on Fedora 8

[bradley <bj...@nc...>]

I am having some trouble installing on Fedora 8.  I think its trying to 
tell me I don't have numpy or numeric, but I definitely do.  The 
build.log and config.log are attached.  I got the error while running make.

Would creating a symbolic link somewhere fix this?  I can confirm these 
packages are installed...
gcc-c++
boost
boost-devel
gtkglextmm
gtkglextmm-devel
libglademm24-devel 
python
numpy
python-numarray
numeric

[Visualpython-users] Packaing gtk+quartz

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

I ran across "an example of how to build a native, bundled app with 
gtk-quartz":

http://developer.imendio.com/node/145

Bruce Sherwood

[Visualpython-users] From newbie: major performance woes

[Ting L. <dri...@gm...>]

Just a suggestion, Jiang. Give a try of VMD. It also support Python
scripting and it's designed to visualize the model you have. Good Luck! Ting

Re: [Visualpython-users] From newbie: major performance woes

[Jiang Q. <jq...@ph...>]

On Wed, Nov 07, 2007 at 10:46:36PM -0500, Bruce Sherwood wrote:
> The URL to the program was omitted from the previous note:
> 
> 	http://physics.harvard.edu/~jqian/vector.py)
> 
> I don't see any of the crashes on Ubuntu that you see. You might try 
> updating your graphics card driver, a frequent source of problems of the 
> kind you describe.
I'm using the latest proprietary graphic driver fglrx. At the end of the 
email the I'll put the output of my glxinfo. As I said, all the crazy 
openGL 3D stuff like stellarium, googleearth and the stable version of 
visual runs just fine. So I'm skeptical that my openGL implementation is 
at fault---so far the beta version of visual is the only openGL 
application that does not work on my rig.
> 
> I do however see the slowness (even with shininess=0 and the 
> experimental scene.lod=-6), and this is one of the issues in the beta 
> version that needs to be addressed. I'm stunned that in the production 
> version of Visual rotation is smooth, as there are more than 9000 spheres!
Well, I'll have to say 9000 spheres are not a good measure for the 
rendering, because after all what we see is a two dimensional projection 
of a 3D pack, and if we view from the outside, we see around 9000^(2/3) 
of about 400 spheres on the surface as the spheres are packed pretty 
tightly and cover each other. But still, it's quite when we see the 
surface.  However, what really helps me is the fact that I'm able to 
zoom into the system and rotate to maneuver and "walk" inside the 
system. When I do that, my system is slower but still usable in the 
production version. So I'm happy about it, no doubt, and it'll really be 
wonderful if I can deliver transparency with an acceptable performance 
cost. 

BTW, is there a way to install both the production and beta version and 
to choose them from runtime? I set the directory of the production 
system to be /usr/local and the beta to be /usr when configuring, but it 
seems that the beta doesn't like the presence of production system and 
crash if I don't remove the /usr/local packages.
Jiang
> 
> I'm particularly grateful to have this example program, because it has 
> uncovered a bizarre bug. I modified all the spheres to have shininess=0, 
> in the hopes that this would improve performance. To my great surprise, 
> the spheres continued to have specular highlights. Then I found that 
> only if I comment out the initial lines that create boxes, the spheres 
> lose their shininess. This is a very strange interaction.
> Bruce Sherwood



glxinfo

direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
    GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating,
    GLX_EXT_import_context, GLX_OML_swap_method, 
GLX_SGI_make_current_read,
    GLX_SGIS_multisample, GLX_SGIX_fbconfig
client glx vendor string: SGI
client glx version string: 1.4
client glx extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, 
GLX_EXT_import_context,
    GLX_EXT_visual_info, GLX_EXT_visual_rating, 
GLX_MESA_allocate_memory,
    GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control,
    GLX_MESA_swap_frame_usage, GLX_OML_swap_method, 
GLX_OML_sync_control,
    GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync,
    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,
    GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap
GLX extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, 
GLX_EXT_import_context,
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_OML_swap_method,
    GLX_SGIS_multisample, GLX_SGIX_fbconfig
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: ATI MOBILITY RADEON X300
OpenGL version string: 2.0.6958 Release

Re: [Visualpython-users] From newbie: major performance woes

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

Yeah, I guess that note isn't well written at that. I think the "Note" 
refers to an earlier version of this description that may have said 1.30 
was the minimum required, but not if you were using Python 2.3 or 
higher. I should dig back in the archives and correct this prose. Thanks.

Bottom line: 1.31 is supposed to be okay, but later should be better.

Bruce Sherwood

Jiang Qian wrote:
> On Wed, Nov 07, 2007 at 10:51:17PM -0500, Bruce Sherwood wrote:
>> I should have commented about your question about boost. Here are the 
>> relevant comments from INSTALL.txt, included in the source package:
>>
>> The Boost C++ libraries version 1.31 and higher (1.33.1 reccomended) 
>> (www.boost.org). Note that 1.31 is required if you are using Python 2.3 
>> or higher, and is recommended in any case due to getting much better 
>> error messages. 1.32.0 or higher is required if you want to use GNU G++ 
>> 3.4.0 or higher to build the suite.
> Yes I read that, I take that to mean my boost 1.31 will work, but is not 
> optimal, as I have gcc 3.3.4. However I'm confused by the sentence that 
> you required boost 1.31 or higher, but in the next sentence "Note..." 
> you said again boost 1.31 is required. Does that mean only this version 
> is good?
> Jiang
>> Bruce Sherwood
>>
>> Jiang Qian wrote:
>>> On Wed, Nov 07, 2007 at 10:11:32AM -0500, Bruce Sherwood wrote:
>>> Now one worry about my ancient ubuntu is 
>>> that my libboost version is still 1.31. Would that be a problem?

[Visualpython-users] Taiwan laptop with VPython

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

I received this note from cc...@ma...:

It is very hard to introduce Vpython outside class where Vpython had 
been installed since not every one has enough experience to install 
softwares, for instances: python and vpython etc.

Now it is a good news for Python and Vpython users:

Asus begins to sell a linux-based PC, Eee PC only 900g weight and cost 
about US$300! LiveTeXmacs (A distro remastered from KNOPPIX-5.1 and 
includes Python-2.5.1, Vpython and other killer python packages)  can 
run on such small PC. It means that VPython can play more flexibly than 
ever.

Some pictures and a flash demo about "Vython on Eee PC" can be found at

http://diffusion.cgu.edu.tw:8080/2007

Best regards,

chu-ching huang

Re: [Visualpython-users] From newbie: major performance woes

[Jiang Q. <jq...@ph...>]

On Wed, Nov 07, 2007 at 10:51:17PM -0500, Bruce Sherwood wrote:
> I should have commented about your question about boost. Here are the 
> relevant comments from INSTALL.txt, included in the source package:
> 
> The Boost C++ libraries version 1.31 and higher (1.33.1 reccomended) 
> (www.boost.org). Note that 1.31 is required if you are using Python 2.3 
> or higher, and is recommended in any case due to getting much better 
> error messages. 1.32.0 or higher is required if you want to use GNU G++ 
> 3.4.0 or higher to build the suite.
Yes I read that, I take that to mean my boost 1.31 will work, but is not 
optimal, as I have gcc 3.3.4. However I'm confused by the sentence that 
you required boost 1.31 or higher, but in the next sentence "Note..." 
you said again boost 1.31 is required. Does that mean only this version 
is good?
Jiang
> 
> Bruce Sherwood
> 
> Jiang Qian wrote:
> >On Wed, Nov 07, 2007 at 10:11:32AM -0500, Bruce Sherwood wrote:
> >Now one worry about my ancient ubuntu is 
> >that my libboost version is still 1.31. Would that be a problem?

Re: [Visualpython-users] From newbie: major performance woes

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

I should have commented about your question about boost. Here are the 
relevant comments from INSTALL.txt, included in the source package:

The Boost C++ libraries version 1.31 and higher (1.33.1 reccomended) 
(www.boost.org). Note that 1.31 is required if you are using Python 2.3 
or higher, and is recommended in any case due to getting much better 
error messages. 1.32.0 or higher is required if you want to use GNU G++ 
3.4.0 or higher to build the suite.

Bruce Sherwood

Jiang Qian wrote:
> On Wed, Nov 07, 2007 at 10:11:32AM -0500, Bruce Sherwood wrote:
> Now one worry about my ancient ubuntu is 
> that my libboost version is still 1.31. Would that be a problem?

Re: [Visualpython-users] From newbie: major performance woes

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

The URL to the program was omitted from the previous note:

	http://physics.harvard.edu/~jqian/vector.py)

I don't see any of the crashes on Ubuntu that you see. You might try 
updating your graphics card driver, a frequent source of problems of the 
kind you describe.

I do however see the slowness (even with shininess=0 and the 
experimental scene.lod=-6), and this is one of the issues in the beta 
version that needs to be addressed. I'm stunned that in the production 
version of Visual rotation is smooth, as there are more than 9000 spheres!

I'm particularly grateful to have this example program, because it has 
uncovered a bizarre bug. I modified all the spheres to have shininess=0, 
in the hopes that this would improve performance. To my great surprise, 
the spheres continued to have specular highlights. Then I found that 
only if I comment out the initial lines that create boxes, the spheres 
lose their shininess. This is a very strange interaction.

Bruce Sherwood

Jiang Qian wrote:
> On Wed, Nov 07, 2007 at 10:11:32AM -0500, Bruce Sherwood wrote:
>> The beta version is called the beta version because there are problems 
>> with it, and it's helpful to have your report of what doesn't work; 
>> there have been almost no reports from Linux users. I normally work on 
>> Windows but have tested the Linux beta version against a variety of 
>> applications. I had concluded that the beta version mostly works okay on 
>> Linux, while there are serious bugs on Windows. You're reporting that it 
>> isn't okay even on Linux, which I was not aware of.
> In addition to the testing I reported to be not working properly, the 
> stonehenge example crash the beta immediately after launch. And hanoi.py 
> shows a lot of artefacts and becomes slow and pretty much unusable.
>> My own testing was done on a more recent version of Ubuntu, though that 
>> seems an unlikely issue, and your hardware is certainly adequate 
>> (presumably your 1.86MHz processor is a typo; it must be 1.86GHz).
> Yes of course that's a typo. Now one worry about my ancient ubuntu is 
> that my libboost version is still 1.31. Would that be a problem?
>> Because I'm trying to get into working on the problems with the beta 
>> version myself, it could be helpful if you would send me an example of a 
>> program where interactivity is compromised, to add to my suite of test 
>> programs.
> Please find in this URL a program of visualizing 9288 spheres in a 27 
> unit cell random non-overlapping distributions. Colors marks the grain 
> boundaries. It the stable version, I can rotate the pack at will, zoom 
> in, etc. This is so even when I improve the sphere rendering smoothness 
> by decreasing the two if(size <0.02) if(size<=0.125)... lines to 0.004 
> and 0.125 respectively. The stock stable 3.2.9 presumably would be even 
> faster.
> 
> However, in the beta version, I cannot rotate the pack at will, 
> interactivity becomes inadequate.
>> There isn't a simple patch to make the production version have 
>> transparency. There was a major change in the fundamental architecture 
>> of Visual to make transparency a possibility.
>>
>> As stated in the description of the points object, these are circles or 
>> squares, not spheres, of particular use in plotting graphs. They may or 
>> may not be of any use to you. I would think that they're a lot faster 
>> than spheres.
> Too bad.
>> The late Arthur Siegel did experiment a bit with specifying the level of 
>> detail for the rendering of spheres. There is an undocumented attribute 
>> of the "display" object:
>>
>> scene.lod = -3 # range is -6 (low level of detail) to 0 (high)
>> sphere()
>>
>> I don't like having negative values for "level of display" (lod), so 
>> think of this as very experimental, but it will let you try some things. 
>> Alternatively, since you evidently have a lot of experience, you could 
>> make changes of your own to the internal workings of Visual to 
>> experiment with the issues. Thanks much for your report.
> Unfortunately I really kind of need to actually use visual to help me 
> intuitively grasp some problems in my research, so I can't afford to 
> play it too much. So I decided to forgo transparency for now and revert 
> back to the stable version. Thanks for the help, though.
> Jiang
>> Bruce Sherwood
>>
>> Jiang Qian wrote:
>>> Hi:
>>> 	Sorry about the confusing subject line of my last email. I did 
>>> manage to compile the beta, I just have major performance problem.
>>> 	I took a look at the code of sphere.cpp, and notice there's 
>>> discussion about levels of details. I wonder, however, are all that 
>>> exposed to the user? Is there anyway I can reduce the level of details 
>> >from my script? Or if that's not possible, is it possible to in fact 
>>> change the code manually and recompile?
>>> 	Another issue that may or may not have anything to do with my 
>>> performance woes. There are several demos in the example directory does 
>>> not run properly in my installation. Drape shows only a rod. Double 
>>> pendulum is way slower than in 3.4, Hanoi shows artifacts whenever I 
>>> move a ring. I'm beginning to think there might be something wrong with 
>>> my beta installation. How can I check?
>>> 	Thanks in advance for your help.
>>> 								Jiang
>>>
>>> On Wed, Nov 07, 2007 at 01:35:57AM -0500, Jiang Qian wrote:
>>>> Hi all:
>>>> 	I'm new to this list. I installed the stable visual-3.2.9 and it 
>>>> worked great. But I really would like to to get the transparency to 
>>>> work.  So I installed visual 4.beta16. I jumped through all sorts of 
>>>> hoops, and finally got it to work. The transparency works quite well. 
>>>> But I have serious performance issue.
>>>> 	I mainly use visual to visualize packed spheres, and small 
>>>> particles inside the spaces between them. In visual 3.2.9, a system with 
>>>> a few hundred spheres packed inside a cube works very smoothly: I can 
>>>> rotate, zoom at will with middle and right button. By combining the two, 
>>>> I can essentially "walk" into the sphere packs.(The spheres rendered are 
>>>> not perfectly smooth, but I manually changed some lines in the source 
>>>> code to make the smoothness ok). It all works fine, the only thing I 
>>>> miss is transparency.
>>>> 	However, in visual 4.beta16, using identical code(with *no* 
>>>> transparency yet), I get a spectacularly smooth and well lit spheres, 
>>>> but the tradeoff seem to be heavy performance penalty: I can barely zoom 
>>>> and move, the rotation is slow. Interactive zooming and rotation is the 
>>>> key reason why I use visual: otherwise I can just render things in 
>>>> povray. Needless to say, I would like to find a way to trade away some 
>>>> of the more spectacular visual effects to have better interactive 
>>>> performance.
>>>> 	I tried to look through the documentation of beta, but there 
>>>> aren't too much info about performance tuning. The only thing I found is 
>>>> to set shininess to 0, which helps marginally at best.
>>>> 	What other tricks can I use to improve interactive performance?  
>>>> For example, can I tune the smoothness of the spheres? Sometimes my cpu 
>>>> usage is not even fully 100%, but dragging, rotating and zooming the 
>>>> image is still very slow.
>>>> 	It'll really be a shame if I have to revert to the old version 
>>>> due to performance issue.  There must be a way to balance performance 
>>>> and effects.
>>>> 	In a related issue. I also need to render particles between the 
>>>> spheres in the pack. In the old version, I basically render them as 
>>>> smaller spheres. But in the new version, there's a mention of point 
>>>> objects, which seems to be just for that purpose. However, there's not 
>>>> too much documentation of the point objects. How do I use them? Do they 
>>>> offer a lighter overhead than the render spheres? Can I give them 
>>>> colors?
>>>> 	On the final note, a word about my system: I have a thinkpad 
>>>> T43, with Pentium M Dothan 1.86MHz, 1GB PC2-4200 memory, ATI X300 mobile 
>>>> discrete graphics(M22) with 64MB of VRAM, and 60GB 7200rpm disk. It's 
>>>> not a powerful machine by today's standard, but it runs the old version 
>>>> of visual just fine. Also, runs other 3D accelerated openGL programs 
>>>> like googleearth and stellarium just fine(glxgears score, which I know 
>>>> is not a benchmark, is around 1750 FPS).
>>>> 	The software environment is an outdated ubuntu(5.04), with 
>>>> custom compiled 2.6.18 kernel, gcc version 3.3.5, python 2.4, fglrx 
>>>> proprietary driver 8.42.3(latest).  Numpy 1.0.3, the latest gtkglxtmm I 
>>>> compiled and installed from source.  If you want to know more, let me 
>>>> know what more relevant info I can give.
>>>> 	If there's a simple patch for the stable version 3.2.9 that 
>>>> enables transparency, I'll be very happy to use that, too. Because 
>>>> really the stable version satisfies all my need except for 
>>>> transparencies.
>>>> 	Thank you all for any hint/help you can give.
>>>> 								Jiang
>>>>
>>>> -------------------------------------------------------------------------
>>>> This SF.net email is sponsored by: Splunk Inc.
>>>> Still grepping through log files to find problems?  Stop.
>>>> Now Search log events and configuration files using AJAX and a browser.
>>>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>>>> _______________________________________________
>>>> Visualpython-users mailing list
>>>> Vis...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>>> -------------------------------------------------------------------------
>>> This SF.net email is sponsored by: Splunk Inc.
>>> Still grepping through log files to find problems?  Stop.
>>> Now Search log events and configuration files using AJAX and a browser.
>>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>>> _______________________________________________
>>> Visualpython-users mailing list
>>> Vis...@li...
>>> https://lists.sourceforge.net/lists/listinfo/visualpython-users

Re: [Visualpython-users] From newbie: major performance woes

[Jiang Q. <jq...@ph...>]

On Wed, Nov 07, 2007 at 10:11:32AM -0500, Bruce Sherwood wrote:
> The beta version is called the beta version because there are problems 
> with it, and it's helpful to have your report of what doesn't work; 
> there have been almost no reports from Linux users. I normally work on 
> Windows but have tested the Linux beta version against a variety of 
> applications. I had concluded that the beta version mostly works okay on 
> Linux, while there are serious bugs on Windows. You're reporting that it 
> isn't okay even on Linux, which I was not aware of.
In addition to the testing I reported to be not working properly, the 
stonehenge example crash the beta immediately after launch. And hanoi.py 
shows a lot of artefacts and becomes slow and pretty much unusable.
> 
> My own testing was done on a more recent version of Ubuntu, though that 
> seems an unlikely issue, and your hardware is certainly adequate 
> (presumably your 1.86MHz processor is a typo; it must be 1.86GHz).
Yes of course that's a typo. Now one worry about my ancient ubuntu is 
that my libboost version is still 1.31. Would that be a problem?
> 
> Because I'm trying to get into working on the problems with the beta 
> version myself, it could be helpful if you would send me an example of a 
> program where interactivity is compromised, to add to my suite of test 
> programs.
Please find in this URL a program of visualizing 9288 spheres in a 27 
unit cell random non-overlapping distributions. Colors marks the grain 
boundaries. It the stable version, I can rotate the pack at will, zoom 
in, etc. This is so even when I improve the sphere rendering smoothness 
by decreasing the two if(size <0.02) if(size<=0.125)... lines to 0.004 
and 0.125 respectively. The stock stable 3.2.9 presumably would be even 
faster.

However, in the beta version, I cannot rotate the pack at will, 
interactivity becomes inadequate.
> 
> There isn't a simple patch to make the production version have 
> transparency. There was a major change in the fundamental architecture 
> of Visual to make transparency a possibility.
> 
> As stated in the description of the points object, these are circles or 
> squares, not spheres, of particular use in plotting graphs. They may or 
> may not be of any use to you. I would think that they're a lot faster 
> than spheres.
Too bad.
> 
> The late Arthur Siegel did experiment a bit with specifying the level of 
> detail for the rendering of spheres. There is an undocumented attribute 
> of the "display" object:
> 
> scene.lod = -3 # range is -6 (low level of detail) to 0 (high)
> sphere()
> 
> I don't like having negative values for "level of display" (lod), so 
> think of this as very experimental, but it will let you try some things. 
> Alternatively, since you evidently have a lot of experience, you could 
> make changes of your own to the internal workings of Visual to 
> experiment with the issues. Thanks much for your report.
Unfortunately I really kind of need to actually use visual to help me 
intuitively grasp some problems in my research, so I can't afford to 
play it too much. So I decided to forgo transparency for now and revert 
back to the stable version. Thanks for the help, though.
Jiang
> 
> Bruce Sherwood
> 
> Jiang Qian wrote:
> >Hi:
> >	Sorry about the confusing subject line of my last email. I did 
> >manage to compile the beta, I just have major performance problem.
> >	I took a look at the code of sphere.cpp, and notice there's 
> >discussion about levels of details. I wonder, however, are all that 
> >exposed to the user? Is there anyway I can reduce the level of details 
> >from my script? Or if that's not possible, is it possible to in fact 
> >change the code manually and recompile?
> >	Another issue that may or may not have anything to do with my 
> >performance woes. There are several demos in the example directory does 
> >not run properly in my installation. Drape shows only a rod. Double 
> >pendulum is way slower than in 3.4, Hanoi shows artifacts whenever I 
> >move a ring. I'm beginning to think there might be something wrong with 
> >my beta installation. How can I check?
> >	Thanks in advance for your help.
> >								Jiang
> >
> >On Wed, Nov 07, 2007 at 01:35:57AM -0500, Jiang Qian wrote:
> >>Hi all:
> >>	I'm new to this list. I installed the stable visual-3.2.9 and it 
> >>worked great. But I really would like to to get the transparency to 
> >>work.  So I installed visual 4.beta16. I jumped through all sorts of 
> >>hoops, and finally got it to work. The transparency works quite well. 
> >>But I have serious performance issue.
> >>	I mainly use visual to visualize packed spheres, and small 
> >>particles inside the spaces between them. In visual 3.2.9, a system with 
> >>a few hundred spheres packed inside a cube works very smoothly: I can 
> >>rotate, zoom at will with middle and right button. By combining the two, 
> >>I can essentially "walk" into the sphere packs.(The spheres rendered are 
> >>not perfectly smooth, but I manually changed some lines in the source 
> >>code to make the smoothness ok). It all works fine, the only thing I 
> >>miss is transparency.
> >>	However, in visual 4.beta16, using identical code(with *no* 
> >>transparency yet), I get a spectacularly smooth and well lit spheres, 
> >>but the tradeoff seem to be heavy performance penalty: I can barely zoom 
> >>and move, the rotation is slow. Interactive zooming and rotation is the 
> >>key reason why I use visual: otherwise I can just render things in 
> >>povray. Needless to say, I would like to find a way to trade away some 
> >>of the more spectacular visual effects to have better interactive 
> >>performance.
> >>	I tried to look through the documentation of beta, but there 
> >>aren't too much info about performance tuning. The only thing I found is 
> >>to set shininess to 0, which helps marginally at best.
> >>	What other tricks can I use to improve interactive performance?  
> >>For example, can I tune the smoothness of the spheres? Sometimes my cpu 
> >>usage is not even fully 100%, but dragging, rotating and zooming the 
> >>image is still very slow.
> >>	It'll really be a shame if I have to revert to the old version 
> >>due to performance issue.  There must be a way to balance performance 
> >>and effects.
> >>	In a related issue. I also need to render particles between the 
> >>spheres in the pack. In the old version, I basically render them as 
> >>smaller spheres. But in the new version, there's a mention of point 
> >>objects, which seems to be just for that purpose. However, there's not 
> >>too much documentation of the point objects. How do I use them? Do they 
> >>offer a lighter overhead than the render spheres? Can I give them 
> >>colors?
> >>	On the final note, a word about my system: I have a thinkpad 
> >>T43, with Pentium M Dothan 1.86MHz, 1GB PC2-4200 memory, ATI X300 mobile 
> >>discrete graphics(M22) with 64MB of VRAM, and 60GB 7200rpm disk. It's 
> >>not a powerful machine by today's standard, but it runs the old version 
> >>of visual just fine. Also, runs other 3D accelerated openGL programs 
> >>like googleearth and stellarium just fine(glxgears score, which I know 
> >>is not a benchmark, is around 1750 FPS).
> >>	The software environment is an outdated ubuntu(5.04), with 
> >>custom compiled 2.6.18 kernel, gcc version 3.3.5, python 2.4, fglrx 
> >>proprietary driver 8.42.3(latest).  Numpy 1.0.3, the latest gtkglxtmm I 
> >>compiled and installed from source.  If you want to know more, let me 
> >>know what more relevant info I can give.
> >>	If there's a simple patch for the stable version 3.2.9 that 
> >>enables transparency, I'll be very happy to use that, too. Because 
> >>really the stable version satisfies all my need except for 
> >>transparencies.
> >>	Thank you all for any hint/help you can give.
> >>								Jiang
> >>
> >>-------------------------------------------------------------------------
> >>This SF.net email is sponsored by: Splunk Inc.
> >>Still grepping through log files to find problems?  Stop.
> >>Now Search log events and configuration files using AJAX and a browser.
> >>Download your FREE copy of Splunk now >> http://get.splunk.com/
> >>_______________________________________________
> >>Visualpython-users mailing list
> >>Vis...@li...
> >>https://lists.sourceforge.net/lists/listinfo/visualpython-users
> >
> >-------------------------------------------------------------------------
> >This SF.net email is sponsored by: Splunk Inc.
> >Still grepping through log files to find problems?  Stop.
> >Now Search log events and configuration files using AJAX and a browser.
> >Download your FREE copy of Splunk now >> http://get.splunk.com/
> >_______________________________________________
> >Visualpython-users mailing list
> >Vis...@li...
> >https://lists.sourceforge.net/lists/listinfo/visualpython-users

Re: [Visualpython-users] Needed Packages for Vpython Depricated

[bradley <bj...@nc...>]

Forgot to include that the packages may just be renamed and not 
depricated. 

[Visualpython-users] Needed Packages for Vpython Depricated

[bradley <bj...@nc...>]

I have found out why vpython will not run on Fedora 8.  I went to update 
and got this message...

--> Running transaction check
---> Package visual.i386 0:4.beta16-1.fc7 set to be updated
--> Processing Dependency: libboost_thread.so.2 for package: visual
--> Processing Dependency: libboost_python.so.2 for package: visual
--> Finished Dependency Resolution
Error: Missing Dependency: libboost_thread.so.2 is needed by package visual
Error: Missing Dependency: libboost_python.so.2 is needed by package visual

I looked up what boost provides and in boost-1.33 the packages 
libboost_thread.so.2 and libboost_python.so.2 are provided.  They are 
not however in boost-1.34. 

Brad Longo

[Visualpython-users] scene.exit neglected

[Martin S. <kv...@gm...>]

Setting the scene.exit to 0/1 should change the VPython window
behavior on pressing
the window close button - at least according to the manual at the webpage of
http://www.vpython.org/webdoc/visual/display.html

However, it does not change anything for me. The window is just
closed, and the rest
of a respective program (tries to) runs. Have I overlooked something?

I run python 2.5 with VPython 3.1.1 on Ubuntu Linux 7.10, and it was the same
for python 2.4 on former Ubuntu releases.

Martin

[Visualpython-users] Vpython Beta Fedora 8 RPM Problems

[bradley <bj...@nc...>]

I managed to install the tar file to get the beta version of vpython.  
When I run it I get the same error I was getting with the stable version 
of vpython.  For some reason I cannot build the rpm for the beta version 
though.  Here is the build error I'm getting.

Compiling ./core/util/atomic_queue.cpp ...
Compiling ./gtk2/random_device.cpp ...
Compiling ./gtk2/rate.cpp ...
Compiling ./gtk2/timer.cpp ...
Compiling ./gtk2/text.cpp ...
Compiling ./gtk2/render_surface.cpp ...
Compiling ./gtk2/display.cpp ...
Compiling ./python/wrap_ustring.cpp ...
Linking cvisualmodule.la ...
make[1]: *** [cvisualmodule.la] Error 1
make[1]: Leaving directory `/home/brad/rpmbuild/BUILD/visual-4.beta16/src'
make: *** [all-recursive] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.99896 (%build)


RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.99896 (%build)

P.S. The spec is the same one used to make my fc7 rpms which worked.  
Does anyone have any ideas?

Brad Longo

[Visualpython-users] Fedora 8 Packages

[bradley <bj...@nc...>]

I have made packages for vpython for fedora 8, but vpython is not 
working on it.  I'm not sure if this is a fedora issue or a vpython one 
yet.  The packages are the same as they were for fedora 7 just with 
fedora 8's name instead so I don't think it's my fault, but I won't rule 
it out.    Here is what I get whenever I try to run a vpython file.

> $ python sphere.py
>
> Gtk-WARNING **: Failed to load module "libgnomebreakpad.so": 
> libgnomebreakpad.so: cannot open shared object file: No such file or 
> directory
> Gdk-ERROR **: GLXBadContext
>   serial 106 error_code 154 request_code 143 minor_code 5
> python: xcb_xlib.c:41: xcb_xlib_lock: Assertion `!c->xlib.lock' failed.
> Aborted
This is from $strace python sphere.py.....
open("/usr/lib/python2.5/site-packages/visual/atexit.so", 
O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/python2.5/site-packages/visual/atexitmodule.so", 
O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/python2.5/site-packages/visual/atexit.py", 
O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/lib/python2.5/site-packages/visual/atexit.pyc", 
O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
stat64("/home/brad/Desktop/atexit", 0xbf8622f4) = -1 ENOENT (No such 
file or directory)
open("/home/brad/Desktop/atexit.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT 
(No such file or directory)
open("/home/brad/Desktop/atexitmodule.so", O_RDONLY|O_LARGEFILE) = -1 
ENOENT (No such file or directory)
open("/home/brad/Desktop/atexit.py", O_RDONLY|O_LARGEFILE) = -1 ENOENT 
(No such file or directory)
open("/home/brad/Desktop/atexit.pyc", O_RDONLY|O_LARGEFILE) = -1 ENOENT 
(No such file or directory)
stat64("/usr/lib/python2.5/atexit", 0xbf8622f4) = -1 ENOENT (No such 
file or directory)
open("/usr/lib/python2.5/atexit.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT 
(No such file or directory)
open("/usr/lib/python2.5/atexitmodule.so", O_RDONLY|O_LARGEFILE) = -1 
ENOENT (No such file or directory)
open("/usr/lib/python2.5/atexit.py", O_RDONLY|O_LARGEFILE) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=1631, ...}) = 0
open("/usr/lib/python2.5/atexit.pyc", O_RDONLY|O_LARGEFILE) = 5
fstat64(5, {st_mode=S_IFREG|0644, st_size=2142, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
0) = 0xb7bd5000
read(5, 
"\263\362\r\n\304o\'Gc\0\0\0\0\0\0\0\0\5\0\0\0@\0\0\0s\304\0\0\0d\0"..., 
4096) = 2142
fstat64(5, {st_mode=S_IFREG|0644, st_size=2142, ...}) = 0
read(5, "", 4096)                       = 0
close(5)                                = 0
munmap(0xb7bd5000, 4096)                = 0
close(4)                                = 0
close(3)                                = 0
mmap2(NULL, 10489856, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 
-1, 0) = 0xb71d5000
mprotect(0xb71d5000, 4096, PROT_NONE)   = 0
clone(child_stack=0xb7bd54b4, 
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, 
parent_tidptr=0xb7bd5bd8, {entry_number:6, base_addr:0xb7bd5b90, 
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, 
limit_in_pages:1, seg_not_present:0, useable:1}, 
child_tidptr=0xb7bd5bd8) = 14881
gettimeofday({1194470766, 630823}, NULL) = 0
nanosleep({0, 100000000},
Gtk-WARNING **: Failed to load module "libgnomebreakpad.so": 
libgnomebreakpad.so: cannot open shared object file: No such file or 
directory
Gdk-ERROR **: GLXBadContext
  serial 106 error_code 154 request_code 143 minor_code 5
python: xcb_xlib.c:41: xcb_xlib_lock: Assertion `!c->xlib.lock' failed.
 <unfinished ...>
+++ killed by SIGABRT +++



In addition I am having issues building the rpm for the beta version for 
some reason, but when I figure out why its giving me build errors it 
will be available with the rest.

Brad Longo

Re: [Visualpython-users] VPython on Leopard

[Frank W. P. a. A. U of R <wo...@pa...>]

I upgraded to leopard this weekend and ran vpython without a problem; this 
was one of the first things I checked.  This was with the new version of 
X11, but with vpython compiled previosuly on 10.4.

Frank

On Wed, 7 Nov 2007, Joe Heafner wrote:

> X11 is *really* broken in Leopard and that's why I've not yet
> upgraded. The X11-users mailing list is full of patches and fixes, but
> so far nothing officially from Apple. Because I too use VPython in the
> classroom, I can't install Leopard until X11 is fixed.
>
> Joe Heafner
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>

-- 

_____________________________________________________________________

  Frank L. H. Wolfs                  e-mail: wo...@pa...
  Department of Physics and Astronomy
  University of Rochester
  B&L 203A, RC Box 270171                      fax: (585) 273 - 3237
  500 Wilson Blvd.                           phone: (585) 275 - 4937
  Rochester, NY 14627              http://teacher.pas.rochester.edu/

Re: [Visualpython-users] VPython on Leopard

[Joe H. <hea...@gm...>]

X11 is *really* broken in Leopard and that's why I've not yet
upgraded. The X11-users mailing list is full of patches and fixes, but
so far nothing officially from Apple. Because I too use VPython in the
classroom, I can't install Leopard until X11 is fixed.

Joe Heafner

Re: [Visualpython-users] From newbie: major performance woes

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

The beta version is called the beta version because there are problems 
with it, and it's helpful to have your report of what doesn't work; 
there have been almost no reports from Linux users. I normally work on 
Windows but have tested the Linux beta version against a variety of 
applications. I had concluded that the beta version mostly works okay on 
Linux, while there are serious bugs on Windows. You're reporting that it 
isn't okay even on Linux, which I was not aware of.

My own testing was done on a more recent version of Ubuntu, though that 
seems an unlikely issue, and your hardware is certainly adequate 
(presumably your 1.86MHz processor is a typo; it must be 1.86GHz).

Because I'm trying to get into working on the problems with the beta 
version myself, it could be helpful if you would send me an example of a 
program where interactivity is compromised, to add to my suite of test 
programs.

There isn't a simple patch to make the production version have 
transparency. There was a major change in the fundamental architecture 
of Visual to make transparency a possibility.

As stated in the description of the points object, these are circles or 
squares, not spheres, of particular use in plotting graphs. They may or 
may not be of any use to you. I would think that they're a lot faster 
than spheres.

The late Arthur Siegel did experiment a bit with specifying the level of 
detail for the rendering of spheres. There is an undocumented attribute 
of the "display" object:

scene.lod = -3 # range is -6 (low level of detail) to 0 (high)
sphere()

I don't like having negative values for "level of display" (lod), so 
think of this as very experimental, but it will let you try some things. 
Alternatively, since you evidently have a lot of experience, you could 
make changes of your own to the internal workings of Visual to 
experiment with the issues. Thanks much for your report.

Bruce Sherwood

Jiang Qian wrote:
> Hi:
> 	Sorry about the confusing subject line of my last email. I did 
> manage to compile the beta, I just have major performance problem.
> 	I took a look at the code of sphere.cpp, and notice there's 
> discussion about levels of details. I wonder, however, are all that 
> exposed to the user? Is there anyway I can reduce the level of details 
> from my script? Or if that's not possible, is it possible to in fact 
> change the code manually and recompile?
> 	Another issue that may or may not have anything to do with my 
> performance woes. There are several demos in the example directory does 
> not run properly in my installation. Drape shows only a rod. Double 
> pendulum is way slower than in 3.4, Hanoi shows artifacts whenever I 
> move a ring. I'm beginning to think there might be something wrong with 
> my beta installation. How can I check?
> 	Thanks in advance for your help.
> 								Jiang
> 
> On Wed, Nov 07, 2007 at 01:35:57AM -0500, Jiang Qian wrote:
>> Hi all:
>> 	I'm new to this list. I installed the stable visual-3.2.9 and it 
>> worked great. But I really would like to to get the transparency to 
>> work.  So I installed visual 4.beta16. I jumped through all sorts of 
>> hoops, and finally got it to work. The transparency works quite well. 
>> But I have serious performance issue.
>> 	I mainly use visual to visualize packed spheres, and small 
>> particles inside the spaces between them. In visual 3.2.9, a system with 
>> a few hundred spheres packed inside a cube works very smoothly: I can 
>> rotate, zoom at will with middle and right button. By combining the two, 
>> I can essentially "walk" into the sphere packs.(The spheres rendered are 
>> not perfectly smooth, but I manually changed some lines in the source 
>> code to make the smoothness ok). It all works fine, the only thing I 
>> miss is transparency.
>> 	However, in visual 4.beta16, using identical code(with *no* 
>> transparency yet), I get a spectacularly smooth and well lit spheres, 
>> but the tradeoff seem to be heavy performance penalty: I can barely zoom 
>> and move, the rotation is slow. Interactive zooming and rotation is the 
>> key reason why I use visual: otherwise I can just render things in 
>> povray. Needless to say, I would like to find a way to trade away some 
>> of the more spectacular visual effects to have better interactive 
>> performance.
>> 	I tried to look through the documentation of beta, but there 
>> aren't too much info about performance tuning. The only thing I found is 
>> to set shininess to 0, which helps marginally at best.
>> 	What other tricks can I use to improve interactive performance?  
>> For example, can I tune the smoothness of the spheres? Sometimes my cpu 
>> usage is not even fully 100%, but dragging, rotating and zooming the 
>> image is still very slow.
>> 	It'll really be a shame if I have to revert to the old version 
>> due to performance issue.  There must be a way to balance performance 
>> and effects.
>> 	In a related issue. I also need to render particles between the 
>> spheres in the pack. In the old version, I basically render them as 
>> smaller spheres. But in the new version, there's a mention of point 
>> objects, which seems to be just for that purpose. However, there's not 
>> too much documentation of the point objects. How do I use them? Do they 
>> offer a lighter overhead than the render spheres? Can I give them 
>> colors?
>> 	On the final note, a word about my system: I have a thinkpad 
>> T43, with Pentium M Dothan 1.86MHz, 1GB PC2-4200 memory, ATI X300 mobile 
>> discrete graphics(M22) with 64MB of VRAM, and 60GB 7200rpm disk. It's 
>> not a powerful machine by today's standard, but it runs the old version 
>> of visual just fine. Also, runs other 3D accelerated openGL programs 
>> like googleearth and stellarium just fine(glxgears score, which I know 
>> is not a benchmark, is around 1750 FPS).
>> 	The software environment is an outdated ubuntu(5.04), with 
>> custom compiled 2.6.18 kernel, gcc version 3.3.5, python 2.4, fglrx 
>> proprietary driver 8.42.3(latest).  Numpy 1.0.3, the latest gtkglxtmm I 
>> compiled and installed from source.  If you want to know more, let me 
>> know what more relevant info I can give.
>> 	If there's a simple patch for the stable version 3.2.9 that 
>> enables transparency, I'll be very happy to use that, too. Because 
>> really the stable version satisfies all my need except for 
>> transparencies.
>> 	Thank you all for any hint/help you can give.
>> 								Jiang
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems?  Stop.
>> Now Search log events and configuration files using AJAX and a browser.
>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>> _______________________________________________
>> Visualpython-users mailing list
>> Vis...@li...
>> https://lists.sourceforge.net/lists/listinfo/visualpython-users
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users

Re: [Visualpython-users] VPython on Leopard

[Ruth C. <rwc...@nc...>]

It was visual-py24.  (Because I'm trying to understand the issues facing 
professors who have their students using VPython on computers in the 
instructional laboratories, I've tried to stick to versions they could 
reasonably expect to install on clusters of 10-30 computers.  As far as 
I can tell, only a source version of visual-py25 is available; doing a 
source install on 30 computers isn't a real option.)

I'll try visual-py25. If visual-py25 does work with Leopard's X11, is 
there a chance a binary version will become available?

    Ruth

Martin Costabel wrote:
> Ruth Chabay wrote:
>> I upgraded to Leopard on my new Mac, and VPython stopped working -- 
>> some programs ran, but mouse input was ignored, so one could not zoom 
>> or rotate.  A little Googling revealed that X11 is indeed broken on 
>> Leopard.  Various workarounds are discussed on the net, including 
>> removing the Leopard version of X11 and reinstalling the Tiger 
>> version.   I haven't yet managed to do this successfully. If anyone 
>> has successfully worked around this, I'd like to hear about it.
> 
> Which version of vpython are you talking about?
> For me, Fink's visual-py25-3.2.9-1003 works on Leopard, with Leopard's 
> X11. As for the beta versions, the last one I tried to make work was 
> 4.beta16, and it didn't work, same as the other ones I tried before it.
> 

-- 
-------------------------------
Ruth Chabay
Professor of Physics
North Carolina State University

email: Rut...@nc...

[Visualpython-users] From newbie: major performance woes

[Jiang Q. <jq...@ph...>]

Hi:
	Sorry about the confusing subject line of my last email. I did 
manage to compile the beta, I just have major performance problem.
	I took a look at the code of sphere.cpp, and notice there's 
discussion about levels of details. I wonder, however, are all that 
exposed to the user? Is there anyway I can reduce the level of details 
from my script? Or if that's not possible, is it possible to in fact 
change the code manually and recompile?
	Another issue that may or may not have anything to do with my 
performance woes. There are several demos in the example directory does 
not run properly in my installation. Drape shows only a rod. Double 
pendulum is way slower than in 3.4, Hanoi shows artifacts whenever I 
move a ring. I'm beginning to think there might be something wrong with 
my beta installation. How can I check?
	Thanks in advance for your help.
								Jiang

On Wed, Nov 07, 2007 at 01:35:57AM -0500, Jiang Qian wrote:
> Hi all:
> 	I'm new to this list. I installed the stable visual-3.2.9 and it 
> worked great. But I really would like to to get the transparency to 
> work.  So I installed visual 4.beta16. I jumped through all sorts of 
> hoops, and finally got it to work. The transparency works quite well. 
> But I have serious performance issue.
> 	I mainly use visual to visualize packed spheres, and small 
> particles inside the spaces between them. In visual 3.2.9, a system with 
> a few hundred spheres packed inside a cube works very smoothly: I can 
> rotate, zoom at will with middle and right button. By combining the two, 
> I can essentially "walk" into the sphere packs.(The spheres rendered are 
> not perfectly smooth, but I manually changed some lines in the source 
> code to make the smoothness ok). It all works fine, the only thing I 
> miss is transparency.
> 	However, in visual 4.beta16, using identical code(with *no* 
> transparency yet), I get a spectacularly smooth and well lit spheres, 
> but the tradeoff seem to be heavy performance penalty: I can barely zoom 
> and move, the rotation is slow. Interactive zooming and rotation is the 
> key reason why I use visual: otherwise I can just render things in 
> povray. Needless to say, I would like to find a way to trade away some 
> of the more spectacular visual effects to have better interactive 
> performance.
> 	I tried to look through the documentation of beta, but there 
> aren't too much info about performance tuning. The only thing I found is 
> to set shininess to 0, which helps marginally at best.
> 	What other tricks can I use to improve interactive performance?  
> For example, can I tune the smoothness of the spheres? Sometimes my cpu 
> usage is not even fully 100%, but dragging, rotating and zooming the 
> image is still very slow.
> 	It'll really be a shame if I have to revert to the old version 
> due to performance issue.  There must be a way to balance performance 
> and effects.
> 	In a related issue. I also need to render particles between the 
> spheres in the pack. In the old version, I basically render them as 
> smaller spheres. But in the new version, there's a mention of point 
> objects, which seems to be just for that purpose. However, there's not 
> too much documentation of the point objects. How do I use them? Do they 
> offer a lighter overhead than the render spheres? Can I give them 
> colors?
> 	On the final note, a word about my system: I have a thinkpad 
> T43, with Pentium M Dothan 1.86MHz, 1GB PC2-4200 memory, ATI X300 mobile 
> discrete graphics(M22) with 64MB of VRAM, and 60GB 7200rpm disk. It's 
> not a powerful machine by today's standard, but it runs the old version 
> of visual just fine. Also, runs other 3D accelerated openGL programs 
> like googleearth and stellarium just fine(glxgears score, which I know 
> is not a benchmark, is around 1750 FPS).
> 	The software environment is an outdated ubuntu(5.04), with 
> custom compiled 2.6.18 kernel, gcc version 3.3.5, python 2.4, fglrx 
> proprietary driver 8.42.3(latest).  Numpy 1.0.3, the latest gtkglxtmm I 
> compiled and installed from source.  If you want to know more, let me 
> know what more relevant info I can give.
> 	If there's a simple patch for the stable version 3.2.9 that 
> enables transparency, I'll be very happy to use that, too. Because 
> really the stable version satisfies all my need except for 
> transparencies.
> 	Thank you all for any hint/help you can give.
> 								Jiang
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users

Re: [Visualpython-users] VPython on Leopard

[Martin C. <cos...@wa...>]

Ruth Chabay wrote:
> I upgraded to Leopard on my new Mac, and VPython stopped working -- some 
> programs ran, but mouse input was ignored, so one could not zoom or 
> rotate.  A little Googling revealed that X11 is indeed broken on 
> Leopard.  Various workarounds are discussed on the net, including 
> removing the Leopard version of X11 and reinstalling the Tiger version. 
>   I haven't yet managed to do this successfully. If anyone has 
> successfully worked around this, I'd like to hear about it.

Which version of vpython are you talking about?
For me, Fink's visual-py25-3.2.9-1003 works on Leopard, with Leopard's 
X11. As for the beta versions, the last one I tried to make work was 
4.beta16, and it didn't work, same as the other ones I tried before it.

-- 
Martin

[Visualpython-users] From newbie: compile beta error

[Jiang Q. <jq...@ph...>]

Hi all:
	I'm new to this list. I installed the stable visual-3.2.9 and it 
worked great. But I really would like to to get the transparency to 
work.  So I installed visual 4.beta16. I jumped through all sorts of 
hoops, and finally got it to work. The transparency works quite well. 
But I have serious performance issue.
	I mainly use visual to visualize packed spheres, and small 
particles inside the spaces between them. In visual 3.2.9, a system with 
a few hundred spheres packed inside a cube works very smoothly: I can 
rotate, zoom at will with middle and right button. By combining the two, 
I can essentially "walk" into the sphere packs.(The spheres rendered are 
not perfectly smooth, but I manually changed some lines in the source 
code to make the smoothness ok). It all works fine, the only thing I 
miss is transparency.
	However, in visual 4.beta16, using identical code(with *no* 
transparency yet), I get a spectacularly smooth and well lit spheres, 
but the tradeoff seem to be heavy performance penalty: I can barely zoom 
and move, the rotation is slow. Interactive zooming and rotation is the 
key reason why I use visual: otherwise I can just render things in 
povray. Needless to say, I would like to find a way to trade away some 
of the more spectacular visual effects to have better interactive 
performance.
	I tried to look through the documentation of beta, but there 
aren't too much info about performance tuning. The only thing I found is 
to set shininess to 0, which helps marginally at best.
	What other tricks can I use to improve interactive performance?  
For example, can I tune the smoothness of the spheres? Sometimes my cpu 
usage is not even fully 100%, but dragging, rotating and zooming the 
image is still very slow.
	It'll really be a shame if I have to revert to the old version 
due to performance issue.  There must be a way to balance performance 
and effects.
	In a related issue. I also need to render particles between the 
spheres in the pack. In the old version, I basically render them as 
smaller spheres. But in the new version, there's a mention of point 
objects, which seems to be just for that purpose. However, there's not 
too much documentation of the point objects. How do I use them? Do they 
offer a lighter overhead than the render spheres? Can I give them 
colors?
	On the final note, a word about my system: I have a thinkpad 
T43, with Pentium M Dothan 1.86MHz, 1GB PC2-4200 memory, ATI X300 mobile 
discrete graphics(M22) with 64MB of VRAM, and 60GB 7200rpm disk. It's 
not a powerful machine by today's standard, but it runs the old version 
of visual just fine. Also, runs other 3D accelerated openGL programs 
like googleearth and stellarium just fine(glxgears score, which I know 
is not a benchmark, is around 1750 FPS).
	The software environment is an outdated ubuntu(5.04), with 
custom compiled 2.6.18 kernel, gcc version 3.3.5, python 2.4, fglrx 
proprietary driver 8.42.3(latest).  Numpy 1.0.3, the latest gtkglxtmm I 
compiled and installed from source.  If you want to know more, let me 
know what more relevant info I can give.
	If there's a simple patch for the stable version 3.2.9 that 
enables transparency, I'll be very happy to use that, too. Because 
really the stable version satisfies all my need except for 
transparencies.
	Thank you all for any hint/help you can give.
								Jiang

[Visualpython-users] VPython on Leopard

[Ruth C. <rwc...@nc...>]

I upgraded to Leopard on my new Mac, and VPython stopped working -- some 
programs ran, but mouse input was ignored, so one could not zoom or 
rotate.  A little Googling revealed that X11 is indeed broken on 
Leopard.  Various workarounds are discussed on the net, including 
removing the Leopard version of X11 and reinstalling the Tiger version. 
  I haven't yet managed to do this successfully. If anyone has 
successfully worked around this, I'd like to hear about it.

    Ruth

-- 
-------------------------------
Ruth Chabay
Professor of Physics
North Carolina State University

email: Rut...@nc...

[Visualpython-users] Detailed instructions for installing on Mac OSX

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

Danny Caballero, a physics graduate students at Georgia Tech, wrote a 
detailed installation guide for installing VPython on Mac OSX. I thought 
I had posted this at vpython.org a few weeks ago, but apparently not. It 
is now available on the Mac download page. Thanks, Danny!

Bruce Sherwood

[Visualpython-users] Windows beta: good news and bad news

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

The good news is that I've succeeded in replacing the Windows-specific 
code in the beta version with platform-independent GTK code. This is 
what Jonathan Brandmeyer started with originally but abandoned when it 
seemed very difficult for developers (including me) to install GTK on 
Windows. In the interim installing GTK and GTKMM has gotten easy, and 
there are of course advantages to being able to debug and use the same 
code on all platforms. (The relevant GTK binaries can be packaged with 
Visual, so it needn't be necessary for end users to install these 
materials.)

I also hoped that this would be sufficiently different to shake loose 
some of the serious bugs that the beta version has on Windows. The bad 
news is that it seems to have made no difference. The good news is that 
this eliminates the possibility that the problems lay in the 
Windows-specific code. One area that is attracting particular suspicion 
is the new rendering scheme for curves, which was changed in the beta 
version but which I have reason to think is causing problems on Windows.

I have not checked in my changes to CVS. Basically they consist of 
eliminating from src/win32 all files but winrate.cpp and wintimer.cpp, 
commenting out most conditional includes in various files that were 
based on the compiler flag _WIN32, and making some minor adjustments in 
src/Makefile.in to the lists of .lo files for Linux and Windows.

Bruce Sherwood