Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


Results on Voxel Cone Tracing - Part 2


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
13 replies to this topic

#1 jcabeleira   Members   -  Reputation: 694

Like
6Likes
Like

Posted 14 May 2013 - 03:39 PM

Hello, guys. Please forgive me for the shameless self promotion, I'd just like to share and discuss the results I got with my Voxel Cone Tracing implementation. So, in my last post I presented an early version of my own implementation of global illumination using voxel cone tracing, since then I've done a lot of improvements and ended up creating a demo that you can find here to show it. Very soon I'll be writing a set of articles explaining the implementation in more detail but for now I'll outline the most important aspects:

 

My implementation uses two 128x128x128 3D textures to store the voxelized scene, a small texture and a larger one, where the small one covers a 30x30x30m volume of the scene while the larger one covers a 120x120x120m volume. Together they provide a voxelized representation of the scene with enough quality and range for the GI processing. The volumes are fixed at the world origin, they do not follow the camera because that makes the lighting unstable, I know this  is impractical for a video game but it's enough to cover the smalll scene of my demo.

No Sparse Voxel Octree is used, this is because I concluded from my early experiments that traversing the tree takes a huge toll on performance probably because the divergent code paths and incoherent memory accesses are not very GPU friendly. So, In general volume textures seem to provide much better performance that octrees at the expense of huge memory waste (because of empty voxels). I haven't profiled one method against the other, my choice was based simply on experiments so please feel free to argue against these arguments and provide your own insight on the subject.

 

The scene is voxelized in real-time using a similar version of the technique described by Cyrril Crassin in the free OpenGL Insights chapter that is available here. The voxelization is quite fast and can be performed in real-time without a great impact on performance which allows to make the lighting dynamic, if any object or light source moves you'll see the lighting change accordingly.

Once the voxel volume is ready it is possible to simulate a second bounce of GI by revoxelizing the scene to a second volume while using the first volume to perform cone tracing for each fragment that is inserted into the volume. Note however that this is very expensive and doesn't compensate the reduced improvement in visual quality so it's disabled by default in the demo.

 

The diffuse lighting is calculated in groups of 3x3 pixels to improve the performance and a edge refinement is done later to fix the difficult cases. For each group of 3x3 pixels 16 cones are traced in all directions with 32 samples per cone. The tracing of each cone is done pretty much like Crassin describes in his paper, for each sample inside the cone we read the corresponding mipmap level of the volume texture and accumulate both the color and the opacity of the voxel information that was read.

 

The specular lighting is calculated by tracing a cone along the reflection vector. Voxel cone tracing gives the flexibility to generate sharp and glossy reflections which is really neat. In general both look good but the lack of resolution of the voxel volume prevents the accurate rendering of glass and mirror materials. Sharp reflections are problematic also because they require an insane amount of samples per cone (200 in the demo) to avoid missing scene features like thin walls. The tracing is optimized to skip large portions of empty space by sampling a lower resolution mipmap level of the voxel volume and checking its opacity (similar to sphere tracing), if the opacity is zero then there are no objects nearby and we can skip that space altogether. This is essentially an GPU friendly approximation of what is done with a Sparse Voxel Octree.

 

So this concludes the overview of the implementation. Please feel free to leave your comments.

 

Don't forget to try the demo (I recommend running it on a Nvidia GTX 680 or similar, it's untested for AMD hardware so I have now idea how it runs on it).

 

Here is some eye candy :

 

 

SerenityRevisited1.jpgSerenityRevisited3.jpgSerenityRevisited2.jpg



Sponsor:

#2 nikitablack   Members   -  Reputation: 614

Like
0Likes
Like

Posted 15 May 2013 - 02:04 AM

The pictures are great. But can't run demo on AMD Radeon HD 6750M.


#3 lipsryme   Members   -  Reputation: 1052

Like
0Likes
Like

Posted 15 May 2013 - 05:20 AM

Seems to crash after startup, AMD Radeon HD 5750M.



#4 jcabeleira   Members   -  Reputation: 694

Like
0Likes
Like

Posted 15 May 2013 - 07:15 AM

Thanks for your feedback, guys. I'm sorry to hear that you guys with AMD's are having problems running the demo. Unfortunately I have no means to address this problem since I do not own an AMD graphics card to test it. The demo uses a lot of advanced GPU features so this may be due to the driver not supporting some OpenGL extensions or simply some shader syntax which isn't 100% correct (NVIDIA is more permissive in this aspect). For now assume that only NVidias 600 series are supported, in the meantime I'll try to figure out a way to test it on AMDs.



#5 Promit   Moderators   -  Reputation: 7658

Like
0Likes
Like

Posted 15 May 2013 - 01:52 PM

I get a device driver timeout on my GTX 480, driver 314.22. sad.png  I'll try it on our GTX 690 or GTX Titan equipped machines later.



#6 _Slin_   Members   -  Reputation: 209

Like
0Likes
Like

Posted 16 May 2013 - 08:24 AM

On my GTX 460 it is just all black, or differently fucked up (looks like some z prepass messup?) if I disable directional lighting.



#7 Vilem Otte   Crossbones+   -  Reputation: 1567

Like
0Likes
Like

Posted 16 May 2013 - 11:51 AM

It looks good, I could run it at work on GTX 680, no luck at Radeon 6870. At home I can't get it run on AMDs either. The problem probably aren't supported features though, it is more likely that some GLSL shaders aren't valid for AMD gpus, but are valid for NVidia gpus.

 

This especially counts twice for compute shaders, as AMD finally supports them in stable driver (13.4 has been beta for quite a while -> now it is stable -> hooray), but the driver has like a TON of differences from NVidia driver (damn those vendors, both!) ... so most likely the compute shaders are causing the issues. I could give it a look or two on AMD, sadly I have too much work these weeks and I won't be regularly available till 15th June or so.


Edited by Vilem Otte, 16 May 2013 - 11:58 AM.

My current blog on programming, linux and stuff - http://gameprogrammerdiary.blogspot.com


#8 jcabeleira   Members   -  Reputation: 694

Like
0Likes
Like

Posted 17 May 2013 - 04:21 AM

Yeah, these differences between vendors are a bit annoying even though everything is fairly well defined in the OpenGL specification.

For a simple guy like me the only option would be to either buy an AMD or borrow it from a friend just to adapt the source code to it. I'll see what I can do about it, I'd really like to all of you guys to be able to run it. I'll keep in touch.



#9 gboxentertainment   Members   -  Reputation: 770

Like
0Likes
Like

Posted 18 May 2013 - 11:14 PM

This is very impressive, but I am also getting the same problem as _Slin_ where everything is black. If I turn off diffuse GI then the sky shows up, but all textures are still black.

I'm running on gtx485m, with nvidia driver 314.22, Windows 7 ultimate 64-bit SP1.



#10 Neo PanGaia   Members   -  Reputation: 114

Like
0Likes
Like

Posted 27 May 2013 - 09:30 PM

very awesome.. id love to see this integrated with smartbody



#11 jcabeleira   Members   -  Reputation: 694

Like
0Likes
Like

Posted 08 July 2013 - 05:46 PM

Hello, guys. Sorry to ressurrect this old topic, I'd just like to make a small update.

I've spent some time trying to make the demo run on AMD hardware but it turns out that the latest AMD driver (Catalist 3.14) is quite buggy. Some required OpenGL features like Shader Buffer Objects seem to be flawed (see my post on OpenGL.org) so for the time being there won't be any support for AMD. :(

 

I'd like to hear your opinion about these problems, if anyone as experience with these drivers please feel free to provide suggestions. I'd appreciate it a lot.



#12 Bacterius   Crossbones+   -  Reputation: 9289

Like
0Likes
Like

Posted 08 July 2013 - 09:34 PM

Hello, guys. Sorry to ressurrect this old topic, I'd just like to make a small update.

I've spent some time trying to make the demo run on AMD hardware but it turns out that the latest AMD driver (Catalist 3.14) is quite buggy. Some required OpenGL features like Shader Buffer Objects seem to be flawed (see my post on OpenGL.org) so for the time being there won't be any support for AMD. sad.png

 

I'd like to hear your opinion about these problems, if anyone as experience with these drivers please feel free to provide suggestions. I'd appreciate it a lot.

 

Yes I tried the demo again a week ago or so but it just wouldn't work on my HD6950 even with Catalyst 13.14. It's ridiculous how bad AMD is at catching up with new OpenGL features angry.png


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


#13 Chris_F   Members   -  Reputation: 2465

Like
0Likes
Like

Posted 08 July 2013 - 09:53 PM

Yay, aren't OpenGL and proprietary device drivers fun to work with?



#14 Promit   Moderators   -  Reputation: 7658

Like
0Likes
Like

Posted 17 July 2013 - 10:38 AM

The last couple rounds of AMD's driver (13.2 and 13.3) have been spectacularly f***ed up too, each in their own creative ways. I don't know what's going on over there but they're doing an incredibly bad job lately.






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