View frustum and the ilogical way to think

Hi, this is a little post to warn all can read it, about the ilogical way to think on the view frustum.
Suposse you have the bounding box (of an object to be rendered), your camera's frustum and you can calculate if a point is inside the camera's view frustum, then:

• A = All points of the bounding box are inside the frustum.
• B = Some part of the object are in the frustum and must be rendered.

We can say that:

• A-->B, that is, if all points are into the view frustum then the object if completely inside the frustum.

but take care (and remember your old clases of "First-Order Logic"):

• The oposit of A-->B is not (no A -->no B). That is, if all points of the bounding box are outside the view frustum then the object is outside the view frustum. This is false.

Supose you have a bounding box (an object) in the center of the view frustum. If you move the camera to put it in front and very close of the object (mantain it in the center), then left points of the bounding box are out of the frustum by the left plane, and the right points of the bounding box are outside by the right plane. In this situation, and by the above predicate, all points are outside the view frustum but the object would be drawn.

The right oposite proposition for A-->B is "not (A-->B)" or "not (no A or B)" or "A and no B", and this a very different thing than the previous and erroneous definition.

Finally (thanks Brandon) the right to think to know when to draw a object because it is present in the camera view frustum is (or could be):

• If all points of the bounding box are inside the frustum, then the object is completely inside the frustum and must be render,
• if all points are outside by the left plane, or all points are outside by the right plane, etc, then the object is completely outside the frustum and must not be drawn.
• other cases, portions of the object intersects with the view frustum and can be drawn.
  

Improving performance with display lists

Recently I have been working with shapefiles to add support for it in The Balloon Project. Thanks to the GeoTools I can read the format easyly and render it as line loops (GL_LINE_LOOP).
Initially I was using the brute force for rendering, that is, all points in the window are calculate every time they are going to be rendered. They work for polygons with few points and textures (tile images), but when a shapefile with a thousand of points appears in the scene the brute force is not a good solution.
For this, I change some code and now I am using display list in all my renderable object. The performance has increased surprising in my latpop even with a shapefile.

NetBeans with your preferred LAF

To all that want to change the default LookAndFeel of its NetBeans:
Can I run NetBeans with a custom look and feel?
Also you can take a look at the themes way here.

Tips about "Out of memory" exception

Recently I have problems with the memory in The Balloon Project. By default, Java starts with a maximum configured memory of 64 Mb and when a layer is loaded with a great number of 512x512 image tiles that is not enought.
Here I want to put a couple of links to pages that talks about the JVM memory options and the out of memory exception:

• Catching OutOfMemoryErrors.


• Tuning JVM switches for performance.