Create terrain heightmap

[deleted-user-OlpHy1NoMNug]

I'm trying to troubleshoot a workflow where I export scenes from CE into Lumenrt and the terrain becomes "sculptable" in Lumenrt.  As it stands now, I can get the "sculptable" terrain into Lumenrt but it's not keeping any of its heightmap attributes.  It just remains flat.  Here is the response I received from Lumenrt support:

Hi Scott,

Thanks for the files.

The 32-bit TIFF format is indeed not supported.

As for your 16-bit TIFF image, I noticed that all values are very close: it only uses a very small part of the full 16-bit range (0 to 65535).
Actually, for maximum precision, LumenRT expects the heightmap to use the full range of values, i.e. the lowest part of your terrain should have value 0, and the highest part should have value 65535, independently of the real-world altitudes. The real-world altitude range is specified separately.

For example, if the real altitudes of your terrain are between 3 meters (lowest altitude) and 15m (highest altitude), then the heightmap image should be filled so that points with altitude 3m have value 0 (full black) and points with altitude 15m have value 65535 (full white). And aside from the heightmap, CityEngine should tell LumenRT that value 0 corresponds to 3m and value 65535 corresponds to 15m, so that LumenRT can build the terrain with correct real-world altitudes.

So maybe you can adjust the CityEngine settings so that it better corresponds to what LumenRT expects.

Any suggestions?

Scott

[MicahTaylor]

That is interesting.  While I am not sure of the answer, I do have a few suggestions.

1. In the LumenRT Exporter, their is a script input option at the bottom of the dialogue box.  Write a script to reclassify the terrain values from 0 to 65535.  This will prevent that from messing up the terrain in CE because it takes place during export.

2. Reclassify a copy of the terrain (normalize 0 to 65535) in ArcGIS before you import it into City Engine.  Use this as your terrain before you export....While this may look ridiculous in CE viewport....it might give you the result you need in LumenRT because currently you are getting "flat" terrain with a small range of values...so a very large range could result in the actual terrain.

3.  Get E-On LumenRT on the phone!  The reason I say this is because, while the LumenRT software is awesome for scene creation, it is very buggy.  I kept losing animations and textures in my scenes after hours of work....I emailed them files and never heard back.  I kept pushing until a support tech called me and they talked me through the problem...after waiting almost 2 months.

Good luck .... I will be interested to know how this works out.

[deleted-user-OlpHy1NoMNug]

Micah,

As far as suggestion #2, how do I reclassify into a normalized data set of 0 to 65535?  I'm familiar with reclassifying but not sure about the normalizing.

Scott

(Separately I agree totally about the power of Lumenrt but the frustrations as well.  Perhaps since they were purchased by Bentley we might see better tech support.  They still seem very much like a startup software company.)

[deleted-user-OlpHy1NoMNug · Accepted solution]

Micah,

I received an answer from Lumenrt and just running through some initial tests it works perfect.  Here's the thread (e-on software - Viewtopic )

Interestingly, now that I can export a scene without exporting the terrain (that is to use the terrain export proxy instead of clicking export visible terrains within the export dialog) the scenes are generating in Lumenrt much quicker. 

To follow up on our previous discussion, I have had several interactions with David Burdick (the representative from Lumenrt) and he's right on top of things so they certainly have that going for them on the support side.

[MicahTaylor]

Excellent!  That is good to know.  David is the person that helped me as well.  I am glad you heard back.

As for suggestion #2...Normalizing may have been a bad term.  I meant linear mapping your range of values.

newRasterPixel = 1 + ((currentRasterPixel - 3) * (65535 - 0) / 15 - 3)

but nevermind that...Davids way is easier.