I have a conversion program that says it will convert it to 3ds.  Once it's converted I should be able to load it as a 3ds object  Then is it just  a matter of collosion detection and controlling the camera??

Basically yes! I'm currently writing some example code that shows how to start (the collision detection isn't perfect in this example and you can't shot anything, but anyway...).
I've uploaded a demo of it here (still without sources, but they'll follow once it's finished):
http://www.jpct.net/download/fpsdemo.zip
Controls go like this:

Commandline parameters:

width=xxx  : The width of the framebuffer
height=xxx : The height of the framebuffer
fullscreen : Force the engine to use fullscreen modes
16bit      : Try to get a videomode with 16bit color (instead of 32)


Controls:

cursor-keys : Moving around
PGUP/PGDWN  : Looking up/down
ESC         : Exit
x           : Switch between Software/LWJGL mode (may have some problems in fullscreen mode!)


BTW: I'm very interested in the HL->3DS converter (the level i'm using for the demo has been converted from Q3 format), because i was always looking for such thing but couldn't find anything good (that worked!).

Hope this helps.

I've noticed a flaw in the GLRenderer that was caused by the fact that LWJGL0.7 behaves slightly different than 0.6...it's fixed now and i've uploaded the fixed version as a "silent update"...

The topic says it all (almost)...the change-log can be found here:

http://www.jpct.net/changes.html

As you can see, this version supports LWJGL 0.7. It comes with a slightly newer version of the LWJGL-DLLs (0.71a) than the last official release of LWJGL does.

Finally, here's a shot showing how the new RGB-scale option for Lights may look like...this is vertex lighting only and as you may have noticed, the colors are looking quite rich though.

Related to this: The upcoming version 0.93 will (most likely) have support for RGB-scaling which can improve lighting quality/appearance. Here are some examples...


No scaling (this is what 0.92 would render)


2x scaling


4x scaling

While this isn't exactly what the software renderer offers (overbright lighting), it comes close to it. The software renderer will support the scaling too, of course.

I've seen Mazer before...as well as the zBuffer-flaws the lighting implementation causes... :wink:

To answer your question: jPCT can't to lightmaps, because it can't do multitexturing. This limitation comes from the fact that it's not hardware only but offers a software renderer too. Multitexturing in software is so expensive, that i decided against it and because the feature-set of both renderers should be as equal as possible, there is not support for it at all.
However, it does have its own T&L pipeline and offers a lighting similar to the native OpenGL lighting (i.e. vertex lighting). It supports ambient, specular (in two slightly different implementations) and diffuse lighting with an unlimited amount of lightsources (in theory...in practice, performance starts to drop when you are overusing light).

I guess you've already seen the "viewer"-test-app i posted on javagaming.org. What you see there is all vertex-lighting using some more or less randomly placed lightsources...and i think it looks quite well for vertex-lighting, so maybe this is still an option for your game.

BTW.: The software renderer supports overbright lighting, which increases the possibilities of vertex-lighting very much (i.e. the maximum light intensity per channel is not 1 but 32 in this case). Sadly, no current consumer hardware can do this, so the OpenGL renderer can't make use of it. The 3dfx Rampage would have supported it, if 3dfx would have just survived... :cry:

Fixed it...try the updated version using the same link as above. I was mixing up the coordinates in the method, so the results were totally wrong *most* of the time, but somehow not in my test-case...
Anyway, it should work now. I got it working like this:


       cube=Primitives.getCube(20);
       cube.setEnvmapped(Object3D.ENVMAP_ENABLED);
       theWorld.addObject(cube);
       cube.build();

       dummy=Object3D.createDummyObj();
       dummy.setCenter(new SimpleVector(0,-40,-100));
       dummy.setRotationPivot(new SimpleVector(0,0,0));


The thing is, that it works this way, but without any other objects in the scene, you won't notice it (except for the fact that the lighting will change).
Anyway, what i basically did was to offset the center of the dummy so that it starts at the point where the camera should be placed in the beginning. You have to make sure, that the RotationPivots of the dummy and the player are describing the same position in WORLDSPACE after doing the transformation (despite the rotation pivot never actually get transformed...). This can be tricky if they differ in OBJECTSPACE...which they don't in this example (they are both placed at the origin). However, maybe drawing this on a piece of paper helps...at least it helped me. There may be other options to get the same effect, but this should work. Then again, i haven't stressed this method very much, so i'm not sure which fancy tricks it will allow for and which not.
I hope it was somehow understandable what i tried to explain...

Get it here: http://www.lwjgl.org/

Anyway, jPCT won't support it until 0.93 or 0.94. I'll wait some days before starting to port jPCT to 0.7, because quite a lot has changed and i want to see how things go first (well, that and i'm lazy... )