InvalidPointer

The syntax of C++ is very, very similar to C#, I'd say you have bigger problems if that's an issue. On the brighter side, SlimDX was architectured to follow the design of unmanaged D3D very closely. While there are some subtle changes and more idiomatic code, if you can understand how device state is manipulated in either API you'll at least have an idea of where to start with the other.

Most of the more interesting bits, like shader code, work fundamentally the same way in either since it's a separate language altogether. The theory and mathematics behind common techniques are also going to be the same.

I'm only posting out of curiosity but isn't the title of the topic a bit bold? I had no idea forward rendering was even dead, I understand deferred shading can be of great advantage, but even in some of the best deferred systems forward rendering can still be of great use. Hybrids aside forward rendering when mixed with a pre-z-pass (read and to a tiny degree tested) is a viable alternative and offers many great advantages, ranging from memory and bandwidth saving, to diversity of shaders.

Deferred shading is just really, really in vogue right now and it ends up being one of those hobbyist engine bullet points. Plenty of modern games (Skyrim, MW3, Mass Effect 3 and basically any UE3 game for that matter) use forward shading, some to very great effect.

I have a question about grapics like in RuneScape. Just useing RuneScape as a example.
1.) How does RuneScame build the map. is it all code, or a Map Editor?
2.) are the grapics set in sprites?, if so were do you find them.

The runtime/'game' bits are all code, i.e. any of the stuff that tries to draw or pull data from the map. It has to get executed somehow! That said, Jagex also has a dedicated team of environment artists that use a level editing tool to arrange and manipulate parts of the word to their artistic whim. This, too, uses code in the sense that it's a computer program that takes user input.

I don't think Runescape uses sprites anywhere outside of particle systems, actually. Old versions (pre-2004) did a Doom-style 2.5D deal for characters and game items, but I think everything's all models now.

As an architectural suggestion, don't design the renderer in such a way that it cares. As far as it's concerned, it just takes black-box textures, meshes, materials, etc. and feeds them to the graphics hardware.

*On top of that* you can implement an atlasing system-- a part of the character logic would be an excellent place to put this.

This way, you get the best of both worlds

Watertight meshes are pretty par for the course, I don't think you'd earn any ire by placing that restriction.

Also, instead of mucking about with actually bouncing some rays around, I would *highly* suggest using some of Jensen's top-notch work on dipole transmittance. It's really good stuff

I'm not sure where you're getting your information from, as swizzles/masking are dirt-cheap to the point of being free. You can also just dink around with some 2D matrix multiplication for your texture coordinates, so the final cost for something like what you describe there is maybe 2-3 ALU operations per texture coordinate matrix multiply and the standard texture read per, well, texture read. For three channels that's like 6-9 ALU and 3 reads, which is hardly expensive in this day and age.

Also, you assume Unreal is dinking around with the actual texture data when it actually isn't.

In terms of mechanics, the material compiler pretty literally concatenates HLSL strings then feeds that into fxc/cgc to get some runnable bytecode. There's a little bit of extra script stuff for parameter exposure, but you seem to be really overthinking this. It isn't magic ;)

Yes, definitely. You can set the exposure value manually if you want-- many games do just this! (CoD:BlOps and possibly MW3 in particular)
EDIT: I'm pretty sure Source/Half-Life 2 lets you goof with exposure as well, though they do have a wonky fake-exposure trick due to their clever-as-hell in-shader tonemapping operation.

Also, HDRBlendable is (I think) the FP10 format. It should render slightly faster since you write half as much (assuming you're fill-bound, which isn't all that uncommon in high-overdraw scenarios with cheap shaders-- much like a light prepass renderer) as a traditional FP16. You can also experiment with fixed-point encoding schemes if you're willing to give up multipass rendering, though I don't think that's actually an option for you.

Part 1: Theoretically, yes, they can run concurrently. The D3D/GL specs are intentionally not too specific about how this works under the hood, just that the end result needs to be deterministic. There *may* be specific hardware implementations that kill or rearrange operations if this happens in practice, but there are no blanket 'this is how it must work' restrictions I am aware of. When in doubt, use atomics.

Part 2: Good question, I think you may be okay. It's entirely possible to do depth-only rendering by not binding any RTVs (just a DSV) and I would think the same would apply here.

What Are You Doing, Really™? GPUs are in general not very well-suited to variable-length data like that. Bad for concurrency.

Also, if you're using a floating-point depth buffer (DXGI_FORMAT_R32F/R16F and friends, assuming D3D10+) you can actually flop the near and far planes (near plane has what you set as far plane distance, and vice versa) and switch the test direction (depth test becomes GREATER_EQUAL instead of LESS_EQUAL, etc.) for some further precision improvements. This will *NOT* work for UNORM-based formats, as it exploits the mechanics of how floating-point numbers are represented-- some unneeded extra precision is shifted away from where the camera is and ends up 'spread out' over the remaining depth range.

Double post, sorry, couldn't justify the edit.

So basically I know that tone-mapping will prevent the possibility of getting the same output as your input, which is my coworker’s reason for skipping the conversion to linear space when setting light colors and material colors.

This is very workable mechanically, but I disagree with the reasoning. sRGB space exists because 8-bit normalized linear representations are not sufficient to represent the human visual range (see Bungie's really cool presentation on the topic) without *very* visible banding. Using a sort of perceptually-optimized logarithmic space (sRGB) allows for extra precision in the darker ends of the spectrum, which are generally more visible to the eye. Once you start using high-precision formats instead (like, say, 32-bit floating point, which coincidentally maps to what most HDR light source data is internally stored as) you have sufficient precision in both the darks and brights that using the logarithmic scale is no longer necessary. Thus, you're really just wasting computations by doing the conversion(s).

And what I want to clear up is whether or not that is a valid line of logic and whether or not it is canceled out by tone-mapping.
That is, does tone-mapping implicitly perform a conversion to (or close to) sRGB while also performing its function of brightening/darkening the screen, thus making my sqrt() an incorrect addition to the pipeline?

What Hodgman said. I know John Hable's ALU-based filmic tonemapper produces results in gamma 2.2 space (NOT the same as sRGB, but close) but the more boring stuff like Reinhard is linear. Considering that tonemapping itself isn't very rigorous in the 'physically-plausible' sense, film simulation aside, you can probably get away with treating the result as either for artistic effect.

The most common monitor colour-spaces are gamma-1.8, gamma-2.2 and sRGB, so any value that's chosen from a monitor is probably in one of these colour-spaces. In a professional studio, you should ensure that all of your artists have monitors that are calibrated to the same colour-space (preferably sRGB).

What's your stance on embedding a color management utility into the editor and using that to convert to sRGB/linear? While I can certainly concede that proper calibration is a Very Good Idea™ and should probably be done anyways, that solution seems vastly more robust.

EDIT: And grab the current monitor calibration for conversion purposes, I mean. I think Windows will let you do this, and the more I talk about it the more I get the urge to try and implement something like this.

I do know how megatextures work, and I tried to caution them against the use of them. And failed the interview as a result. It was literally the turning point of the interview. I was applying to be their next next-gen game-engine programmer and had passed all previous interviews.

With respect to Squeenix, what a phenomenally stupid decision. I personally think MegaTextures are pretty neat (the new Radeons do them in hardware! ) but were I in the interviewer's shoes I'd probably just get into a very heated debate

On-topic: So if I'm understanding this correctly, you're trying to make the actual, on-monitor clear color constant regardless of rendering settings? I'm still a little murky on the end goal here.

As a bit of an addendum, there's no real reason why you can't pick either sRGB or straight linear for any kind of texture-- in fact you can probably get better quality by making this decision at asset cook time by way of a histogram. Look at what values you're storing (this works best if you use a high-precision source format, I prefer 16 bit normalized integer/32-bit floating point per channel depending on the semantic type of the texture in question) and make the final decision based on what fraction of the total pixels sit above some threshold. Crysis 2 does something pretty similar and the results are *very* impressive-- with standard DXT1/DXT5 textures and an additional histogram denormalization you can get very, very good quality even at insane exposures.

Just for funsies:

* What are some shadow-volume algorithms? When would you use shadow-volumes over shadow-maps?

'Shadow volume algorithms' is a bit ambiguous. In terms of shading calculation, I've looked into the bog-standard Crow 1977 paper and Forest's Penumbra Wedges idea, but it's not something I've really investigated much. (see later) In terms of masking you have the standard Z-pass and Z-fail/Carmack's Reverse.

Second part: In practice, never. Shadow maps are superior in pretty much every conceivable way these days. Filtering's better, you get free support for alpha-tested surfaces, you can amortize a lot of the cost over several frames, etc. Translucent surfaces can also receive shadow maps, too, which is something shadow volumes are flat-out incapable of. Point lights are a little more difficult to do, but there exist methods like dual-paraboloid and cube projection that can work pretty effectively.

Lastly, I figured out how F.E.A.R./F.E.A.R. 2 got such nice shadow edge transitions not that long ago. They actually apply a depth bias to the shadow boundary geometry so you don't get that ugly faceting artifact near silhouette edges. It's so unbelievably stupid, it's brilliant. If you must use shadow volumes, give that a whirl.

* What are some ways that you can filter shadow maps? What other techniques can you use to get better results from shadow-mapping?

This could probably be rephrased as 'how *can't* you filter shadow maps, and the answer is 'there aren't any ways'
Percentage-closer filtering is the oldest (I think) and works pretty well for the general case. Variance shadow maps and friends are rather popular these days, though I think exponential variance shadow maps in particular are the flavor of choice. Shadow maps for area lights seem to be pretty in vogue for CG research, and most of them seem to involve microfacet back-projection, though there are some more interesting VSM-like approaches I know of (the rather underutilized interpolation-friendly soft shadow maps seems promising, but I haven't yet got around to implementing it so I can't speak with total authority) Crytek's also experimented with using some sampling noise to get softer shadows for marginal performance cost, and this looks really good if you render the contribution into a God of War-style white buffer and blur it a bit. I won't tell if you won't ;)

Better's also a vague term. If you want to avoid acne, generating the shadow map by way of using backfaces for map generation works fairly well, as does using midpoint shadow maps (though the latter is a lot more expensive and is NOT compatible with all filtering methods, at least not to the extent that backface maps usually are)
Improving effective resolution also has scads of research. You've got perspective shadow maps, trapezoidal shadow maps, the irregular Z-buffer idea, adaptive shadow maps, cascaded shadow maps and the new, very promising adaptive shadow maps by way of rectilinear shadow map warping. That doesn't really even begin to scratch the surface.

* What are some techniques for rendering reflective materials?

Reflective in the sense of 'analytical lights' would mean your standard rogue's gallery of BRDF models. Image-based reflection is a little less broad in scope and is really constrained by the capabilities of your target hardware more than anything. You have your cubemaps, spheremaps, esoteric-projection maps and even some raytracing done in screen space if you want to get really fancy.

* How would you implement DOF on SM3? What about SM5?

Rendering budget would play a larger role in determining the algorithm(s) used rather than shader model, IMHO. Bokeh DOF by way of scads of billboards has been receiving some attention by Epic and friends, inelegant as it may be. While they make use of D3D10+ hardware features, I think you could probably cook up something pretty similar using vertex texture fetch/render to vertex buffer and point sprites on D3D9-equivalent feature levels. Probably wouldn't be as fast due to the rather inexpressive API, though.

If you want cheap and are doing bloom, you can also do things the Unreal Way™ and repurpose your bloom buffer. You don't get out-of-focus bleed, but if your game involves a lot of fast motion the artifacts probably won't be too noticeable. Infinity Ward also details some tricks to work around that problem that mostly involves blurring your circle of confusion, but that's not quite perfect either.

Also, if you want bokeh DOF but don't want to commit performance seppuku DICE details how to do a separable blur with a hexagonal shape. Whoever thought that up needs to get a pay hike; it's brilliant and involves decomposing the shape down into a series of skewed box blurs.

* Give an overview of how skinned meshes are drawn.

Animate bones, collect/weight influences, project to screen(?) This seems a little too easy.

Note that I don't include things like tangent transformation since there are some more modern bump mapping approaches (thinking primarily of Mikkelsen's stuff here) that don't actually need it. You could also use quaternions or even dual quaternions if you want to save some memory/interpolators and preserve volume across deformations, respectively.

* What's the difference between forward and deferred shading schemes?

Forward shading considers lighting as an object-space query, deferred shading opts for a more screen-space approach. There's so much futzing around with G-buffer design I don't consider going into detail about the various data designs useful due to their fluidity. I'm actually working on expanding some of the ideas behind light-indexed deferred rendering to try and get some of the best from both worlds.

* What are some different lighting models, and what's special about them?

Isotropic microfacet BRDFs like Phong/Blinn-Phong consider the surface to have lots of bits pointing every-which-way, and are a good fit for most surfaces.

Anisotropic BRDFs, like the Ashikmin-Shirley and Kajiya-Kay models, are designed to simulate the effects of surfaces where the little bits are instead usually facing along a single direction, and are practical for things like hair or brushed metal.

BSSRDFs are probably the most expressive/expensive, so you don't see them much in games, though there's some new research by d'Eon, Jimenez and Mikkelsen about efficiently implementing them on a GPU. (Blur kernels say hello) Eric Penner's got some really cool stuff that calculates the scattering ahead of time and examines the curvature of the surface to try and fit what you've got to what you precomputed. Hacky, but extremely fast and surprisingly effective.

I consider things like energy conservation to be subtopics of the above three items, and if you aren't paying attention to this, then your graphics programmer license is revoked until you do In short, you'll need to adjust the approximate models like Blinn-Phong so that they reflect the amount of light they receive based on the properties of the surface, (tl; dr BRDF normalization) and for extra credit adjusting the diffuse reflection such that it only accounts for light that was NOT reflected based on the specular component of your shading model.

* What are the pros/cons of performing lighting in tangent space vs view or world space?

Precision reasons and being able to reuse tangent-space normal maps for different objects, though the latter is sort of a non-feature these days. World-space shading can also make handling scads of lights easier as there's less transforming to be done/interpolators that need to be used. Object-space shading (conspicuously absent, I note ) can end up being the best of both worlds, actually. Contrary to popular belief, it can also play nice with skinned meshes.