Menu
▾
▴
visualpython-users
|
From:
<fre...@gb...> - 2007-12-23 11:25:41
Attachments:
merlin01.png
|
Ok, so I'm now using vpython 4...
1) it fixed the crash when quit/hide display :o))))
2) all examples passed, but some have strange behaviour:
=2D controlstest.py: closing the main window using the window x box only=20
closes the 3D view, and freezes the main view.
=2D convex.py: closing the window using the window x box freezes.
=2D crossproduct.py: 100% CPU usage. very Slow.
=2D glinfo.py: freezes after printing the infos
=2D planar.py: CPU 100% usage
=2D randombox.py: 80% CPU usage
=2D texturetest.py: freeze if closed using the window x box
=2D tictac.py: 100% CPU usage
=2D Tk-Visual.py: freezes if 3D view closed using the window x box
=2D toroid_drag.py: 100% CPU usage
3) my app is much more slower (drag/move), and I'hve now 60-70% CPU usage=20
(vs 10-15% with vpython 3). It also freezes if I close the 3D view using=20
the window x box.
I have a general question: how do I cleanly stop the vpython mainloop from=
=20
my app? I mean, without the need to click on the GTK close button?
Last, I'm very impressed by the texture feature: in fact, this is why I=20
switched to vpython 4. I'm developping a pano head simulation, and I want=20
to apply a 360=B0x180=B0 pano on a vpython sphere, to simulate the real wor=
d.=20
BTW, is it possible to map the image *inside* a sphere?=20
=2D-=20
Fr=E9d=E9ric
http://www.gbiloba.org
|
|
From:
<fre...@gb...> - 2007-12-23 18:22:11
|
Another question (more a feature request): could it be possible to=20 precisely select the color (giving RGB values) for stereo mode? That way,=20 it would be possible to adjust it according to the glasses used... =2D-=20 Fr=E9d=E9ric http://www.gbiloba.org |
|
From: Bruce S. <Bru...@nc...> - 2007-12-25 06:24:39
|
Do try the new 4.beta21, which addresses many problems, some of which are those you mention. In particular, the problems with tictac.py and toroid_drag.py (and also hanoi.py) have to do with loops containing almost no computation, a case where the multithreading is not doing the right job for reasons not understood. As a workaround, those programs now contain rate statements, which don't harm perfomance but make the programs work properly. As mentioned in the announcement of 4.beta21, there are various performance problems with rendering, and I hope to address them. I've already made a big improvement in handling curves containing large numbers of points. At the moment there is no way to texture the inside of a sphere, but that's an interesting suggestion. I suppose you've already noticed that in either Visual 3 or 4 you can move inside an object. Bruce Sherwood Frédéric Mantegazza wrote: > Ok, so I'm now using vpython 4... > > 1) it fixed the crash when quit/hide display :o)))) > > 2) all examples passed, but some have strange behaviour: > > - controlstest.py: closing the main window using the window x box only > closes the 3D view, and freezes the main view. > - convex.py: closing the window using the window x box freezes. > - crossproduct.py: 100% CPU usage. very Slow. > - glinfo.py: freezes after printing the infos > - planar.py: CPU 100% usage > - randombox.py: 80% CPU usage > - texturetest.py: freeze if closed using the window x box > - tictac.py: 100% CPU usage > - Tk-Visual.py: freezes if 3D view closed using the window x box > - toroid_drag.py: 100% CPU usage > > 3) my app is much more slower (drag/move), and I'hve now 60-70% CPU usage > (vs 10-15% with vpython 3). It also freezes if I close the 3D view using > the window x box. > > I have a general question: how do I cleanly stop the vpython mainloop from > my app? I mean, without the need to click on the GTK close button? > > Last, I'm very impressed by the texture feature: in fact, this is why I > switched to vpython 4. I'm developping a pano head simulation, and I want > to apply a 360°x180° pano on a vpython sphere, to simulate the real word. > BTW, is it possible to map the image *inside* a sphere? > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > ------------------------------------------------------------------------ > > _______________________________________________ > Visualpython-users mailing list > Vis...@li... > https://lists.sourceforge.net/lists/listinfo/visualpython-users > |
|
From:
<fre...@gb...> - 2007-12-25 16:55:25
|
On mardi 25 d=E9cembre 2007, Bruce Sherwood wrote: > Do try the new 4.beta21, which addresses many problems, some of which > are those you mention. In particular, the problems with tictac.py and > toroid_drag.py (and also hanoi.py) have to do with loops containing > almost no computation, a case where the multithreading is not doing the > right job for reasons not understood. As a workaround, those programs > now contain rate statements, which don't harm perfomance but make the > programs work properly. > > As mentioned in the announcement of 4.beta21, there are various > performance problems with rendering, and I hope to address them. I've > already made a big improvement in handling curves containing large > numbers of points. Ok, I'll give it a try. > At the moment there is no way to texture the inside of a sphere, but > that's an interesting suggestion. I suppose you've already noticed that > in either Visual 3 or 4 you can move inside an object. Yes, I use this behaviour: I'm in a big sphere, simulating the sky. In=20 fact, when I apply the texture on it, I can see it rom the inside. So,=20 there is nothing to do :o) The texture is reversed, but it is not really a= =20 problem. =2D-=20 Fr=E9d=E9ric http://www.gbiloba.org |
|
From: Bruce S. <Bru...@nc...> - 2007-12-25 06:30:01
|
Could you give a more complete statement of your suggestion? It is already the case that there are several different anaglyph modes (redblue, redcyan). Are you saying that given particular red-cyan filters, whose "red" and "cyan" are of course just approximations, you might hope to achieve better color separation by using red+some+green" (say) and "cyan+some_red"? Note that while red-blue has large separation, it is essentially monochrome, whereas the red-cyan version provides some colors by adding white to both views, thus giving pastel colors but avoiding the case of a red ball having no image for the cyan eye. Some months ago someone pointed out various failings of the current anaglyph implementation (for which I'm responsible), and at some point I'd like to follow up on that critique. But it's currently VERY low priority..... Bruce Sherwood Frédéric Mantegazza wrote: > Another question (more a feature request): could it be possible to > precisely select the color (giving RGB values) for stereo mode? That way, > it would be possible to adjust it according to the glasses used... > > |
|
From:
<fre...@gb...> - 2007-12-25 10:16:03
|
On mardi 25 d=E9cembre 2007, Bruce Sherwood wrote: > Could you give a more complete statement of your suggestion? It is > already the case that there are several different anaglyph modes > (redblue, redcyan). Are you saying that given particular red-cyan > filters, whose "red" and "cyan" are of course just approximations, you > might hope to achieve better color separation by using red+some+green" > (say) and "cyan+some_red"? Yes, that's the point. I can also be a work-arround for non-calibrated=20 monitors... > Note that while red-blue has large=20 > separation, it is essentially monochrome, whereas the red-cyan version > provides some colors by adding white to both views, thus giving pastel > colors but avoiding the case of a red ball having no image for the cyan > eye. I didn't know that. Stereo is really a very interesting point, and I'm sure= =20 in will be the next image revolution. > Some months ago someone pointed out various failings of the current > anaglyph implementation (for which I'm responsible), and at some point > I'd like to follow up on that critique. But it's currently VERY low > priority..... I understand! =2D-=20 Fr=E9d=E9ric http://www.gbiloba.org |
|
From:
<fre...@gb...> - 2007-12-25 22:00:04
|
On dimanche 23 d=E9cembre 2007, Fr=E9d=E9ric Mantegazza wrote: Ok, I tested the new beta: > - controlstest.py: closing the main window using the window x box only > closes the 3D view, and freezes the main view. =46ixed. > - crossproduct.py: 100% CPU usage. very Slow. No change. > - glinfo.py: freezes after printing the infos No change. > - planar.py: CPU 100% usage No change. > - randombox.py: 80% CPU usage 50% only. > - texturetest.py: freeze if closed using the window x box No change. > - tictac.py: 100% CPU usage =46ixed. > - Tk-Visual.py: freezes if 3D view closed using the window x box No change. > - toroid_drag.py: 100% CPU usage =46ixed. > 3) my app is much more slower (drag/move), and I'hve now 60-70% CPU > usage (vs 10-15% with vpython 3). It also freezes if I close the 3D view > using the window x box. My 3D view is now as quick as with previous versions! Great job :o) =2D-=20 Fr=E9d=E9ric http://www.gbiloba.org |
|
From: Bruce S. <Bru...@nc...> - 2007-12-26 05:05:22
|
Thanks for the detailed report. crossproduct and planar: These had the same problem as some other examples -- the workaround is simply to add rate(100) immediately following the while statement. I simply failed to catch these further examples of the problem of quitting from a tight loop. (But I should say I only saw a problem with quitting, not any sluggishness.) I've checked in corrected versions to CVS. glinfo: It's not clear to me whether this has ever worked properly on Linux. Note the statement in the program, "This test of OpenGL options is useful mainly on Windows." randombox: I believe the poor performance is due to incomplete implementation of improved handling of lighting of boxes. There needs to be variable level of detail in splitting a side into a number of triangles, dependent on how far away the box is, as is in the case for spheres. I'm aware of the issue. As was the case with curve, box needs work to cut the render speed significantly. texturetest and Tk-Visual: I can't reproduce any problem with these examples. I'm delighted that the changes made a big improvement in the performance of your app. Bruce Sherwood Frédéric Mantegazza wrote: > On dimanche 23 décembre 2007, Frédéric Mantegazza wrote: > > Ok, I tested the new beta: > > >> - controlstest.py: closing the main window using the window x box only >> closes the 3D view, and freezes the main view. >> > > Fixed. > > >> - crossproduct.py: 100% CPU usage. very Slow. >> > > No change. > > >> - glinfo.py: freezes after printing the infos >> > > No change. > > >> - planar.py: CPU 100% usage >> > > No change. > > >> - randombox.py: 80% CPU usage >> > > 50% only. > > >> - texturetest.py: freeze if closed using the window x box >> > > No change. > > >> - tictac.py: 100% CPU usage >> > > Fixed. > > >> - Tk-Visual.py: freezes if 3D view closed using the window x box >> > > No change. > > >> - toroid_drag.py: 100% CPU usage >> > > Fixed. > > >> 3) my app is much more slower (drag/move), and I'hve now 60-70% CPU >> usage (vs 10-15% with vpython 3). It also freezes if I close the 3D view >> using the window x box. >> > > My 3D view is now as quick as with previous versions! > > Great job :o) > > |
|
From:
<fre...@gb...> - 2007-12-26 08:54:54
|
On mercredi 26 d=E9cembre 2007, Bruce Sherwood wrote: > Thanks for the detailed report. > > crossproduct and planar: These had the same problem as some other > examples -- the workaround is simply to add rate(100) immediately > following the while statement. I simply failed to catch these further > examples of the problem of quitting from a tight loop. (But I should say > I only saw a problem with quitting, not any sluggishness.) I've checked > in corrected versions to CVS. > > glinfo: It's not clear to me whether this has ever worked properly on > Linux. Note the statement in the program, "This test of OpenGL options > is useful mainly on Windows." > > randombox: I believe the poor performance is due to incomplete > implementation of improved handling of lighting of boxes. There needs to > be variable level of detail in splitting a side into a number of > triangles, dependent on how far away the box is, as is in the case for > spheres. I'm aware of the issue. As was the case with curve, box needs > work to cut the render speed significantly. Ok. > texturetest and Tk-Visual: I can't reproduce any problem with these > examples. Strange... BTW, you didn't tell me how (if it is possible) to quit a=20 vpython app without using the exit button? > I'm delighted that the changes made a big improvement in the performance > of your app. :o) =2D-=20 Fr=E9d=E9ric http://www.gbiloba.org |
|
From: Bruce S. <Bru...@nc...> - 2007-12-27 00:21:47
|
I thought I remembered that import sys followed by sys.exit() would kill a VPython program. But when I try this on either Visual 3 or Visual 4 it doesn't have that effect. Does someone else know how to kiil a VPython program from the program? Bruce Sherwood Frédéric Mantegazza wrote: > On mercredi 26 décembre 2007, Bruce Sherwood wrote: > > >> Thanks for the detailed report. >> >> crossproduct and planar: These had the same problem as some other >> examples -- the workaround is simply to add rate(100) immediately >> following the while statement. I simply failed to catch these further >> examples of the problem of quitting from a tight loop. (But I should say >> I only saw a problem with quitting, not any sluggishness.) I've checked >> in corrected versions to CVS. >> >> glinfo: It's not clear to me whether this has ever worked properly on >> Linux. Note the statement in the program, "This test of OpenGL options >> is useful mainly on Windows." >> >> randombox: I believe the poor performance is due to incomplete >> implementation of improved handling of lighting of boxes. There needs to >> be variable level of detail in splitting a side into a number of >> triangles, dependent on how far away the box is, as is in the case for >> spheres. I'm aware of the issue. As was the case with curve, box needs >> work to cut the render speed significantly. >> > > Ok. > > >> texturetest and Tk-Visual: I can't reproduce any problem with these >> examples. >> > > Strange... BTW, you didn't tell me how (if it is possible) to quit a > vpython app without using the exit button? > > >> I'm delighted that the changes made a big improvement in the performance >> of your app. >> > > :o) > > |
|
From: Joe H. <hea...@gm...> - 2007-12-27 00:31:36
|
I didn't know it was ever possible to kill a VPython program from =20 inside the program, but I too want to know how! Joe Heafner (Sent from my iPhone.) On Dec 26, 2007, at 19:21, Bruce Sherwood <Bru...@nc...> =20 wrote: > I thought I remembered that import sys followed by sys.exit() would =20= > kill > a VPython program. But when I try this on either Visual 3 or Visual =20= > 4 it > doesn't have that effect. Does someone else know how to kiil a VPython > program from the program? > > Bruce Sherwood > > Fr=C3=A9d=C3=A9ric Mantegazza wrote: >> On mercredi 26 d=C3=A9cembre 2007, Bruce Sherwood wrote: >> >> >>> Thanks for the detailed report. >>> >>> crossproduct and planar: These had the same problem as some other >>> examples -- the workaround is simply to add rate(100) immediately >>> following the while statement. I simply failed to catch these =20 >>> further >>> examples of the problem of quitting from a tight loop. (But I =20 >>> should say >>> I only saw a problem with quitting, not any sluggishness.) I've =20 >>> checked >>> in corrected versions to CVS. >>> >>> glinfo: It's not clear to me whether this has ever worked properly =20= >>> on >>> Linux. Note the statement in the program, "This test of OpenGL =20 >>> options >>> is useful mainly on Windows." >>> >>> randombox: I believe the poor performance is due to incomplete >>> implementation of improved handling of lighting of boxes. There =20 >>> needs to >>> be variable level of detail in splitting a side into a number of >>> triangles, dependent on how far away the box is, as is in the case =20= >>> for >>> spheres. I'm aware of the issue. As was the case with curve, box =20 >>> needs >>> work to cut the render speed significantly. >>> >> >> Ok. >> >> >>> texturetest and Tk-Visual: I can't reproduce any problem with these >>> examples. >>> >> >> Strange... BTW, you didn't tell me how (if it is possible) to quit a >> vpython app without using the exit button? >> >> >>> I'm delighted that the changes made a big improvement in the =20 >>> performance >>> of your app. >>> >> >> :o) >> >> > > ---=20 > ---------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Visualpython-users mailing list > Vis...@li... > https://lists.sourceforge.net/lists/listinfo/visualpython-users |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X