Advice needed!

Oops, i guess i didnt see that: Issues concerning Javadoc, core features, scope etc. No troubleshooting requests here please!! Sorry!



Hello,



As the title suggest, i’m bugged right now in my project. It’s my first project using jMonkey, but i did do a previous game using Java3D.



Now, i want to make a retro, but in 3D, Dungeon Hack (Dungeon Master, Eye of the Beholder clone). I have my Dungeon Generator all set up and ready to go. The goal is to have a dynamic world, where monsters and players can alternate the level, destroy walls, construct traps, etc.



I’m just unsure about where to go next, about 3D. Right now, i can generate a 256x256 map composed of cubes without having memory issues, but my maps are supposed to be 512 by 512. Also, all the cubes are rendered no matter what.



IE this is my test code so far:

[java]

for(int i = 0; i <256; i++){

for (int j = 0; j<256; j++){

if(world[j] != 0 && world[j] != 255){

Box b = new Box(new Vector3f(j2, 0, i2), 1f, 2.0f, 1f);

Geometry geom = new Geometry(“Box”, b);

geom.updateModelBound();



Material mat = new Material(assetManager, “Common/MatDefs/Misc/SolidColor.j3md”);

mat.setColor(“m_Color”, ColorRGBA.Brown);

geom.setMaterial(mat);



rootNode.attachChild(geom);

}



}



}

[/java]



Possible Solutions:


  • I heard about VBOs and Display Lists, i’m not sure what they do and why i should use them. In my previous project, i simply added stuff to the root Node and i had no problem, although it was fairly simple and non cpu or gpu expensive. Although i have to keep in mind that every “cube” could have it’s texture changed, could be destroyed or have it’s geometry changed. Also i should have the option to add more geometry or cubes to my Display List (or VBO).


  • I could set up the player’s view to be 32 cubes away. This way, i could calculate only the visible faces of eahc cube and simply add these planes to the root node. The downside, is a lot of calculations each time the player changes position.



    One last thing:


  • I am used to pass the renderer to each object, in pure OO fashion, so that each object renders itself. I am not used to having an “Update/Render” classical loop in my games. Is it a better approach than mine?



    Thanks for the time and, hopefully, answers :wink:



    [edit] Ok i read on Display List and VBOs and it seems in my case VBOs are the prefect choice. So, now, how do i implement them in jMonkey? What do i actually put inside these VBOs? The player’s calculated view? Or do i dump every cube in it?

Does your terrain change?

How often in relation to frames?

Are many cubes identically?



If so combine all cubes of one type to one large model at run time, as your current problem is only the object count.

And update them only when needed. Maybee remove the unneeded sides as well in this step.



For the view distance, you could calculate it only every 2 seconds or so, to reduce wasted cpu power.



Yes the main update is far superior, as soon as you have a bit more complex actions taking place. Basically the objects still render more or less themselves if you look deep enough into the core of jme.



The update loop is far superior as soon as you have a global scope, for example a FullScreen overlay effect, cause the rendering order is really important here. Also it helps you to reduce bugs,as the update loop passes all data texture ect to the graficcard when the objects render in your way, you would have to ensure this in each models render method → mega redundant code.



The last question I’m not sure how jme handles that