-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Volume rendering is wrong #37
Comments
I’ve noticed that the colormaps in general for volumes and geometry seem to be a bit off. Will forward to the intel folks, your guess sounds likely for volumes, not sure what’s going on with geometry coloring.
|
Yes, its in OSPRay. RaycastVolumeRenderer_computeVolumeSample is attenuated first by the samples's w: color = clamp(sampleOpacity / volume->samplingRate) * make_vec4f(sampleColor.x, sampleColor.y, sampleColor.z, 1.0f); which is accumulated along the ray, where color is the accumulation and volumeColor is the sample: color = color + (1.0f - color.w) * volumeColor; Suppose the current color is (0,0,0,0) and we only do one sample, resulting in a volume color of (0.5,0.5,0.5,0.5) - that is, white attenuated by opacity/samplingRate = 0.5. The result of accumulation is (0.5,0.5,0.5,0.5) Now if background is enabled - say (1,1,1,1), it gets applied: color = color.w * color + (1.0f - color.w) * background; and the result is 0.5_(0.5,0.5,0.5,0.5) + (1-0.5)_(1,1,1,1) = (0.75,0.75,0.75,0.75) |
If you do a wavelet and use an all-white colormap against a white background, you should get a all-white image - a polar bear in snow picture, because opacity * white + (1 - opacity) * white is white. You do in a RenderView, but not in an OSPRay window - places where the opacity is low are dark. Maybe the data value is multiplied by the opacity twice - once as part of the accumulation along the array and later against the background?
The text was updated successfully, but these errors were encountered: