1

I am quite knowledgeable on Python, but not so much on Blender. And I have no experience on Python scripting (although eager to learn). My problem is that I have some raw data of height from which I want to build a 3D model.

I have thought of two main alternatives

  1. Make a Blender script that reads the raw data and changes the Z value of vertices
  2. Convert the raw data into a Z-height Blender-friendly format

1. Blender Script

Well, it intimidates me a little bit. I have not found a way of accessing the vertices with a sane ordering, and I feel like I will be doing a very ad-hoc thing. However, maybe I haven't look enough at it. I would be delighted to find some similar example, but I have been unable to find it.

2. Blender-friendly format

I thought that maybe using an intermediate representation is a good thing. The data can be reused by other people and adapted. It seems to be resolution agnostic, which is a good thing.

My first approach was using a "Float" TIFF (supported by Pillow). But Blender seems to dislike it (it doesn't seem to read non-colour formats). My raw data is float, so I would prefer to use it. I know that I can use instead a 8-bit grayscale, but this is not enough information for my purposes. 16-bit would be meh-okay --I am ready to settle with that. Which formats would be nice for Blender? OpenEXR seems to be powerful but there is a lack of export tools --I am doing the raw-data conversion from Python scripts.

Sorry if this seems a two-in-one question. But my genuine problem is the one at the top, and I wanted to share some of my thoughts in my two different approaches. Though I hadn't got much far in any of them... :(

MariusSiuram
  • 121
  • 4
  • If you want to convert height data into a 3D surface, take a look at the answers in http://blender.stackexchange.com/questions/27933/creating-a-large-landscape-with-accurately-varied-elevations – Ed Tate Feb 06 '16 at 15:07
  • @EdTate all the answers seem to rely on images. I fail to choose a image format with enough data information in it. Any suggestion on a sensible format choice? – MariusSiuram Feb 06 '16 at 16:43
  • If not enough information, means not enough resolution in the image, then if 16 bits is enough resolution, you might try using your data to generate a 16 bit grey scale tiff in python - see http://stackoverflow.com/questions/7247371/python-and-16-bit-tiff, then use the displacement modifier. – Ed Tate Feb 06 '16 at 17:31
  • @EdTate "Blender seems to dislike it (it doesn't seem to read non-colour formats)." it seems to apply also to integer 16bit tiff. I have tested some tiff variations, and Blender keeps on considering all "strange" TIFF as RGB space and messing it up completely. But, there is a workaround... – MariusSiuram Feb 07 '16 at 07:09

1 Answers1

1

Use a RGB TIFF

Ok, it is a tricky solution, and I am not sure the behaviour of the "Fields" checkbox. But it seems to yield reasonable result with my testing toy data. The idea is using the commonly used displace modifier. But, as I could not come up with a friendly format, I use a regular RGB to work in Blender.

The workflow is the following:

  1. Adapt the raw data into a 24 bit resolution (integer), and partition it in three bytes. The idea is that (0, 0, 0) is the lowest, (255, 255, 255) the highest, and the following trivial conditions are assured:

    • (0, 0, 255) < (0, 1, 0)

    • (0, 255, 0) < (1, 0, 0)

  2. Save the previous 24 bit into a RGB channel TIFF. The data is a bit strange, but as a matter of fact, you have 24-bit of "information" per pixel.

  3. Make the typical plane > displace > image > etc. in Blender, and activate the checkbox of "Fields".

  4. If I'm not mistaken, you have now a height-mapped 24-bit resolution thanks to the RGB 8-bit per channel TIFF.

Edit: Now I'm trying this with real data, and it seems to fail (the height is veeery noisy, so it seems that I have misunderstood the "Use fields" option, which I cannot find in the documentation. For now, I will use 8 bits of data. Which I am not very happy with.

MariusSiuram
  • 121
  • 4