RFC for potential Procedural Terrain project

I’m posting an early demo to get comments to help me decide whether to open source this product.  If there is no demand, I will not make the effort to maintain an open source project for this. If anybody offers to help, that would be a strong influence.  Whether open source or not, progress on it will be very fast, as I have an urgent business need for a flexible terrain system.



You can see a very pre-alpha demonstration of my new Procedural Terrain system in Modeler.  All code is brand new, including very efficient LOD and sewing algorithms.  It is not ready to use with a game yet.  It has only the most basic features so far.



Nevertheless, thisModeler cut in  demonstrates merging of multiple altitude algorithms and efficiency at large scale.  This world map instance is the real-time merge of 2 Simplex noise functions (an improvement upon Perlin) plus a low-res visual grayscale map.



  • SHIFT+F1 loads the terrain.  As in typical commercial MMORPGs, the visuals load quickly, but it takes a couple minutes before terrain traversal is responsive (depends on your PC's resources).

  • Use SHIFT+F2 to see the continent you are on.  It is 10km x 10km.  You are at the red dot.

  • Use LMB+RMB to walk and steer (same as some commercial RPGs).  Same+SHIFT to run.  (Plus other standard keystrokes and mouse movements)

  • Run far away from the starting point, then go back home with your HOME key to show how the terrain handles hyper-jumping.

  • To go to a more interesting, mountainous, area of the map, SHIFT+F10 and enter: -3000, 0, -2000.  (I have not added anything to detect edges yet, so you will break it if you hyper-jump or walk off the edge of the world).  Once again, the new, large terrain area loads very quickly and there is no slow-down to traversal.

  • Use PGUP to disable terrain-traversal-mode so you can fly above and look at the terrain.  PGDOWN to enable t-t-m again.



Next on my schedule are support for SVG files for painting altitudes and textures; fix clipping bugs; texture splatting.

You know where I stand on this :slight_smile: Gave it a good 20 minutes on a Vista that frequently brakes things (just yesterday it failed to run Nexon's 'Dungeon Fighter') and everything ran nicely.



=> Takes about 5 seconds to load the terrain, and another 5 until you can walk around without the initial lag.

=> Walking around is generally smooth but I did encounter the occasional lag when "running" using the mousekeys + shift.

=> Also, is it intentional that by using the mousekeys+shift+W (alternative forward) you actually boost your speed even more? By combining all of these, I ran so fast the program/pc had severe problems keeping up, causing pretty major lags and spikes.



Specs:

Inspiron 1720 Dual Core, T7500, 2.20 GHz x2.

Nvidia GeForce 8600M GT



Q: Will the code only be put out in public and up for review once you know for sure that open sourcing it might be a viable option? Maybe you could grant access to prospective developers?



Btw, may I suggest you put on the sky by default? Walking around was much more enjoyable with it turned on :smiley:



With this particular demo I fear you would be putting dangerous MMO ideas into many young minds ;D For sure there is immense potential here, and I would love nothing more than to see it harvested in a greater collaborative effort. Coupled with a user friendly editor, JME would be one major step closer to rapid prototyping.



It's amazing that you've put this together so quickly. Surely you've pushed yourself to get here. I sincerely hope some like minded, competent developers step up to help ease the load.



Would you mind, or mind if I, take a stab at a brief tech-demo of this project to put on youtube? I might make it part of a sort of bi-monthly update to round up all the major development around JME this past month.

erlend_sh said:

...
=> Walking around is generally smooth but I did encounter the occasional lag when "running" using the mousekeys + shift.


I'll have to keep an eye on that.


=> Also, is it intentional that by using the mousekeys+shift+W (alternative forward) you actually boost your speed even more? By combining all of these, I ran so fast the program/pc had severe problems keeping up, causing pretty major lags and spikes.


Known minor bug with Modeler.  Workaround:  Don't do that!  :wink:

Thanks very much for the testing details (incl. testing hardware details).  Usually it takes about 3 email exchanges before I can wring those details from helpers.


...
Q: Will the code only be put out in public and up for review once you know for sure that open sourcing it might be a viable option? Maybe you could grant access to prospective developers?


I can't provide Subversion access while it lives in my application code base, but I could send snapshots of specific classes (as I did for you and lanmower a few weeks back).  If somebody were to convince me that they could be a principal, I would give them Subversion access after signing an NDA.  If the product goes open source, the source could will then necessarily be hosted publicly.


Btw, may I suggest you put on the sky by default? Walking around was much more enjoyable with it turned on :D


I'll consider, but Modeler is a general modeling utility, not a walker.  The sky has nothing to do with the terrain product itself.

Thanks very much for the enthusiastic comments.


Would you mind, or mind if I, take a stab at a brief tech-demo of this project to put on youtube? I might make it part of a sort of bi-monthly update to round up all the major development around JME this past month.


You're welcome to whenever you want.  But you may want to hold off for major enhancements over the next week.  I'm a fast developer, and I'll be concentrating on this for at least another week.

It is still buggy it seems. I used the run faster trick erlend mentioned, but the blocks stopped loading while I was still near the center of the map! It’s like the loading thread crashed completely. Clearly this shouldn’t happen, no matter how fast you’re moving. It might be a problem with the map, but I doubt it… Here’s a screenshot if that helps:



More things:

  1. It seems the terrain has it's backfaces rendered… this lowers fps unnecessarily. Disable backface rendering using CullState.
  2. The sky seems to be very large, when looking at one corner directly, you can see it being clipped against the far plane.
  3. This library would be a lot more useful if it loaded pre-generated terrain, rather than creating it's own.
  4. I don't think it should lag when loading, it feels… unnatural. Even in World of Warcraft when doing traveling the game doesn't lag, even though you move really fast through the landscape. I guess they are using some kind of smart LOD…
  5. I can see that you're some kind of lod… I think it would be faster maybe with smarter buffer management e.g with the kind jME3 uses.
  6. I didn't have any "major" spikes that erlend mentioned when using the ran faster trick, granted there were a few but they didn't freeze my pc like it did to his.
  7. I reproduced the problem I mentioned at the beginning of the post, once again near the center of the map. I don't think it has anything with the run faster trick.

Hi this looks very interesting, procedural terrain, I love everything procedural.



But I do have one question, what exactly would a developer use this for?



is this basically a large scale terrain editor and handler for a game? cause it seems pretty cool. 10km by 10km is beefy :slight_smile:

Hi blaine,



runs fine on Vista 64, core i7, Geforce 200.



Somteimes there are small hickups when Lod is done. But i cant reproduce momokos problem with missing tiles.



Needs to load about 5 secs, but it seems there is no initial lag. Only if i do the teleporting, about 3-4 seconds you see the terain popping up.



Stats:

ca. 55 instantaious FPS,

ca. 46 average FPS,

at 290k polys.



Nice :slight_smile:



I really like your work, and vote for open sourcing the code.



Regards,



Snare

snareoj2 said:

Thanks very much for the testing details.


Eggsworth said:

...But I do have one question, what exactly would a developer use this for?

is this basically a large scale terrain editor and handler for a game?...


Yes, that's right.  The game developer specifies which procedures and parameters to use to generate the terrain altitudes and textures.


  • At one extreme would be local, non-networked games with a pre-defined map, as I explained to Momoko in a previous post on this topic.  The procedural aspect is really trivial in this case, and consists of a single procedure to map the input height map (in image, float[] or jME *HeightMap format) to the terrain system's heightAt() system.


    [li]One interesting intermediate case is the networked version of the previous.  The procedure works like above except that portions of image, float[] or jME *HeightMaps are fetched from the network before they are needed.  Here we also use just one procedure.

  • Another intermediate case is purely procedural Simplex.  The only work to do ahead of time is to run trials with different noise parameters (such as randomization seeds, and any number of frequency+amplitudes) to see what you like best.  A basic example of this is the flattish area around Home of the demonstration.  The grayscale map is nearly flat there, so the only terrain characterstics you see are due to the 2 Simplex noise functions.  Note that this one bullet is a generalization of what mapspinner does (wrt altitudes).  Mapspinner supports just one Perlin function with no randomization seed and limited freq+amplitude flexibility, though these limitations may well be removed in the future.  Purely procedural systems are extremely efficient since they deal only with data at the vertexes that you need to render.  This isn't only good for large maps:  many small games just want a little patch of realistic land for the characters to stand on.


  • The demonstration is an example of the most complex case, where altitudes and terrains for a huge game map are generated on-the-fly by blending very efficient pre-defined data (such as coarse height map images or SVG files) and/or game-managed data (such as game-managed or player-initiated terrain modifications) and/or parameters for noise functions.  Game-managed or player-initiated terrain modifications specifically are handled efficiently so they do not eliminate the procedural benefits, as with other terrain products.



At some point, existing graphical utilities such as SceneMonitor and Modeler can be modified to graphically specify the predefined data needed for terrains.  Until then, you can use 2D raster and vector graphics editors.  No pre-defined data is needed to use defaults such as default Perlin functions + (the upcoming) height-based texturing.

It runs out of memory before it finishes loading the terrain on OS X  :(  It uses up ~150 mb and then calls it quits.  It ran out of memory on the 'blockloader' thread 3 times before it stopped running…



Looks great from the screenshots though… Nice work!

sbook said:

It runs out of memory before it finishes loading the terrain on OS X  :(  It uses up ~150 mb and then calls it quits.  It ran out of memory on the 'blockloader' thread 3 times before it stopped running..

Looks great from the screenshots though.. Nice work!


What JVM are you running?  I don't know much about what's available for OSX.  The last time I worked with that was about 1 1/2 years after Java 1.4 was GA and at that time there was still no 1.4-compatible JVM available for OSX.

The JNLP specifies 256 MB via -Xmx256m.  There are other JNLP memory specification parameters which may be more portable across JVMs.
blaine said:

What JVM are you running?  I don't know much about what's available for OSX.  The last time I worked with that was about 1 1/2 years after Java 1.4 was GA and at that time there was still no 1.4-compatible JVM available for OSX.

The JNLP specifies 256 MB via -Xmx256m.  There are other JNLP memory specification parameters which may be more portable across JVMs.


I'm running 1.6.0_15, I just rebooted and tried again with the same results..  If I get a chance later today I'll boot into the other partition and see how she fares
I don't know whay you mean by showing depth.  The screen shots on this page show that depth is shown the entire time.  The only notable thing I notice when changing screen size is a bug I sometimes get where textures stop rendering.  The temporary work-around for when this does happen,  is to restart Modeler after you set the new desired screen size.

Ah I see what it was. For some reason I thought some command was turned to visualize depth. But it's just the textures being lost.
Guess that's due to the context being reset, huh?

I haven't run into ExceptionListeners before.  API spec says it is for "recoverable exceptions", and I see no addExceptionListener in the API spec index.  Any tips or a reference for using this?  If that doesn't work out, I can add try's everplace where Threads may be getting killed.

Look at the call Thread.setUncoughtExceptionListener.

This item is just as important to me as the terrain stuff, but people considering whether to use the terrain systems should know that the problem under discussion here will not effect your use of Procedural Terrain.

Okay. Still it slows down the fps, and might cause other problems. I think the terrain engine running in a standalone app would be better..

I'd appreciate any additional tips you could give to help me troubleshoot Modeler's JOGL renderer performance problem.

If you're using an Animator object for JOGL, there's a FPSAnimator which lets you set an fps limit, setting it to 60 should do.
Momoko_Fan said:
Quote:
I don't know whay you mean by showing depth.  The screen shots on this page show that depth is shown the entire time.  The only notable thing I notice when changing screen size is a bug I sometimes get where textures stop rendering.  The temporary work-around for when this does happen,  is to restart Modeler after you set the new desired screen size.

Ah I see what it was. For some reason I thought some command was turned to visualize depth. But it's just the textures being lost.
Guess that's due to the context being reset, huh?
Yes, but the weird thing is that I capture that and do everything I am supposed to to reinitialize the scene in the JOGL handlers provided for that purpose.  The textures won't render any more.
Quote:
Quote:
I haven't run into ExceptionListeners before.  API spec says it is for "recoverable exceptions", and I see no addExceptionListener in the API spec index.  Any tips or a reference for using this?  If that doesn't work out, I can add try's everplace where Threads may be getting killed.
Look at the call Thread.setUncoughtExceptionListener.
Ah, it's Thread.setUncaughtExceptionHandler().
Quote:
Quote:
This item is just as important to me as the terrain stuff, but people considering whether to use the terrain systems should know that the problem under discussion here will not effect your use of Procedural Terrain.
Okay. Still it slows down the fps, and might cause other problems...

Yes, and as I said this is a big concern of mine.  But that is irrelevant to my stated point:  Modeler can completely choke but that would have no effect on the quality of the Terrain product.
Quote:
Quote:
I'd appreciate any additional tips you could give to help me troubleshoot Modeler's JOGL renderer performance problem.
If you're using an Animator object for JOGL, there's a FPSAnimator which lets you set an fps limit, setting it to 60 should do.

I am already using FPSAnimator, but not surprisingly this has no effect since low frame rate is itself a symptom of the performance problem.  You can check the frame rate with SHIFT+F11.  Setting the frame rate to 60 when you are getting 27 without any throttling isn't going to help anything (I have verified this with both FPSAnimator and manual throttling).  I should note that I never see these extreme frame rate or CPU issues on Linux (with Sun JVM), where I develop.


I'll make a few long-hanging-fruit optimizations to the Terrain system tomorrow morn, but the performance issues are mainly with Modeler.
Modeler can completely choke but that would have no effect on the quality of the Terrain product.

But modeler is the only way where one can evaluate the terrain product's performance. Modeler's performance issues are eclipsing the terrain product's benefits and possibly problems. It's possible the lag issues and spikes disappear if the terrain product runs outside of modeler, but it's also possible they stay.
Momoko_Fan said:

Modeler can completely choke but that would have no effect on the quality of the Terrain product.

But modeler is the only way where one can evaluate the terrain product's performance. Modeler's performance issues are eclipsing the terrain product's benefits and possibly problems. It's possible the lag issues and spikes disappear if the terrain product runs outside of modeler, but it's also possible they stay.


Fair enough.  I'll notch up priority to make the terrain product independent of Modeler before open-sourcing.  It will then be easy for me to make up a StandardGame or SimpleGame demo.
blaine said:

Fair enough.  I'll notch up priority to make the terrain product independent of Modeler before open-sourcing.  It will then be easy for me to make up a StandardGame or SimpleGame demo.


That sounds great doing the demo in StandardGame... People often see something in the jmetest packages and then try to replicate it in their own StandardGame usage since os many on the forums prefer it..  Only problem is that they may not have read all the StandardGame & GameState documentation on the wiki. :|

blaine said:

I added back-face culling.  No detectable performance effect.


Wouldn't that only make a performance difference at the edges of the continent when you're sitting at a place where both the front and back planes can be seen?

sbook said:

blaine said:

I added back-face culling.  No detectable performance effect.


Wouldn't that only make a performance difference at the edges of the continent when you're sitting at a place where both the front and back planes can be seen?


I think that backside culling eliminates some work even when the back side would not be visible.  Otherwise there would usually be no reason to do it.  For my current purposes, it can't hurt anything and I don't have time now to look into theoretical questions.

  • I've done pretty much nothing to systematize texturing yet.  I'll hit that tomorrow, and in this case I will be able to leverage some code that I had used with my fork of mapspinner many months back.

  • Thanks to the benefits I have received by people enthusiastically testing for me in this Topic, I've decided to open source the project.

  • I've separated Procedural Terrain from my Modeler and my proprietary code.  Still thinking about whether to split or open source one math utility class, but the hard work's done.

  • The terrain system is now usable as a proper standalone library.  A sample user class is provided.  It takes very little code to make your own terrain.  You don't need to modify any code of the library, even if you want to make a custom ElevationProcedure implementation.

  • I've updated the Modeler Procedural Terrain demo and I've also added a SimpleGame Terrain demo.  They both use the same exact sample class to set up the terrain.  Performance of even the Modeler version has improved, but the pauses at Block borders has become more noticable.  That may be due to my decision to do index sewing in the OpenGL thread so that the player will never see unsewn blocks.  I can probably safely move most or all of that work into the background thread.

  • Everything that Procedural Terrain does (excepting texturing, which I just haven't got to yet) is very flexible, from scales and resolutions, to what height algorithms to use (in the form of a chain of procedures), to settings for individual procedures, like static elevation for flat areas or randomzation seeds, amplitude, and frequency for noise functions.

  • Each procedure in the elevationProcedureChain can be optional, absolute vs. relative/aggregating, final.  A trivial case would be the FlatProcedure by itself which would set all terrain to the specified elevation.  A simple case not much more difficult is a JmeHeightMapProcedure by itself which just sets heights absolutely according to a jME *HeightMap.



Here is sample code to show (a) how to configure your own unique terrain as shown in the demos, (b) exactly what needs to go into a SimpleGame (similar code for StandardGame, Modeler, etc.).  This is working sample code that will be part of the Procedural Terrain distribution.  FYI, the only thing that the custom ProceduralTerrainSample constructor does that the library ProceduralTerrainSample constructor does not do is to set up the texture.  Once the texture system's working, the sample can call the ProceduralTerrain constructor directly.


    static public ProceduralTerrainSample newProceduralTerrainSample(
            Vector3f center) throws TerrainMap.NoApplicableProcedureException,
            IOException{
        URL gsUrl = null;
        gsUrl = com.jme.util.resource.ResourceLocatorTool.locateResource(
                com.jme.util.resource.ResourceLocatorTool.TYPE_TEXTURE,
                "/terra_proc.png");  // This holds height values
        if (gsUrl == null) {
            log.error("Image not found:  /terra_proc.png");
            throw new RuntimeException("Image not found: "
                    + "/terra_proc.png");
        }

        TerrainMap terrainMap = new TerrainMap(30f, .3f);
                                          // blockLen and vertFreq
        SimplexProcedure simplexProcedure = new SimplexProcedure(700L);
        // SimplexNoise.TRADITIONAL_SEED;
        simplexProcedure.addFunction(.2f, .2f);  // (freq, ampl)
        simplexProcedure.addFunction(.05f, 1.5f);  // (freq, ampl)
        simplexProcedure.init();
        GlobalGrayscaleHeightMap grayscale = new GlobalGrayscaleHeightMap(
                gsUrl, 10f, -100f, terrainMap.getBlockLen());
                    // GS scale and height offset
        terrainMap.addProcedure(grayscale);
        terrainMap.addProcedure(simplexProcedure);
        terrainMap.init();

        ProceduralTerrainSample newPTS = new ProceduralTerrainSample(
                "proceduralTerrain", center, terrainMap,
                Thread.currentThread().getPriority() - 1, grayscale);
        newPTS.setLoadRange(270f);
        newPTS.setLoadedSpares(10);
        newPTS.setAttachRange(180f);
        return newPTS;
    }




    protected void simpleInitGame() {
            ...  // Light setup, etc.
            camLoc = cam.getLocation();
            terrain = ProceduralTerrainSample.newProceduralTerrainSample(
                    camLoc);
            terrain.startLoaderThread();
            rootNode.attachChild(terrain);
            terrain.update(true);
            rootNode.updateModelBound();
            rootNode.updateRenderState();
    }

    protected void simpleUpdate() {
        if (terrain != null) try {
            camLoc.setY(terrain.getTerrainMap().elevationAt(
                    camLoc.getX(), camLoc.getZ()) + eyeHeight);
            cam.update();
            terrain.update(false);        } catch (Exception e) {
            logger.log(Level.SEVERE, "Aborting", e);
            finish();
        }
    }
}

blaine said:
Thanks to the benefits I have received by people enthusiastically testing for me in this Topic, I've decided to open source the project.
Thrilled to hear that!

Another quick test with modeler:
On my first run I ran into a couple issues. First off, for some reason my shift-run would only last for a second or so until I returned to ordinary walking speed, at which point I could immediately do a lil run with shift again...

Also ran into that resize window bug that messes with the texture. To add to that, it seemed when I closed the program then ran it again, I could not downsize the window again. It was full screen, but it showed the enlarge button instead of the downsize (I dunno the exact English term for these).

On the plus side, I could turbo-run (shift, W, mouse) this time with little to no lag at all! Did you do address this or is it just my computer being in a better mood today? ;)

tried this on mac os x 10.5.8 64 bit intel, java version 1.6.0_15…

app failed on first key press…

here's the output from the console…



22/10/2009 10:01:42 [0x0-0x2cd2cd].com.apple.JavaWebStart INFO: Loaded block +060.000x-180.000
22/10/2009 10:01:42 [0x0-0x2cd2cd].com.apple.JavaWebStart Exception in thread "blockloader" java.lang.OutOfMemoryError: Direct buffer memory
22/10/2009 10:01:42 [0x0-0x2cd2cd].com.apple.JavaWebStart  at java.nio.Bits.reserveMemory(Bits.java:633)
22/10/2009 10:01:42 [0x0-0x2cd2cd].com.apple.JavaWebStart  at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:95)
22/10/2009 10:01:42 [0x0-0x2cd2cd].com.apple.JavaWebStart  at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:288)
22/10/2009 10:01:42 [0x0-0x2cd2cd].com.apple.JavaWebStart  at com.jme.util.geom.BufferUtils.createFloatBuffer(BufferUtils.java:731)
22/10/2009 10:01:42 [0x0-0x2cd2cd].com.apple.JavaWebStart  at com.admc.agf.terrain.Block.<init>(Block.java:133)
22/10/2009 10:01:42 [0x0-0x2cd2cd].com.apple.JavaWebStart  at com.admc.agf.terrain.ProceduralTerrain.run(ProceduralTerrain.java:112)
22/10/2009 10:01:42 [0x0-0x2cd2cd].com.apple.JavaWebStart  at java.lang.Thread.run(Thread.java:637)
22/10/2009 10:01:42 [0x0-0x2cd2cd].com.apple.JavaWebStart Oct 22, 2009 10:01:42 AM com.admc.agf.terrain.TerrainRunner simpleUpdate
22/10/2009 10:01:42 [0x0-0x2cd2cd].com.apple.JavaWebStart SEVERE: Aborting
22/10/2009 10:01:42 [0x0-0x2cd2cd].com.apple.JavaWebStart java.lang.IllegalStateException: Can't 'update' ProceduralTerrain unless block-loader thread is alive
22/10/2009 10:01:42 [0x0-0x2cd2cd].com.apple.JavaWebStart  at com.admc.agf.terrain.ProceduralTerrain.update(ProceduralTerrain.java:424)
22/10/2009 10:01:42 [0x0-0x2cd2cd].com.apple.JavaWebStart  at com.admc.agf.terrain.TerrainRunner.simpleUpdate(TerrainRunner.java:159)
22/10/2009 10:01:42 [0x0-0x2cd2cd].com.apple.JavaWebStart  at com.jme.app.SimpleGame.update(SimpleGame.java:60)
22/10/2009 10:01:42 [0x0-0x2cd2cd].com.apple.JavaWebStart  at com.jme.app.BaseGame.start(BaseGame.java:84)
22/10/2009 10:01:42 [0x0-0x2cd2cd].com.apple.JavaWebStart  at com.admc.agf.terrain.TerrainRunner.parseAndRun(TerrainRunner.java:94)
22/10/2009 10:01:42 [0x0-0x2cd2cd].com.apple.JavaWebStart  at com.admc.agf.terrain.TerrainRunner.main(TerrainRunner.java:82)
22/10/2009 10:01:42 [0x0-0x2cd2cd].com.apple.JavaWebStart  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
22/10/2009 10:01:42 [0x0-0x2cd2cd].com.apple.JavaWebStart  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
22/10/2009 10:01:42 [0x0-0x2cd2cd].com.apple.JavaWebStart  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
22/10/2009 10:01:42 [0x0-0x2cd2cd].com.apple.JavaWebStart  at java.lang.reflect.Method.invoke(Method.java:597)
22/10/2009 10:01:42 [0x0-0x2cd2cd].com.apple.JavaWebStart  at com.sun.javaws.Launcher.executeApplication(Launcher.java:1509)
22/10/2009 10:01:42 [0x0-0x2cd2cd].com.apple.JavaWebStart  at com.sun.javaws.Launcher.executeMainClass(Launcher.java:1447)
22/10/2009 10:01:42 [0x0-0x2cd2cd].com.apple.JavaWebStart  at com.sun.javaws.Launcher.doLaunchApp(Launcher.java:1258)
22/10/2009 10:01:42 [0x0-0x2cd2cd].com.apple.JavaWebStart  at com.sun.javaws.Launcher.run(Launcher.java:114)
22/10/2009 10:01:42 [0x0-0x2cd2cd].com.apple.JavaWebStart  at java.lang.Thread.run(Thread.java:637)
22/10/2009 10:01:42 [0x0-0x2cd2cd].com.apple.JavaWebStart Oct 22, 2009 10:01:42 AM com.jme.app.BaseSimpleGame cleanup
22/10/2009 10:01:42 [0x0-0x2cd2cd].com.apple.JavaWebStart INFO: Cleaning up resources.
22/10/2009 10:01:42 [0x0-0x2cd2cd].com.apple.JavaWebStart Oct 22, 2009 10:01:42 AM com.jme.app.BaseGame start
22/10/2009 10:01:42 [0x0-0x2cd2cd].com.apple.JavaWebStart INFO: Application ending.
22/10/2009 10:01:43 [0x0-0x239239].org.eclipse.eclipse[12385] Exception in thread "AWT-EventQueue-0" java.lang.ClassCastException: sun.java2d.HeadlessGraphicsEnvironment
22/10/2009 10:01:43 [0x0-0x239239].org.eclipse.eclipse[12385]  at apple.awt.CToolkit$4.run(CToolkit.java:1309)
22/10/2009 10:01:43 [0x0-0x239239].org.eclipse.eclipse[12385]  at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
22/10/2009 10:01:43 [0x0-0x239239].org.eclipse.eclipse[12385]  at java.awt.EventQueue.dispatchEvent(EventQueue.java:461)
22/10/2009 10:01:43 [0x0-0x239239].org.eclipse.eclipse[12385]  at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:269)
22/10/2009 10:01:43 [0x0-0x239239].org.eclipse.eclipse[12385]  at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190)
22/10/2009 10:01:43 [0x0-0x239239].org.eclipse.eclipse[12385]  at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:184)
22/10/2009 10:01:43 [0x0-0x239239].org.eclipse.eclipse[12385]  at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:176)
22/10/2009 10:01:43 [0x0-0x239239].org.eclipse.eclipse[12385]  at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)
22/10/2009 10:02:10 [0x0-0x239239].org.eclipse.eclipse[12385] Exception in thread "AWT-EventQueue-0" java.lang.ClassCastException: sun.java2d.HeadlessGraphicsEnvironment


ncomp said:

tried this on mac os x 10.5.8 64 bit intel, java version 1.6.0_15...
app failed on first key press...
here's the output from the console...


22/10/2009 10:01:42 [0x0-0x2cd2cd].com.apple.JavaWebStart INFO: Loaded block +060.000x-180.000 ...




Please specify whether this is from the Modeler or SimpleGame demo.

I have some memory issue with OSX.  As soon as you tell me, I'll make an alternate JNLP file with memory specs given a different way, and I'll keep adjusting until it works for OSX users.