Update - many changes since I last posted in this thread.
https://github.com/timscaffidi/ofxVolumetrics
*increased rendering quality
*simplified, optimized raycasting shader, fixed type casting issues
*fixed near and far clipping issues, clipping planes match external scene regardless of FBO resolution
*rendering from within the volume is now possible
*fixed face culling issue, automatically detects and handles both right and left handed coordinate systems and properly culls faces
*added Xcode project files
*example now uses ofEasyCam
*made a video of it in action:
http://vimeo.com/35720138
UPDATE
OK, I am done with the first version. Included is an example that renders the head seen below.
Let me know what you think and what changes you’d like to see!
I’m learning git, so I’ve moved this addon to my git repo, seems like this will make everything easier.
https://github.com/timscaffidi/ofxVolumetrics
recent changes:
* updated shader with Joshua Noble’s compatibility fixes.
* Fixed a strange freezing issue when rendering at certain angles, seemed like the shader was getting into a very long/infinite loop in rare occasions.
/UPDATE
I am in the process of cleaning up my volumetric renderer to release as an addon. Since I’m using 3d textures I figured I’d include an ofxTexture3d class to make things more modular and reusable.
Since ofTexture is designed for 2d only, it doesnt really make sense for me to just make a subclass, or at least I have trouble thinking about how to go about that properly, so instead I’m making a standalone class which mimics much of the interface that ofTexture uses.
While implementing my loadData functions, I saw this in ofTexture.cpp:
/*if(glFormat!=texData.glType) {
ofLogError() << "ofTexture::loadData() failed to upload format " << ofGetGlInternalFormatName(glFormat) << " data to " << ofGetGlInternalFormatName(texData.glType) << " texture" <<endl;
return;
}*/
if(w > texData.tex_w || h > texData.tex_h) {
ofLogError() << "ofTexture::loadData() failed to upload " << w << "x" << h << " data to " << texData.tex_w << "x" << texData.tex_h << " texture";
return;
}
// update our size with the new dimensions
texData.width = w;
texData.height = h;
I see that there used to be an error when trying to load data of a different glType, however that code is now commented out, and the new type overrides the old one. Also, as long as the new width and height are <= the current width and height, those are overwritten as well.
The image data is uploaded using glTexSubImage2d, may or may not replace the entire texture. The texture data on the gfx card is then essentially being cropped? Does openGL not really care if you upload data as a different type? For example if i allocate the texture using GL_RGB and then load data as GL_LUMINANCE using smaller dimensions than originally allocated, what happens to the data that was not updated? does it become unusable because they are in different formats?
I guess I am asking this so that I know weather or not to even allow loading a different format of data into an existing 3d texture, because it is useful to use glTexSubImage3d to only update a slice of the volume, yet still keep the entire texture’s dimensions the same. I would think that if you tried to upload data in a different format in this case, you may get some strange output.
Well, thorugh writing this post, I think I’ve come to the conclusion that I should not allow different formats than the allocated one, but maybe I’m wrong. I’ll post back here if I run into more problems/design issues for this addon.