This small piece of code is worring me:

for ( int y=0;y<anncore.getNet().outputWeights.length;y++ )
{
rect((float)(anncore.getNet().outputWeights[y][0]*10),(float)(anncore.getNet().outputWeights[y][1]*10),10,10);
}

The values I pass to the rect function come from getNet() which reads from
a thread.
I use the same values for any other output (like line() or println() ) and
I get no problems. It breaks when the sent values are specially low. If I
limit the production of the values to higher ranges (from the thread) then
there is no problem. I really think it doesn't have to do with Threads.

I use the 121-expert under windows. Eclipse platform

These are the values that the code is passing (printed with System.out.println)

8.0366003E8
1.9926263E9


java.lang.ArrayIndexOutOfBoundsException: 60200
at processing.core.PLine.drawLine_plain_spatial(PLine.java:769)
at processing.core.PLine.draw(PLine.java:404)
at processing.core.PGraphics3D.render_lines(PGraphics3D.java:1460)
at processing.core.PGraphics3D.endShape(PGraphics3D.java:988)
at processing.core.PGraphics.endShape(PGraphics.java:1111)
at processing.core.PGraphics3D.quad(PGraphics3D.java:2223)
at processing.core.PGraphics.rectImpl(PGraphics.java:1267)
at processing.core.PGraphics.rect(PGraphics.java:1262)
at processing.core.PApplet.rect(PApplet.java:7004)
at ANNGenerator.draw(ANNGenerator.java:41)
at processing.core.PApplet.handleDisplay(PApplet.java:1314)
at processing.core.PGraphics.requestDisplay(PGraphics.java:564)
at processing.core.PApplet.run(PApplet.java:1409)
at java.lang.Thread.run(Unknown Source)

another comment:

There is no problem when you simply do this, of course:

rect( (float)1.E-10, (float)1.E-10, 10, 10 );

Another addition:

I've discovered that it happens only with P3D rendering option.

that's a very large double... 8.0366003E8 is 8.0366003 x 10^8. the 1.E-10
is very small. we should still be able to catch it, so it qualifies as a
bug, but in general you're just confusing the renderer pretty badly. in the
meantime, it should be fixable by not using such large numbers.

may be a duplicate of bug #246.

fixed for 0151.