So I've started this project, and I'm realizing that there's a bit more to volumetric rendering than I had first thought. The general idea is really simple, but that's also what makes it so risky. Most of the reading I've done on the subject (it's actually tougher to find info on than one would think) points to the quick-and-dirty method, rendering via slices:
[caption id="" align="alignnone" width="500" caption="Source: http://charhut.info/files/cs280/volume1.png"]
[/caption]So in the above picture you'd be rendering a crude sphere. Obviously aliasing is a massive concern here. But nevertheless I decided I'd try this approach first. My initial attempt was promising:
 |
 |
However there's that bit of aliasing in the right photo from looking at the slices from the "side". Sort of like the demo pic above. It It looks horrid, and will seriously interfere when I start using complex volumetric textures instead of a big green block. I thought adding alpha blending would remedy this, but while it made the block look cooler it actually made the aliasing more apparent...just smoother:
 |
| From Voltex |
So this method wasn't going to work. Or at least not the way I wanted it to. I also experimented with rendering three dimensions worth of slices, oriented to each axis in turn. This DID result in a near-perfect rendering of the volumetric cube from all angles, but it also tanked my frame rate for obvious reasons. I threw the code into a display list and compiled it just to see, but it actually didn't help much. Even if the speed had been bearable, when I was doing the 3-dimensional slice renderings I wasn't using alpha blending, I have a feeling the aliasing would have come back once I did...
So now I've got to try another route. I stumbled across some old PS3.0 demos on NVidia's site yesterday, and one of them happened to be on volumetric texture rendering. I had a peek at the demo code and saw that they use a different approach of ray-marching a solid cube in the pixel shader. It also runs extremely fast compared to my old-fashioned OpenGL code, and the aliasing is completely absent in all cases. All around it just seems like the right direction to go, although I'm very inexperienced with shaders. I'm going to try this over the next week or so and see if it gets me closer to what I'm aiming for.
On the subject of the MRI data. The one dataset I have in my possession is just a folder of JPEG images. I've managed to load these into my 3D texture volume using a great little C library called SOIL. Unfortunately the fact that they are jpg images means there's no alpha blending at all, so the renderings are pretty boring and not worth showing here. I haven't decided what I want to do with them in that case. One thought is to preprocess them with photoshop's batch image action and see if I can apply alpha to the images based on pixel contrast, this might work since they are grayscale, but I'm very inexperienced with photoshop as well. Another idea is to implement color keying to blend out all of the black, however this would be a crude way to do it, and would miss the finer details of the dataset. The option I was looking at prior to stumbling upon the ray-marching demo was to implement the conversion in a pixel shader, and essentially do what photoshop would do for me on the fly. This still might be possible, especially since I'd be dealing with shaders anyway at that point, but I'd rather not over-complicate the shader code if I don't have to.
As for other MRI datasets. I found a website absolutely FULL of them: Link
The only issue is that the license they are under requires them to be packaged in a special format that guarantees that whenever the data is distributed the property rights are included. However, they also distribute an open-source program that can read and render the dataset in these files meaning I can learn to open them myself. This is next after I get my volumes rendering correctly and the initial MRI data drawing how I want it. I've had a look at the code for opening these special files and it seems pretty easy to implement, so it shouldn't be too much work. Plus then I'll have MUCH clearer MRIs to work with!
On a final note: I initially intended to do procedural generation via volumetric density algorithms as state in Ken Perlin's paper. This is currently on the back burner. I'm hoping that everything else goes smoothly and I get to it, but I'm starting to see that rendering the volumes efficiently can itself be a complicated process, and I'd rather get that working with some quality MRI data before I experiment with generating something on my own.
No comments:
Post a Comment