13+ years of experience. Prefer roles where I can work as an Individual Contributor, complex non UI work, using static typed languages (ask me why).
Coming off a Principal Engineer job at a startup where I built the core of their Android, iOS and Backend. Also designed and built Bluetooth LE based (nRF51) & USB based (Atmel SAMD21) IR devices to help control your devices, and HAL for Android TV platform prototypes.
FXAA and other similar techniques are only relevant when dealing with deferred rendering only. Detecting edges on the depth buffer may sound as the solution until you realize that two planes at right angles has an edge between that can alias. The change there is in the normal and not the Z.
Also modern graphics cards do not give programmatic access to the z-buffer as the z-buffer format is often proprietary. Deferred shading based renderers often duplicate the z-value also into a texture.
Deferred rendering can render large number of dynamic, unshadowed lights very efficiently. It can be used as approximate global illumination technique.
> FXAA and other similar techniques are only relevant when dealing with deferred rendering only.
Why is that? While techniques like FXAA are needed for deferred rendering due to the order of operations, I don't see why FXAA isn't acceptable on non-deferred renderers.
> Detecting edges on the depth buffer may sound as the solution until you realize that two planes at right angles has an edge between that can alias. The change there is in the normal and not the Z.
If you have two planes at a right angle to each other, you'd see that in the depth buffer. Imagine you're looking at a line of pixels and you're doing this on each pixel -- you'd look to see if the pixels on either side of the one you're on are trending in opposite directions from the current one, and know it's an edge.
> Also modern graphics cards do not give programmatic access to the z-buffer as the z-buffer format is often proprietary.
As far as I'm aware, all modern graphics cards allow you to render the depth buffer to texture just like the color buffer.
> Deferred rendering can render large number of dynamic, unshadowed lights very efficiently. It can be used as approximate global illumination technique.
Sure, but there's no reason you can't do post-AA using the RTT depth buffer and your composited color buffer.
> Why is that? While techniques like FXAA are needed for deferred rendering due to the order of operations, I don't see why FXAA isn't acceptable on non-deferred renderers.
FXAA is acceptable for the other techniques as well. However, MSAA is, in my opinion, a better technique as it uses supersampling at the edges and is already hardware assisted. FXAA's strength is that it is less expensive than MSAA memory and bandwidth wise. Both are a premium in deferred shading as you are using a 4x RBGA16 texture render target or something close to it :)
> If you have two planes at a right angle to each other, you'd see that in the depth buffer. Imagine you're looking at a line of pixels and you're doing this on each pixel -- you'd look to see if the pixels on either side of the one you're on are trending in opposite directions from the current one, and know it's an edge.
The question is can you get reliable edge detection with less number of texture look-ups on the z-buffer versus the RBG based edge detection?
> As far as I'm aware, all modern graphics cards allow you to render the depth buffer to texture just like the color buffer.
Not quite. You can render the z value to a texture, but that is done in the pixelshader and do not touch the hardware z-buffer used for z-fail/z-pass tests. It is this hardware z-buffer that is inaccessible, as it shares it memory with the stencil buffer which is used for stencil tests. Hence the proprietary format.
> Sure, but there's no reason you can't do post-AA using the RTT depth buffer and your composited color buffer.
> All render target surfaces used together must have the same bit depth but can be of different formats, unless the D3DPMISCCAPS_MRTINDEPENDENTBITDEPTHS cap is set.
As you can see, the bit depth restriction means that you would end up with 2x bandwidth usage with the z based edge detector, especially on the older hardware where you do not have the bandwidth to spare. It would be a different case if you can sample the hardware z-buffer.
> The question is can you get reliable edge detection with less number of texture look-ups on the z-buffer versus the RBG based edge detection?
The way it's working in my mind has about the same number of lookups as FXAA, but I'm honestly not sure how that'd pan out in practice. We'll see.
> As far as I'm aware, all modern graphics cards allow you to render the depth buffer to texture just like the color buffer.
Not quite. You can render the z value to a texture, but that is done in the pixelshader and do not touch the hardware z-buffer used for z-fail/z-pass tests. It is this hardware z-buffer that is inaccessible, as it shares it memory with the stencil buffer which is used for stencil tests. Hence the proprietary format.
No need for the internal format, though -- raw depth buffers are A-OK.
> As you can see, the bit depth restriction means that you would end up with 2x bandwidth usage with the z based edge detector, especially on the older hardware where you do not have the bandwidth to spare. It would be a different case if you can sample the hardware z-buffer.
One thing to keep in mind is that yes, you're rendering it to texture and you incur some overhead there, but you don't have to pull that data back to the CPU so you're dependent on bandwidth between the GPU and its memory, not main memory. Sure, it's double the memory used there, but that's negligible from a bandwidth perspective. Also a good thing to note that you generally already have your depth buffer if you're doing deferred rendering, and you can do all the AA based on that, in theory.
> he way it's working in my mind has about the same number of lookups as FXAA,
However, the FXAA will have a clear win as it works over a partly transparent polygon. So you will have to combine both an RBG and z based to get the same result as an FXAA.
> you're dependent on bandwidth between the GPU and its memory, not main memory.
The bandwidth I was talking about was the older cards which do not have bandwidth or fill rate to keep 60fps with deferred shading, no AA. FXAA would be a candidate there if it is a pure RGB technique on the composited frame, especially as it is cheaper than MSAA.
> Not quite. You can render the z value to a texture, but that is done in the pixelshader and do not touch the hardware z-buffer used for z-fail/z-pass tests. It is this hardware z-buffer that is inaccessible, as it shares it memory with the stencil buffer which is used for stencil tests. Hence the proprietary format.
This was true for Direct3D 9 but 10+ allow you to bind the depth/stencil buffer as a texture, although there is the caveat that you can't have it simultaneously bound as a texture and as a render target.
> This was true for Direct3D 9 but 10+ allow you to bind the depth/stencil buffer as a texture, although there is the caveat that you can't have it simultaneously bound as a texture and as a render target.
Missed that one as I have been mostly playing around in DX9 and only a bit of DX10.
There is the case of the billboarded or partly transparent texture. The z-based edge methods will not work in these cases as you render them with z-write off. Meaning, atleast in those cases, FXAA is a clear winner over both MSAA and z-based edge detection.
>> FXAA and other similar techniques are only relevant when dealing with deferred rendering only. Detecting edges on the depth buffer may sound as the solution until you realize that two planes at right angles has an edge between that can alias. The change there is in the normal and not the Z.
Why do you say that FXAA is only relevant to deferred rendering?
If you have a deferred rendering setup, you'll have the depth buffer and the normal buffer (a floating point texture with normal vectors) available. These can be used to do edge detection for silhouette edges and non-silhouette sharp edges.
I don't know the details of modern anti aliasing techniques, but I'd guess that you can get the best edge detection using a combination of the color, depth and normal buffer. Whether you want to do this for anti aliasing is a different issue, a simple RGB edge detect may yield better results.
>> Also modern graphics cards do not give programmatic access to the z-buffer as the z-buffer format is often proprietary. Deferred shading based renderers often duplicate the z-value also into a texture.
This doesn't make any sense. The depth buffer may be internally stored in a compressed proprietary format, but it's still available to the programmer as a regular buffer or texture.
You have plenty of ways to access the depth buffer for reading. The depth buffer can be rendered into a texture (either as floating point or regular 24 bit integer), which can be read back in a shader. You can do regular lookups where you get back the depth value or a shadow lookup with percentage closer filtering.
The depth values can also be read back from the buffers (using glReadPixels in OpenGL) to be analyzed on the CPU (not feasible for anything realtime) or saved to disk or whatever.
When doing cel-shading you usually render a pass that stores the depth and normal values of each pixel into a texture. Thus you have your own z-buffer and access to the normals.
If either the difference of the normal or the z-value is over a certain threshold you add some black color to the pixel to make the edge look thicker.
Can you give some more details on the language/libraries that you are using? I am just getting started on a 6DOF game...
I am planning to use C++ to code up the engine. So the easiest option is to use Boost.statechart to implement a Hierarchical Finite State machine based AI. I can always switch to a hand coded state machine later on if the performance of boost is not good. See an old article on Halo 2 AI: http://www.gamasutra.com/gdc2005/features/20050311/isla_01.s...
Havok Behaviour seems to be a game middleware covering the same area. So it might be an option if you are targeting PC (See licensing details of the same) even if it is not open source. I am not considering it as most of the features of it seem to be targeting the FPS game type which is a bad fit for a 6DOF game.
Apart from the high level AI functionality that can be implemented using Boost.Statechart, there is also the need for good pathing. For a 6DOF game reduces to a problem of generating non intersecting B-Splines a between source and target. Space is mostly empty ;) This is relatively simpler compared to the pathing algorithm needed for an FPS. Off the top of my head, I would use something like Boost Graph library to do an A* search on a Nav nodes as the simplest solution for an FPS game. You should be able to provide various heuristics using multiple vistors to customize the A* searches. Another option is to use a dedicated pathing library like Path Engine ( http://www.pathengine.com/ ) or Havok AI ( http://havok.com ). Unfortunately both are paid libraries. A Nav Mesh based pathing provided by Path engine or Havok AI will be much better than the Nav Node system, but with adequate coding and good level design, it should not too different from a nav node system. Eg: Left 4 Dead 1 & 2 seem to be using a Nav Mesh based system versus Alien swarm which seem to use a Nav Nodes based system for pathing.
Planning of AI is a hard problem without having the constraint of being real time. I would instead use strategically placed volume triggers (Ghost/Phantom object of your physics library) to customize the AI NPC behaviour (triggering AI HFSM transitions) or to trigger a preset sequence of scripted actions (Cinematics, sort of). Combine that with a decent nav nodes system and some randomness, we get sufficiantly 'intelligent' behaviour. This, however, becomes a data heavy approach to game level design. A full planning engine becomes a code heavy approach. The trick seem to be to strike a balance between the two :D
Remote: No
Willing to Relocate: Toronto Preferred (will need work permit), otherwise depends.
Technologies: C/C++/C#, Obj-C, Java, Swift, Android, iOS, Python, Django, Embedded (mbedOS), AOSP HAL, others as needed
Resume: https://www.linkedin.com/in/hormis/
Email: hormis.t2512 AT gmail
13+ years of experience. Prefer roles where I can work as an Individual Contributor, complex non UI work, using static typed languages (ask me why).
Coming off a Principal Engineer job at a startup where I built the core of their Android, iOS and Backend. Also designed and built Bluetooth LE based (nRF51) & USB based (Atmel SAMD21) IR devices to help control your devices, and HAL for Android TV platform prototypes.