Jump to content

  • Log In with Google      Sign In   
  • Create Account


Voxel Software Rendering Feasibility


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
8 replies to this topic

#1 Toothpix   Crossbones+   -  Reputation: 810

Like
1Likes
Like

Posted 12 April 2012 - 04:58 PM

If a program renders volumetric data, for example of the quality of Atomontage, could this be implemented with software rendering techniques as opposed to hardware acceleration? I have recently seen a software renderer (polygons) of the following quality: http://www.youtube.com/watch?v=KdzRRQdkr08 . Would it be possible to implement something like this in software rendering using volumetric data? Would there be additional graphics API's required such as the Windows GDI in the Windows API?


C dominates the world of linear procedural computing, which won't advance. The future lies in MASSIVE parallelism.


Sponsor:

#2 Bacterius   Crossbones+   -  Reputation: 8494

Like
3Likes
Like

Posted 13 April 2012 - 12:57 PM

Voxel rendering's bottleneck isn't the rendering per se, it's the voxel storage. If you have all your voxel data in low-latency memory, arranged in a nice acceleration structure, you can render it in software quite efficiently. Problems start when your voxel data gets bigger than your available memory and starts to spill onto the hard drive and you have to fetch it while hiding latency as best as possible.

So, yes, software voxel rendering is feasible. What library/API you choose to implement it with is, of course, up to you.

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#3 Sirisian   Crossbones+   -  Reputation: 1724

Like
3Likes
Like

Posted 13 April 2012 - 03:18 PM

This also depends on the quality you want to render with and the screen resolution.

For low quality look into raycasting methods. They often rely on single sampling and are extrmely fast with the right algorithms, but their quality with a single sample per pixel is often low. If you want to go that route look into 3DDDA and octree traversal algorithms. They are rather easy to thread. Look at Laine's papers on SVO traversal. Note with some tweaks this method looks very nice.

For medium quality look into cone tracing.

For higher quality (or "perfect" rendering) look into beam tracing.

For naive rendering look into polygon rasterization. In any case read the Larrabee article as it comes up sometimes for things like octree frustum culling. (Similar algorithm).

For handling the framebuffer look into pixeltoaster. Also this goes without saying, but work on your algorithms from a high level and optimize down. When you think you have things right start switching over to SIMD instructions.

Also if you render volumes front to back don't use source alpha minus one blending. It doesn't model volumes. This algorithm does.

#4 Krypt0n   Crossbones+   -  Reputation: 2487

Like
4Likes
Like

Posted 15 April 2012 - 08:18 PM

beside OpenCL and Cuda version, I've also a CPU version of my voxel tracer. The problems that you get are similar to those of a raytracer, the higher the resolution, the slower it gets.
With some smart memory management, it actually scales better on CPU than on GPU, as your GPU is just dependent on raw memory bandwidth, and having a lot of diverging ray paths, results in cache trashing between rays in the same warp/wavefront. On cpu, you can organize rays to travel coherent through memory, to maximize the cache usage.

Atm my GPU version is usually faster (quadcore intel Penryn vs NVidia GTX460), but with more complex models and some compression, the GPU version is faster (in smaller resolutions).


you can check out some voxel renderings in my gallery: http://twitpic.com/photos/michael_hpp , sometimes I state which version I've used, I think the bottom most picture with the animated imp was CPU.

Edited by Krypt0n, 15 April 2012 - 08:21 PM.


#5 PolyVox   Members   -  Reputation: 708

Like
2Likes
Like

Posted 16 April 2012 - 02:18 AM

you can check out some voxel renderings in my gallery: http://twitpic.com/photos/michael_hpp , sometimes I state which version I've used, I think the bottom most picture with the animated imp was CPU.


Nice pictures! Kind of off topic but where is this scene from: http://twitpic.com/8iohd5/full Is it a freely available test scene or something you aquired privately?

#6 Sirisian   Crossbones+   -  Reputation: 1724

Like
2Likes
Like

Posted 16 April 2012 - 01:45 PM

Nice pictures! Kind of off topic but where is this scene from: http://twitpic.com/8iohd5/full Is it a freely available test scene or something you aquired privately?

That's actually one of the model's in Laine's SVO papers also. It's Marko Dabrovic's Sibenik Cathedral model. You can find it in a lot of places online. One of them is here.

#7 PolyVox   Members   -  Reputation: 708

Like
2Likes
Like

Posted 17 April 2012 - 05:09 AM

Ah, I recognise it now :-) Because of the cars I though it was a museum or something. They must have been added seperatly.

#8 Sirisian   Crossbones+   -  Reputation: 1724

Like
2Likes
Like

Posted 17 April 2012 - 07:59 AM

Ah, I recognise it now :-) Because of the cars I though it was a museum or something. They must have been added seperatly.

Wait a second. I spoke too soon since I just took a quick glance. That doesn't look like that model at all. I've never seen that model he linked with the cars. Now I'm curious also.

#9 Toothpix   Crossbones+   -  Reputation: 810

Like
1Likes
Like

Posted 17 April 2012 - 04:43 PM

you can check out some voxel renderings in my gallery: http://twitpic.com/photos/michael_hpp , sometimes I state which version I've used, I think the bottom most picture with the animated imp was CPU.


Wow, those are IMPRESSIVE. Are any of those done in real time with software rendering? How big are those voxel models in file size?

C dominates the world of linear procedural computing, which won't advance. The future lies in MASSIVE parallelism.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS