visualpython-users

[Visualpython-users] Re: horror story

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

>    1. Re: Horror story (Jonathan Brandmeyer)
> From: Jonathan Brandmeyer <jbr...@ea...>
[deletions]

> I think that it means that you were somehow creating an visual object
> with an explicit color value set to "None" rather than a 3-tuple.

That's really odd, since I don't.  (*grin*)  What I'm doing is using an HSV
color 3-tuple, since I only have to work with one element (the H, the first
in the 3-tuple) in order to get a full range of colors according to a
certain property of the object.  I then just translate the HSV to RGB for
VPython's use.  Even if the first element of the tuple were weird, the other
two elements are explicitly 1 and 1 (hue, 1,1).

> You can add an extra couple of lines of code to
> process_init_args_from_keyword_dictionary (in primitives.py) that tests
> keywords for the 'color' key and prints out the value if it exists.
> eg,
> if 'color' in keywords:
> print type(keywords['color']), keywords['color']

Thank you, Jonathan, I'll try that, but I can't print anything to the shell
window; I'll have to try to write any messages to a file and even that
is unlikely to work.  When the program runs and expecially when this
happens, the program hogs focus and the CPU is in 100% usage.  I can't even
Windows-multitask at all and that's on a 2.2 GHz (Intel 3.4 GHz equivalent)
Athlon64 w/512 MB memory.
Thus I can't _see_ the shell without minimizing the stereo window, which
sometimes works (after a _long_ pause) and sometimes doesn't.  There's
no chance of catching "live" error messages, or more than one of them
if static.

This is all because the scene.exit=0 function (close the stereo window;
leave the shell and edit windows open) _doesn't work_ in this VPython (2.4).
I wanted especially to know if that has been fixed.
Has it?
(I know there's a new version up, but has this particular irritant been
fixed in it?  I can't go on forever re-initializing Idle every time I close
the stereo window.  It makes it really hard to work on a program when I have
to start from scratch every time I test some minor thing and have to close
the stereo window....)

Peace
JB
jb...@te...
Web: http://tetrahedraverse.com

[Visualpython-users] Re: horror story, v.3

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

> Subject: Re: [Visualpython-users] Horror story
> From: Jonathan Brandmeyer <jbr...@ea...>
> On Mon, 2005-12-05 at 20:49 -0600, John Brawley wrote:
>
> > "Traceback (most recent call last):
[dels]
> I think that it means that you were somehow creating an visual object
> with an explicit color value set to "None" rather than a 3-tuple.  You
[and]
> Try to reduce the program to the minimum that reproduces the problem.
> If that process doesn't help you find it, post the minimal example here.
> Otherwise, it will be nearly impossible to see what is wrong.

I've poked around and found some other effects.

(I am pursuing this in-list partly because I may be doing something very
much more visually complex than might be the case with others' use of
VPython, thus might be "testing to near destruction" VPython's ability to
handle complex scenes.  That's a guess, though.)

This seems to be an 'interactive' problem between VPython, OpenGL, and my
(new) video card, which ought to be able to handle anything my program or
VPython can throw at it: it's an nVidia GeForce FX 5200 with _256MB_ of
memory on-card.

(In re: your (Jonathan's) diagnose of "None.None" object color as seemingly
reported in the traceback, since the error doesn't crash the program, it is
possible that this is a secondary reaction to occasional detection of a
zero- (or minus-) length cylinder, of which there can be many in this
program (but, the program's written to exclude this situation).
PovRay would call this a "degenerate cylinder," whose ends are the
same point in 3D space.  If a non-cylinder is nonetheless asked to be
colored, it might result in a similar error from the VPython coloring
subsystem. (?)

Furthermore, I find that allowing this visual nastiness to go on (and on,
and on...) eventually results in the system settling down and rendering
correctly (the problem mostly disappears by itself--but reoccurs if I
re-initialize the program with the same inputs), _even with_ 10,000 points
or so (see relation to complexity, below).
IOW, not only does the problem not crash the program, but also it "heals
itself" after a (usually very long) while, and at least without zooming
(likewise see complexity, below).

At any rate:

1) It is related to complexity of a scene, but does not occur using an
entirely different program with similar complexity.  IOW, my program causes
it when using more than 'x' number of visual objects, OR when using less
than that but zooming in.  My MYST games, though (hence no Pythons at all),
even with fast motion and very complex scenes, do not cause it.

2) Complexity: I ran a different VPython program I wrote, using 10,000
points, and it causes the problem you saw (in the URL I provided).  However,
using 3333 points causes a _different_ problem: the stereo scene "flashes"
back and forth between L eye and R eye, turning white objects (tiny balls,
hence points) blue for a time, and back again.  Using only 333 points does
not cause either problem, but does cause yet a _different_ problem: zooming
in on the scene, which has 333 "balls" in it (they look like points from a
distance, and are rendered as points by the system when they're tiny like
that) causes each ball on-screen to show a round (ball-diameter-limited)
version of the same horrible-orthogonal gridlike random-color crap shown in
the URL I gave you.  IOW, instead of the whole half-window (stereo) filling
with this crap, only the balls themselves (against a black background) fill
with it.
Moreover, zooming _out_ stops the problem, and zooming back in re-causes it.
Moremoreover, the difference between causing and not causing, in zooming
terms, is a matter of a millimeter or less of mouse movement.  IYOW, there
is a specific "distance" into the scene, where balls grow large enough to
require more rendering, and the problem appears, back away from which the
balls render just fine.  Increasing the number of balls used (say, from 333
to 500) makes the problem occur at a lesser distance-in to the scene.

3) SO, what I have is a rendering-capability problem, which sounds like a
video card problem, BUT there's the fact that it only happens when using my
program, VPython, and a highly complex rendering task.

Now, given this further info, do you have any other ideas as to what's what?
(And, thanks much for help so far.)

Peace
JB
jb...@te...
Web: http://tetrahedraverse.com

Re: [Visualpython-users] Re: horror story

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

On the exit issue: This is two different issues, not one. With the 
Boost-based version of Visual there crept in a new bug that scene.exit = 
0 doesn't prevent the exiting of all graphics wndows when one is closed. 
That has not yet been fixed.

But there's a different issue that has always been present as far as I 
know, and never understood. If you start IDLE, then open a file for 
editing, you can repeatedly run, close the graphics window, and keep 
editing.

If on the other hand (on Windows) you right-click on a .py file and ask 
to edit using IDLE, you only get to run once before IDLE itself quits, 
which is annoying. But starting from IDLE gets around this problem.

Bruce Sherwood

John Brawley wrote:

>>   1. Re: Horror story (Jonathan Brandmeyer)
>>From: Jonathan Brandmeyer <jbr...@ea...>
>>    
>>
>[deletions]
>
>  
>
>>I think that it means that you were somehow creating an visual object
>>with an explicit color value set to "None" rather than a 3-tuple.
>>    
>>
>
>That's really odd, since I don't.  (*grin*)  What I'm doing is using an HSV
>color 3-tuple, since I only have to work with one element (the H, the first
>in the 3-tuple) in order to get a full range of colors according to a
>certain property of the object.  I then just translate the HSV to RGB for
>VPython's use.  Even if the first element of the tuple were weird, the other
>two elements are explicitly 1 and 1 (hue, 1,1).
>
>  
>
>>You can add an extra couple of lines of code to
>>process_init_args_from_keyword_dictionary (in primitives.py) that tests
>>keywords for the 'color' key and prints out the value if it exists.
>>eg,
>>if 'color' in keywords:
>>print type(keywords['color']), keywords['color']
>>    
>>
>
>Thank you, Jonathan, I'll try that, but I can't print anything to the shell
>window; I'll have to try to write any messages to a file and even that
>is unlikely to work.  When the program runs and expecially when this
>happens, the program hogs focus and the CPU is in 100% usage.  I can't even
>Windows-multitask at all and that's on a 2.2 GHz (Intel 3.4 GHz equivalent)
>Athlon64 w/512 MB memory.
>Thus I can't _see_ the shell without minimizing the stereo window, which
>sometimes works (after a _long_ pause) and sometimes doesn't.  There's
>no chance of catching "live" error messages, or more than one of them
>if static.
>
>This is all because the scene.exit=0 function (close the stereo window;
>leave the shell and edit windows open) _doesn't work_ in this VPython (2.4).
>I wanted especially to know if that has been fixed.
>Has it?
>(I know there's a new version up, but has this particular irritant been
>fixed in it?  I can't go on forever re-initializing Idle every time I close
>the stereo window.  It makes it really hard to work on a program when I have
>to start from scratch every time I test some minor thing and have to close
>the stereo window....)
>
>Peace
>JB
>jb...@te...
>Web: http://tetrahedraverse.com
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>for problems?  Stop!  Download the new AJAX search engine that makes
>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>_______________________________________________
>Visualpython-users mailing list
>Vis...@li...
>https://lists.sourceforge.net/lists/listinfo/visualpython-users
>  
>