[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