I’m trying to process the output of a Material Map device using a Code device, but it outputs an exotic packet format (Byte Map) that cannot be used with any of the documented input methods in the lua script, so I can never pass it on to my compute kernel. I tried all of them, but they fail at creating an image internally:
[string “local materials = wm.inputBuffer(0)…”]:1: input: createImage: Unsupported packet type
This is on the latest build in the “current” channel.
Confirmed. The Code device currently doesn’t have an I/O path for byte maps. This will get fleshed out in the next build!
Integer-valued maps within WM in general are new and have very limited support. They are useful for ID-based map outputs in particular, and I plan to introduce more support for them across WM devices, bearing in mind their intended purpose (they basically should never blend, only snap from one value to another, etc).
If you really need to work on the values you can convert an intmap to a regular float-based heightmap right now with the following moderately janky setup 
That’s a pretty useful workaround, thanks a lot 
Also glad to hear that there is better support for integers in the works, I work with material IDs and zones / area markings a lot and I’m trying to avoid having to export a new mask for each ID.
The issue I’m trying to solve here is that the Material ID output exported using Heightfield output on the Byte Map directly seems to result in a bitmask encoding rather than the Material ID as a grayscale value, but software further down the pipeline requires the IDs as grayscale values. So far I’ve just been using imagemagick after exporting to convert the masks but having it be done within WM would be much more practical.
Maybe a value based encoding mode could be added to Material ID?
It sounds like your use for material IDs is exactly what I was hoping to be able to streamline and support effectively, so I’d like to hear more about why the ID output isn’t working for you.
The current mat-ID bytemap export puts the material ID byte as a 0..255 value, duplicated across all channels, so that it will load as greyscale.
It sounds like that is what you need, so I’m not sure what’s going wrong here in the workflow – what are you seeing instead?
Note that WM shows the raw byte values mapped to a colorful palette within the WM viewports so that you can distinguish them; otherwise it would just be impossibly subtle variants of black.
Thanks for your help! This actually seems like a classic case of user error, I apologize 
It’s of course working exactly as intended and as you described, and in fact after I had setup a test project and checked all the output images I couldn’t even replicate the issue I had earlier. After some investigation I found out that a single height output device in my other project had accidentally been set to 16 bit PNG instead of 8 bit, and while the resulting file was still perfectly correct, my downstream software somehow misinterpreted it and reported values 0 to 1028 instead of 0 to 4 like it actually contains. Coincidentally this file was alphabetically first and the first one I tried to use so I assumed all other files would have the issue too and that I was misunderstanding the way WM encodes the Material IDs, hence my idea with changing the encoding using a Code device.
Nevertheless, I appreciate the plans for better support for the Byte Maps, looks like a very promising feature!
