Promit

Retina support is not required to launch an app.

The Battlefield slides on DX11 discuss DirectCompute a fair bit, since they actually do their major shading in compute.

http://www.slideshare.net/DICEStudio/directx-11-rendering-in-battlefield-3

CUDA is used massively in a lot of industries for high speed computing, but I don't think it ever got much traction in games. OpenCL may have, but I think it'll probably be relegated to high speed computing. OpenGL Compute (new in 4.3) is a much more reasonable choice for games.

There are much less extreme options to try before doing what's suggested above. The key is to fit the shadow frustum as close as possible to the view frustum and shadow casters onto that frustum. Get your Z depth as tight as you can, boost the shadow precision if you can, make the shadow area smaller if you can. Try centering the shadow in front of the camera. Explore Z precision tricks like reversed depth planes.

 

That said, I haven't tested screen-space soft shadows yet but this might be an intrinsic part of blurring in what is basically the wrong domain.

 

Depends entirely on what you're doing.

 

Is it a point light or directional? Either way there's multi sampling the shadow map is going to improve it, but is going to take up much the same performance hit as just increasing shadow maps size. There's also temporal anti aliasing. The idea being you slightly shift the projection of the shadow map each frame, keeping the last frames results to combine with the new ones. It's basically multi sampling over time, but has issues with moving objects.

 

If it's just a directional shadow, say from the sun, then things get a bit easier. Cascaded shadow maps use multiple shadow maps projected towards the sun, in a neat kind of shadow LOD trick. http://developer.download.nvidia.com/SDK/10.5/opengl/src/cascaded_shadow_maps/doc/cascaded_shadow_maps.pdf There's also a much more advanced version of this this that I have bookmarked somewhere, and I can't remember the name of. Regardless it advances on cascaded shadow maps to the point where you can get results that are basically alias free.

 

Anyway, hope that helps.

SDSM?

http://visual-computing.intel-research.net/art/publications/sdsm/

 

PS Holy shit this text editor we've got nowadays is a piece of trash

Often, the unique ID lets you backtrace where something came from. You can tag it into commands being sent into the render or physics systems and use it to track misbehaving values inside that code. You can even display it on screen as a "what am I currently looking at?" marker, which is useful when you can SEE something going haywire but don't know where it came from or what it's linked to.

 

In terms of "needs", it depends. It's common to use unique IDs to manage message dispatching in message-based systems, for example. Or to separate physical pointers from the entity data, which can also be handy when reloading on the fly.

Well written GL is probably slower than well written D3D 11 code. (Source) But there are a lot of intersecting factors at play, and optimizing your GL code might yield bigger speedups than a D3D rewrite in the same amount of time. Stuff like using your buffers properly, batching,  vertex arrays, uniform buffers, texture formats, avoiding slow path GL stuff, etc. There are also driver headaches, but no sense worrying about those unless Intel is really big for you and in that case testing is the correct approach.

What's the computation for the X and Y parameters that BRDF Explorer uses for aniso distributions? Are they tangent/bitangent vectors?

Note that GL automatically sets w to 1 when it's unspecified. You don't have to do anything.

After fixing the above and also changing my formula for converting specular power to the anisotropy values, here are better results of Ashikhmin-Shirley.

 

Ash2.png

Ash3.png

Ash0.png

 

 

L. Spiro

The new highlights are much better 

If you are interested in a good overview of the semi-standard lighting models, take a look in the Lighting section of Programming Vertex, Geometry, and Pixel shaders.  Jack wrote a good, in-depth discussion of each of them individually, and the shader code should be at least a good starting point for your work (assuming HLSL of course...).

 

P.S.: My preference is: all of them!  Make your material system flexible enough to swap them in and out with data definitions!

Naturally -- this isn't an engineering thread. I'm just a bit tired of seeing the same four or so BRDFs over and over again and I was hoping for a wider view of the subject.

 

L.Spiro -- it looks interesting and I like a couple things about it. Something about the look of the brighter specular areas really goes down poorly with me though. I'm not sure it's the BRDF though; the highlights are very blown and I'm wondering if maybe I'm just not happy with the choice of tonemap in those shots. The roof of the orange car looks very odd to me, and the specular on the blue one is awfully wide. 

For me, a Mesh is essentially a VAO, plus some parameters for topology (triangle lists, strips etc) and offsets. It's composed from vertex buffers, an index buffer, and a "vertex declaration" (D3D9 terminology) slash "input layout" (D3D10+ terminology). It's essentially an array of the data that you wind up passing as VertexAttribPointer. Tends to look like this:

 

struct VertexElement{
    unsigned int Index;
    int Size;
    int Type;
    unsigned int Stride;
    unsigned int Offset;
    class GraphicsBuffer* Buffer;
    unsigned int Divisor;
};

 VertexElement ve[] = {
        { VE_Position, 3, GL_FLOAT, sizeof(SimpleVertex), offsetof(SimpleVertex, position), rawVb },
        { VE_TexCoord, 2, GL_FLOAT, sizeof(SimpleVertex), offsetof(SimpleVertex, texcoord), rawVb },
        { VE_Diffuse, 4, GL_FLOAT, sizeof(SimpleVertex), offsetof(SimpleVertex, color), rawVb },
    };
 

That plus an index buffer is enough information to recompose the relevant GL calls to create a VAO. Each of these things gets paired with a material and a few other things (bounding volumes for example) and away we go.

I'm just curious what everyone's using nowadays, or what you'd like to investigate looking forward. I guess Normalized Blinn Phong is the easy starter choice, and Cook-Torrance is a popular model amongst the more expensive ones. But I'm wondering what else is out there and what the advantages and disadvantages of those models are.

 

Also, what BRDF do you want to use that is currently near feasible? What would you choose if your min spec was 3x SLI GTX Titans? ;)

I find myself in the nasty situation that my game tools need to support Mac OSX and I can't demand Windows only. The good news is that I don't have to port any tools -- this is a ground up write that can take both platforms into account ahead of time. I'm free to choose any language I like, but an attempt with Python and wxWidgets convinced me that it wasn't a path I want to follow. Right now I would very much like to use C# for all my tool stuff and just build it in a way that works well across Windows, OSX, and potentially Linux.

 

I already know that Mono's runtime works well enough for my purposes, so I'm not concerned about that. I'm also not concerned with rendering. The big question is what to do about the UI library. I want to build fairly complex interfaces, and I only want to do it once. That tends to suggest either WinForms or Gtk#, but I don't know how well WinForms works on OSX or how well Gtk# works in general. I'm hoping one of you has "in the trenches" experience on doing cross platform C# interfaces and some recommendations about how to do this.

There's no reason to constantly create and delete. For that matter, the only thing GenTextures does is to return an unused index. You can use it or not, but after you've got a valid texture name you can just BindTexture it and TexSubImage2D to it every frame. See this for more info:

http://www.opengl.org/wiki/Common_Mistakes#Updating_a_texture

But to sum up:

1) GenTextures once

2) TexImage2D once

3) BindTexture and TexSubImage2D every frame

I like the stories here, keep em coming. I guess I ought to contribute mine at some point but for the time being I've pinned the topic

Most of you would do well to listen carefully to swiftcoder, as the debugger issue is a bit more complex and subtle than it seems at first glance. Indeed, I would suggest a handful of necessary but not sufficient criteria for a competent software engineer:
* Able to effectively debug problems in a debugger.
* Able to effectively debug problems without a debugger, but with other runtime tools. Very common in games, kernels, distributed systems, high performance or GPU computing.
* Able to effectively debug problems without ANY runtime tools. This one is hard, as it rules out printf, visualization, etc.

There are competing aspects of competence here. You have a large variety of tools at your disposal as a programmer, in fact an extraordinary amount compared to most other disciplines. It is important to be able to work your way around all of these tools at various levels. I hate doing the vi/gcc thing for example, but I can and occasionally need to. The counter point is that there are an awful lot of situations where, for whatever reason, your tools are highly ineffective.

Why do production games now have major custom debugging suites in games and toolchain? Debuggers are one tool that serve a particular purpose. Sometimes this purpose is inappropriate, as in the case of tracking how values evolve over time. Sometimes the tool itself is non-functional; I work with a robot system that expects its host to maintain a certain response time, which means that a debugger will crash it if I try to pause the host software. There are a large and exciting variety of situations in which debuggers will generate no results or worse still, deceving/confusing/blatantly wrong information. There's also my favorite: attaching a debugger fixes the problem. This is very common with multithreading heisenbugs.

It's critical that you are able to use all of your tools, including but not limited to debuggers. It's also critical that you're able to use your brain, as many problems are fixed much more quickly by reasoning critically about the nature of the issue, or applying other techniques such as binary search through a revision history in the case of regressions. Being multitalented and adaptable is key.