My suggestion for the naming stuff:
A Interface you give with the Imagebased one, that can be used to generate the filenames accordingly to own needs.(Like make it compatible with tools you use without the need for renaming)
(Also a missing map should be a Warning not a INfo I think)
Index: Namer.java
===================================================================
— Namer.java (revision 0)
+++ Namer.java (revision 0)
@@ -0,0 +1,5 @@
+package com.jme3.terrain.heightmap;
+
+public interface Namer {
- String getName(String base,int x,int y,String extension);
+}
Index: ImageBasedHeightMapGrid.java
===================================================================
— ImageBasedHeightMapGrid.java (revision 7567)
+++ ImageBasedHeightMapGrid.java (working copy)
@@ -27,11 +27,13 @@
private final String textureExt;
private final AssetManager assetManager;
private int size;
- private Namer namer;
- public ImageBasedHeightMapGrid(String textureBase, String textureExt, AssetManager assetManager) {
- public ImageBasedHeightMapGrid(String textureBase, String textureExt, AssetManager assetManager,Namer name) {
this.textureBase = textureBase;
this.textureExt = textureExt;
this.assetManager = assetManager;
-
this.namer = name;<br />
}
public HeightMap getHeightMapAt(Vector3f location) {
@@ -40,14 +42,15 @@
int z = (int) location.z;
AbstractHeightMap heightmap = null;
try {
-
Logger.getLogger(ImageBasedHeightMapGrid.class.getCanonicalName()).log(Level.INFO, "Loading heightmap from file: " + textureBase + "_" + x + "_" + z + "." + textureExt);<br />
-
final InputStream stream = Thread.currentThread().getContextClassLoader().getResourceAsStream(textureBase + "_" + x + "_" + z + "." + textureExt);<br />
-
String name = namer.getName(textureBase,x,z,textureExt);<br />
-
Logger.getLogger(ImageBasedHeightMapGrid.class.getCanonicalName()).log(Level.INFO, "Loading heightmap from file: " + name);<br />
-
final InputStream stream = Thread.currentThread().getContextClassLoader().getResourceAsStream(name);<br />
BufferedImage im = null;
if (stream != null) {
im = ImageIO.read(stream);
} else {
im = new BufferedImage(size, size, BufferedImage.TYPE_USHORT_GRAY);
}
// CREATE HEIGHTMAP
heightmap = new Grayscale16BitHeightMap(im);
I’ll make the suggested changes, thanks. I have only one question: can the Namer object be initialized with the nameBase and ext info, so it does not need to be passed to getName each time?
Hm yeah might be more intelligent to only pass them once ^^
Commit done… I’ve splitted the TerrainGridTest so now exists a new TerrainFractalGridTest, and the original is set to use a list of pregenerated heightmapimages, I placed in the test-data a while ago. I kept the original constructor for ImageBasedHeightMap in case anyone uses it, but it calls the new constructor with a Namer object.
Great, I have one question tho, where do your pregenerated heighmaps get the alphamap(for blending the terrain textures) from? I tried to found where you load those, since they clearly differ for each heighmap part, but I was unable to find out.
Well, I’m using a different material. I found a way to map textures by height and elevation info. No alphamap is included.
Hm I see intersting approach, but is there some kind of Listener I can attach myself to so whenever a new hieghmap is loaded I can set the material for that part of the map manually? Cause I have them already pregenerated and I will probably use a Material with support more different Textures anyway (since the generated ones have like 20 different Biomes).
Well, I just came to the conclusion, that I have to support alphamaps, as I’m gonna need them too, because there are things I cannot calculate on the fly on the GPU (eg. roadmap). But it cannot handle it automatically, as any material can be set, and currently only alphamaps need to be changed, but any other material can have any number of uniforms that is position dependent. There is already a listener interface defined, I’ll add a method that will handle material change, and call it when initialization is done.
Cool, (btw if you wonder what I’m doing currently, I plan to create/support a direct toolchain from l3dt to jme3. But with all the stuff you already did, this mostly leaves me with a automatic material generation)
ok… I have commited the change with a new TerrainGridAlphaMapTest class. I had to change the way it precalculated the initial terrain, because the material needs to be set ahead of it, so now an extra
[java]terrain.initialize(Vector3f)[/java]
needs to be called.
(btw. that’s great, I got some inspiration from l3dt, but I still need to get more natural materials. So if you create some, I’m interested. )
crash oh god… initialize ? Is this use correct ?
[java] terrain = new TerrainGrid( "terrain", 65, 513, G.myHeightMapGrid );
terrain.setMaterial( mat_terrain );
terrain.setLocalTranslation( 0, 0, 0 );
terrain.setLocalScale( 10f, 2f, 10f );
terrain.initialize( Vector3f.ZERO );[/java]
I have new crashes and want to understand if it comes from me or from the update.
I’m doing the exact same things in the same order in the tests, so it should be working. What’s the exception or error?
Okay, I found why… I just decreased the Logger’s level to “Warning” instead of “All”, and then my application was creating tons of objects too fast (it’s much faster without the logger !).
Java didn’t follow and the JVM crashed. I just added a Sleep on a strategic spot and it works now. TerrainGrid feels better too 
Hi Anthyon, Great job with the fractal Terrain Generator! I’ve tested it on an win xp machine with quite old hardware and it works great.
A problem I ran across is that the collision-groups aren’t updated when the terrain is updated, the simple fix under would solve it i guess:
FROM LINE 247 in TerrainGrid.java:
if (control != null) {
int currentCollisionGroup = control.getCollideWithGroups();
control = new RigidBodyControl(new HeightfieldCollisionShape(getHeightMap(), getLocalScale()), 0);
control.setCollisionGroup(currentCollisionGroup);
this.addControl(control);
space.add(this);
}
Thanx for your great contribution to the community!
Hi again. There still seems to be some problems, even after the fix above.
Could it be that the new collision hull is not seamless with the old?
Thanks for the fix… I do have some troubles with the collision check. If I get too far it becomes unreliable, and I can fall through the terrain. I think it’s some precision stuff, and not that it’s not working at all.
Can you describe when do you get this problem? Right after the first switch of terrains, or far away from the origo?
Strange… I just tested it, and I can get anywhere far, except when I’m running straight ahead, in the direction the test positions me. Then I simply fall through the terrain on the second switch.
It’s right after switches of terrains at any time, and happens in any direction. The collisionshape that falls through is a rolling sphere working as a wheel. It seems to fall partly through the terrain and thus it gets shot into the air.
I’ll try to figure out if the sphere falls into the terrain every time, or if it sometimes gets positioned above the terrain. That could indicate whether or not if the accuracy is the problem.
I can also build a simple test case this evening with the issue, that way you can analyze without the unnecessary clutter in my existing code.
I can replicate the problem in special cases as I can see, so if you can provide an always failing test that would be a lot of help.
Is it me or the starting point to a TerrainGrid is (1, 0, 1) ?
When I generate my Grid from (0, 0, 0) to (1, 0, 1), the world’s ZERO location is right in the middle of those four Terrains.
It’s confusing.