1

I am a beginner QGIS user, using it to supplement other skill sets in 3D modelling and rendering.

I am trying to use UK lidar data in Blender to render 3D topographic maps. For this to work correctly I need to use a UINT16 DEM raster that when using the hillshade layer style / render type in QGIS, looks as smooth as a babys bum. The issue I am facing currently is when I export a UINT16 tiff (a format needed for Blender to use as a displacement map) the tiff appears to have terracing / stepping artefacts which previously were not there in the previous merged float32 lidar DTM.

Current process:

1 - Import lidar DTM tiles to QGIS 3.20.3-Odense using OSGB36 British National Grid project CRS

2 - Merge tiles using float32 as an output (when viewing in the hillshade render type, it looks perfect. Unfortunately Blender does not accept float32 tiff files as a displacement)

3 - Translate (Raster - Conversion - Translate (Convert Format)) from float32 to uint16 using standard settings, no compression, same projection (severe terracing / stepping artefacts apparent when viewing in the hillshade render type)

See below gif comparing the two.

enter image description here

I am unable to use the uint16 tiff as it stands as the visual impact (stepping) in the displacement in Blender is too visible and not an accurate representation of the terrain.

Attempts at solving this issue:

1 - using GRASS r.rescale:

Following the thought process that the original float32 having values between 115.823 and 527.712 is quite small, and the conversion to uint16 is compressing the values, merging them in areas to create the steps. Rescaling the values to something much larger using GRASS r.rescale could reduce the issue when translating to uint16. This did not work, I had the same result as using standard values when translating to uint16.

2 - Double checking there wasn't a 'nearest neighbour' resampling method anywhere in my process. Thinking if I could use 'bilinear' instead it might not create the stepping. Couldn't find this anywhere in any tool I am using.

3 - Try all the setting variations I could in the raster translate tool. No solution found.

I am struggling to see what I'm missing. I had the same problem when I first started using QGIS and SRTM data where I was using 'export map to image' for the displacement map, and the resulting 0-255 jpeg obviously created the stepping due to lack of information. However as I am using uint16 I fail to see why the conversion is creating the artefacts when there should be 0-65000 odd values available.

Improve this question
2
  • Interesting question, Phil. I'm curious about your process step #3, Translate. Although QGIS has a Translate tool, it has to do with vector data, not your raster data. So please edit your question and expand this step with more detail: exactly which tool(s) you used, and what settings. Screenshots are always helpful! Also, which QGIS version?
    – Stu Smith
    Commented Jan 21, 2022 at 1:37
  • @StuSmith Thank you for your comment, I have updated my post to include details of the Translate tool and version of QGIS I am using. I used the Translate tool under Raster - Conversion - Translate (Convert Format)
    – pwrogers
    Commented Jan 21, 2022 at 18:49

3 Answers 3

Reset to default
2

You can't change data type from float32 to integer without loosing precision. The values will be rounded to the closest meter (or whatever crs unit you are using).

I'm using Warp to change data type. The DEM is styled with a hillshade ffect:

enter image description here

What you can do is to create a hillshade first, then convert this to integer: enter image description here

Improve this answer
2
  • Thank you for attempting to answer my question. I have tried your method, and while it does produce a smooth grey band hillshade in UINT16 format, I in fact need to use a UINT16 DEM in Blender to act as a height map. The hillshade produced by your method will not produce the UINT16 tiff I need to render an accurate displacement in Blender. If you switch the Render Type to hillshade on the Layer your solution outputs, this is what is likey to be displayed in Blender.
    – pwrogers
    Commented Jan 21, 2022 at 18:56
  • Sounds like a Blender issue. I dont know Blender, but I've read there's something called "Subdivision Surface", see: geosupportsystem.se/2021/10/20/qgis-och-blender
    – Bera
    Commented Jan 22, 2022 at 12:51
1

Thank you all for your suggestions, however I have just found the solution!

The latest release of Blender reads float32 tif files!!! No uint16 needed. I feel stupid to ask the question in the first place... but I will leave it up in case anyone else has the same problem I was experiencing. Just update your Blender to 3.0 or higher and it will natively read float32 files.

Thanks again for your suggestions, I was not aware of the Graphical Modeler before, VERY useful.

Improve this answer
1

The existing answers didn't work for me so I'm posting an alternative that did.

The accepted answer suggests that Blender is now able to read Float32 TIF files, however, I was not able to work with them using Version 3.1.2 and the Blender docs page Supported Graphics Formats listed only 8bit and 16bit TIF files as being accepted.

Instead, I did the QGIS conversion using GDAL as below then loaded the result into Blender:

  1. From the menu bar select 'Processing' > 'Toolbox'
  2. Open 'GDAL' > 'Raster conversion' > 'Translate (convert format)'
  3. Add the below settings (hopefully self-explanatory to a degree) enter image description here
  4. Additional parameter -scale in the above is needed, in my example, this was added with -scale 60 930 0 65535 which in order means src_min src_max dst_min dst_max
  5. Select 'Run' and wait until it completes, you should now have a UInt16 version of your TIF without losing any information. This can be loaded into Blender

Seeing tif info I'm sure this is obvious for experienced QGIS users but as a novice it took me a while to realise the metadata about the tif's data type and band information could be seen in QGIS by right-clicking on its layer and selecting 'Properties...' then 'Information'.

Improve this answer
2
  • Hey Jonny, thanks for your solution!That's odd because I have only been using Float32 tiff's in Blender since asking this question! I had to reduce the height values significantly to get them to work, 0.0002 in some cases, otherwise the terrain was stretched past the camera and not visible once rendered. I hope this can be a solution to you also to avoid having to process the tiff in the first place. Cheers, Phil
    – pwrogers
    Commented Apr 20, 2022 at 13:20
  • That's interesting! I'll try again and see if I can get the floats to work with altered height values. It sounds like we're both using 'National LIDAR Programme - data.gov.uk' for our data.
    – JonnyIrving
    Commented Apr 21, 2022 at 9:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.