IsoSurface Demo - Dev blog experiment... (released)

I cannot follow those indications on my Linux box because in my case, even if I can see the GUI with all the sliders, the mouse pointer is hidden and I cannot know where I’m clicking. I tried to change the sliders by chance but failed to hit any control. Only changing of GPU works. It seems any Intel GMA or HD may do the same, and X4500 is the only one GMA listed in JME3 minimum requirements. I will try to play with the sliders in the code.


Ups, cannot generate binaries due to a dependency on a project called Lemur (no open source?). Also the assets are missing (no part of what was open sourced?).

@N-18 said: I cannot follow those indications on my Linux box because in my case, even if I can see the GUI with all the sliders, the mouse pointer is hidden and I cannot know where I'm clicking. I tried to change the sliders by chance but failed to hit any control. Only changing of GPU works. It seems any Intel GMA or HD may do the same, and X4500 is the only one GMA listed in JME3 minimum requirements. I will try to play with the sliders in the code.

Ups, cannot generate binaries due to a dependency on a project called Lemur (no open source?). Also the assets are missing (no part of what was open sourced?).

Lemur is another project in contrib. If you search here then you will find a whole forum section for it.

Did you hit the space bar to get the mouse to appear?

Thanks. The space key showed the mouse pointer allowing me to go to Filters tab and disable water, that seems to be what this GPU does not like.

@pspeed said: Lemur is another project in contrib. If you search here then you will find a whole forum section for it.

Ok.

No new release just yet but I did finally get instancing working… and with instancing, I could finally turn wind on for the trees.

Instancing does lose me a few FPS but it gives back so much RAM… it’s glorious.

Here is a video for now:

5 Likes

It’s looking so good, nice work.

So, finally I’ve posted what will be the last release for a while. For my initial concept of this experiment, it is pretty much considered “done”. I could add and tweak things forever but it wouldn’t get me any closer to a game.

Also, some of the things I could add would make the code even more complicated to follow. For example, mutable terrain is no big deal except that suddenly I have to implement terrain caching, etc. which obfuscates things and causes more sharing between zone implementations than exists now. Right now it’s nice because the zone implementations are pretty independent and IsoTerrainZone is especially straight forward since it just grabs density data and generates a mesh. No worries of pulling mutated data from a cache or from storage, etc…

Anyway…

The big change in this update is the trees are now using instancing. This may be slightly slower on some platforms but the memory usage is much better. Furthermore, I can load all LODs at once for free and just switch between them. When I was batching, I rebuilt the batches every time the LOD changed. So now even crossing from one zone to the next should be much cheaper.

Here are the download links again:
https://simsilica-tools.googlecode.com/svn/trunk/IsoSurfaceDemo/release/IsoSurfaceDemo-Windows.zip
https://simsilica-tools.googlecode.com/svn/trunk/IsoSurfaceDemo/release/IsoSurfaceDemo-Linux.zip
https://simsilica-tools.googlecode.com/svn/trunk/IsoSurfaceDemo/release/IsoSurfaceDemo-MacOSX.zip

Note: since google code is dead now you’ll have to build from source here: GitHub - Simsilica/IsoSurfaceDemo: Technology demo of the IsoSurface terrain library.
…until I get around to pushing a new release up.

Controls are still the same as in this post:

http://hub.jmonkeyengine.org/forum/topic/isosurface-demo-dev-blog-experiment/page/2/#post-289215

…except now you can also hit “p” to fire a projectile.

Oh, and I added video recording. F12 toggles video recording on/off.

Bugs of note:
-really the only one I can think of is that the grass doesn’t always sort properly when it’s in the adjacent tile. As you move around it’s supposed to resort the grass based on your current location. For adjacent tiles it’s only supposed to do it when their relative grid position changes… except when you are close and then it will sort them always. So I think some interaction is causing them to not sort when they are supposed to. At any rate, the visual issue is that the grass looks like it did before I fixed sorting and then will suddenly pop in with correct sorting. A relatively minor issue.

Fun ways to play:
In addition to the bug’s eye view mentioned in a previous post, I’ve found that setting walk mode on but then running around with ctrl-shift pressed can be quite fun. Quickly finding the paths that can be traversed and/or seeking high-ground to jump across large valleys can be quite a challenge… but it’s a skill that improves with practice. Earlier tonight I even managed to on-the-fly jump from one tall hill, skip-bounce on a floating island, and continue on to the next hill… it was exciting enough to make me ‘whoop’ out loud.

This is encouraging because the original game idea was some kind of hover-bike racing game. I would do the terrain a little differently and have more and larger trees… but it’s nice to know that even in this primitive form the rough mechanic is still kind of fun.

Might as well load this post up with some screen shots, too:





4 Likes

The demo is simply amazing. Great work. I’m definitly going to use the IsoSurfaceLib.jar for my game - am I allowed to ?

@pspeed: I checked out the IsoSurface SVN project and there are two errors in the code. I’m using the trunk engine jme3-core.jar - the two places are:

Line 123 + 124 in InstanceTemplate.java

VertexBuffer vb = new VertexBuffer(Type.InstanceData); vb.setInstanceSpan(1);
Type.InstanceData doesn't exist + VertexBuffer.setInstanceSpan() doesn't exist.

Type.InstanceData is also referenced in InstancedTreeZone line 371.

I also checked out the IsoSurfaceDemo which gave me an error here:

TerrainState.java, line 64:
import com.simsilica.iso.plot.PlotFrequencyZone;

the PlotFrequencyZone doens’t exist.

Is there a better place to report bugs on SVN checkouts? I know it’s all work-in-progress and I’m only supposed to use the compiled jar-file - but I just wanted to see how it was done and to help.

@asser.fahrenholz said: The demo is simply amazing. Great work. I'm definitly going to use the IsoSurfaceLib.jar for my game - am I allowed to ?

Of course. That’s what it’s there for. :slight_smile:

@asser.fahrenholz said: @pspeed: I checked out the IsoSurface SVN project and there are two errors in the code. I'm using the trunk engine jme3-core.jar - the two places are:

Line 123 + 124 in InstanceTemplate.java

Type.InstanceData doesn’t exist + VertexBuffer.setInstanceSpan() doesn’t exist.

Type.InstanceData is also referenced in InstancedTreeZone line 371.

I mentioned earlier in the thread (thought forgot to mention it in the last release post) that I had to move to trunk (and abandon 3.0 stable compatibility) to get instancing working… because instancing is only in trunk.

@asser.fahrenholz said: I also checked out the IsoSurfaceDemo which gave me an error here:

TerrainState.java, line 64:
import com.simsilica.iso.plot.PlotFrequencyZone;

the PlotFrequencyZone doens’t exist.

Is there a better place to report bugs on SVN checkouts? I know it’s all work-in-progress and I’m only supposed to use the compiled jar-file - but I just wanted to see how it was done and to help.

This is a fine place. If the traffic gets to be too high then maybe I’ll have @erlend create a forum section for IsoSurface (and SimArboreal or whatever, too) or something.

Anyway, you can comment out that line and the if( freqPlot ) section way below it. It’s left over from some testing and I either need to check in the test class or remove that code. Sorry for the trouble.

@pspeed said: I mentioned earlier in the thread (thought forgot to mention it in the last release post) that I had to move to trunk (and abandon 3.0 stable compatibility) to get instancing working... because instancing is only in trunk.

If I understand what you are saying, I have to use the trunk engine jme3-core.jar. But that’s what I’m doing…I’ll double check to see if I have a double reference to the jar-file.

Thanks for replying so fast.

This is the Type-enum from the trunk:

/** * Type of buffer. Specifies the actual attribute it defines. */ public static enum Type { /** * Position of the vertex (3 floats) */ Position,
    /**
     * The size of the point when using point buffers (float).
     */
    Size,

    /**
     * Normal vector, normalized (3 floats).
     */
    Normal,

    /**
     * Texture coordinate (2 float)
     */
    TexCoord,

    /**
     * Color and Alpha (4 floats)
     */
    Color,

    /**
     * Tangent vector, normalized (4 floats) (x,y,z,w)
     * the w component is called the binormal parity, is not normalized and is either 1f or -1f
     * It's used to compuste the direction on the binormal verctor on the GPU at render time.
     */
    Tangent,

    /**
     * Binormal vector, normalized (3 floats, optional)
     */
    Binormal,

    /**
     * Specifies the source data for various vertex buffers
     * when interleaving is used. By default the format is
     * byte.
     */
    InterleavedData,

    /**
     * Do not use.
     */
    @Deprecated
    MiscAttrib,

    /**
     * Specifies the index buffer, must contain integer data
     * (ubyte, ushort, or uint).
     */
    Index,

    /** 
     * Initial vertex position, used with animation.
     * Should have the same format and size as {@link Type#Position}.
     * If used with software skinning, the usage should be 
     * {@link Usage#CpuOnly}, and the buffer should be allocated
     * on the heap.
     */
    BindPosePosition,

    /** 
     * Initial vertex normals, used with animation.
     * Should have the same format and size as {@link Type#Normal}.
     * If used with software skinning, the usage should be 
     * {@link Usage#CpuOnly}, and the buffer should be allocated
     * on the heap.
     */
    BindPoseNormal,      
     
    /** 
     * Bone weights, used with animation (4 floats).
     * Only used for software skinning, the usage should be 
     * {@link Usage#CpuOnly}, and the buffer should be allocated
     * on the heap.
     */
    BoneWeight,

    /** 
     * Bone indices, used with animation (4 ubytes).
     * Only used for software skinning, the usage should be 
     * {@link Usage#CpuOnly}, and the buffer should be allocated
     * on the heap as a ubytes buffer.
     */
    BoneIndex,

    /**
     * Texture coordinate #2
     */
    TexCoord2,

    /**
     * Texture coordinate #3
     */
    TexCoord3,

    /**
     * Texture coordinate #4
     */
    TexCoord4,

    /**
     * Texture coordinate #5
     */
    TexCoord5,

    /**
     * Texture coordinate #6
     */
    TexCoord6,

    /**
     * Texture coordinate #7
     */
    TexCoord7,

    /**
     * Texture coordinate #8
     */
    TexCoord8,
    
    /** 
     * Initial vertex tangents, used with animation.
     * Should have the same format and size as {@link Type#Tangent}.
     * If used with software skinning, the usage should be 
     * {@link Usage#CpuOnly}, and the buffer should be allocated
     * on the heap.
     */
    BindPoseTangent,
    
    /** 
     * Bone weights, used with animation (4 floats).
     * for Hardware Skinning only
     */
    HWBoneWeight,

    /** 
     * Bone indices, used with animation (4 ubytes).
     * for Hardware Skinning only
     * either an int or float buffer due to shader attribute types restrictions.
     */
    HWBoneIndex,
}

from: VertexBuffer.java

Am I looking the wrong place ?

@asser.fahrenholz said: This is the Type-enum from the trunk:

from: VertexBuffer.java

Am I looking the wrong place ?

Most certainly. Maybe you are still building from JME SVN? It’s really old now.

Note the big giant message on this page:
https://code.google.com/p/jmonkeyengine/

@pspeed said: Note the big giant message on this page: https://code.google.com/p/jmonkeyengine/

Hah. Thanks. I somehow assumed that the two repositories were sync’ed - anyways. Thanks - i’ll try my luck with checking out from Git.

@asser.fahrenholz said: Hah. Thanks. I somehow assumed that the two repositories were sync'ed - anyways. Thanks - i'll try my luck with checking out from Git.

Note: you can use SVN to check things out from github and it works just fine. :slight_smile:

Awesome! I think i will use your marching cubes implementation on my voxel based terrain.

By the way at MarchingCubesMeshGenerator.java row 97, isn’t suppose to be
this.cells = new int[cx* cy * cz];
instead of
this.cells = new int[cy* cy * cz];

?

@Riccardo said: Awesome! I think i will use your marching cubes implementation on my voxel based terrain.

By the way at MarchingCubesMeshGenerator.java row 97, isn’t suppose to be
this.cells = new int[cx* cy * cz];
instead of
this.cells = new int[cy* cy * cz];

?

Yes, probably. :slight_smile: I’ll fix it.

@Riccardo said: Awesome! I think i will use your marching cubes implementation on my voxel based terrain.

By the way at MarchingCubesMeshGenerator.java row 97, isn’t suppose to be
this.cells = new int[cx* cy * cz];
instead of
this.cells = new int[cy* cy * cz];

?

Fix committed. Forgot to credit you… sorry.

Thanks for the patch, though.

Hi,

I’m checked out the IsoSurface Demo and downloaded the jinput.jar-files, and the lwjgl-platform-2.9.0-natives from java2s.com, when I try to run the project from jmonkeyengine SDK, the settings window comes up fine, but when I press start, nothing happens…the game runs for a while (the sdk shows it as running) and then it exits.

Any idea as to where to look ?

@asser.fahrenholz said: Hi,

I’m checked out the IsoSurface Demo and downloaded the jinput.jar-files, and the lwjgl-platform-2.9.0-natives from java2s.com, when I try to run the project from jmonkeyengine SDK, the settings window comes up fine, but when I press start, nothing happens…the game runs for a while (the sdk shows it as running) and then it exits.

Any idea as to where to look ?

Well, first, you shouldn’t have had to download any of jinput or lwjgl natives. That’s a sign that things weren’t setup right.

As to the other, if you didn’t get an error on the SDK console then I don’t know what to say… but it sounds like your project is setup strangely… so I don’t know.

Well, I basically checked out the project and a whole bunch of libs were missing (when running it from the sdk). I’ll try a gain and update you as to what the SDK is reporting.