Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.

Don't forget to read Tuesday's email newsletter for your chance to win a free copy of Construct 2!

Vilem Otte

Member Since 11 May 2006
Offline Last Active Today, 12:15 PM

#5192613 Good C (not C++) math library?

Posted by Vilem Otte on 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).

#5190071 Tube AreaLight - Falloff problem

Posted by Vilem Otte on 29 October 2014 - 08:34 PM



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

#5161607 float or double depth buffer?

Posted by Vilem Otte on 19 June 2014 - 07:19 PM

OK, I've tried the different versions (lowest time - no triangle on screen, highest time - closeup view, triangles all over the screen):

tie50.exe -> from 22ms to 44ms

tie51.exe -> from 19ms to 31ms

tie53.exe -> from 22ms to 43ms
tie53.exe -> from 19ms to 38ms

#5161178 float or double depth buffer?

Posted by Vilem Otte on 17 June 2014 - 05:58 PM

I've tried it - I can confirm that no malware or old school virus has been installed (or it overcame my AV here). Regarding speed, I got 22ms to 44ms on Haswell-based Core i3 (in laptop). So it was quite fast...


What was visible though, your depth test isn't precise, the parts on hull flickered, dunno why (maybe it was just on my machine, or it's just setup of projection matrix that has intentionally set up near and far plane to test the precision).

#5160806 Build a render farm using DirectX and radiosity?

Posted by Vilem Otte on 16 June 2014 - 03:44 AM

On Windows you don't physically need a monitor hooked up, but in order to use D3D the video card needs to be set up as a display device with a compatible WDDM display driver. The same goes for CUDA, and I would assume OpenGL/OpenCL (I don't have experience with those so I can't tell you for sure).


Actually with OpenCL, the situation is a little bit more "complicated". You can use different device types to execute your OpenCL kernels - as for now, there are 3 supported:

CL_DEVICE_TYPE_CPU - OpenCL will use host processor for computation. This option works fine in terminal without starting X (in linux), although you would need CPU-based renderfarm for this (of course with enough CPUs with lots of cores you can beat GPUs) - but it will most likely be more expensive.

CL_DEVICE_TYPE_GPU - OpenCL will use GPU device to perform the computations. Each vendor implemennts his own OpenCL driver differently:

  • AMD implementation allows running OpenCL applications without running actual xserver (I think you need root privileges to run the app like that - but the last time I tried this was like year ago, things might have changed since then - back then the feature was called "console mode" in clinfo ... since Catalyst 13.4 as far as I remember)
  • NVidia, I haven't digged into this one. I know it is possible for CUDA, so I bet you can do the same with their OpenCL.

CL_DEVICE_TYPE_ACCELERATOR - Special OpenCL accelerators (IBM CELL Blade or Xeon Phi), I would like to get my hands on Xeon Phi and try it out. But well, it's very expensive and also hard to get (I mean like compare it to any current GPU in terms of "what you get for your money")

#5160715 Build a render farm using DirectX and radiosity?

Posted by Vilem Otte on 15 June 2014 - 04:36 PM

Uhm... just to clarify - MJP most likely used ray traced radiosity (thats why Optix). I believe there are implementations of fast rasterizers for CUDA too (and also for OpenCL - if you prefer it) - in case you wouldn't like to use D3D in the end.


The thing is, if you'd go with CUDA/OpenCL instead of D3D (or alternative) - you will most likely end with better system (allowing you to do more ... with OpenCL you will have even more advantages, like you could run it on various systems) ... unless you dive into compute shaders (but still I'd recommend going with CUDA/OpenCL if that is the case).



but it's difficult to find CUDA guys here.

I have to disagree with this ... ph34r.png

#5153516 Graphics baseline for a good-looking PC game?

Posted by Vilem Otte on 14 May 2014 - 03:10 AM

Technically taken, it is possible to use tessellation along with F.e. QDM or POM or relief mapping (anyone actually tried it? If so, could you share a screenshot?) ... but once you can tessellate to the level where your triangles are at size of pixel (which isn't a problem on modern GPUs), why would you need & want to do some offset mapping - it won't help the model to look better at that point.

#5130820 how alive is oop?

Posted by Vilem Otte on 12 February 2014 - 09:17 AM

I thought of posting the "Still alive" song here, but the people could down vote me. Anyways it is very popular, although multi paradigm is getting even more popular (especially with C++ (since C++11) and C# (there are of course others - like named Scala).


I always stand on the side - use those weapons that fits the enemy -> e.g. use OOP on the place, where OOP is strong. OOP is weak in some areas too, so why not use Functional, Procedural, or any other that fits this problem ~ e.g. don't try to force OOP on places where it doesn't fit well.

#5128088 How to building sah bvh ?

Posted by Vilem Otte on 01 February 2014 - 09:42 PM

I think he already replied you with that information...


From what I know, Lauterbach's LBVH construction was implemented on GPU and shown some good results (although compared to F.e. split-bvh they were a lot worse), there is also hierarchical LBVH - aka HLBVH, that was also built on GPU and this one yields better results than standard LBVH.


Google some HLBVH papers, there are more of them.wink.png

#5126488 Getting started with procedural game engine programming

Posted by Vilem Otte on 26 January 2014 - 07:31 AM

I will just note, that DirectX has still few advantages over OpenGL in terms of development:

- It has much more features (OpenGL basically equals Direct3D, but you have also DirectCompute, DirectSound, etc. etc. in there), of course you can use other open-sourced portable libraries in place of Direct* ones

- There are "no vendor wars" in DirectX, for example we all had to wait years before AMD (ATi) implemented framebuffers in their OpenGL drivers; it is not as bad as it was,but still, compared to Direct3D it is bad;

- All in all, people won't care whether you used DirectX or OpenGL (+ other libraries), they will care only about the results ... honestly - if you want to learn, I'd suggest trying out both


Of course OpenGL also has some (portability is one of its strengths, extensions can be counted both - an advantage (features are in there when they are released), and disadvantage (vendor wars), and of course there are more)


Just an edit - I will also join the people suggesting Game Engine Architecture by Jason Gregory, it's awesome book.

#5115509 Creating an Open World game

Posted by Vilem Otte on 08 December 2013 - 07:04 PM

Arguing about lines is useless. With good application design you can greatly reduce the number of written lines (even in terms of magnitudes). For some parts you can also try a new, different, approach, reducing the number of the lines even further.


A simple linux application 'tree' has around 90 KiB of code (around 3.5k lines I think, but thats just a guess), written in C. You can do the same application in Haskell on less than 400 lines, my version (simplified) has around 12 KiB (with tons of comments) ... there are even shorter. So yeah, by changing approach to the problem, you can reduce code written (and if you know what you're doing, you can also reduce time spent coding/thinking how to code it).


It is the same with good application design, if you cleverly separate your program to parts (even making some parts of it modular), you can save a ton of time ... although this means that you need to think forward.




First of all, why do the AAA games have so many people working on them? The answer is simple, most of it is art. Creating good art takes really a lot of time, and for large open worlds you need a TON of art, and what is more important, it needs to look consistent in different parts of world (so basically small team of people is better than huge team here). The less artists in the team, the higher art consistency is. I don't know about 2 painters producing exactly same mood with the picture - this applies for games too. Although less artists = more time to get art done.




Open world games are doable in small teams, especially if know how to use tools. Generating terrain and nature is not really hard, filling the world with animals and enemies can be automated, but filling the world with story and interesting stuff can't (just not yet, procedural quests are still the worst one out there). This is where you will need the help of others, or your world will either look empty, or it will eat huge amount of your time.

#5114430 Scene Graphs and Lights

Posted by Vilem Otte on 04 December 2013 - 05:53 PM

I second what Hodgman said.


I'll also add, that we have a BVH (Bounding Volume Hierarchy) for lights. Their bounding volumes represent area that light affects (e.g. for point light we have a sphere, for spot light it is a cone, and similarly for area lights (as we do support them in our tech)).

Now, first we can quickly tell whether we have to compute with given light (e.g. whether it affects any pixel in given view frustum), second we can quickly tell which lights affect each given object.


The objects we need to test are taken from another BVH, that contains scene objects (we actually split objects in static and dynamic ones - because for static objects you don't need to rebuild the hierarchy, for dynamics you need to either rebuild, or sometimes just refit).


So basically we're working with multiple "scene graphs" in our tech (BVH is actually an implementation that can be used as scene graph). To explain a little bit about BVH (unless you know what it's all about) - check http://en.wikipedia.org/wiki/Bounding_volume_hierarchy


Technically you could also use some spatial hierarchy for this - KD-trees or Octrees for example.

#5103390 Gameplay vs. programming abilities

Posted by Vilem Otte on 22 October 2013 - 08:33 AM

Game development is similar to generic software development. All parts of the whole software must have decent quality to be good software. For example, very good software with terrible GUI will be always less used then good software with good GUI.


Apply this to games - you need good software, good art, good interface, good music, etc. - being terrible in one case means that game will be considered worse.

#5100098 Performance optimization SSE vector dot/normalize

Posted by Vilem Otte on 10 October 2013 - 01:59 AM

MSVC is horribly bad with vectorized code, even 2012 isn't as good as F.e. GCC or ICC are. Sadly as you are forced to MSVC 2008 you can either use inline assembly, or just live with horribly bad vectorized code.

#5096816 Most Widely Used Programming Language (for games)

Posted by Vilem Otte on 25 September 2013 - 05:59 PM

Write in C - because it is just so awesome and simple. Also there are other reasons that Torvalds would tell you - here is a link for fun - http://harmful.cat-v.org/software/c++/linus


I personally hate virtual machines and interpreted languages, so for me - everything that is not interpreted is fine.