3D Engines terrain implementation ogre vs jme

Troubleshooting General Help
1

oh the wonderful complexities of benchmarking :slight_smile:



first of all i must say that both the topic title and post content is very missleading since this is not a comparison between ogre and jme in general, but a comparison between terrain techniques and implementations.



i started out this post by listing a hundred facts about java, jME and performance as arguments against your conclusions, but those lists always comes out more like a flaming war so i decided to skip that…but


  • yes, our old terrain implementation with the sucky clod loding technique is slow, and i could write a faster terrain renderer in qbasic using a better/newer technique
  • no, this does not benchmark either ogre or jme in general, or how the core performs



    i must say that it's the longest most ambitious post i've seen proving almost none of the conclusions drawn  :smiley:



    lets gather up and write a new terrain implementation instead. llama where are you? :slight_smile:
2
MrCoder said:

first of all i must say that both the topic title and post content is very missleading since this is not a comparison between ogre and jme in general, but a comparison between terrain techniques and implementations.

Point taken :)

i must say that it's the longest most ambitious post i've seen proving almost none of the conclusions drawn  :D

Hehe.... actually it started as a post stating "yuck ... this is slow".
Unfortunatly with a little bit of tweaking it wasn't as slow anymore.
So i had to change the message :D

lets gather up and write a new terrain implementation instead. llama where are you? :)

Tried his large terrain as well.
3

more techniques and improved terrain is something we really would want in jme. unfortunately we want a 1.0 release before retiring and thus have several todo's on hold :wink:



when it comes to LODing it's very much about performance vs looks. do you accept popping vertices or not, continous lod or tiled lod and offcourse how hard to lod…

these days with the gpu getting stronger people abandon cpu heavy lod techniques like clod or roam and just try to push as many triangles as possible in as gpu friendly way as possible(geomipmaps, geometry clipmaps etc etc)



llama's terrain with the right settings was pretty fast as i remember? (so long ago since i tested it)

4

Todi, this seems to be something you're very interested in.  The great thing about jME is that we are always appreciative of code contributions by the community. :wink:



Feel free to develop something entirely awesome and revolutionary and then you can be happy because you'll be able to write game code in Java and have terrain that is extremely fast and efficient. :wink:



…see, that's the problem with pointing out flaws is you inevitably get called to the task of fixing it. :slight_smile:

5

guess i have to adapt our old code to the 0.11 version of jme

unfortunatly i am not the biggest ace in 3D, especially texturing and lod algorithms.

6

feel free to clean it up, jme:ify it, oop package it and post as a contribution  :smiley:

7

If terrain gets a rewrite ( or is superceeded )  , can we all get together and agree what we want from it ( as a pass, as a node …, splat this, lod that … , triangle strip, triangle fan,triangle toilet… )


8

i'd say documentify, cleanify and optimify llama's code. if i remember correctly, it even allows implementing different LOD techniques.

i think the one llama implemented is quite similar to the one ogre uses. except llama's code uses dynamic loading/unloading of terrain patches and uses by default a higher LOD level (but i have to admit i drew this conclusion only by running the ogre terrain demo, so it isn't really objective).



nothing against your implementation todi, but as far as i remember it had no LOD.

oh my… i just love terrain LOD algorithms…  XD

9
Todi said:

MrCoder said:

first of all i must say that both the topic title and post content is very missleading since this is not a comparison between ogre and jme in general, but a comparison between terrain techniques and implementations.

Point taken :)

i must say that it's the longest most ambitious post i've seen proving almost none of the conclusions drawn
10

yeah, vertex texture fetch with 3.0 is great for terrain…and shader model 4.0 with geometry shaders, tesselation possibilities and texure arrays for easy splatting…mmm

11
sfera said:

i'd say documentify, cleanify and optimify llama's code. if i remember correctly, it even allows implementing different LOD techniques.
i think the one llama implemented is quite similar to the one ogre uses. except llama's code uses dynamic loading/unloading of terrain patches and uses by default a higher LOD level (but i have to admit i drew this conclusion only by running the ogre terrain demo, so it isn't really objective).

nothing against your implementation todi, but as far as i remember it had no LOD.
oh my... i just love terrain LOD algorithms...  XD

As i already said over a year ago (gush how time flies by): we don't want to compete. ( I just say that in case my english sounds different :D)
Basically there is one main difference between Iliamas aproach and ours.
Iliama (as i understand it) undertook the task to implement seemless terrain without anything else.
So he rewrote terrainblock, added some terainmanager and lod.

We had a more abstract problem. We were in need of a "framework" that could load and parse a world description and then takes care of everything including seemless terrain,
So we started out with the goal to have some "TerrainManagment" that takes care not only of endless terrain but also of placement of static objects in that world terrain, as well as static sounds skybox etc. in short a kind of dynamic world loader. We also started implementing a terraincreator that would create seamless terrain by adapting each "block" to the adjacent ones.
Since neither of us is a 3D guru we relied on jme standard features like the old terrainblock. When it came to lod and texture splatting however our knowledge came to a first limit. And since then we didn't have much time until a short while ago.

Now I think his implementation of  terrain is more feature rich and better than ours. Naturally because we didn't implement one at all.
I think that our apporach to the more abstract problem (world loading with static objects, sounds, skysetting etc.) is better than his because (as i see it) it was not in his scope.

I think it would be beneficial if we could "define" the scope of a potential change in terrainhandling in jme.
We(our team) needs texturesplatting, dynamic loading of terrain AND objects and sounds in that terrain, simulation of daylight and change of skyboxes.

But the basic question for us all here is: What is needed or wanted for jme and what for developers using jme ?
If there is a need for a more general "world definition" framework like ours, then we might simply throw in our (in case of pure 3D rather abstract ;) ) knowledge and file format definitions and perhaps iliama assists with a new and adapted version of his code. I would be willing to spend time on this.
If there is a need for a terrain managment system then i agree that iliamas solution alone is perhaps sufficient for most people.

Comments ? Suggestions ?


12

just one comment. as much as i want people to be able to just plug in a complete "render my gameworld", it's very hard to get those "solve everything"-frameworks adaptable enough…

i think an engine benefits more from having those kinds of modules than a few big complete game modules…but if it can be made extensible and adaptable enough, it's cool

13

Iliamas <- much more awesome nick than LLama :wink:



With the pass system you can add "passes" for things like texture splatting, or morphing, and I think earlier in this thread I attempted to explain how you can use it do object loading and such.



You can customize this as far as you want, including adding sounds and stuff like that. Basically everything that could fit within the block based 3 stage loading mechanism can be "hooked up".



Block based meaning that objects have to be associate with a "block" or several "blocks" that are loaded/unloaded, and are not handled based purely on coordinates. 3 stage meaning that blocks can have 3 stages (or less), based on how far they are from the viewer.