This page covers the misc. details associated with the MMTerrain Engine c#/Unity port, some issues may not be applicable to c++/dx.
If a question or concern isn't covered please send an email to:
Applicable questions/issues will be consolidated and added to the FAQ as needed.
The main documentation is covered in the following files:
The separate in-house tiling utility (not part of the engine, but useful for prepping data) is available here:
NOTE: The tiling utility is essentially an image re-sampler, it provides no specific functionality that can't be duplicated elsewhere. Provided that the tiled imagery is available at whatever XY index and whatever detail level (and the metadata settings are correct), textures and elevations can be fed in at runtime from virtually any source.
The use of discrete images provides a platform-independent means of storing and handling terrain data as an intermediate solution. While it may be suitable for some application, it is expected that proprietary resource management schemes will be employed for advanced applications. Although texture delivery in Unity is largely restricted by pipeline/threading limitations, the actual streaming process in the core is straightforward in terms of tile requests and metadata settings.
A: Assuming you have the basic asset package, please go over the documentation first, in full. All of the critical info is covered in some way, and it's possible that a full understanding of the options may clarify any questions.
A: The tiler is a free utility included as a courtesy, and is NOT part of the actual engine itself. The engine uses tiled images and elevations to assemble a dynamic-LOD mesh at runtime, virtually everything else (including the wrapper script) is an example of just one possible way of using the core engine. Texture2D delivery can be direct in memory (as described in the docs), so discrete images aren't a hard requirement for using the engine.
However, it is understood that there may be difficulties in prepping the data (which is why the tiler is included, as a helpful bonus accessory), and ultimately, the engine should be capable of running the majority of potential data, SO -
Please email and describe the issue, and we will do our best to address it (within reason). It's not possible to guarantee all possible inputs or settings will work, especially for unique/bizarre/extreme cases, which is why the tiler is technically "unsupported". If it is possible to support new or unique special cases with an easy tweak or modification (that can also benefit the tool in general), we would be happy to consider it.
A: Go over the documentation and wrapper script thoroughly, and see how the critical settings are being used (such as tile size).
Examine the test database here:
NOTE: The core engine itself is designed to run with virtually any data source (GeoTIFFs, for example), however, Unity has specific limitations in terms of streaming images, and for the web-based viewer it is easiest to use jpgs for everything.
A: The core engine is an optimized terrain renderer built to handle incredibly large datasets. The streaming engine architecture is designed to work with raw unprocessed heightmaps and diffuse textures. Level of detail, morphing, etc. is calculated at runtime.
A: First and foremost, Unity is very limited in terms of GPU access (such as updating vertex buffers, etc.), and some network functionality. This means that less data can be streamed and rendered than in a stand-alone c++/opengl or dx implementation.
The biggest limitations with the platform are (a) acceptable formats for input data (Unity prefers compressed jpg), and GPU access. The core engine is designed to max out all available resources of the platform, so in a different context (with custom network code and direct GPU control) the possibilities are much greater.
Not publicly. I'm constantly updating the core and stopping to wrap up a package for license hasn't been much of a priority. The c++/opengl implementation is obviously much more powerful, and porting that to c#/Unity obviously came with some restrictions. My primary interest in Unity is portability across different platforms, the ideal development environment would be straight c++ code with an opengl or dx framework.
A: I'm currently looking at options for releasing a package in the Unity store, and/or partnering with others doing related work.
A: I'm always happy to discuss topics related to terrain, but I'm not releasing any source code or laying out the algorithms for others to duplicate. On the other hand, I believe the core approach is very interesting, and I would like to discuss these ideas with others who have done similar research.
A: Yes, check out the Birmingham demo (referenced above), they can all be factored in behind the scenes (lat/lon, UTM, etc.).
A: Probably not, but I am happy to answer any questions, or discuss potential projects and collaboration.
A: I plan on releasing a plugin for Unity 4 and 5 (standard and pro versions), and launching a free viewing utility here on this site.
A: I am generally responsive to direct queries and I like to get feedback (positive or negative), feel free to email me at: