Me and and one of my friends have been working on a 3D tank game for a couple of months. It is far from ready, but if you’d like to see some screenshots and our project status, please turn your browser to:
http://javawarz.saberhagen.org
We plan to release a tech demo of the game this summer.
Regards,
/ Pike
Who!
Looks very good ! 
The framerate looks good too… What was the computer’s specs running on ?
I’d love to try this game…
++
Chman
The game was running on a Athlon MP 1600+ with a geforce 4 4200. Remember that the framerates in the screenshots are sometimes misleading because they were taken during different stages in the development. In the current codebase with the new terrain engine, the framerate is between 100-200fps in 1024x768x32 depending on view.
// Gregof
JavaWarz Developer
Very nice shots. Are you using Quadtrees or Octtrees to render the terrain?
EDIT: And you website also answers this… Octtree. I have yet to play with octtree. Have you played with Geomipmapping yet? If so, how would you compare the two?
What model format are you using for the tank?
EDIT: Oh, I see from your site it’s milkshape. Do you make use of a skeletal system for animation?
Keep up the great work. I look forward to a chance to play with it.
No skeletal animations. The model consist of a couple of groups -> turret, chassis, gun, wheels and tracks. From there the game engine can identify all parts and move them individually the way we want, ie rotating chassis/turret, elevating gun, adjust wheel position based on suspension etc. The tracks movement is simulated by rotating(moving) it’s texture.
We don’t know if this will be the final way of making a “JavaWarz-tank”, but it seems to work great for now.
Regards,
/ Pike
[quote]Very nice shots. Are you using Quadtrees or Octtrees to render the terrain?
EDIT: And you website also answers this… Octtree. I have yet to play with octtree. Have you played with Geomipmapping yet? If so, how would you compare the two?
[/quote]
Hi
We initialy implemented an octtree based renderingsystem for the terrain, but the implementation was not good(read: fast) so it was scrapped (Sorry, that it wasn’t reflected on the page). The new terrain engine uses both quadtrees and geomipmapping although it isn’t complete yet. I plan on writing some docs on the site describing the techniques currently used and those planned.
// Gregof
I’d be very interested in reading how you handled that. I currently use geomipmapping extensively and have had good results on large terrain, I am using frustum culling. What would the Octtree + geomipmapping technique give you over geomipmapping + frustum culling? Does the Octtree allow for occlusion culling?
Hi
Thanks for your interest in our game/engine!
The goal of the terrain in our engine, is to be able to render very large ( > 100 square kilometers). In our case, our geomipmaps are 17x17 vertices in the highest detaillevel and 2x2 in the lowest level (5 levels), if we use only geomipmapping + frustum culling, the number of checks against the frustum would grow exponentially and they are (at least what i have seen) somewhat computationally expensive when the terrain get larger (i.e size doubles, and frustum checks go up 4x). With the mipmaps as leafs in the quadtree, the removal of the unseen geomipmaps should be a lot quicker with fewer frustum checks.
Note that i haven’t tried the lower mipmaps and very large terrains yet, as we are still in heavy development, but the results so far has been encouraging. I hope i have the time™ to document the techniques used later 
Regards
// Gregof
So what exactly does the Terrain Render do? Does it render terrain that is near to you.
The differnt aproach would to be to load the entire map into memory at once. I guess this could get too big to keep in memory. Is that why you do the terrain rendering - basically breaks things up? If it breaks things up, then do you have the terrain stored in an object file and parts of the object file are loaded when needed?
Hi
The “terrain renderer” renders the map, but in order to do so efficiently, it “splits” the map up in pieces that is assembled in runtime dependent on your current view. If you have small maps, they can be fitted in to memory directly but when the maps are getting very large one has to dynamically load parts of the map from disk while unloading others when needed.
regards //
Gregof
really looks good!
are you planning to sell the game, make it opensource?
Larry
[quote]really looks good!
are you planning to sell the game, make it opensource?
Larry
[/quote]
We’re glad you think it looks good.
Both me and Gregof has started many small game projects before and they NEVER get anyway near finished.
This time we’ve made a promise to ourselves to run this project till it’s finished. 
That’s our primary objective.
Until then there is no decision regarding the license of the game/code, however we doubt we’ll ever try to make it commercial.
Regards
/ Pike