Recently I've spent quite some time looking at volume rendering algorithms. Now I managed to get some results. The ray casting implementation is not very sophisticated yet but later I'm going to improve it.
On the screenshot below you can see the volume 64x64x64 with such a strange shape inside (it was not the aim to get such a shape, it was generated somehow as a test data;). Screen resolution 640x480. Frame rate, as you have noticed probably, is only several frames per second. Not very useful yet but while development I used to switch the screen resolution to 320x240 which increased frame rate to 10 fps.
Originally I started implementing the algorithm for OpenGL but later decided to use one of the existing engines as a platform. I'm not very familiar yet with ogre so the code is owfull yet but I'm going to make it as a easy to use library. Parhaps new scene manager or something like that.
Any ideas are welcome.
16.07.2009
Loading real-world datasets works now but not as nice as I expected. Seems normals smoothing has been broken.
Last edited by Maxym on Thu Jul 16, 2009 12:06 pm, edited 2 times in total.
Cool stuff! Are you generating it for any particular purpose, or just for fun? If you want to learn about volume rendering, I can really recommend the book Real Time Volume Graphics
PolyVox wrote:Cool stuff! Are you generating it for any particular purpose, or just for fun? If you want to learn about volume rendering, I can really recommend the book Real Time Volume Graphics
Just for fun. Before it was supposed to be used in the project but the circumstances have changed.
Thx for the recomendation, I'll study it carefully.
BTW: one thing I'd like to ask to more experienced Ogre users: What would be the best way to add this stuff to the ogre? As you can see this is just a box which is rendered with complex fragment shader. As far as I can see it can't be added just as a plugin because it needs to be edited somehow on the move. I mean to change shape in real time, which was the main idea of the algorithm, right?
Maxym wrote:BTW: one thing I'd like to ask to more experienced Ogre users: What would be the best way to add this stuff to the ogre? As you can see this is just a box which is rendered with complex fragment shader. As far as I can see it can't be added just as a plugin because it needs to be edited somehow on the move. I mean to change shape in real time, which was the main idea of the algorithm, right?
Nice work. This isn't the sort of thing you'd usually 'add' to Ogre as such, not as a plugin. It would normally sit 'above' Ogre, as a supplementary library that users would interact with directly, but which also calls Ogre methods in order to implement its functionality.
Maxym wrote:BTW: one thing I'd like to ask to more experienced Ogre users: What would be the best way to add this stuff to the ogre? As you can see this is just a box which is rendered with complex fragment shader. As far as I can see it can't be added just as a plugin because it needs to be edited somehow on the move. I mean to change shape in real time, which was the main idea of the algorithm, right?
Nice work. This isn't the sort of thing you'd usually 'add' to Ogre as such, not as a plugin. It would normally sit 'above' Ogre, as a supplementary library that users would interact with directly, but which also calls Ogre methods in order to implement its functionality.
Thanks for the explanation. Yes that's what I was thinking about. Even it I found out that this should be implemented as SceneManager it would be linked to the client application anyway to let access its functionality. For now I'm not sure whether it will be a scene manager of just a library which creates an Entity object which will be rendered with Volume Rendering shader.
Maxym wrote:
Thanks for the explanation. Yes that's what I was thinking about. Even it I found out that this should be implemented as SceneManager it would be linked to the client application anyway to let access its functionality. For now I'm not sure whether it will be a scene manager of just a library which creates an Entity object which will be rendered with Volume Rendering shader.
Generally, you want to limit your users as little as possible. If its a scene manager, then whoever wants to use it has to use this as THE scene manager (unless they are working with the portal connected SM, but that still requires work)
If its just an advanced technique for rendering single (or a number of) objects, I say make it as drop-in-able as you can.
Noman wrote:
If its just an advanced technique for rendering single (or a number of) objects, I say make it as drop-in-able as you can.
Yeah, that's exactly what I would like to achieve but for performance reasone all such objects must be rendered after all other objects in the scene (for early ray termination). Seems it requires more serious such objects management, doesn't it?
Maxym wrote:BTW: one thing I'd like to ask to more experienced Ogre users: What would be the best way to add this stuff to the ogre? As you can see this is just a box which is rendered with complex fragment shader.
Well, my gut instinct is that you don't need to do anything complex like creating a custom scene manager. Although it looks fancy, ultimatly it could just be an Ogre Entity? I mean it's actually just a box, with a big 3D texture and a (complex) fragment shader. If your just trying to add volume rendered images to your scene then that's probably the easiest way to proceed. Not sure about having it intersect other pieces of geometry though...
Also, I'm pretty sure that other open source scene graphs (OpenSceneGraph, OpenSG, etc) have volume rendering nodes. But be interesting to see how they approach things from a design perspective.
We have been working on a CT and MRI reconstruction system for a couple of months using several different volume rendering systems. We do not modify Ogre's core at all in order to do it. Everything is done through shaders on the GPU and so easily fits "on top" of Ogre's core system. You can see some older screenshots of the system in our gallery (http://www.luster3d.com/gallery.php) under the DataPhysics Research name. Those are only images of one of the rendering modes with a very low-res scan (only 51 slices) but you can see that with pure shaders and no core modifications we can get a good reconstruction.
Praetor wrote:You can see some older screenshots of the system in our gallery (http://www.luster3d.com/gallery.php) under the DataPhysics Research name.
I've checked the link. Looks cool!
The thing that would be useful for me is what performance you managed to get. In terms of resolution/number of slices/Graphics card => FPS.
PolyVox wrote:Well, my gut instinct is that you don't need to do anything complex like creating a custom scene manager.
Yep, I agree that that's easy to add as a single object to the Ogre. That was only suggestion about scene manager in case we have planty of volume objects. Scene manager would allow managing the objects in more smart way. But that's not the way I'm going to move in the close future;)
My laptop has a 7600M and we get >20 FPS in that rendering mode 512x512. The other rendering mode can be slower, down as low as 10FPS depending on the exact circumstances (which basically boils down to how far the ray has to go before we terminate). Anything over an 8600 get well within interactive framerates. Note, when you are not interacting with the volume we generate a full resolution image (those screenshots are obviously at whatever window resolution you have) that takes longer to produce.
Praetor wrote:Note, when you are not interacting with the volume we generate a full resolution image (those screenshots are obviously at whatever window resolution you have) that takes longer to produce.
I'm not sure I completely understand you. You mean that you generate full resolution image only if the object is frozen on the screen? Good idea, I've not thought about that.
Yes. Render a lower-res so that the framerates stay interactive. When the user stops moving the volume, render a high-res version for them. This is fairly standard in the medical viewers we've tried.
Praetor wrote:Yes. Render a lower-res so that the framerates stay interactive. When the user stops moving the volume, render a high-res version for them. This is fairly standard in the medical viewers we've tried.
It's a nice trick. So I have a plan for further improvement:
1. First of all I have to add loading raw files from the hard drive. It's not there yet. Now it's really necessary since I've found a lot of datasets in raw file format following the link provided by PolyVox (http://www.volvis.org/).
2. Increasing frame-rate while moving - very useful feature. Thanks for the advice.
BTW: Is there any recomendation on traversal algorithm? I guess there must be more smart algorithm for that, because I implemented first thing which came up in my mind.
Last edited by Maxym on Wed Jun 24, 2009 7:03 am, edited 1 time in total.
We read our data from DICOM files, since it is medical, but you should probably can probably make a new codec for Ogre which will read the raw files into hardware 3D textures.
I can't reveal too much about the inner workings of the rendering algorithm. We do use several acceleration techniques to speed up rendering and also a few novel refinement techniques to increase image quality (which lets us take fewer samples, thus increasing speed). First of all, do you early-out of your rays? That's the the first and easiest technique.
Praetor wrote: First of all, do you early-out of your rays? That's the the first and easiest technique.
Sure, I even did think about such an optinization because my algorithm doesn't support any transparency, so ray termination immediately after iso-surface intersection was so obvious.
Maxym wrote:BTW: Is there any recomendation on traversal algorithm? I guess there must be more smart algorithm for that, because I implemented first thing which came up in my mind.
It's usually useful to implement some kind of empty space skipping, for example via an Octree. That should help performance.
PolyVox wrote:It's usually useful to implement some kind of empty space skipping, for example via an Octree. That should help performance.
I think it would help a lot, but it's not likely to be easy (and fast) to pack volume data into such a tree. But that's only preparation step, where speed is not that important. I'll think about later.
Small status update:
Loading real-world datasets works now but not as nice as I expected.
Known issues:
1. Seems normals smoothing has been broken.
2. Some distant parts of the volume are clipped for some unknown for me reason. I have no idea yet why it happens, will check it later on.
Maxym wrote:Unfortunately, there is no efforts in this direction from my side. The project is dead.
Did you get further since your last post in this thread - and did you ever make any of the source public? If you'd like to discuss more, feel free to PM me a contact email, it could be of some interest.
Oh - and thanks for replying so quickly to this old dead thread!
Looking to find experienced Ogre & shader developers/artists. PM me with a contact email address if interested.
no, I didn't publish the source code since I didn't reach outstanding performance. I can share the source code if you like for reference but it can take time to exhume it from old hard drives.
