[Alistair]

Hi everyone,

I'm getting some strange dark patches when I view cases in paraview (see the attached images). From the front the patches appear dark, but from the back they are light. The patches do not seem to affect the cases as they run fine and checkMesh says the mesh is ok, so this seems to be more of an aesthetic problem!

I've played around with the lighting in paraview and it appears as if the face normals are inverted, ie changing the backlight affects the dark patches on the front, while they are unaffected by chances to the front lighting. Does anyone know how this could have happened? I'm using snappyHexMesh to mesh the blades of the turbine, could it be something to do with this? If so it seems strange that the mesh passes checkMesh and solves fine.

If anyone has any ideas it would be greatly appreciated!

Alistair

[wyldckat]

Greetings Alistair,

Mmm, this is interesting... OK, two possibilities come to mind:

1. It's either a problem with the communications between ParaView/VTK and the OpenGL drivers for the graphics card, where the triangles are being improperly given;
2. Or the triangles have in fact their normals inverted, therefore it wouldn't be a OpenGL problem.

If the problem is the second one, then it might be a problem on how the geometry is being processed. So, here are a few questions:

• The blue patches we're seeing, where do they come exactly?
  • Is it from an STL file?
  • Are the patches surfaces that are read from the mesh?
  • Are these patches the sides of the mesh volume?
• If it's from the OpenFOAM case, which plug-in are you using to read the case? Is it the internal plug-in (file extension ".foam") or the external/official plug-in (file extension ".OpenFOAM")?
• Are the drivers for the graphics card properly installed?
• Are the desktop acceleration+animations turned on?

Well... I can't remember anything else... but the next place I can think of for checking for more solutions would be this blog post of mine: Related issues to ParaView with OpenFOAM - Fixes and solutions

Best regards,
Bruno

[Alistair]

Hi Bruno,

Thanks for getting back to me, I'll answer all of the questions I can, the computer was set up and OpenFoam software installed by my supervisor so I'm not too familiar with the internal workings, he's away today and tomorrow so I won't be able to get any answers on that front for a little while unfortunately.

The blue patches are indeed from an stl file, the case is 3D, the screenshots are just from a slice. I've attached two more screenshots from a case using the same stl file, but with better refinement, hopefully the screenshot of the wireframe will make it clearer what the mesh looks like. The edges of the blue patches are the boundaries of the mesh. As you can see in the more refined mesh the areas move and become smaller with the mesh, I've also played with the lighting in paraview so they appear less pronounced, but I still can't completely get rid of them.

The files open in paraview with the extension .OpenFOAM and desktop animations are turned on.

Is there anything I can do to test whether the drivers for the graphics card are installed properly? I haven't seen anything else that suggests they aren't, videos etc seem to play fine.

Regards,
Alistair

[7islands]

I'm not so sure but it could be due to this (post #3)?

T

[plm]

I know this is an old thread but I'm posting for anyone who has had similar problems as I have......

If the problem is in fact due to the surface normals, there is a filter within paraview (GenerateSurfaceNormals) which allows you to flip them and which (for me at least) has solved the lighting problems!

Hope that helps someone!
plm

[wyldckat]

Greetings to all!

I'm bumping up this thread to add some more information on this topic, which I discovered this week.

When using an Intel HD GPU (one of those integrated with the CPU), there are some somewhat known issues with the OpenGL drivers, allegedly due to Intel not implementing a more recent version of OpenGL. Anyway, an example with a pretty extensive attempt at fixing a similar issue of "black triangles" on Windows: 'Black Triangles' in Tomb Raider II (Win7-64)

Either way, plm's fixed partially the problem I had as well with said Intel HD GPU (on Windows!), namely by applying the "Generate Surface Normals" filter.
Beyond this (and the reason for this post), I found the following details:

• What this filter does is described on the VTK Doxygen documentation: http://www.vtk.org/doc/release/5.10/...taNormals.html
  

  The filter can reorder polygons to insure consistent orientation across polygon neighbors. Sharp edges can be split and points duplicated with separate normals to give crisp (rendered) surface definition. It is also possible to globally flip the normal orientation.

• In fact, for me, all it did was literally sort the black triangles to one side and the illuminated triangles to the other side. Using the "Flip" option would then change the light from one side to the other, therefore illuminating the dark area and leaving the other area in the dark.
• When I used this filter on a machine that had an NVidia GPU, the "Flip" option provided by this filter can actually help with situations where the light is darker than we want it to be on the darker side, at the cost of making the other side darker .
• In my case with the Intel HD, I ended up with some sporadic transparent triangles when I zoomed in too close, as a result of the filter. Therefore, I searched for more information on the topic related to lighting issues on ParaView and eventually found this post: http://the-unofficial-paraview-devel...107.html#a2109
  • From it, the following Python code does a neat trick:
    

    RenderView1 = GetRenderView() 
    
    # Turn off "Head Light" 
    RenderView1.LightSwitch = 0 
    
    # Turn off "Light Kit" 
    RenderView1.UseLight = 0 
    
    r = GetDisplayProperties() 
    r.Ambient = 1.0 
    r.Diffuse = 0.0

  • Apparently the Intel HD cards cannot handle properly the "Diffuse" lighting algorithms in VTK (which is the default), but can handle just fine the "Ambient" lighting algorithms.
  • The downside is that on ParaView, this is currently only achievable through Python scripting. When the patch mentioned on the following bug report is implemented, we should have said controls: http://vtk.org/Bug/view.php?id=13963

Best regards,
Bruno

PS: For those confused by me mentioning VTK, this is because ParaView uses VTK.

[malv83]

Hi, just wondering if any of you know why paraview displays my solution with some patches like in the attached pic?...

Thanks

[flotus1]

Looks like multiple representations on top of each other. Blank all but one, and see if things change.

[CFDanielGER]

Originally Posted by wyldckat

Greetings to all!

I'm bumping up this thread to add some more information on this topic, which I discovered this week.

When using an Intel HD GPU (one of those integrated with the CPU), there are some somewhat known issues with the OpenGL drivers, allegedly due to Intel not implementing a more recent version of OpenGL. Anyway, an example with a pretty extensive attempt at fixing a similar issue of "black triangles" on Windows: 'Black Triangles' in Tomb Raider II (Win7-64)

Either way, plm's fixed partially the problem I had as well with said Intel HD GPU (on Windows!), namely by applying the "Generate Surface Normals" filter.
Beyond this (and the reason for this post), I found the following details:

• What this filter does is described on the VTK Doxygen documentation: http://www.vtk.org/doc/release/5.10/...taNormals.html
  
• In fact, for me, all it did was literally sort the black triangles to one side and the illuminated triangles to the other side. Using the "Flip" option would then change the light from one side to the other, therefore illuminating the dark area and leaving the other area in the dark.
• When I used this filter on a machine that had an NVidia GPU, the "Flip" option provided by this filter can actually help with situations where the light is darker than we want it to be on the darker side, at the cost of making the other side darker .
• In my case with the Intel HD, I ended up with some sporadic transparent triangles when I zoomed in too close, as a result of the filter. Therefore, I searched for more information on the topic related to lighting issues on ParaView and eventually found this post: http://the-unofficial-paraview-devel...107.html#a2109
  • From it, the following Python code does a neat trick:
    

    RenderView1 = GetRenderView() 
    
    # Turn off "Head Light" 
    RenderView1.LightSwitch = 0 
    
    # Turn off "Light Kit" 
    RenderView1.UseLight = 0 
    
    r = GetDisplayProperties() 
    r.Ambient = 1.0 
    r.Diffuse = 0.0

  • Apparently the Intel HD cards cannot handle properly the "Diffuse" lighting algorithms in VTK (which is the default), but can handle just fine the "Ambient" lighting algorithms.
  • The downside is that on ParaView, this is currently only achievable through Python scripting. When the patch mentioned on the following bug report is implemented, we should have said controls: http://vtk.org/Bug/view.php?id=13963

Best regards,
Bruno

PS: For those confused by me mentioning VTK, this is because ParaView uses VTK.

When I run the script you mentioned I get following error:
AttributeError: type object "RenderView" has not attribute "LightSwitch".

I am using Paraview 5.6.0 (64 bit). When I comment this line it works. Is there a way to also execute the first line of the code which gives the error?

Many thanks for your help!