Text archives Help

---

Colin Poczatek <jpoczatek@rics.bwh.harvard.edu> writes:
> On 03/08/2011 12:31 PM, tom fogal wrote:
> > Hi Collin!
> >
> > Colin Poczatek<jpoczatek@rics.bwh.harvard.edu>  writes:
> >> When I change the bounds on the hue scale so more voxels are
> >> saturated (ie close to max hue) those voxels aren't rendered as
> >> bright but appear very dark.  This is apparent if you look at the
> >> "pink ball".
> >
> > Can you turn off lighting and tell me if that fixes the problem?
>
> Ok, so that fixes it.  I think I missed that since I was focused on
> using isosurface rendering and hence lighting was always on (and I
> have a strong feeling of dejavu).  Is there a change that can be made
> to fix this?  You lose "depth cues" with no lighting, and my bosses
> seem to greatly favor the isosurface rendering, though I prefer the
> 1dtf...  But I can mimic an isosurface by changing the alpha values
> when I write the QVis file...

Yeah, that confirms what I suspected.  What you're seeing is the
result of a straightforward approach to calculating normals, instead
of the more intelligent approach.  The root of the issue is that our
gradient drops to basically nothing at boundary voxels.  Gradients are
used for normals in lit volume rendering.  Since the normal drops to
near-zero, the diffuse factor of the lighting equation basically drops
out.  You essentially end up getting only the ambient component of the
lighting equation.

What we *should* do is hack the normals 'outward' at a clip plane
boundary.

Your data exhibits the same issue even without a clip plane, though, at
the boundaries of the data.  For your data, we probably should also pop
the normals out at the external edges, but it's not clear to me that
we'd want to do that on all data.  You might be able to hack ImageVis3D
to look correct without a clip plane by adding a boundary layer of
blank voxels around your data.

> If you want to look at the files I put them here: (QVis and uvf)
> http://zoomwhee.mgh.harvard.edu/~cpoczatek/fogal/
>
> Toggling lighting it's pretty obvious which part of the data are
> misbehaving.
>
> I find it funny that the shader with lighting just doesn't like pink
> voxels...

Thanks for the data.

I attached a 'lighting.glsl'.  Place it in your "Shaders/"
subdirectory, overwriting the existing file that's there.

This version adds in a hack which works around the issue for you.
Basically, if the diffuse factor goes to zero, it knocks it back up
somewhat randomly.  You can play with the "0.005" and "0.5" to suit
your needs; the higher you make 0.5, the brighter those previously-grey
voxels will show up.  The higher you make 0.005, the more you'll
"break" traditional volume rendering, causing voxels which aren't grey
but close to it to appear as the 0.5 values.

It doesn't "fix" isosurface rendering, though.  The Compose-FS.glsl
appears to (incorrectly?) utilize its own 'Lighting' function, instead
of using the "library" version like the other shaders.  Probably an
oversight when we consolidated.  Hacking it in the same manner should
fix that, though.

Best I can offer in the short term, sorry =(

HTH,

-tom

/*
   For more information, please see: http://software.sci.utah.edu

   The MIT License

   Copyright (c) 2008 Scientific Computing and Imaging Institute,
   University of Utah.


   Permission is hereby granted, free of charge, to any person obtaining a
   copy of this software and associated documentation files (the "Software"),
   to deal in the Software without restriction, including without limitation
   the rights to use, copy, modify, merge, publish, distribute, sublicense,
   and/or sell copies of the Software, and to permit persons to whom the
   Software is furnished to do so, subject to the following conditions:

   The above copyright notice and this permission notice shall be included
   in all copies or substantial portions of the Software.

   THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
   FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
   THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
   LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
   FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
   DEALINGS IN THE SOFTWARE.
*/

/**
  \file  lighting.glsl
*/

vec3 Lighting(vec3 vPosition, vec3 vNormal, vec3 vLightAmbient,
              vec3 vLightDiffuse, vec3 vLightSpecular, vec3 vLightDir) {
  vNormal.z = abs(vNormal.z);

  vec3 vViewDir    = normalize(vec3(0.0,0.0,0.0)-vPosition);
  vec3 vReflection = normalize(reflect(vViewDir, vNormal));
  float diff_factor = max(abs(dot(vNormal, -vLightDir)), 0.0);
  if(diff_factor < 0.005) {
    diff_factor = 0.5;
  }
  return clamp(
    vLightAmbient +
    vLightDiffuse * diff_factor +
    vLightSpecular * pow(max(dot(vReflection, vLightDir),0.0),8.0), 0.0,1.0
  );
}

---

• [IV3D-USERS] odd color volume bug?, Colin Poczatek, 03/08/2011
  • [IV3D-USERS] Re: odd color volume bug?, tom fogal, 03/08/2011
    • [IV3D-USERS] Re: Re: odd color volume bug?, Colin Poczatek, 03/08/2011
      • [IV3D-USERS] Re: Re: Re: odd color volume bug?, tom fogal, 03/08/2011

---

Archive powered by MHonArc 2.6.16.