Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Vilem Otte

Member Since 11 May 2006
Offline Last Active Yesterday, 11:28 PM

Posts I've Made

In Topic: automatic light probes positioning

13 November 2014 - 03:33 AM

i guess i have to throw LP away and perform raytracing with sky on CPU (just rays - top/left/right/forward/backward) for every object that is moving , to learn if object is under indirect lighting or not..

 

just occlusion factor = 5results/5 = 0...1

 

My appologize for going OT here - but this one needs a comment

 

Note that this will be quite slow unless you have some kind of hierarchy in which you store your scene (and you're back to beginning - it can be Octree, KDtree, BVH, BIH, etc. - you will still have to build it (or pre-compute it for static scenes). Also note that you will get your results per object, which looks acceptable only for small objects.

 

E.g., you might be able to test 5 rays for some higher number of complex objects in scene without hierarchy but it will look bad (you could accumulate occlusion over time - but moving objects would blink) - e.g. you will need more rays (more samples), and so your performance will drop (a lot) - which implies the need of hierarchy for scene (this can accelerate the ray tracing process).

 

Hint. You could use short rays for computing occlusion (even though it won't be global then), with good hierarchy (read SAH KD-tree, Split-BVH, etc.) this gives you ability to compute tens of milions or even hundreds of milions rays per second on todays hardware.


In Topic: Good C (not C++) math library?

13 November 2014 - 03:18 AM

#Nairou C11 won't be in MSVC for quite long time (As Ravyne said there isn't a solid C99 compatibility as for now). Also I don't think Microsoft sees C compiler as their main focus (they focus on the C# mainly), and I don't really believe the situation will get better in next years.

 

I would second SIMDx86, although it has been 2 years since the last time I've used it - it is now marked as "inactive" on SF (there is SSE, SSE3 and Altivec implementation as for now - no AVX).


In Topic: Tube AreaLight - Falloff problem

29 October 2014 - 08:34 PM

Alright...

 

Important note - I'm trying to describe area lighting a bit, I couldn't test your code at this point. Anyways maybe you find my notes useful:

 

What we have - a tube light defined by 2 points (L0 and L1) and radius ® ... (for the simplicity let us assume that it forms a capsule shape). What we need to calculate for each point we're shading (P):

  • Closest point on tube (this can be used for attenuation)

Our 2 points define a line. Let us define that line as L0 + t * (L1 - L0) ... and we're searching for 't'. This can be done simply using formula derived here -> http://mathworld.wolfram.com/Point-LineDistance3-Dimensional.html - e.g.: t = dot(L1 - P, L2 - L1) / dot(L1 - L0, L1 - L0) - now we clamp t between 0 and 1 (e.g. if it is smaller than 0, then it equals 0 ... if it is larger than 1, then it equals 1). Thus we got our closest point on line... (lets note it as Cl)

 

Closest point on capsule (Cc) thus equals Cc = Cl + normalize(P - Cl) * r; (NOTE: for actual distance it is enough to use d = length(P - Cl) - r).

 

From here we can correctly compute attenuation.

  • Calculate diffuse light

Now this is a challenge. What we actually need to compute right now is how large solid angle is occupied by the capsule in hemisphere above given point (in direction of its normal).

 

Note: Your approach in code (using 2 endpoints to light it) is just wrong - you are not lighting using area light, but just using 2 points.

 

Generally solving solid angle (which is possible for simple analytic shapes like capsule is), would give us how much of whole capsule is visible at given point, from here we can calculate diffuse light. I won't write full process of integration here (I've quickly searched net whether someone actually computed equation for solid angle of capsule and I couldn't find any results) - it would take some time with fully running brain (it is generally not a good idea to do this kind of computations at 3am), so I will try during tomorrow.

 

The problem can be also solved using Monte-Carlo approach - using some good random number generator generate N points over the capsule (Note: that they need to be uniformly distributed over its surface - this is also a challenge, especially for capsule!), and use these points to calculate diffuse light.

 

  • Calculate specular light

We can't really take approach of monte carlo here (actually we can, but N would really need to be large number - and thus it would be slow), because seeing specular of 16 point lights instead of reflected capsule wouldn't look really convincing (using 10000 on the other hand, for good sized capsule, would look convincing though - but that is insane approach for realtime graphics).

 

We can do better, all we need is to derive ray-capsule intersection test (actually we're fine with ray-sphere and ray-cylinder tests - as every capsule can be composed of these ... Note: we could also use these 3 to simplify integration inprevious step). For each shading pixel we generate reflection vector and test that one against capsule (which is reflected (aka specular) light).

 

Now this will work for non-rough surfaces (wet surfaces), for rough surfaces we could use this approach - we generate reflected ray and compute minimal distance between capsule and reflected ray (note, it can be simplified to minimal distance between 2 lines), based upon this distance and radius of our light we can create quite good looking smooth specular (that won't "sparkle", compared to direct ray-capsule intersection).


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:

https://code.google.com/p/understanding-the-efficiency-of-ray-traversal-on-gpus/

 

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:

https://github.com/marekvinkler/NTrace

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").


PARTNERS