Voxels not rendered

[eile]

While debugging the 'events per voxel' functor, I create volumes which have 157 in a few voxels and none in the rest. In Livre, I cannot see the voxels. I used the Gauss transfer function which should show values in the middle of the spectrum, moving the maxima around. All I can get is a homogenous blob. Also used --samples-per-ray=4096 just in case the volume was undersampled.

[bilgili]

What is the sparsity of the volume ? If 5 voxels in 1000000 voxel cube, I would say probability that a ray hitting a voxel is very low. You increased the sampling along the ray but we should need a ray density as well then, meaning sending more rays per pixel.

[eile]

164 events/voxels in the standard livre resolution (~256^3?)

[bilgili]

Really sparse. 164/16777216 probability there is a voxel. And there is perspective projection, where sparsity increases with the depth. In fact with sparsity, the problem should be reversed to project a volume to screen. Or, there is a Computer Graphics Forum paper :) We can try.

[eile]

Devils advocate: If I load it in Paraview, I see all 'on' voxels.

[bilgili]

Can you give me exact command line parameters ?

On 30 Jul 2015, at 10:49, Stefan Eilemann notifications@github.com wrote:

Devils advocate: If I load it in Paraview, I see all 'on' voxels.

— Reply to this email directly or view it on GitHub https://github.com/BlueBrain/Livre/issues/96#issuecomment-126229759.

[bilgili]

It will be great if you can give all command line parameters you are using.

[eile]

You'll need the new densityFunctor, which is not ready yet. Command line is:

bin/livre.app/Contents/MacOS/livre --volume fivoxSpikes://

Preliminary CR is at https://bbpcode.epfl.ch/code/15156

[bilgili]

They are rendered. Voxel values are 255 and the tf should be accordingly. You can create a tf file and load it.

[bilgili]

I have debugged a bit more. The issues are: 1) Due to number of rays that are casted from eye is not enough to sample when there is 1 voxel data. 2) While sampling a voxel, I am using a GL_LINEAR sample from text3d, as a result the values are decreasing when sample is far from the center of the voxel. If I use GL_NEAREST, I can see them

Those are causing undersampling and biased voxels. Those can be resolved by using multiple samples along the ray. But where from is the question. You can sample from the surrounding voxels, but when voxels are big it will be a bit blurry. Checking for the results.

[eile]

1) should not be an issue if one voxel is bigger than 1 pixel in screen space, which with the given SSE of 4 or 8 should always be the case.

[bilgili]

It is nothing to do with the sse, this is all related to the texture sampling. Even with sse=1, ray may not be close to the voxel center.

[eile]

Yes, but if the voxel is bigger than a pixel, it should always be hit by at least one ray.

[bilgili]

With GL_NEAREST yes, with GL_LINEAR it will be different

[eile]

Yes == you can miss?

If so, please explain. Afaik, if the voxel is bigger than a pixel in screen space, nearest is guaranteed to hit the voxel since there must be at least one fragment where the nearest voxel to a given sampler position is filled. For example, if you rasterize a screen-aligned quad bigger than a pixel, at least one fragment is generated. Skype?

[bilgili]

Please check GL_LINEAR documentation. You wont miss but your value will be different than the center of the voxel. Therefore instead of 255 you will read 67. And if that is not in the tf, good luck rendering a voxel.

[eile]

I'm talking about NEAREST.

[eile]

With nearest, and a voxel bigger than a pixel, you should always get at least one "hit" to my understanding.

[bilgili]

Yes you are right with NEAREST and you have a rendering with it already when you set the Tex3D to use it. Currently it is GL_LINEAR as I have said before. And, as I also have said before also, GL_NEAREST causes blocky renderings. To have non-block results wit GL_NEAREST and to have GL_LINEAR like results you should have more samples per pixel or per ray.

[eile]

Ok, got it.

With linear, >1px voxels and a "ramp" transfer function we should then still see something, right? I could not get this to work either.

[bilgili]

Currently it works if you set all values to 1 1 1 1 except 0. This is not a "good solution", in fact far from it. I have to check how other people doing it right or if they are failing as well, I will have to improve sampling schemas.

[eile]

Sorry, I still don't understand: My transferFunction is Color = f( intensity ), with f( intensity ) { return Vector4( intensity, intensity, intensity, intensity ); }. The Shader should get a value > 0, therefore show me a more-or-less grey voxel. I cannot see this today - why?

[bilgili]

have you tried what I proposed ?

[eile]

We are talking around each other - let's discuss on Monday.

[bilgili]

Fixed with #145.