[vtk-developers] Proposed fix for vtkOpenGLTexture

[Aron Helser]

If you submit it as a pull-request, then you can add a comment with the
single line:

Do: test

and the bot will run tests for you.

On Tue, Feb 19, 2019 at 1:45 PM Patrick Bergeron <pbergeron at spiria.com>
wrote:

> Interesting for the workaround. Thanks!
>
>
> I'm soooooo not set-up for running the test suites. Any volunteer?
>
>
>
> ------------------------------
> *From:* Ken Martin <ken.martin at kitware.com>
> *Sent:* February 19, 2019 11:59:26 AM
> *To:* Patrick Bergeron
> *Cc:* vtk-developers at vtk.org
> *Subject:* Re: [vtk-developers] Proposed fix for vtkOpenGLTexture
>
> You can do this in VTK as is using vtkTextureObject->Create2DFromRaw and
> then vtkTexture->SetTextureObject.
>
> But I don't have an issue with your suggested change provided it passes
> testing.
>
>
>
> On Tue, Feb 19, 2019 at 11:48 AM Patrick Bergeron <pbergeron at spiria.com>
> wrote:
>
> Hello. I sent a recent email stating I needed to pass arbitrary data to a
> shader, encoded in a texture of float format.
>
>
> Unfortunately, my shader only received texels with values clamped between
> 0-1.  As you can imagine, this is a problem.
>
>
> I have traced the problem down to vtkOpenGLTexture::Load() function.
>
>
> What Load() does is :
>
> - Checks number of inputs. If 1, normal texture. If 6, cubemap texture.
> (OK)
>
> - Gets the image scalars (aka pixels) and number of components (aka:
> channels)   (OK)
>
>
> - Calls MapScalarsToColor if not depth map, or if colormpde is
> Map_Scalars, or* if datatype is NOT unsigned char.  (UGH!)*
>
>
> - Resizes the input of the source exceeds GL's internal
> dimension capacity. (OK)
>
> - Resamples the image if needed. (OK)
>
>
> - Creates a 1-channel floating point depth image, if it's a depth texture,
> by calling CreateDepthFromRaw(). (OK)
>
>   (or, if not a depth map)
>
> - Creates a 3 or 4-channel cube map, or normal texturemap, by specifying
> the new converted data type of VTK_UNSIGNED_CHAR.
>
>
>
> There is actually very little to do to support arbitrary float data:
> Simply avoid remapping to unsigned char if the data is float (unless
> there's intentional remapping by using such ColorMode), and pass the actual
> format down to CreateXXXFromRaw()
>
>
>
> My proposed change is to not convert incoming float data to unsigned char,
> but rather, to leave float color data alone.
>
>
> Edit:
>
>
> Change this (eg: remove red line)
>
>
> *        if (this->IsDepthTexture != 1 &&*
> *          (this->ColorMode == VTK_COLOR_MODE_MAP_SCALARS ||*
> *           inscalars->GetDataType() != VTK_UNSIGNED_CHAR ))*
>
> *         {           dataPtr[i] = this->MapScalarsToColors (inscalars);
>         bytesPerPixel = 4;         } *
> to this:
>
> *        if (this->IsDepthTexture != 1 &&*
>
> *          (this->ColorMode == VTK_COLOR_MODE_MAP_SCALARS)) *
> *        {*
> *          dataPtr[i] = this->MapScalarsToColors (inscalars);*
> *          bytesPerPixel = 4;*
> *        }*
>
>
> and these:
>
>
>
> *           this->TextureObject->CreateCubeFromRaw(             xsize,
> ysize, bytesPerPixel, VTK_UNSIGNED_CHAR, vtmp);
> this->TextureObject->Create2DFromRaw(             xsize, ysize,
> bytesPerPixel, VTK_UNSIGNED_CHAR, resultData[0]); *
>
> to these:
>
>           this->TextureObject->CreateCubeFromRaw(
>             xsize, ysize, bytesPerPixel, dataType, vtmp);
>
>
>           this->TextureObject->Create2DFromRaw(
> *             xsize, ysize, bytesPerPixel, dataType, resultData[0]); *
>
>
> And that's all there is to it.
>
> Does anyone have any objection?  The only side effect I can imagine is
> that more texture memory is consumed iff the source image data is float and
> no remapping is desired. With recent GPU hardware, I'd be surprised if this
> was a problem.
>
> In any case, with this change, we can effectively pass unclamped
> arbitrary floating-point data buffers to shaders to be used for advanced
> viz techniques.
>
> Thanks
> Patrick Bergeron
>
>
>
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> https://vtk.org/mailman/listinfo/vtk-developers
>
>
>
> --
> Ken Martin PhD
> Distinguished Engineer
> Kitware Inc.
> 101 East Weaver Street
> Carrboro, North Carolina
> 27510 USA
>
> This communication, including all attachments, contains confidential and
> legally privileged information, and it is intended only for the use of the
> addressee.  Access to this email by anyone else is unauthorized. If you are
> not the intended recipient, any disclosure, copying, distribution or any
> action taken in reliance on it is prohibited and may be unlawful. If you
> received this communication in error please notify us immediately and
> destroy the original message.  Thank you.
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> https://vtk.org/mailman/listinfo/vtk-developers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190219/4e0b96e9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pastedImage.png
Type: image/png
Size: 40581 bytes
Desc: not available
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190219/4e0b96e9/attachment-0001.png>