Better TerrainGrid Control

From what I understand tough, the shadows are 1-bit, so it’s ON or OFF but not “in between”. Shouldn’t the shader maybe go 8-bits to have 255 shades of alpha depending on the occluder pixel’s alpha? Or maybe I’m just wrong with this approach? The goal is to have semi-transparent objects cast a semi-shadow like half tone…? EDIT: @nehon as-tu une idée comment on pourrait y arriver?

After a few issues and a lot of help from normen I’ve managed to add the ability to use the control from within the SceneComposer. The paint is still wet right now, but the hard bit is behind me, and its just plain old java from here, but once I’m satisfied it’s a solid extension I’ll push the update for everyone to use, and possibly to the plugin list, should the wand holder deem it worthy.

5 Likes

So here are the options for the noise-based terrain wizard. The settings mostly speak for themselves. Points of note are that “default material” must use a pre-created material based on a material definition - e.g. make a material based on HeightBasedTerrain.j3md. You can subscribe to the TerrainRequested event if you wish - which gives you access to the TerrainQuad being added, and can change material per-terrainquad if you so desire.

The second tab (Noise Generation) allows you to modify the generation settings, which modifies the heightmap image on-the-fly so you can get a general idea of how your chosen settings are going to look. I can’t really think of a better way to do it than that.

If anyone else has more options in mind let me know and I’ll add them too.

Would it be possible to push this as a downloadable plugin? I think it’s at the state where it’s quite usable now - and would also be grateful for any feedback.

1 Like

Definitely, if only to get more feedback :slight_smile: If you don’t have access to the contrib library PM me your googlecode mail.

1 Like

Awesome =D I’ve pushed the code. @monkeychops I guess you will be the most interested at this point in time.

1 Like

I’ll just leave this here. @jayfella, I discovered by reading optimization topics on the forum that TerrainQuad could be locked (its mesh could be set to “static” instead of “dynamic”, which is the default mode and the only mode that supports mesh deformation/modification) and that would save around 1fps PER TerrainQuad (which certainly makes a difference since there are always at least 9 or 16 TerrainQuads visible) so I think if a terrain is not meant to be modifiable, it could use this line of code that I put in your getWorldItem() function, for instance in the Example_NoiseHeightMap.java file around line #75, like this:

[java]
// Around line 75…
// doesnt exist anywhere, so we’ll create it.
String tqName = “TerrainQuad_” + (int)location.getX() + “_” + (int)location.getZ();
float[] heightmap = getHeightmap((int)location.getX(), (int)location.getZ());
tq = new TerrainQuad(tqName, this.getPatchSize(), this.getBlockSize(), heightmap);
((TerrainQuad)tq).setLocked(true); // <-------- SIMPLY ADD THIS TO LOCK THE MESH
[/java]

I’m quite happy as it saved almost 10fps in my project, just like that! :smiley:

@ben-2 That is correct. If the terrain is to be modified, such as changing its height, then it needs to be set to unlocked. Otherwise lock it to improve performance.

Actually, you know what, I am so sorry, I want to clarify something. I just did many test comparisons with/without my magic code line and it doesn’t seem to affect the fps in the same proportion on every test case. I think it affects the 1fps per TerrainQuad only for VISIBLE TerrainQuads (in the camera frustum) and does not affect the fps for TerrainQuads outside of the view frustum. I have not extensively dug in the JME3 classes to prove this, but I have done 10 test cases in the last hour and I can confirm that if the camera looks at the floor (thus only 1 TerrainQuad is in the frustum) the fps is only 1 frame faster, while if the camera looks far away it is 5-6fps faster. So definitely it won’t always be a huge benefit, but it is still a little good optimization tough :stuck_out_tongue: Sorry for the disappointment :stuck_out_tongue:

Just a note: FPS changes are not valid units of measure on their own. 1 FPS change from 500 FPS is way different than 1 FPS change from 10.

Yes and also, I think 10fps change on my graphics card could very well be 20fps change or even 5fps change for another graphics card. But in my case I have a /kind of good/ graphics card (GTX 650Ti) that was giving only a poor 57fps uncapped and it made that exact same view go from 57fps to 63fps, so it may be even more noticeable on lower end graphics card in my situation. It may very well be a 6fps change that will make it or break it. Who knows, It’s too soon to tell, but of course this ain’t going to be the only optimization I’ll do.

Unrelated
As a matter of fact, I definitely have to find a way to double this framerate or I’ll have to release my game only in 4 years from now when everybody will have GTX 780 lol… but I’m working on it, I’ve read all the optimization pages from the forum but I’m rethinking ways to remove bottlenecks. I found this little optimization we just described, but I’m sure there are plenty more hiding. For instance, I am currently working on a way to triple fps by disabling physics when geometries did not move for a period of time, in my case going from about 60fps to more than 200fps (not even joking). I wrote this in another thread few days ago, it does not belong in this thread, so, I’ll restrain from explaining it here. What jayfella did is really really good enough IMO.

Running the profiler is your best bet. There could be something in your update code that is taking longer than it should. Whenever I start optimizing I have to stop myself and say “no Brent, use the profiler otherwise you might not be optimizing” and that little inner voice is usually correct =)

I’ve been looking into terrain paging for something I’m working on and found this work here which seems to be the most recent developments in this area with Jmonkey - it looks nice but the code published in without a license. @jayfella it seems that your intention is for people to use this code - would you consider adding a license so that it can be? As-is with no license I have to assume copyright and so whilst it’s nice to try it out and look I can’t use it in anything.

of course. I’ll add it now. Anything in my github can be considered free to use and abuse as you see fit.

Which repository are you speaking of specifically?

Whichever you think is best of the World and TerrainWorld :smile:
I’m just looking for something to page in and out heightmaps, and the work you’ve done looks to expand on the basic terraingrid stuff nicely. Still working out exactly what I need to do (basically visualising large heightmaps) but before I start using someone else’s code I like to be sure it’s permitted - and in my experience it’s satisfying as a developer to know your work is being used (or at least looked at).

ok I added a license to both repositories. Not the nicest name in the world for a license, but it pretty much describes what you’re allowed to do.

1 Like

Haha, nice :smile: