-- This slot is reserved for the most recent working releases --



Downloads:

GIFImage Source Code  Version date:  July 7, 2009
The base class for loading information from GIF files.  Supports most versions of the GIF format, including single frame (87a), animated (89a), interleaving, transparent color, LZW compression, and "clr" non-compressed data.

GIFLoader Source Code  Version date:  July 7, 2009
Library for using animated GIFs as textures in jPCT.  Provides methods for loading GIF files into "mosaic textures", animating, checking for current animation frame, and determining the UV coordinates of the current frame.  TODO: add methods for blitting.  This download includes the above GIFImage class.


Demos:

Animated GIF inside an applet  (download the Source Code)
Demonstrates loading and animating a multi-frame GIF image via the GIFImage class.

GIF Box  (download the Source Code)
Demonstrates using animated GIFs as textures in jPCT.


Android Port, for use with jPCT-AE

Example Ap  (source code)


Documentation:

GIFImage and GIFLoader JavaDoc  Version date:  July 7, 2009

This is not related to jPCT, but are you using anything on your forum to fight back against content-scraper bots?  I started revamping my website last weekend, and I installed SMF.  I have already been targeted twice by internetserviceteam.com (and was spammed once).  I ended up banning anything from hostnames  *.internetserviceteam.com and *.de, and I installed honeypot bot traps (don't know if these measures have been successful yet).  I was just wondering if you are doing anything special here, or if anyone else has some tips for blocking the scraper bots.

I am trying to come up with a navigation system for NPC spaceships.  Basically, I want them to have a target position anywhere in 3D space and rotate/translate smoothly toward it (no sharp un-realistic turns).  I also want to specify a maximum value the ship can rotate around its z-axis and x-axis (so the ship doesn't flip upside-down when moving to a target position behind where it started out).  I'm sure I can eventually work out a system to do this, but I thought I would check first if anyone has done something like this before, and could give me some ideas (no reason to re-invent the wheel if I don't have to).

In an applet I am working on, I got the following messages, which I haven't seen before:
Additional visibility list (2) created with size: 10000
Exception in thread "AWT-EventQueue-2" java.lang.NullPointerException
at com.threed.jpct.World.renderScene(Unknown Source)
at C3.JupiterDefense.paint(JupiterDefense.java:166)
at javax.swing.RepaintManager.paintDirtyRegions(Unknown Source)
at javax.swing.RepaintManager.paintDirtyRegions(Unknown Source)
at javax.swing.RepaintManager.seqPaintDirtyRegions(Unknown Source)
at javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(Unknown Source)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
The applet is a target shooter which generates a lot of bullets, each having two Object3Ds (a box and a billboarded quad), so I am thinking that perhaps the problem is that I am not disposing of all these Object3Ds properly.  When I am finished with each bullet, I am running the following method:
    public void remove()
    {
        world.removeObject( object3D );
        if( childrenObjects != null )
        {
            for( int i = 0; i < childrenObjects.length; i++ )
            {
                world.removeObject( childrenObjects[i] );
            }
        }
    }
Is there something else I need to be doing in addition to calling removeObject()?

At this point, I don't really know if it is related to too many Object3Ds or what.  I will try and replicate a simple test case if possible - the project is quite large atm.  I thought in the mean time, someone might recognize that message (or why might the message "Additional visibility list (2) created with size: 10000" be generated?)

--EDIT--
Oh, I forgot to mention, I have the following line in the applet's init() method, which is where the number "10000" is coming from:
Config.maxPolysVisible = 10000;I suppose a posibility is that the applet is running out of memory, but in that case I would expect to receive some kind of "out of memory" message instead.  I'll try and run this program as an application and see if the problem still exists.

Here's another question that's probably been asked a hundred times:

Is there a way to get a Graphics context to draw on when using hardware rendering mode?  I can't use getGraphics() since, as the Javadoc states, "when using OpenGL support, this value is rather meaningless".

I suppose I could draw my layer onto an Image, and use that to create a Texture to use in the blit() method.  I'd have to rethink how I handle images that change dynamically (since I wouldn't want to create a new texture every frame).  Also, is a texture's alpha information taken into account by blit()?  If not, is there another way to draw simi-transparent 2D stuff on top of the rendered scene?

--EDIT-- I see that one of the blit() methods has the ability to set an additional color.  I'll play around with this to see if I can get the results I'm looking for.

I don't know if this is a bug or if it is intentional, but I thought I would point it out just in case.  Billboarding does not take an Object3D's parents' rotations into account (i.e. when rotating the parent, the child Object3D behaves as if it were BILLBOARDING_DISABLED).  Subsequent movements of the camera then result in the object auto-aligning to a direction other than the camera.

I have a couple more questions related to building a terrain Object3D.

My first question is why does building an Object3D increase its vertice count?  Building the following square Object3D increases its vertice count from 4 to 12
        Object3D terrain = new Object3D( 2 );
        SimpleVector bottomLeft = new SimpleVector( 0, 0, 0 );
        SimpleVector bottomRight = new SimpleVector( 5, 0, 0 );
        SimpleVector topRight = new SimpleVector( 5, 0, 5 );
        SimpleVector topLeft = new SimpleVector( 0, 0, 5 );
       
        int triangle1 = terrain.addTriangle( topLeft, 0, 0,
                                             bottomLeft, 0, 1,
                                             bottomRight, 1, 1 );
        int triangle2 = terrain.addTriangle( bottomRight, 1, 1,
                                             topRight, 1, 0,
                                             topLeft, 0, 0 );

        System.out.println( "Unique Vertice count before build: " + terrain.getMesh().getUniqueVertexCount() );
        System.out.println( "    Triangles: " + terrain.getMesh().getTriangleCount() );
        terrain.build();
        System.out.println( "Unique Vertice count after build: " + terrain.getMesh().getUniqueVertexCount() );
        System.out.println( "    Triangles: " + terrain.getMesh().getTriangleCount() );Strangely, the number of triangles remains 2 even though the number of vertices triples.  What is causing this, and how do I prevent it from happening?

My second question is what is the best way to determine a polyID given a triangle number.  I don't suppose they are the same, are they?

My last question is about OcTree's.  The JavaDoc states that the best maxPoly value to use for an OcTree depends on the object and its usage.  Unfortunately, I don't know enough to know what the best value to use for my situation might be.  What would you recommend for terrain objects that are 32X32 grids with two triangles per square?

There are a couple of ways I am considering to interact with a terrain via the mouse:

The first way would be to make each square of the terrain its own individual Object3D, and use the World.checkCollision( SimpleVector, SimpleVector, float ) method to determine which grid square of the terrain that the user clicked on.

The second way would be to place the entire terrain into a single Object3D, and generate an actual collision event, then call the CollisionEvent.getPolygonIDs() method.  This could be used to determine which grid square of the terrain was clicked on by searching all polygons in the terrain for a match.

Is there likely to be a significant performance difference with either method, or is there a different way all-together to accomplish this?