And someone PM'ed me about the source code - it is in the src directory in the zip file.

Hi guys.  I haven't looked at the code since 2007.  Suffice to say its open for anyone who wants to advance it or simply use the source for their own projects / ideas.  If I recall I used JDOM for XML parsing and I developed this on XP.  I also used a GUI rendering package (LWJGL / FENGUI) for the floating menu.  I'm sure the whole thing needs to be rebuilt with updates from those sources.  The build.bat is pretty simplistic, assumes file permissions and assumes you have Java in your path.

I'd love to say I can help but I'm just a manager now, you know how that goes.  Half my brain atrophied when I stopped developing in 2008 and was replaced with PowerPoint skills
 

Thanks for the kind words.  I have not touched this code since I released it but keep this in mind:

The biggest weakness is the hardcoded ambient/world lighting inside the devkit.  There needs to be a checkbox to disable any "free" lighting you get when you are configuring a scene.  Otherwise - how would you ever get a true picture of your lighting?  It was a dumb oversight on my part and easily changed.  Better yet the ambient light should probably be configurable and persist with the level so there would be no hardcoded ambient lighting in your game either. 

If I recall, the ambient/world lighting is configured right in the main DevKit class.

You could dowload the "Devkit" code.  Its all about loading and placing objects dynamically and all the source code is included.  The terrain, in this case would be the room and you could load all the furniture through the load interface.  Hope that helps.

Really impressive.  The demo's are really great!  I have to admit because of complexity I was going to avoid elevations for my ToEE RPG and implement regular 2D A* but now that this exists...

What is your distribution going to look like?  Will source be included with purchase like Torque?

Again, really impressive Raft!

Sorry not so familiar with that term.  Do you mean like mixing and matching animations such as having the legs running, walking or standing combined with various separate upper body animations like waving or arms folded?

Yup I guess I'm confused about the difference between moving and flipping.

I've been pretty puzzled about UV texture manipulation too.  For example - I've seen some GL engines implementing a waterfall by moving a seamless water texture across a plane object.  Looks very effective and it can't be too expensive.  They have to be manipulating the UV!  unless they are simply moving/resizing the plane but I don't think so....

There has to be a way to do it.
 

Just a general question about skeletal animation "in game": 

What is the logic of ingame skeletal animation vs. keyframe meshes?  I'm guessing less memory/resources for skeletal animation?  Flexibility to add animations without redeploying the mesh?  I'm a 3DMax Biped user and I've made the comical attempt to export from Max to Ogre3D's format using oFusion.  That was certainly not a pleasant experience.  If I recall it was complaining about vertexes having multiple bone weights and it was removing them during export!  I have NO confidence in a plugin that makes vertex weighting decisions after I carefully assigned them.

I've been a bit suspicious about ingame support for skeletal animation because I'm worried about "when things go wrong".  I can fix issues in max with skin envelopes and vertex weighting - but unless the tool is developed in the game engine itself how can you be certain the mesh translation will work as expected?  Meshes seem "safe".  The Unreal franchise uses meshes only if I recall.

On the other hand clearly skeletal animation "in game" is popular.  Ogre3D does it.  Torque does it.  Not sure how many others but clearly its popular.  Just curious why?  Resources?  Too many model formats to support? 

Nice code raft! First off - its so much cleaner than my meat and potatoes coding style with its just keep on going exception handling  .

I never even considered reversing a sequence.  Nice concept!

Thanks for contributing too of course.  The more the merrier!

Its all a trade off.  JPCT is a very user friendly API for 3D beginners but it is still a game engine and anyone messing with a game engine should expect long hours of testing, research and buckets of frustration.  The javadoc is pretty well documented compared to most.  The forums are a great resource.

Just my opinion:
If I had to pick a source of frustration about JPCT though - it would not be JPCT at all, but the community here.  In my opinion no game engine can exist without community participation and unfortunately there is little participation.  Lots of projects with lots of valuable code written and lots of unfulfilled promises to post code..  Since the tutorials are bit scanty people will rely on that support and I believe it is lacking.

   

     

Thanks.  One feature that needs to be implemented is a "Disable DevKit Ambients" button to kill the ambient lighting that the DevKit is using.  Once you get into lighting your own level you want to add your own ambients not the default ones.  Right now you can't get a "true" picture of what your lighting looks like.  An oversight on my part.

Another cool feature would be a JCPT Config window - to control a bunch of the JPCT's Config functions realtime.   Fog, lighting, glTransparency etc. 

Folks, I've sent the release to Egon (with source code).  Here is a test scene I created with the revised Camera code.  Note the stacked crates and trees of various scale etc.  It only took me about 10 minutes to create the scene.  Once you get used to the tool manipulating objects and lighting is pretty easy.  The camera is still slightly annoying but its much better than before.  I've included this scene in the release (just load "final.xml" in the load XML dialog).  Load that up and select the various objects and check out the settings on each.  Before you try it out though - please read the notes below the image.

BTW - all the models were free downloads from Turbosquid - so you can do whatever with them.



CHANGES TO THE CAMERA:
The functionality is largely unchanged from what I wrote above, but I did redo the camera.
The controls are as follows:
FOCAL POINT MOVE FORWARD - VK_UP
FOCAL POINT MOVE BACKWARD - VK_DOWN
FOCAL POINT ROTATE LEFT - VK_LEFT
FOCAL POINT ROTATE RIGHT - VK_RIGHT
FOCAL POINT UP - F1
FOCAL POINT DOWN - F2
FOCAL POINT ZOOM IN - VK_PAGE_UP
FOCAL POINT ZOOM OUT - VK_PAGE_DOWN
CAMERA ANGLE UP - VK_HOME
CAMERA ANGLE DOWN - VK_END

A FEW QUIRKS:
- I noticed when I switched machines that depending on the machine the zoom can be really slow.  You can tweak the zoom
factor in CameraManager.java.
- When you place a marker it is best to get out of "place marker" mode, since selecting in the Fenggui interface can
cause the marker to move.
- Trees that are based on planes can only be selected from one side!  Annoying...


INSTALL:
This release assumes you are extracting the zip to "c:".  All the paths in the XML are specified as c:\devkit2...

If that is not acceptable you'll have to change the following files:

c:\devkit2\build.bat

c:\devkit2\build\resources\devkitConfig.xml

c:\devkit2\build\user\xml\final.xml


RUNNING THE FIRST TIME:
Just run it and load the XML file I've released with the kit.  Select the various objects in the scene and check out the settings.

HOW TO START YOUR OWN SCENE:
I havent put any file explorers into the GUI yet - so here are the workarounds to get going.  Its pretty painless.

Not that Models, terrain and xml persistence directories are specified in C:\devkit2\build\resources\devkitConfig.xml. 
(the "textures" directory in you'll see in that file is not functional). 

1.  To save as XML, you'll need to create a blank XML file in the save directory - which right now is
C:\devkit2\build\user\xml.  I know its cheesy but that's as far as I've gotten. When you go to save the
list box will see your file and you can select it. 
2.  Put any models you want to use in the models directory.
3.  Put any terrain you want to use in the terrain directory.
4.  All textures are loaded from C:\devkit2\build\resources\textureConfig.xml.  Any textures you want to access
in the devkit need to be precached from that file.  I'll be adding a texture explorer at some point.   
5.  The property extensions config file is C:\devkit2\build\xml\ext_template.xml.  Note that once you start a scene
it will be dependent on that file's state, so you should just change it once!


If you have any problems, suggestings or whatever please post them here and I'll try to help. 

Thanks!
- Todd

I'm preparing the package now.  I'm trying to distribute a version with a functional XML file sample and test models.  I put this test together a few minutes ago.  I was able to rotate the fence pieces easily and build the coral and stuff.  That's nifty.  The camera is proving to be a MAJOR liability though  - I've got to rethink what I'm doing there.  Its really annoying.  I mean reeeaaaallly annoying.   I'll fix it.  A few more days.  Other than the camera though - this thing really works well!

Here is some real basic user guide stuff.  I'll going to do a separate install doc.