Jump to content

  • Log In with Google      Sign In   
  • Create Account

Vilem Otte

Member Since 11 May 2006
Offline Last Active Oct 22 2014 04:39 AM

Posts I've Made

In Topic: GPU ray tracing in real time

20 September 2014 - 07:07 PM

Generally ray tracing is fast enough today to get some solid quality rendering, but...


Now, I've been contributing to one academic project for some time, first - this is Aila/Laine work on high performance ray tracing in CUDA:



We took their project and started adding some stuff (I based my thesis on the new-added stuff ... and generally a theory around it), we ended up with quite large framework that is able to use a lot more features:


The features that were added are -> Solid texture support, path tracing support (bidirectional path tracing is currently WIP), more acceleration structures (right now we have KD-Trees and BVHs (with several ways to build, including HLBVH)), multiple materials support, etc.


The only large problem with this project is, that we based our code on top of Aila/Laine framework (not that it is bad, but it isn't something you can turn into library and give it out to public ... it would need a lot of work), and the bigger problem... it is in CUDA, I hate platform specific code (and I love OpenCL), but as I stated before, it is academic project - academics like CUDA, they prefer it + the other guy wanted to base the code on top of existing framework.


I've been trying to write a OpenCL based library (and example files) with my experiences from that project (and several others that involved ray tracing, but they were a lot smaller), that would generally allow to perform ray tracing using "any device" (not all of them, but at least all that supports OpenCL) without some crazy dependencies. I've got to the state, where it worked (it still was slower than NTrace, supporting just some older BVH schemes, etc.). I currently don't have time to fully continue my work on the project (any contributors are welcome biggrin.png ... just joking of course ph34r.png) - but if you would like to get access to it, I have it on local Linux machine, putting it up into git isn't a problem and you could check that out (that project is several times smaller than NTrace and in my opinion easier to read).

In Topic: Best reflection method

08 September 2014 - 04:24 AM

Technically we don't necessarily need voxel representation of the scene, you can use standard triangular representation of the scene, good quality BVH and perform ray tracing (assuming you do deferred rendering, you really just need to perform ray tracing of secondary rays). This way you achieve good quality hard reflections (of course you can change them into smooth reflections - either by using some "smart" blurring (you need to take edges into account ofc) or "use more rays").

In Topic: Post process order?

22 July 2014 - 08:58 PM

Just a note - if you are doing standard AA (or technically any solid AA technique), it should be resolved AFTER tone mapping (otherwise it won't work right).

In Topic: Jumping over to DirectX?

23 June 2014 - 01:04 PM



1. I would more likely say "welcome to light side". For me, the only strong argument why I'm using OpenGL in most of my applications is one - Linux (this counts especially when you're not developing games, but software for doing various high performance computations).


2. Comparing bare bones applications will show you larger difference in speed, than for case of F.e. full game. But generally yes, D3D will perform better.


#OP & thread generally:


I won't even mention debugging - under OpenGL we literally had to develop our own tools from scratch (they work well, but it took us hell a lot of time to create them).


Dealing with AMD vs NVidia vs any other vendor (and often driver versions) under OpenGL, with some recent features, is a bloody mess (I still remember moment, where one user of my applications had troubles with 3D textures and Intel gpu, that officially supported 3D textures extension (and also OpenGL version, where it was promoted into core), but once you sampled 3D texture inside shader, you were doomed.


So, as for me - go right away, switch to D3D.

In Topic: float or double depth buffer?

21 June 2014 - 04:12 AM

tie55 - 18ms to 35ms (holding F1 - 12ms to 29ms)

tie55b - 18ms to 36ms (holding F1 - 13ms to 30ms)
tie55c - 18ms to 34ms (holding F1 - 12 ms to 29ms)

In default resolution (550x400), I'm for some reason unable to switch it.


There is still a ton of z-fighting, sometimes triangles disappear.