Project libProcTer: procedural terrain library

[cjp]

I decided to start this thread, because I re-started working on libProcTer again, and I wanted a central place to discuss progress with the Orbiter community.

libProcTer website: http://libprocter.sourceforge.net/
Demo download (windows): link

Description:
LibProcTer is a library for generating planetary terrains, suitable for use in realtime simulations like flight simulators. The library can use existing data and fill in missing data with procedural terrain generation.

Currently, there is no Orbiter add-on for libProcTer yet, only a stand-alone demo program. It seems to be possible to make such an add-on, but unless it is integrated into an OVP plugin for the next Orbiter version, you'll probably need a very good computer, because speed won't be optimal.

libProcTer is similar to Orulex. Orulex has improved a lot since I started libProcTer, but I think I still have some ideas that are not yet implemented in Orulex.

Screenshot:

Latest news:
(see also the latest posts in this thread)
The tiling has been changed to use the Mercator projection. This should keep the tiles square-shaped, even at high latitudes. Currently there are two big 'holes' at the poles (approx. 50km wide), but there are ideas on how to fix this. Some ideas are written down here.

The source code has undergone a major redesign to make it less chaotic. A diagram of the current next-version design is available here.

An Orbiter add-on based on libProcTer is in development. Before releasing it, I want to add at least one more feature: a 'crater world' plugin for all bodies without map data.

 

[cjp]

I made some progress on the new version, but it still isn't as good as the previous version. The only thing still missing is loading of texture files from disk, and the only thing holding me back from re-implementing it is that I now use a different projection than the images.

I also created a first version of the API documentation.

I have some questions for you:

• Do you like to receive project news through this thread, even when no Orbiter add-on has been released yet? Or should I stop bumping up this thread until I release something useful to the Orbiter community?
• If you are interested in making landscape add-ons, what do you think of the API?
• What do you think about having two landscape systems: Orulex and libProcTer? My idea is: live and let live. Let each one try out his own ideas. Be as open as possible about the solutions used in both packages. Copy as many good ideas as possible from each other. Continue improving as long as you want, and let the user decide which is best.
• Are there comments on the internal software design of libProcTer? Especially comments from experts like Artlav are welcome.
• What would you like me to continue working on? For instance, I could focus on releasing a new demo as soon as possible, or releasing an Orbiter plug-in as soon as possible, or on first getting the texture loading working again.

 

[tblaxland]

I have some questions for you:

• Do you like to receive project news through this thread, even when no Orbiter add-on has been released yet? Or should I stop bumping up this thread until I release something useful to the Orbiter community?
• If you are interested in making landscape add-ons, what do you think of the API?
• What do you think about having two landscape systems: Orulex and libProcTer? My idea is: live and let live. Let each one try out his own ideas. Be as open as possible about the solutions used in both packages. Copy as many good ideas as possible from each other. Continue improving as long as you want, and let the user decide which is best.
• Are there comments on the internal software design of libProcTer? Especially comments from experts like Artlav are welcome.
• What would you like me to continue working on? For instance, I could focus on releasing a new demo as soon as possible, or releasing an Orbiter plug-in as soon as possible, or on first getting the texture loading working again.

1. Post updates here. I am interested even if it is only an academic interest.
2. No comments on the API itself, but I note your use of Doxygen. I've just spent a few minutes browsing their site and it looks pretty handy, especially since I do a lot of my documentation as comments anyway.
3. No problem with having two landscape systems if they don't divert resources from one another (and they don't seem to be).
4. No comments.
5. Getting texture loading working would be high on the list for me.

 

[cjp]

1. Post updates here. I am interested even if it is only an academic interest.
5. Getting texture loading working would be high on the list for me.

Will do.

The texture department has the following challenges:

• I use Mercator projection, while most maps are available as plate carrée. BTW, Google Earth uses Mercator too.
• I'd like to be able to load the greyscale altitude maps with the original high number of bits per pixel. The conversion tools I use now (to make the tiles), and the library I use now to load the images seem to lose this information.
• Currently, I am using libSDL_image for image loading. For licensing reasons, I'll probably have to switch to raw libpng or libjpg in the Orbiter add-on.

The last item has the following reason:
The base distribution of libProcTer is GPL (not LGPL!), and I'd like to keep it that way, to give open source flight simulators an advantage. However, as long as I am the only copyright owner, I will be prepared to sell commercial licenses. For Orbiter, I'll make a free ('as in beer') license, of the type 'not for commercial purposes'. This license will be GPL- incompatible.

Edit:
Just found out that libSDL_image and libSDL are LGPL. It may be legally possible to use them in the OrbiterProcTer plugin. I only don't know whether there are technical difficulties in linking an Orbiter plugin with SDL.

 

[martins]

I am not really sure I understand the rationale about the Mercator projection. Doesn't this mean that the resolution of your mapped textures is decreasing from the poles towards the equator, from essentially infinity to some given value?

Ok, the tiles remain square, so the resolution decrease is isotropic in both directions, but on the other hand, it seems a bit wasteful to spend most of the texture data on the poles, which usually don't get as much close-range attention as the equatorial regions.

With the orbiter tiling system I was actually trying to go the other direction: I kept the latitudinal resolution constant, but reduced the longitudinal resolution from the equator to the poles, by splitting the sphere in latitude stripes, and reducing the number of texture patches in each stripe towards the poles.

I am however realising that this approach (while keeping the resolution approximately constant over the sphere) has its own problems, in particular when trying to implement adaptive LOD methods, so I was thinking about ditching it in the future, in favour of a simple equirectangular projection.

 

[cjp]

Ok, the tiles remain square, so the resolution decrease is isotropic in both directions, but on the other hand, it seems a bit wasteful to spend most of the texture data on the poles, which usually don't get as much close-range attention as the equatorial regions.

It is true that the poles usually don't get that much attention. They tend to be uninhabited, and the most fuel-efficient launches (including virtually all manned spaceflight) happen around the equator. An unfortunate exception is the concept of building bases on the lunar poles, but this shouldn't be the first priority.

Let me explain one thing: I am NOT spending most of the texture data on the poles. Texture tiles are available at multiple levels of detail. Compared to the equator, tiles of equal LOD level on the poles have a much smaller physical size. As the LOD selection level looks at physical tile size (among other things), it will simply not load the higher LOD levels around the poles.

Effectively, the physical size of a texel(*) in the highest loaded LOD level is (approximately, on average) independent of latitude. What is stored on disk is a different question of course, but this may depend on user preferences. Most sensible tile packages will only provide entire map coverage in the lower LODs, and provide high-level tiles only for non-polar regions.

In fact, it may very well be the plate carée method that is wasting texture memory. Agreed, it isn't stretched in the latitudinal direction around the poles, but is is still immensely stretched in the longitudinal direction. If you want to use square-resolution tile textures, and you don't want to waste texture memory on that, and you want more or less square physical tile sizes, then the tiles at higher latitudes will span a much larger longitudinal angle range than those around the equator. The result is that tile neighbor and subdivision relationships become incredibly complicated.

I think, using my method, I am able of combining the following:

• Square texture resolutions
• Approximately square physical tile sizes
• Very simple tile neighbor and subdivision relationships
• Reasonably efficient use of texture memory

(*) I mean Texture Element. The island in the Netherlands is always about 20km long (independent of projection method) .

 

[Urwumpe]

What about replacing the poles by a different projection, like for example a polar projection map? I think orbiter did that in the past.

 

[martins]

Let me explain one thing: I am NOT spending most of the texture data on the poles. Texture tiles are available at multiple levels of detail. Compared to the equator, tiles of equal LOD level on the poles have a much smaller physical size. As the LOD selection level looks at physical tile size (among other things), it will simply not load the higher LOD levels around the poles.

Ah yes, that makes sense. Thanks for clarifying.

 

[cjp]

What about replacing the poles by a different projection, like for example a polar projection map? I think orbiter did that in the past.

I've thought about different solutions, including this one. At least, with the Mercator projection, you know you will need some kind of fix, because the poles themselves can not be part of the map (they are at infinity).

My experience is that with a vertical map resolution of twice the horizontal map resolution, the 'holes at the poles' are already very small, and hardly noticeable from high orbit (see attached images). When higher latitude tiles are added automatically (e.g. when the highest-latitude tile wants to split), the hole visibility can stay low even from low viewpoints.

Still, a solution is needed. I've not yet decided which one to choose (that's why the holes are still there). Some options:

• Stretch the most northern and most southern tiles a bit, to close the gap. Probably hardly noticeable, but might be computationally expensive to move those vertices around each time some tile changes in the polar region.
• Add some vertices that close the gap, and have the same textures as the surrounding tiles (there's always four of them per pole). Might be cheaper, but stretching a row of texels is slightly less visually appealing. My favorite at this moment.
• Special 'top-view' polar maps. Does not combine very well with the rest of the map, and with the terrain generation. If you choose a fixed size polar map, then either the regular grid will start overlapping the polar map when viewed from nearby, or the region inside the polar map will have no terrain generation. Or you need a different terrain generation + subdivision method for the polar regions, but I don't like that.
• Special tiles for the polar regions that use a different projection method, so that they include the poles. I don't like this either: different tile types = more code = more difficult to maintain, and more difficult to roll back other decisions.

PS.
In the attached images you do see higher resolution around the poles. This is because you only see the lowest LOD in these images. At the viewing altitude where equatorial tiles are already split twice, the polar tiles are still what you see here. Based on tile size alone, the polar tiles would be joined in those screenshots, but there simply isn't a lower-than-lowest LOD.

In the wireframe screenshot, each tile has a different wireframe color. In the current settings, each tile has a mesh of 4*4*2 triangles.

 

[Artlav]

About having two landscape systems:
libProcTer does the same job with an entirely different solution. That alone is good enough reason for what was called "live and let live", along with cooperation - one idea is one good idea, two ideas are four good ideas.

About the polar projections:
In Orulex engine the problem is sort of nonexistent, i used 6-way cubic projection which lacks singularities and LOD problems at poles or otherwise.

But, Orulex engine was designed and composed for procedural generation purposes, and procedurally generated planet is a sphere without a concept of pole or any other singularity. Not every planet is like Earth with uninhabited poles.

Mapping a texture to that system is an additional feature, and the main colors do have some singularity problems, but LOD are still latitude-independent. Essentially i use Orbiter's projection for that, whatever it's name is.

Polar view, Earth:

Polar view, procedural planet:

In such model there are some small distortions at the cube's joints:

The grid view to make it make more sense:

And the overall view of the grid subdivision below.
I was thinking about retro-adapting some kind of ROAM to that system, but a way to combine ROAM and textures was never found by me.

About comments on the libProcTer system:
Feels like it's DAMN overcomplicated.
Some of it are differences in coding styles, but with 110Kb/~4500 lines of code for libProcTer vs 121 Kb/~3560 lines of code for Orulex, the feature ranges don't quite add up.

The API boasts a wide selection of functions, but i didn't found the main ones - get altitude and get color by position of some sort. Either they are none, or lost in the noise.
Or, maybe, it's too different and i look for something that is not expected?

Last test-version i tried had some slowdowns when flying low and fast, do it drop resolution when it can't catch up with real-time?

How do you plan to add multicore support?
There seems to be two threads running, but they don't look scalable.

Overall, i can't give any specific comments on architecture and source code without making sens of the source code, and i can't work on making sense of the code since i got lots of things to do (seriously), so general ideas is all i can help with, and sorry if some of the abovesaid sounds like uninformed nonsense.

 

[cjp]

In Orulex engine the problem is sort of nonexistent, i used 6-way cubic projection which lacks singularities and LOD problems at poles or otherwise.

Then you have eight poles instead of two, but OTOH the distortions are a lot less severe.

Polar view, Earth:
[picture]

Polar view, procedural planet:
[picture]

In such model there are some small distortions at the cube's joints:
[picture]

I still can't match that picture quality. Maybe I will with some better map data and a better PC.

The grid view to make it make more sense:
[picture]

And the overall view of the grid subdivision below.
I was thinking about retro-adapting some kind of ROAM to that system, but a way to combine ROAM and textures was never found by me.
[picture]

Question: what kind of pattern does your mesh subdivision system follow? Does it use triangles as basic shape or rectangles? Because of texturing, I felt it was necessary to use rectangles. The reason is that you can't texture-map one half of a triangle with one texture, and the other half with another texture. So the texture edges have to fall on mesh edges.

Feels like it's DAMN overcomplicated.
Some of it are differences in coding styles, but with 110Kb/~4500 lines of code for libProcTer vs 121 Kb/~3560 lines of code for Orulex, the feature ranges don't quite add up.

At this point I should really have a look at the source code of Orulex. Can you please provide me again with a source code link?
I have to say that the next version will be more simplified than the currently released one. The source code may even have shrunken.

The API boasts a wide selection of functions, but i didn't found the main ones - get altitude and get color by position of some sort. Either they are none, or lost in the noise.
Or, maybe, it's too different and i look for something that is not expected?

The current API documentation is incomplete. Most importantly, it is focused on plugin developers, and not yet on application developers. I can imagine most of it is lost in the noise: the terrain generator in the not-yet-released version is really a simple piece of code (I can post it here if you like). Adding some tutorials may make the documentation a lot more readable. To give you a first hint: the job of the plugin is to fill the members m_HeightMap and m_ColorMap.

Last test-version i tried had some slowdowns when flying low and fast, do it drop resolution when it can't catch up with real-time?

Low altitude means larger mesh and more textures. The next version will have less things that scale with total mesh size and number of textures. Of course, rendering will still be slower at low altitude.
High speed (+ low altitude) means lots of new surfaces need to be loaded. The idea is that resolution will drop if it can't catch up, to save frame rate. The next version will have a 'number of texture uploads per frame' setting, which gives a trade-off between performance loss due to texture uploads versus the time it takes to catch up to full resolution when you slow down. Currently it's a compile-time option, but it should be possible to make it run-time configurable.

How do you plan to add multicore support?
There seems to be two threads running, but they don't look scalable.

There are two threads running: one for the simulation and rendering, and one for the terrain generation. How can I make it more scalable? Let the system use more than one thread for terrain generation? Needs some extra code for coordinating everything, but sounds like it's possible.

Overall, i can't give any specific comments on architecture and source code without making sens of the source code, and i can't work on making sense of the code since i got lots of things to do (seriously), so general ideas is all i can help with, and sorry if some of the abovesaid sounds like uninformed nonsense.

Don't worry. I appreciate your comments, even if they are uninformed.

 

[Artlav]

Question: what kind of pattern does your mesh subdivision system follow? Does it use triangles as basic shape or rectangles? Because of texturing, I felt it was necessary to use rectangles. The reason is that you can't texture-map one half of a triangle with one texture, and the other half with another texture. So the texture edges have to fall on mesh edges.

Rectangular. I think it's called quadtree - rectangles divided in 4 or less, with slight cubic extension.

There are two threads running: one for the simulation and rendering, and one for the terrain generation. How can I make it more scalable? Let the system use more than one thread for terrain generation? Needs some extra code for coordinating everything, but sounds like it's possible.

In Orulex there is a central job queue with tasks in it.
Some tasks can be done simultaneously, some require critical sections. On single-CPU systems, the queue is used for small-split non-system multitasking right now.

I was going to make threads to follow the queue doing simultaneous parts. Still need some working on, like detecting non-collisions on LOD updates to make it useful, as well as getting a quad-core CPU.

Right now, one thread is doing the drawing, one does the LOD computing, and optionally, one does procedural generation.

 

[cjp]

Right now, one thread is doing the drawing, one does the LOD computing, and optionally, one does procedural generation.

In libProcTer, drawing and simulation are both the responsibility of the host application. The application can use its own multithreading if it wants to. I have plans for a separate thread for "LOD computing", but I focused first on making it more efficient.

The drawing code in the demo application is embarrassingly simple, with 'beginners' OpenGL' code like 'glBegin(GL_TRIANGLES)' & so on. So far, it is sufficient for the job of demonstrating libProcTer; I'm afraid that a plugin for Orbiter 2006 can only be slower.

Even if you had time to do it, please don't read the source code of the currently released version. It will make your head explode. The next version will be better, but still not optimal (the best feature being it not being released yet ). My hope is that, after developing some versions, I will better be able to understand the essence of the problem, and write a cleaner and smaller solution.

 

[cjp]

I re-enabled texture file loading. Currently I'm still using my old map data; as soon as my Mercator data is finished, I'll release a new demo. it takes long to calculate these maps! And they are only 500m resolution!

I don't think I'll be able to support texture compression, unless there is some way to create compressed textures from uncompressed data in memory. Texture compression could be useful here, because it reduces the amount of data that needs to be pumped to the video card.

 

[cjp]

I released version 0.1.0.
First version with the infamous Mercator projection, and the first to be consistent with the API documentation I released.

Maybe a windows binary will follow soon. Otherwise, you can try to compile it yourself. I manage to do so in Cygwin. And of course it runs in Linux.

I also placed the mesh generating in a separate thread. Now, the only major thing in the main thread of the demo program is the rendering code.
I wonder how this thing will perform in Orbiter. I already made the core of libProcTer compile in Visual Studio. Next step is to update the experimental 'glue code' between Orbiter and libProcTer to this new version.

 

[cjp]

I made an Orbiter plugin that uses the latest libProcTer version, and I'm impressed by how well the frame rate stays high, even on my old & cheap laptop. I'm disappointed in how long it takes for the terrain to load completely. The two observations might be related: maybe I just don't give enough priority to the terrain loading. Currently it is all in 'lowest priority' threads.

Have a look at the attached screenshots.
In the first screenshot, you can see how incredibly detailed the terrain actually is. The DG doesn't cast a shadow, so it may not be obvious from the picture, but it's actually landed! The texture in the pictures is borrowed from another add-on (*), and has a higher resolution than the textures that will be generated by libProcTer. In a finished version, the texture resolution will be lower, but OTOH the ugly tiling effect from this screenshot will be gone.
The second screenshot showed the terrain as generated by a simple dummy terrain plugin. The texture is still the same; the height is now generated with a few sine waves. The terrain is still a bit coarse, as it hasn't fully loaded yet; compare the simT in both screenshots (no time acceleration used). In the second screen shot, the DG is hovering at 1 or 2 km altitude.

I uploaded a windows executable version of the latest demo program; you can find it through the link in the first post of this thread. (this is a standalone demo app; not the Orbiter plugin).

PS.
Is there a way to check the number of views of a thread? When I look at the posts here, it sometimes feels like I'm talking to myself.

(*) The reason for borrowing is that the code to bind libProcTer texture functionality to Orbiter has not yet been written.

 

[TSPenguin]

Sorry for not posting in here. All I can say is "Good Job!". You are making great headway.

You can see the views of the thread in any thread listing (Forum list, new posts, etc.).

 

[tblaxland]

Is there a way to check the number of views of a thread? When I look at the posts here, it sometimes feels like I'm talking to myself.

Fear not, I am following too . Keep up the good work

 

[cjp]

While trying to glue Orbiter and libProcTer together, I walked against an 'interesting problem':

The figure visualizes the mesh data structures in Orbiter and in libProcTer. As you can see, they are not exactly the same, but there is a very large similarity between [MeshGroup, Texture] in Orbiter and [Mesh, Texture] in libProcTer.
The 'stacking' of boxes means there can be more than one of it: for instance, there can be more than one vertex in a MeshGroup (and there usually is). A blue arrow means the number of items can be changed at run-time, while a red line means it can't.
The black arrows with the '1' and 'n' indicate that a Mesh / MeshGroup has a pointer to a texture. A Mesh / MeshGroup is always associated with one texture, but a texture can be used by more than one Mesh / MeshGroup.

First approach:
A naive approach is to use a single Orbiter Mesh, and associate each libProcTer mesh with one of its MeshGroups. This quickly fails, because after an Orbiter Mesh has been loaded, its number of MeshGroups can not be changed. As long as #(Orbiter MeshGroups) >= #(libProcter Meshes) it's OK (you can fill the unused groups with empty mesh data), but as soon as you run out of mesh groups, this approach fails.

Second approach:
My current approach is to simply load a new Orbiter Mesh as soon as I run out of MeshGroups. This works, but now I want to add texture support, so I need some way to connect libProcTer Textures to Orbiter Textures.

This is where the real trouble starts: the number of Textures inside an Orbiter Mesh is also fixed! More importantly, MeshGroups can only be associated to textures within the same Mesh. This means that simply repeating the same trick for textures won't work: if the Nth libProcTer Mesh uses the Mth libProcTer Texture, and they end up in different Orbiter Meshes, the system fails.

Third approach?
My current plan is to reverse the system: start with the allocation of libProcTer textures in Orbiter Meshes, and then allocate libProcTer Meshes on the same Orbiter Meshes where their textures are allocated.

This approach will fail as soon as the number of libProcTer Meshes, associated with the Textures on a certain Orbiter Mesh, exceeds the number of available MeshGroups on that Orbiter Mesh.

If that happens, Textures will need to be re-located to different Orbiter Meshes, and in the extreme case, a Texture's MeshGroups might need to be spread out over more than one Orbiter Mesh. All of this involves expensive data copying operations, and should be avoided.

I think I can avoid the problem by using an Orbiter Mesh with an insanely high MeshGroup-to-Texture ratio. I'll gather some statistics in libProcTer to find out how high it actually needs to be. My hope is that drawing of an empty (zero-vertex) MeshGroup is a cheap operation in Orbiter, because this approach will typically result in a lot of empty MeshGroups.

Another problem is that in libProcTer, the Texture association of Meshes can change rapidly, even when few things change to the textures and meshes themselves. This might become a problem in future optimization steps. This would make it necessary to move MeshGroup data from one Orbiter Mesh to another, when its Texture association changes.

 

[Artlav]

In Orulex, i use one mesh with 1024+128 groups and 1024+128 textures, which is usually sufficient, as at 100000+ polygons the graphics performance is already secondary to the generator's sluggishness.

There is a flag in meshgroup record that prevents it from being drawn at all, so lots of empty groups is not a problem.

Each group corresponds to a single patch of terrain, which triangle count cannot exceed certain value. Each patch of terrain is associated with one texture patch. Several blocks can have a shared texture, if the texture generator is lagging behind the terrain generator (which is common, as the complexity is 10:1), with UV's on different parts of it.

The additional 128 textures/groups were for hosting terrain props, but they were never developed to "on by default" level before the whole thing become obsolete.

In Station Shipyard i use a similar scheme - a large pool of groups, which is filled by the vessel data and textures.

There seems to be no performance penalty for having a 1000+ meshgroups a mesh on it's own right, if your generator put out more than that, it's curious to know why.