Animated Sparse Voxel Octrees

(Imrod walk cycle: 3M voxels, 36fps, GeForce GTX 460, 800×550 pixels, phong shading, normal mapping, shadow mapping, hardware skinning. Original model by Dmitry Parkin)

Introduction

Sparse Voxel Octree (SVO) is one among many representations for 3D objects – Triangle Mesh being the most famous one due to its widespread use in the Real-time domain. SVOs have many advantages over triangle meshes, like implicit level of detail, dense representation, simpler intersection tests, simpler uv mapping.

Their biggest disadvantage (apart form the lack of a hardware-accelerated rendering pipeline) was the infeasibility of animating them. I tackled this problem in my bachelor thesis. The animation technique I developed makes

possible.

Resources

  1. H.L. Carroll on March 29, 2011

    Thank you.

  2. P.W. on April 29, 2011

    Great work you’ve done here! Keep it up!

  3. Stephen Minkin on July 14, 2011

    I am very impressed with you demonstration. I am a 3d artist who works in the games industry as a tech/character artist. Feel free to see my current portfolio at
    http://stephenrminkin.cghub.com/

    I am curious to know if you would be interested in creating another ASVO demo?

  4. Philip on July 21, 2011

    Amazing work! Thanks for sharing!

  5. Anonymous on July 22, 2011

    Why don’t you use a non-propriatary compute engine such as OpenCL instead of the propriatary CUDA. That way it will work on both the AMD and Nvidia GPU’s

  6. Dennis on July 22, 2011

    @Anonymous I chose CUDA, since I was already familiar with it and was under time pressure. Furthermore the renderer should only proof the viability of the animation technique, which is renderer-independent. I’ll cover this and more in a future article.

  7. Nolan on August 2, 2011

    Absolutely awesome! There is a big discussion about implementing Sparse Voxel Octrees on a 3DS Max forum. I brought up your animation, feel free to check out the discussion!

    http://maxforums.org/threads/unlimited_detail_real_rendering_technology_preview_2011/0002.aspx

  8. Chris on August 4, 2011

    This was awesome work.

  9. Guillaume VanderEst on August 6, 2011

    Thank you very much for your posts/videos/examples! I am looking forward to your future posts, as all this voxel stuff was something I’d never heard of until just recently– and I can see what the huge fuss is about with those animations!

  10. Sam on August 9, 2011

    Grats on the animation but, 36FPS for one damn character?!

  11. Dennis on August 10, 2011

    @Sam 1. It’s unoptimized research code. Drawing static geometry isn’t much faster – the animation adds very little overhead. 2. Emphasizing that it’s ONE character doesn’t make any sense, since voxel octrees are resolution bound, not geometry bound. If you can render a whole-screen filling octree, you can render as many as you wish with little to no performance penalty.

  12. Vladimir on November 7, 2011

    Have you considered different type of rednering, such ray/pathtracing?
    It goes very well with octree.

  13. Dennis on November 8, 2011

    @Vladimir I have, but I didn’t bother to implement it since I consider the renderer just to be a proof of concept for the animation technique. Maybe I’ll write a post about it though.

  14. m6mb3rtx on December 2, 2011

    Great work!

    Thanks for sharing it.

  15. robert_d on March 10, 2012

    I’m using Visual Studio 2010 Ultimate, but I can’t open your project.
    I get error “‘asvo_and_asvo_cudaasvoasvoasvo.csproj’ cannot be opened. The project type is not supported by this installation.”

  16. robert_d on March 10, 2012

    I’ve resolved this problem, I had to install XNA Game Studio 4.
    Besides I had to compile XNAnimation library from source code,
    because it doesn’t work with XNA Game Studio 4.
    But now I’m getting this error
    “Error 1 Errors compiling asvo_and_asvo_cudaasvoasvoContentsimple.fx: The effect state ‘MagFilter’ was assigned an invalid value. asvo_and_asvo_cudaasvoasvoContentsimple.fx asvo”

  17. Dennis on March 10, 2012

    @robert_d The error you are getting might come from XNAnimation being incompatible with XNA 4 (or the port to it being not trivial). I’ll try and update the whole project to the newest version and get back to you. Thanks for your interest!

  18. robert_d on March 11, 2012

    I’m eagerly waiting for this, because I need this project for my job.
    Now I’m getting a lot of errors in c# files.

  19. Dennis on March 12, 2012

    @robert_d Dear Robert, I successfully ported the subset of XNAnimation that my application needs to run to XNA 4.0 and emailed the author to ask for permission to redistribute my project with his code in it. I’ll get back to you as soon as possible. Thank you for your patience!

  20. robert_d on March 13, 2012

    Thank you Dennis, that’s very kind of you :)

  21. Dennis on March 13, 2012

    @robert_d The “asvo.zip” link now points to the updated project, have fun! Also, I discovered that asvo_cuda is incompatible with CUDA 4.1, but that would take me a little longer to fix..

  22. robert_d on March 17, 2012

    Do you know why I am getting this error when I try to use
    a model from XNAnimation Samples project (e.g. PlayerMarine.fbx)?
    The error “The array is not the correct size for the amount of data requested” is thrown by the following instruction in createFromFBX method
    _model.Meshes[0].Indices.GetData(_indices);

  23. Dennis on March 20, 2012

    @robert Sorry for getting back to you so late. I’m afraid that my code is very naive and doesn’t support objects with sub-meshes. If you like to try out other objects, store them as one single mesh (e.g. using 3ds max). Feel free to email me with further questions ;-)

  24. Jared on May 17, 2012

    I apologize if this is a dumb question, but I am not a computer scientist. Anyways, I am curious why you choose to bend/rotate the voxels in space the way you do. If I understand them right, they function quite a bit like pixels, so why not reposition them entirely frame to frame like a raster animation would. Is that even move expensive for the processor? I realize that it wouldnt help to keep them in their octree, but it would at least keep the voxels in the grid pattern.

  25. Dennis on May 17, 2012

    @Jared, your proposed approach would be much simpler to implement and yield a higher visual quality than mine. However, considering the memory consumption of volumes encoded as voxels, it wouldn’t be feasible to store a different volume for every animation frame.

  26. Jared on May 24, 2012

    I realize that it would be an enormous amount of data for each frame to be treated as a seperate volume and I see that you addressed that somewhat in the paper you wrote, although I have not finished reading it yet. For the voxels to stay on the grid and not rotate, but rather reappear from frame to frame in their new position, is it possible to compress that data to make in any more manageable? I would think that since it would basically be three dimensional video, wouldnt it be possible to compress the data similarly to HD video except with one more value for the Z dimension? Also, could it be that the voxels could remain in some level of their octree because the voxels would only need to animate at the LOD of which they are being viewed onscreen? Only the octree that is the size of the pixel onscreen would need to be moved from frame to frame.

  27. Dennis on May 24, 2012

    @Jared, your observations are all correct. The only question is whether one can come up with a compression algorithm that is strong enough to shrink such a stream into manageable sizes. Let’s say you can afford to spend 1MB per second of video. Assuming a 1024^3 volume contains 3M voxels, that results in 0.1bits per voxel (@30fps), which is an incredibly tight constraint.

  28. Jared on August 23, 2012

    Hey, its me again. I was just curious if you saw John Carmack’s most recent quakecon keynote and what you thought of it, particularly what he said about SVO’s. He admits that virtualizing geometry similarly to what Megatextures does for textures is probably the next big step, but believes the smart money is on tessellation or something polygon based. It seems he thinks this because all the current tools in the industry are based in polygons and doesnt think a big change is likely to happen. However, he did not say much on the topic. I was particularly disappointed that he didn’t address any of the real benefits of voxels. I don’t really feel right about questioning him, as I am sure he knows far more about it than I, but I have to believe that if the polygons are going to get so small that they are the size of pixels, they might as well be voxels. It would be less data. Although, I am quite fond of tessellation meshes from my experience with Sculptris, but from what I can tell, I wouldn’t think they would be animatable either as triangles don’t deform well and the edge loops are crazy. I would love to know your thoughts.

  29. Dennis on August 23, 2012

    @Jared I did see it and it makes sense. Unification is a natural step in the evolution of software systems. As systems become more powerful, they also become bigger and more complex. Unification is one possibility to deal with that. We saw it in the game industry in the form of deferred rendering and mega textures. Every such step is a trade-off between increased productivity, maintainability and increased resource costs. For example, nobody will deny that ray-tracing is a much better rendering model than rasterization, but our current hardware is not powerful enough to use it in the mass market. I agree with Carmack that the next big step will be the virtualization of geometry. How this will be implemented is another question. I think that volumetric representations have a lot of potential given their features and the vivid research around them. They can simplify artists’ workflows, simplify texture mapping or even replace it by encoding visual data directly inside the volume and are much better suited for deformation. Keep in mind alternatives like Mega Meshes and don’t forget that hybrid approaches are also feasible. I doubt that tesselation alone is strong enough to fill this role (it is foremost an enhancing technique), but I’m sure that we will see a lot of cool things coming out of it as programmers and artists discover its possibilities. One interesting research topic in this regard would be user-guided tesselation, where an artist creates a coarse mesh, applies detail through (procedural/displacement-mapped) tesselation and then has the ability to put finishing touches on the final model without incurring big memory or performance overheads.

(Allowed tags: <a> <blockquote> <cite> <code> <del> <em> <q> <strong>)