I am sure this topic is a very well worn one, but I seem to be having a specific problem. I can't for the life of me seem to be able to get my textured terrain to light properly. Or at all for that matter. I do some vector math to calculate the normals for each point.

But I end up with a plain green sheet without definition. If it means anything, each Terrain has a x and z offset value, as the larger terrain is split into chunks. The ground is also textured, but I do not know if that means anything.

The problem is that I want the game to be able to be run on a lower-end computer. But mine is most definitely not a lower-end computer . I have 4GB of RAM, and the pagefile was not being used. My GPU has 1GB of RAM, and I do not think that was the problem, as I wasn't loading much into it. I guess I will just have to limit the number of chunks to draw at once and do some view frustum culling. Thanks for the help!

I really don't know what a Quadtree is (in terms of 3D graphics) or how I would go about doing anything with them. And having the data be multiresolution probably won't work, but I thank you for your suggestions and I will most definitely think about how I would go about implementing them!

I am working on my project where I render a very, very large terrain. 40 000 square kilometres. Or about 25 000 square miles. That's the size of Southwestern Ontario and then a bit. Or about 1/6 the size of the United Kingdom.

Since this is so massively huge, I obviously couldn't just render it and stick it in a display list. This is because that would take absolutely forever, and would have to do that every time the terrain is changed. That may be a lot, so that is out of the question.

I've decided to take the same approach as Minecraft and many other games, by dividing up the terrain into manageable chunks. I then render one of these every frame or so, and store that in a display list. That works really, really well. Up to a point. I was trying to make it so that I could see the entire terrain at once, in a sort of overview mode. I sat and watched the chunks draw and load, and it was fantastic. I still have some work to do with the lighting and the normals, but it looks good.

And then this happened.

That was just the beginning. It spiked to 99% of my CPU usage, and it actually made my sound stop working and my wacom tablet driver to freeze and stop responding. I decided that that wouldn't make a very good point in a feature list.

And after some fiddling, that brings me here. Asking how any of you managed to wrangle using large terrains. I know that I could just do some trig and such to find out how many chunks are displayed at the current view level and bla bla bla, but I want to see if there are any additional things that I could do, because I want the rendering and graphics to be extremely fast, because the logic is most likely going to be very CPU intensive.

I'm trying to draw some debug information as a HUD over my 3D scene, and when I create a TrueTypeFont my entire 3d model goes.....strange. I can see that it is still there, but it is like a ghostly outline. When I comment out the lines where I convert an AWT font to a Slick TrueTypeFont, it goes back to being normal. I was wondering if anybody had any alternatives to using TrueTypeFont or knows why it is doing this.

Hi,I'm writing my first 3D game in Java with LWJGL, and I am having some problems with rendering terrain. The terrain is planned to be massive, 100 000 000 squares. About 40 000 square kilometres. I know that I can't draw them all at once, so I started with a much smaller, 200x200 area. I use a heightmap to load height values from, and then use TRIANGLE_STRIPS to draw rows. It can render really fast, but I run into a potentially serious problem. Whenever I try and rotate or zoom in using my keyboard, it flickers. It takes less than a second to draw, but it does flicker. I can image that that will become a very serious problem when I have a massive terrain. It requires me to redraw everything every time the view changes.

I was wondering if there was a way to manipulate the camera view without having to redraw the terrain.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org