I'm sure you could parse the 3DS file.  You can see the texture names in Wordpad but I'm fairly certain you want something better than that .

http://www.gamedev.net/community/forums/topic.asp?topic_id=313126

That is really great Raft!  Nicely done!  You should call it A* 3D  since it handles elevations.

OK - got it all done.  Just got the XML Save / Load working.  Lights, proxy objects, regular objects all in there.

Documentation and packaging is all that is left.  You really will have to read the doc to make use of this thing.  Not that it is overly complicated or anything - just that there are a few behaviors that might seem odd (or outright rediculous) at first.

Reminder though - I havent used this thing in practice yet.  I'm sure I'll find annoyances too and fix them as I go.

I'll try to post doc during the day tommorrow in this thread and the package in the next day or two.  I want to make sure it runs out of the box with some test models so you can follow with the document.  Yes the source code will be with the package.

I got Werdy out of there last night and replaced him with a small 3DS model of a camera.  That is the focal point for the JPCT camera.  It will always look at it, pan and zoom around it using the arrow keys and F1 F2 for pitch.  If you go into "select mode" and select the camera like you would any other object in the kit, those arrow keys move the camera object around the level instead, with F1 and F2 controlling the Y-Axis.  That way you simply put it where you are working on the X, Y, Z plane, unselect it, and pan/zoom/pitch around the new location.

The class I wrote stubs out using multiple cameras with the idea being you could create a bunch and toggle around the level at will but I'm going to move on to XML persistence instead so I can get the code out as planned.  After I distribute the code I'll be using this thing pretty heavily myself for Werdy level design so I'll enhance as I go.

There are two additional things I want to add:

1.  PROXY OBJECTS
For example - Spawn Points and Portal Points and Trigger Point.  They will be colored cubes in the editor basically.  A Spawn Point would have a few name/value pairs to go with it like type=npc, name=my_game_specific_creature_name, file=/my/lame/model.3ds.  I will have an XML template that defines the names and you can just change it to suit.  When the XML persists they will save with it.
A Portal Point will define an area that triggers a terrain swap for the World.  You can use it for a hard unload/reload of a level or a simple transition from outdoor to indoor. 
A Trigger Point is just an object to define an area that is intended to cause some effect - such as automatically opening a door as something approaches.

2.  LIGHTING PROXY OBJECTS Like the old UnrealEd.  Place a torch in the world as a proxy for a light, specify the RGB etc.

Thanks Egon.  I'll integrate it tonight on the devkit.  So obviously when I release the the source it will be dependent on that.

Fine. I can do that in a few days once I clean things up a bit so its more usable.  I would rather send it to folks like Remo initially so something more polished can be produced first - but if there is limited interest I'll just post the code and move on.

Send me a PM with your email and I'll send a zip over.

Hmmmm I was hoping this would generate some significant interest???

If you look at some of the other engines out there such as Ogre3D there are tons of plugins and productivity tools and a bunch are a collaborative effort.  Sure I'm building this for my two games (Werdy and my ToEE'esque game) but there won't be anything specific in the code for those games. 

I'm sure there are lots of cool things that could be incorporated into this that would make it really useful for everyone given a bit of thought.  Not to mention - make JPCT more popular?  If everyone sits around and writes there own tools that's not so productive.  Anyway, just my two cents.  If anyone is interested, wants to help out or has suggestions or whatever I'm all ears.




 

I'll check them out.  Thanks.

Egon:

Is it possible to expose more aggressive transparency in JPCT?  I want to take a look at object fade instead of fog like alot of games but I hate the "popping" effect off Objects.  Going from transparency to invisible and removeObject() - and back again.

The transparency options right now look like a half alpha.

Are people going to want the source when its done?

OK so, I've got the basic mechanics complete.  Here is where I'm at:

- Multiple Object Selection and Visual indicator
- Apply change to multiple selection
- Delta tracking of changes from initial values
- Dynamic Object Loading (3DS single, multipart)
- Load from XML persistence
- Orbital camera with zoom, pan, etc
- Floating FengGui UI

To do's:
- Better camera tracking (it is still chasing Werdy).
- Marker placement for object spawning (see that Marker Toggle button? in marker mode you set a marker on the terrain and the load will occur there)
- Persistence to XML across the board
- custom property extentions per object for game content
- Texture Loader (right now I'm just using my XML texture loader for Werdy)

So what you are seeing in the pic: 
I selected 3 of the tree canopy sections and altered the transparency as a group - notice the ones not affected.  Also I detached Werdy's head and messed with the rotations and translations.  If you select the various objects on the screen you can see all the property delta's in the floater screen - and use the "Stepping" box to get back if necessary.  No undo feature yet.  Its hard to see in the pic but right above the "key" label there is a ComboBox which is always in the context of selected objects - so just the 3 canopy objects are in the list since they are highlighted.  You can lock object selections by using the "Select Toggle" which gives you a special cursor.  Turn it on, select some objects and turn it off and the objects will be locked highlighted.  A regular cursor does nothing but show terrain coords on mouse move. 

Nice.  Culling and Transparency would be perfect.

OK so I tried launch4j soup to nuts with an embedded JRE and it worked.  I have an old IBM T42 laptop I stripped of all Java to test the deployment and all is well.

So - you just do this:

Point the launch4j GUI at your JAR that contains all your code, textures, models etc.  I created a "3rdParty" directory and put all the dependency jars and LWJGL dll's lumped in.  I also copied the JRE directory out of my JDK install location and put it right next to "3rdParty".  Then I just zipped it all up with the EXE that launch4j created.

Here is the XML config I used.  You can see the 3rdParty, JRE, Heap sizes and java.library.path stuff in there.  I hope this helps.  I have been wanting to test this thing anyway so your thread gave me the excuse
 


<launch4jConfig>
  <dontWrapJar>false</dontWrapJar>
  <headerType>gui</headerType>
  <jar>C:\jpct\run_test\move.jar</jar>
  <outfile>C:\jpct\run_test\move_test.exe</outfile>
  <errTitle></errTitle>
  <cmdLine>width=1024 height=768 refresh=0 mipmap</cmdLine>
  <chdir>.</chdir>
  <priority>normal</priority>
  <downloadUrl>http://java.com/download</downloadUrl>
  <supportUrl></supportUrl>
  <customProcName>false</customProcName>
  <stayAlive>false</stayAlive>
  <icon>C:\jpct\Launch4j\demo\SimpleApp\l4j\SimpleApp.ico</icon>
  <classPath>
    <mainClass>MoveTest</mainClass>
    <cp>3rdParty/*.jar</cp>
  </classPath>
  <jre>
    <path>jre</path>
    <minVersion>1.5.0</minVersion>
    <maxVersion></maxVersion>
    <dontUsePrivateJres>false</dontUsePrivateJres>
    <initialHeapSize>256</initialHeapSize>
    <maxHeapSize>256</maxHeapSize>
    <opt>-Djava.library.path=3rdParty</opt>
  </jre>
</launch4jConfig>


I just tried Launch4J which creates a windows executable.  If platform is Windows only it might be an option for you.  Just to note though I only tried software mode since here at work I don't have OpenGL support.  I'm a bit worried about that -Djava.library.path=%LIB% thing.  Not sure how that is going to take exactly unless the configuration tool supports relative paths on that.

Also - I had to keep the classpath Jar references outside of the executable in a "3rdParty" directory.  I'm sure I could have exploded out all the underlying class files in my jar root though.  That wont help the JNI situation though.

Namely Culling, Transparency, Blending, Texture?  Assuming of course you have this state.  If not I'll track them in a wrapper but I wanted to avoid abstracting the API in case anyone else wants to use this devkit app I'm making without stumbling on a bunch of custom wrappers.