C++ OP_PixelFormat issues for inputs

General TouchDesigner Discussion
1

I’m working on a C++ CHOP that takes a TOP input to get a list of Vector objects.
But it seems like the values that the code is getting via a debugger are very different from what’s being passed in according to TD.

The code looks like this:

void example::whatever(..., const TD::OP_TOPInput* forceTop)
{
 const auto numInputSamples = static_cast<std::int32_t>(forceTop->textureDesc.width) * 4;
  if (numInputSamples <= 0)
  {
    return;
  }
  auto dlOpts = TD::OP_TOPInputDownloadOptions();
  dlOpts.pixelFormat = TD::OP_PixelFormat::RGBA16Float;
  auto texture = forceTop->downloadTexture(dlOpts, nullptr);

  const auto* inputData = static_cast<float*>(texture->getData());

  for (std::size_t index = 0; index < entities.size(); index++)
  {
    const auto sampleOffset = static_cast<std::int32_t>(index) * 4;
    if ((sampleOffset + 2) >= numInputSamples) break;
    ...
    const TD::Vector force = {
      static_cast<float>(inputData[sampleOffset]),
      static_cast<float>(inputData[sampleOffset + 1]),
      static_cast<float>(inputData[sampleOffset + 2])
    };
    ...
  }

  texture.release();
}

I’ve tried different combinations of pixel formats on the input TOP, formats in the download options, and accessing the data as float/double, and so far I haven’t found a combination that reliably reads the values correctly (even accounting for float inaccuracies).

Does it matter what the pixel format is for the TOP that’s passed in? I got the impression that setting a format in the OP_TOPInputDownloadOptions would cause it to convert whatever the TOP is to the specified format.

In the custom operator sample projects, the examples that use TOP inputs seem to largely just copy their contents into output buffers or use cuda arrays. There don’t seem to be any cases of a non-TOP that uses a TOP input.

2

I ended up figuring it out.
It’s double with RGBA32Float.
The strange thing is that even in cases where the pixel format should mean a smaller block of memory, read access to stuff past the end seems not to cause any crashes, just strange data.