First I want to explain what I’m trying to do.
I’m trying to make a terrain of North America, to a fairly precise scale. With special software I created 8bit png heightmap tiles. 1024x1024 pixels each. Each pixel right now represents 1000 meters. So each tile represents an area of 1024000 meters^2. I have 165 tiles in all from 1_1 to 11_15.
I know from the TerrainGridTileLoaderTest example that it’s possible to set up a paged terrain with many heightmap tiles and material tiles,
My questions are:
The heightmap, when loaded, what size does it take on. If my png file is 1024x1024 pixles will it be 1024 units when loaded by default? And how does the height work? I know the gray values go from 0-255, so does that mean its originally no more then 256 units tall? (given that we are doing no scaling)
Are 16bit gray scale images supported for heights? If so, what would their vertical reach be?
I can see that in TerrainGridTileLoaderTest only 1 tile is loaded in each direction around the camera point. Is it possible to change this? To load 5 tiles in each direction? I would like to be able to control the distance at which the new tiles come in.
When I’m turning on LOD control on my terrain mesh, I see the LODs simplifying the terrain. Is there a function that I can use to specify the distances at which to simplify the terrain? In my case, the simplification starts out way too far in the distance, I would like to make that distance smaller.
I will be dealing with very large distances in my software, so I will need to be able to set the cameras far clipping plane fairly far off. With other engines I had rounding errors because the transforms were done in single precision, 32bit values. Various multi pass bucket techniques (depth partitions) were rewired to render a huge distance, where a distance from the camera to the far off object would be divided into buckets with a distance that has no more than 5 zeroes in it. That takes into account the close clipping plane if that plane clips at 0.01, counts as two zeroes.
Does JME3 have the same problem? What kind of precision does it use? Is there a way to use depth partitions, or can JME handle distances of about 100,000,000 units just fine?
is not a JME problem, really, but an OpenGL one. That’s why you encounter it so often.
Still, with proper LOD and camera-relative coordinates it almost never comes up in most cases. Obviously, you can’t just throw the whole world atlas at OpenGL and expect good things… 95% of what it would be rendering would be wasted effort anyway.
Ok, so JME is still single precision. No problem. I’ve seen double precision engines used for space sims…like Limit Theory, but I guess since GPUs still do single better then double, most engines will still use single.
Does JME have multi pass bucket rendering techniques (depth partitions)? Problem with huge distances is that objects that are too far away will flicker when you move around, so something like a depth partition has to be used.
By camera-relative coordinates, do you mean shifting everything into a more “valid” space when you get too far from 0,0,0?
Ok, so JME is still single precision. No problem. I’ve seen double precision engines used for space sims…like Limit Theory, but I guess since GPUs still do single better then double, most engines will still use single.
Does JME have multi pass bucket rendering techniques (depth partitions)? Problem with huge distances is that objects that are too far away will flicker when you move around, so something like a depth partition has to be used.
By camera-relative coordinates, do you mean shifting everything into a more “valid” space when you get too far from 0,0,0?
Just keep your world data and visualization separate. You can only display about 1920x1080 pixels at a time anyway, no need to use astronomical values to achieve that. Those can be kept in other datasets and be reduced before display.
@DieSlower said:
My questions are:
1) The heightmap, when loaded, what size does it take on. If my png file is 1024x1024 pixles will it be 1024 units when loaded by default? And how does the height work? I know the gray values go from 0-255, so does that mean its originally no more then 256 units tall? (given that we are doing no scaling)
Are 16bit gray scale images supported for heights? If so, what would their vertical reach be?
I can see that in TerrainGridTileLoaderTest only 1 tile is loaded in each direction around the camera point. Is it possible to change this? To load 5 tiles in each direction? I would like to be able to control the distance at which the new tiles come in.
Yes, 256 world units. It is up to you to decide what a world unit “means” - is it one meter, 1 kilometer, the Highest point / 256 “meters”. Also, the images need to be 1025x1025, there must be some overlap or there will be seams in the terrain. There are posts on these forums about that, hopefully you can find those.
No. But you can read whatever data you like and populate a float-array with your code and use that as height field. With a bit of coding on your part it doesn’t have to be image based at all.
No. The current implementation of “endless” terrain is what it is. There are multiple alternatives people have talked about on these forums, don’t know if any of them are packaged as a plug-in. Google search for “terrain paging system”.
@normen said:
Just keep your world data and visualization separate. You can only display about 1920x1080 pixels at a time anyway, no need to use astronomical values to achieve that. Those can be kept in other datasets and be reduced before display.
So the distances will get a bit large. Is there some other way to accomplish this? Most likely at some certain distance I will swap out the terrain for a much more low rez version, but it will still need to be fairly large. And the objects that will be displayed on it, need to be seen on one screen.
Right now whats stopping this is the z fighting that happens on very far objects and the overflow errors. Overflow I think can be fixable with translating the scene closer to the origin.
For the Z fighting…is there some multipass or depth partition rendering in JME?
So the distances will get a bit large. Is there some other way to accomplish this? Most likely at some certain distance I will swap out the terrain for a much more low rez version, but it will still need to be fairly large. And the objects that will be displayed on it, need to be seen on one screen.
Right now whats stopping this is the z fighting that happens on very far objects and the overflow errors. Overflow I think can be fixable with translating the scene closer to the origin.
For the Z fighting…is there some multipass or depth partition rendering in JME?
Again, if you separate the actual terrain data from the visualization you don’t need to render all that stuff you don’t even see in the end and a) save processing power and b) easily get along with 1000 units by scaling the terrain data depending on the zoom level.
I guess I dont understand completely what you mean by separating terrain data from visualization. I understand that you cant see all of the terrain pixels on the screen since its many miles long, and only 1920×1080 pixels are visible at any time. Do you have some specific technique in mind? or a method to visualize this?
In my software the user must see from east to west coast, and zoom in to any point…just like in google earth (but with flat terrain)
I guess I dont understand completely what you mean by separating terrain data from visualization. I understand that you cant see all of the terrain pixels on the screen since its many miles long, and only 1920×1080 pixels are visible at any time. Do you have some specific technique in mind? or a method to visualize this?
In my software the user must see from east to west coast, and zoom in to any point…just like in google earth (but with flat terrain)
Google earth won’t let you see full detail of east and west coast at the same time. It properly uses a resolution pyramid and pages in more detailed data as needed.
How did you get my name right in the @mention and then mess it up in the body? As pspeed said, you have to scale the resolution of the displayed data depending on the zoom as in google earth. You could even use a single terrain page and just change the heightmap to form the whole of north america or a small area you zoomed into.
I guess I dont understand completely what you mean by separating terrain data from visualization. I understand that you cant see all of the terrain pixels on the screen since its many miles long, and only 1920×1080 pixels are visible at any time. Do you have some specific technique in mind? or a method to visualize this?
…)
Have you looked at what @aaronperkins is doing with jmeplanet? That is a very interesting thread and may give you a direction to move in, as well as example code, even though you are using a flat terrain.
You should also look at @javatar’s 3D mercator charts. He’s written up some great documentation to go with the package…
@pspeed
Right, not full detail of course, one would be high and one low or both low.
@normen
Sorry, lol…that’s what happens when you are up for more than 24h The tile approach is kind of what I’m thinking of doing. Having many tiles close in so people can move around…or fly and and maybe use a fog cover at far extends or some other trick… On zoom out at a certain distance the detailed tile will look pretty flat anyway, so there is no reason i cant switch it out with a fairly low level mesh that covers the whole North America.
For the zoomed out view I would have to use wither multi-pass rendering, or the scaling trick. I will have to see what simpler, to code time wise, and what gives better performance for future development.
In zoomed in mode it looks like i have no choice but to go with the camera oriented coordinate system. Are there any special techniques for that? Or anything in JME for that purpose? Right now I’m thinking of checking the distance and applying an offset to the whole scene. Not sure how that will effect performance for now.
Thanks for the links, i will take a look at them. The jmeplanet looks a bit too much for what i’m doing right now, I actually seen that page although have not looked at the code yet. The 3D mercator charts link could be exactly what I need. I’ll look through it, and update the thread when I have a solution.
As pspeed said, you have to scale the resolution of the displayed data depending on the zoom as in google earth. You could even use a single terrain page and just change the heightmap to form the whole of north america or a small area you zoomed into.