Jump to content

  • Log In with Google      Sign In   
  • Create Account


Vilem Otte

Member Since 11 May 2006
Online Last Active Today, 02:31 PM

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




#5094171 Recursive Screen-Space Reflections

Posted by Vilem Otte on 15 September 2013 - 02:14 AM

Quite interesting algorithm you used. Although I'm known as an "opponent" of screen space techniques.Basically current-gen GPUs allow you to perform full ray tracing of the scene. I've did several experiments for my renderer, where I take the results of G-Buffer generation into compute shader, where I create a buffer of secondary rays (even multiple ones per pixel - antialiasing,  that should be ray-casted into the scene.

 

The results of ray tracing is later mixed into scene. "Recursive" reflections and refractions are possible too (using multiple passes of this technique). The performance was very good on Radeon HD 6770 (which can be counted as good mainstream card of these days, even though there are newer and faster ones).

 

Now some technical details and hints, if you're going to try:

- The less pixels you render, the faster it goes (this counts for ray tracing in general), as your reflections and refractions are mostly on normal mapped surfaces, you don't need full resolution result, you're fine with half-width, half-height buffer. Also note that unless you look directly into mirror, you should have just bunch of pixels to actually ray trace.

- The quality of your BVH (SBVH seems to be the best one out there, but slow to build) or KD-Tree matters the most. For static part of scenes you should pre-compute it, dynamic parts are either ignored or use separate BVHs (preferably something that is fast to build - LBVH or HLBVH).

- If needed, use simplier, lower-LOD models (especially for dynamic objects - as you will build/refit your BVH for dynamic objects faster).

 

Advantages: You get "correct" reflections and refractions, no jaggies, no "unknown" areas. Takes little time to implement prototype.

Disadvantages: Takes a lot of time to optimize prototype. Is generally slower than incorrect screen space solution with tons of issues.




#5083390 Convert RGBA buffer to ARGB

Posted by Vilem Otte on 05 August 2013 - 05:52 PM

Hm... and if you want it really fast, do SSE versions:

 

SSSE3 version (really dumb and fast):

__m128i shuffler;
void rgba_to_argb(const int* in, int* out)
{
	const __m128i pixel = _mm_load_si128((__m128i*)in);
	const __m128i tmp = _mm_shuffle_epi8(pixel, shuffler);
	_mm_store_si128((__m128i*)out, tmp);
}

Where:


shuffler = _mm_setr_epi8(0x01, 0x02, 0x03, 0x00, 
			0x05, 0x06, 0x07, 0x04, 
			0x09, 0x0a, 0x0b, 0x08, 
			0x0d, 0x0e, 0x0f, 0x0c);

Of course you can upgrade it to support batch processing and thus making it even more effective.

 

Adapting code for lower SSE versions means emulating _mm_shuffle_epi8 instruction (which is possible with little overhead).






PARTNERS