In the simpleInitApp() method, there is this code:File file = new File("TerrainGridTestData.zip"); if (!file.exists()) { assetManager.registerLocator("http://jmonkeyengine.googlecode.com/files/TerrainGridTestData.zip", HttpZipLocator.class); } else { assetManager.registerLocator("TerrainGridTestData.zip", ZipLocator.class); }
If I comment out both the registerLocator calls and run the test, it still works. That showed me the test is not getting the data from the zip data downloaded from the google code repo, and I found out it is using part of the testdata jar, specifically in the TerrainGrid folder. In there there is a TerrainGrid.j3o and a bunch of “testgrid_0_0_-1.j3o” files, with the numbers as the cell coordinates. Since you cannot open j3o files within a jar file in the SDK, I unzipped them so it is all in a regular folder, and in the SDK attempted to open it, but I am getting a “Error opening testgrid____.j3o” kind of error.
From what I can understand, the AssetTileLoader loads in models to attach to the terrain grid? If so, is there a reason for having the above code in the test? It confused me a lot. And how can I open those j3o files in the testdata jar, and how were they created?
Thanks!
EDIT: How do I post code correctly, I tried using the “code” tags?
Been a loong time since I looked at TerrainGrid ( I now have a personal grudge against it ) but from memory I had to manually download the zip file and put it in either the project’s root directory if running from the sdk or in the .jar’s directory if running from commandline. Not sure it that still applies.
Also .j3o files can be loaded from either zips or jars (same thing actually) but the assetmanager needs the ziplocator.class registered to do it.
This I know because I made sure I could do it with my tiledterrain routines… since big worlds take a lot of tiles
Thanks, and I am interested in your terrain tiler library. I looked for the code, but in the repository is just example code. Do you have one for the source? How is the performance compared to the terrain grid?
Anyone else want to say anything regarding this terrain example? I don’t see a reason for that code that grabs the zip file from googlecode being there if it doesn’t function.
@8Keep123 said:
Anyone else want to say anything regarding this terrain example? I don't see a reason for that code that grabs the zip file from googlecode being there if it doesn't function.
Deprecated means “not meant for use anymore, will probably be removed soon”.
<cite>@8Keep123 said:</cite>
Thanks, and I am interested in your terrain tiler library. I looked for the code, but in the repository is just example code. Do you have one for the source? How is the performance compared to the terrain grid?
Anyone else want to say anything regarding this terrain example? I don’t see a reason for that code that grabs the zip file from googlecode being there if it doesn’t function.
I’m still working on the terrain-editor program as we speak which will make generating the tiles and terraforming them a lot easier but its taking me a bit of time both finding spare time and brain space to code it and also currently learning NiftyGui from scratch is slowing me down (half the menu system is done but still scratching my head on some things.)
The terrain-tiler library itself works fine but could probably be optimized still, I put it out there for anyone to play with and give me feed-back but I’ve had very little of it so far. I’d hoped it would serve as a replacement for terrain-grid but I guess not having a terrain editor makes it less inviting…
Saying all that I am still open to comments/advice or “constructive” criticism from any and all on it. I may be older but I’m still very open-minded and willing to learn.
Thanks, it sounds really cool, but since I’ve been learning about the terrain grid I think I will stick with this.
I do have another question. Is it faster to load terrain through the AssetTileLoader which loads terrain .j30 files (I’m assuming were made in the SDK terrain editor?) or load png heightmaps made in GIMP? Right now I am creating a large (2048x2048) texture in GIMP and using perlin noise then editing it and creating mountains and making it look nicer, then using a plugin I found that will split an image up into a ton of layers, and I am setting it to split the image into a grid of smaller 256x256 images. So I have a bunch of 256x256 png images that also have x and y numbers in the filename corresponding to the cell location on the entire map. Is this the proper way to do this? I heard about some issues with gimp not supporting more than 16 bit grayscale images or something. Is that fixed?
How were the test data files for the terrain grid tile loader test created?
Yeah. I’m probably not the best person to talk about terrain grid. Although I will say keep an eye on your direct buffer memory usage. I managed to peak at about 8gb with terrain grid once.
From what I remember it sounds like you are doing it right for images. Its basically how it works although I can’t remember if the tiles needed to be 256 or 257 square. For the seam joins. Just experiment to figure that out.
As far as premade j3o vs images I’d have to say images are smaller and generate the terrain on the fly but need material to be generated by code unless you use the plain height based texturing. With j3o tiles you can preset all of that and have greater flexibility for materials and height resolution/detail. But very difficult making tiles that fit as the SDK won’t do multiple tiles last I checked. It was one of my issues. I did half make a terrain editor that worked with the images and resaved them as PNG tiles. Should be somewhere.
Sorry for the lack of info but I personally gave up on it. I’m far from an expert though. There are topics where I discussed this with the devs a long while ago if you search. Might find what I may have missed in my noobness at the time.
Cheers
The HttpZipLocator is not happy. You probably don’t want the file downloaded separately from the app anyways. The heightmap images for the tiles need to be 2^n+1 (eg. 257x257). As for performance, a serialized terrain tile is just the heightmap, stored in an array of floats with some extra meta information. It’s not compressed, so in theory a heightmap image could be smaller. The hardest part, as @radanz said, is making the tiles. Building an editor for it does not stop at just modifying terrain; objects and other meshes will need to be introduced into the scene, and this involves a robust and complete infinite-world editor.
Sploreg is correct. I’m remembering quite a lot more now I’ve been thinking about terrainGrid today… (thanks )
Another caveat I remember is that the tile images need to match at the edges, so the north edge of a Tile needs the same values as the South edge of the joining tile. if that makes sense, only then will the mesh between the tiles line up and not have gaps.
That was my biggest issue in making large terrains as taking a single large height-map image and breaking it into tiles means that the edges wont match and gaps would appear. So basically you’ll need to break the main map into 256x256 sizes tiles and then somehow adding the 257th line in so that it matches the connecting tile. = a REAL pain in the butt.
My current height-map I made for my game concept is a 8192x8192 16-bit gray-scale png smoothed out by ImageMagick. When using terrainGrid I also used ImageMagick to slice it into tiles… its a big chunk of memory hogging image to handle but has good detail.
If you want some code examples I’ll try to find my terrain editor I started on for terrainGrid, it’s incomplete but workable - it uses libpngj for handling png load/save.
@Sploreg Thanks! Cleared up a lot of why my terrain wasn’t correct lol.
@radanz I’ll have to keep that in mind, maybe I could write a gimp script to do it for me. That would be awesome, could I see your terraingrid editor?
@8Keep123: I had a 1hr search through my code backups looking for it but still MIA at this time, which annoys me as I was going to raid it for some parts to go into the new editor. There’s still a couple of places to look so I haven’t given up yet, just ran out of time last night and working today (on lunch break atm).
The GIMP script idea would be gold, it could be set to split into 257x257 pixel tiles but have each tile overlap, great idea. Kinda split each 256 pixels but save 257, just have a condition to add or copy out any remaining pixels in the tiles at the edge so you still have a full tile image.
As a side note the Editor I’m working on currently will generate .j3o tiles that would also work with terrainGrid and also I’ve decided to have a function to scan the terrain and generate image heightmap tiles so people can use them should they want to. This way the generated terrains will work with both my library and terrainGrid (or any other paging/tile loader system)
I have this weekend off so hoping to get some good hours of work in on it.
Yea, cool. Oh well, If you ever do find it, tell me please, it’d be nice to have. I think I’ve decided to start working on making a small sdk plugin to take in a large heightmap and just split it up into the chunks for terraingrid, because I doubt many gimp users would ever have a need for something specific like this, and plus I don’t really know much about python.
Yeah sorry about that, looked into my remote backups but not there either, might have lost it when my HDD burned out a few months back.
Best I could find on terrain editing was an early iteration of my own tiler code, used image tiles to generate terrainQuad tiles and write them to a .jme file (same as .j3o - was copied from a tutorial) has a start of terrain editing code but quite incomplete, I think it was copied from or into the terraingrid version, too long ago to remember exactly.
uploaded the project in a zip file here: http://thegame.radans.net/wp-content/uploads/thegame.zip its 54Mb and contains 8x8 image tiles of 512x512 size for testing and some textures. feel free to look at it if you want, may or may not make a lot of sense as I was experimenting a lot back then the image tiles only being 512x512 means they don’t join as per previous note about them being needed at 512+1 but I left them at 512 since I could not overlap the edges when cutting with ImageMagick, instead I used smoothing to seam them manually, if you could feed it properly cut images it’d probably do better.
After everything I’ve done since, code to cut an image into tiled images, even scaling with interpolation, wouldn’t be difficult… My current code does it but writes out terrainQuads not image tiles, but same diff. (that code is on my googlecode repo)
Yeah I ramble too much, sorry
let me know if I can help.
Cheers.
) but from memory I had to manually download the zip file and put it in either the project’s root directory if running from the sdk or in the .jar’s directory if running from commandline. Not sure it that still applies.
)