Would forum members consider 3000 x 2500 pixels (7.5Mp) a ‘large’ surface?I ask because rendering a terrain from this size of surface is painfully and unusably slow despite my having recently built a new system designed for fast processing of LIDAR data (W7 64bit, M8 64bit + surf extension, GTX570 1280Mb GDDR graphics card, core i7 3.4Ghz Sandybridge, P67 board, 16Gb RAM, bags of HDD space for temp files). No drapes, projection the same as the map. Terrains are so slow that simply changing a view point takes about a minute, a linked view doesn’t even respond to a change in reticule position and sometimes Manifold just hangs. The CUDA surface transforms are very fast so that aspect is working well, so I assume it’s a Manifold/OpenGL issue? I’ve read everything in the ‘Fine Manual’ on terrains and, yes, I have the very latest driver for that graphs card. Is my experience typical or untypical? Have I overlooked something? Or… should I be considering another application? With the increasing spot densities of LIDAR data this will rapidly become a major issue and block in my work.

Experiment with the surface and display settings to determine where performance changes. That will indicate where a bottleneck may be. Also it may indicate different workflow.

If performance improves when the size of the surface is reduced that may indicate more RAM will help. RAM is inexpensive - installing 32 GB is not costly if experiments indicate that might help. Hangs are usually deeply recursive thrashing where the system is spending more time paging tasks in and out of operational memory than working on them.

Changing the quality of surface or the number of tiles may indicate CPU bottleneck - that cannot usually be helped by more RAM.It may be helped by a faster graphics card - expensive to try.

Workflow can be used to operate at limits of performance. For example you could change a view using reduced settings for faster performance and then do a rendering with higher settings.

---

With the increasing spot densities of LIDAR data this will rapidly become a major issue and block in my work.

That is a problem for most applications - data is increasing in size faster than hardware or software can keep up.

Due to the end of Moore's Law computer technology is no longer improving fast enough for routine improvements to work. Today there are applications which can display LIDAR data much faster than Manifold - at a cost of less general processing capability. Manifold made an early breakthrough for much faster GPU processing within a very general structure - at a cost of slower display.

The objective is both - fast display and fast processing - within a framework of very general structure such as Manifold has - automatic preservation of georeferencing and seamless transformation of data types for example. That task requires new algorithms, parallelized data access methods and breakthroughs in higher functions.

It also requires extensive re-coding of utility code embedded into older technology. For example most Windows applications make extensive use of routine Microsoft facilities. Those in general are not thread safe and cannot be used with new technology. This requires re-coding of millions of lines of Microsoft supporting code so every detail is thread safe - not rocket science but time consuming - years of effort.

Manifold's OEMs who do not require extensive supporting code have been working with new Manifold technology for over a year. Work at Manifold is steadily proceeding to incorporate the new technology into new retail GIS products. Those will provide improved performance when released - probably later this year.

Those will provide improved performance when released - probably later this year.

That sounds promising!

Thanks for that, Mike. The indications of progress are welcome. I’d be surprised if the GTX570 graphics card was the bottleneck so it’s clearly time to upgrade from the 4x4Gb RAM kit to 4x8Gb. Manifold’s overall functionality is too useful to me to seriously consider another application unless I’m really forced to.

it’s clearly time to upgrade from the 4x4Gb RAM kit to 4x8Gb.

No guarantees more RAM will help. It will only help if the problem is thrashing and the extra RAM is enough to stop that. However more RAM is always good with 64-bit Windows. RAM is so inexpensive you can not go wrong plugging in maximum 32 GB RAM.

It also requires extensive re-coding of utility code embedded into older technology. For example most Windows applications make extensive use of routine Microsoft facilities. Those in general are not thread safe and cannot be used with new technology. This requires re-coding of millions of lines of Microsoft supporting code so every detail is thread safe - not rocket science but time consuming - years of effort.

I'm guessing that Manifold vNext isn't going to be a compact little 22MB download then like the current version then.

Hi Lovelace,

I have previously used a VRML viewer to allow large terrains to be viewed. There was also a program called 3dem which I used to use. Manifold is still essential for making the data for these other products. I think they both use a geoTiff to transfer the DTM and a jpg or tiff overlay to transfer the image data.

I have recently used QGIS for clipping out patches of lidar data for Manifold. Manifold has to load the entire surface, whereas QGIS does not so in the instance where you are looking for a small area in a very large seamless dataset, this strategy helps.

Without going outside manifold, there are also a bunch of tricks. Making the terrain window smaller makes terrains faster to work with. Close all other windows other than the terrain and perhaps a simple map window that shows the area to be navigated. One thing that was not mentioned in the number of tiles being displayed. Displaying a high numbers of tiles has a dramatic impact on display speed. The size of your surface does not seem to be very large. It is a case of experimenting to work out where the boundaries are, then staying within the boundaries. If you can reduce the size of your surface just slightly, you may suddenly find that things have sped up by a factor of ten.

lovelace, did you ever figure out how to increase the speed of terrain rendering in your case? I am having similar difficulty rending "small" (10mp) terrains in 3d, but am not holding my breath on the balance of probabilities for new software "later this year".

Did upgrading the RAM to 32gb result in faster rendering, or was the bottle neck found elsewhere? We also have a GTX-570, and enjoy the speed of the CUDA-enabled functions of Manifold as well as PCI Geomatics' GXL, so I believe out setups are similar.

Thanks for the help!

Joe

Hello Joe, My 3D terrain realisations didn’t need the full resolution of the underlying LIDAR so I created a resampled and downsized surface which was faster (or rather, less slow) to render. For full resolution I create a subset of the LIDAR data as I usually only need this for small areas. Not yet upgraded to 32Gb RAM but will do in very near future and report my experience. I’ve been too busy with day to day contracts to fully evaluate alternatives, but I recently (25^th October) got a quote from the UK Esri people of £1,495 + £425 ‘annual maintenance’ for basic ArcGIS and another £2,495 for their 3D analyst package. I’d rather upgrade my GPS kit for that kind of money. Who knows what 2013 will bring?!