OptiX Ray Tracing

ParaView Support
1

Hello community,

I was looking forward to the 5.7 release when I read that it would support the new NVidia RTX card, so with the first RC of 5.7, I downloaded it, when tried to setup a scene to try it, with an RTX 2080 in my workstation.
I now see that I can choose the OptiX backend when ray tracing is on, but how can I check whether it actually works ? my CPU shows usage peaks around 100% when I change the view, which was typical when using OSpray, but I was expecting a lot more GPU load when choosing OptiX.

Or was my intuition just wrong ?

So, is there a possibility to know whether the RTX cores are actually used ?

Also I can still choose the OptiX backend, even on my laptop, which does not have a RTX card, so is this expected ?

Thanks.

2

It is a bug that the dialog shows OptiX when it is not available. With our RC1 and nightly binaries, only the Linux packages actually have OptiX included. In other situations the behavior right now is to silently use OSPRay in those situations.

Before the RC cycle is through OptiX should be included in the Windows binaries and the OptiX choice should be disabled on Mac.

3

Tracking the issue here: https://gitlab.kitware.com/paraview/paraview/issues/19180

4

Thanks for the quick reply.

So does that mean that my gpu is not used and paraview falls silently back to ospray ? (I have a windows workstation)

5

It looks like it is not working with linux package either.

It works great on my build 5.7.0-RC1 and outputs

VisRTX 0.1.6, using devices:
 0: GeForce RTX 2080 Ti (Total: 11.5 GB, Available: 10.9 GB)

While the downloaded release does not output anything and fallback to ospray.

(On ArchLinux with GeForce RTX 2080 Ti)

1 Like
6

Yes.

7

Hi everyone,

I see that RC2 is ready for download, I tried it on my windows pc with no RTX card, OptiX is not not available. I expect the option to be enabled on a setup with a RTX card, but I want to make sure it is enabled, otherwise, I’ll have to wait for the next RC where it is enabled.

Thanks in advance

8

It should be available in RC2. It would be great if you could test it out and report any problems you encounter to help us see if any fixes are needed for RC3.

9

I gave it a try, but the result was under expectations.

Paraview gives the option to choose OptiX as backend, but when turning it on, the rendering is quite different from what I get with ospray pathtracer.
My goal is to render a free-surface flow with a ship, the ship as a fixed color that I made using a material, the water is made in the same way but with different properties. I can see my ship, but the free-surface is basically not renderer as pathtracer renders it … So I do not know what to think, is it my “water” material that gives the expected result with pathtracer that does not work with OptiX, or is it something with OptiX that I do not understand ?

Thanks in advance

10

Hi Everyone,

I have now easier access to the workstation.
Windows 10, RTX 2080 card, driver version 430.86 (not the latest), paraview 5.7.0-RC2.

I use a few custom materials that seem to work well with ospray:

    "water" : {
      "type": "Glass",
      "doubles" : {
          "attenuationColor" : [1.0, 1.0, 1.0],
          "attenuationDistance" : [1.0],
          "eta" : [1.33]
      }
    },
    "WaterLightBlue": {
      "type": "Principled",
      "doubles" : {
          "thin" : [1.0],
          "ior" : [1.33],
          "transmissionColor" : [0.22, 0.34, 0.47],
          "transmission" : [1.0],
          "thickness" : [1.0],
          "specular" : [1.0],
          "opacity" : [0.6],
          "diffuse" : [1.0],
          "backlight" : [0.0],
          "roughness" : [0.1]
      }
    },
    "WaterDarkBlue": {
      "type": "Principled",
      "doubles" : {
          "thin" : [1.0],
          "ior" : [1.33],
          "transmissionColor" : [0.22, 0.34, 0.47],
          "transmission" : [1.0],
          "thickness" : [1.0],
          "specular" : [1.0],
          "opacity" : [0.85],
          "diffuse" : [1.0],
          "backlight" : [0.0],
          "roughness" : [0.1]
      }
    },
    "YellowShip": {
      "type": "Principled",
      "doubles" : {
          "baseColor" : [1.0, 1.0, 0.0],
          "specular" : [0.5],
          "opacity" : [1.0],
          "diffuse" : [0.5],
          "roughness" : [0.5]
      }
    }

My goal is to render a Ship with the free-surface. (YellowShip for the ship material, WaterDarkBlue for the free-surface)
With OSpray:

ospray_cw
ospray_cw.jpg1516Ă—696 289 KB

With OptiX

optix_cw
optix_cw.png1516Ă—696 124 KB

There seem to be something not working properly with the materials!

Another attempt: (YellowShip for the ship, WaterDarkBlue for a box which surrounds the whole domain, and “water” for the free-surface)
OSpray:

ospray_pathtracer_fs
ospray_pathtracer_fs.jpg1516Ă—696 1.13 MB

OptiX:

optix_pathtracer_fs
optix_pathtracer_fs.png1516Ă—696 97.5 KB

I also tried without using materials, but that does not seems very successful either.

So, does anybody has a clue of what’s going on ?

One thing I do see is the CPU usage reduction, and quicker time to image when using OptiX, but the result isn’t really up to my expectations…

11

That is a bug in the material handling somewhere down in the path from ParaView down to OptiX. I’ll discuss with Tim Biedert and try and take a close look. Thanks for the report. Feel free to report an issue tracker with a small reproducer case.

12

Issue reported here: https://gitlab.kitware.com/paraview/paraview/issues/19296

13

Perhaps OptiX is more sensitive to flipped normals. I have noticed that your free surface does not have a consistent ordering of surface primitives (some of them pointing up, some of them pointing in the opposite direction). My first suggestion is to clean up the surface to insure consistent ordering. And try both path-tracers again.

my 2 cents.

14

Thanks, Jean! That’s exactly what’s happening here. And there is a separate issue where one material parameter is not forwarded correctly. I’m currently preparing a patch for VTK, and will provide the details in the issue tracker.

Regarding the normals: They are inconsistent and facing downwards. Since normals are used for determining whether a volumetric material is entered or exited, this leads to unexpected results. When hitting the surface, the ray basically thinks that it’s leaving the water.

When the normals are oriented correctly, it will push the water material on its internal stack of active volumetric materials and will apply volumetric attenuation and proper IOR handling for every subsequent bounce; until it leaves the volumetric material again and pops it from the stack.

If you don’t consider normals for determining entering/exiting, you will run into other corner cases where volumes will fail (e.g. when the camera starts inside a volume).

I will look into making this more robust.

Thanks for raising this issue!

Tim

15

Material bug fix: https://gitlab.kitware.com/paraview/paraview/issues/19296#note_620419

16

That was very quick! Thanks for that.

I now also see the normals issue, the “Clean” filter solves this issue.
The underlying issue is that the contouring algorithm does not car about normals consistency …

Would it be possible to know when the fix comes in the nightly build ? Then I could try again!

17

It will be in the nightly binaries in a couple of days. Once ParaView’s VTK branch is bumped that is.