Oxide Games released the slides of their GDC presentations :

http://oxidegames.com/2016/03/19/object-space-lighting-following-film-rendering-2-decades-later-in-real-time/

As far as I understand OSL is moving all the lighting pass) into texture space. For all objects in the scene a shaded texture is produced using a world space normal and position texture and then the normal rasterization pass occur.

There are several benefits : first MSAA is quite straightforward, from raster point of view it's just a forward pass. Of course deferred shading can occur in texture but with correct mipmap selection it can be made barely noticeable.

A second benefit is that shading doesn't even need to be recomputed every frame and is a good candidate for async compute. Shading doesn't change a lot in texture space even if a unit is moving.

On the other hand there are several points that I didn't find addressed in the slide : Since no object can share a shaded texture I guess memory consumption must be high. The provided benchmark numbers show Fury X beating a 980 ti with a not so small margin, I'm guessing this is not only due to async usage but also due to high memory bandwidth pressure.

Another point is the authoring tool : every object must have "well flattened" textures. Flattening texture is generally difficult and often requires manual tweaking.

What do you think ?

I went over the presentation yesterday, and it's fascinating. I'm all in favor of exploring alternative approaches to shading, and this is definitely a very different set of trade-offs. That said, I don't get the comparisons to REYES and overall it seems like a very special purpose, application-specific approach to rendering. They spend a good amount of time talking about fixing it to work for terrain, after all. What on earth would happen to it if you gave it general purpose world geometry, like you'd see in a Battlefield game? And as you correctly mentioned, it's terribly sensitive to the structure of texture space for the models you feed it.

I simply can't see it as a basis for a general purpose rendering pipeline.

This stuff was popular in realtime skin shading, after the Matrix 2 published a technique based on it in 2003 Most people stopped using it pretty quickly though.
Since then, I've always wanted to try a general purpose implementation of it like this. Although, I was going to do a hybrid, where only some calculations were done in object space, and others would still be done during rasterization.

Great to see someone's actually done it!

Back on the Wii, we couldn't afford to do per pixel shading either, especially not with large number of dynamic lights, so we actually did a hybrid of this - a kind of light-pre-pass object-space shading, in view-space For each object, we'd render it's lighting into a small (32px IIRC) texture, so that during rasterization it could combine the lighting and material data very quickly, and independently of the number of lights. That hid some of the artefacts because even though the lighting was low resolution, the materials were not.

I don't get the comparisons to REYES

They spend a good amount of time talking about fixing it to work for terrain, after all. What on earth would happen to it if you gave it general purpose world geometry, like you'd see in a Battlefield game?

REYES tessellates, shades, tessellates some more, fine-culls and then samples/filters -- i.e. it does shading before it does triangle rasterization. I think that's the only inspiration they've taken from it.
For arbitrary geo, they'd have to use the indirection technique on everything. FWIW, some film renderers already solve this with with tech like ptex, and it in particular has been implemented in realtime too. It would actually be nice to see something like this...

e.g. Megatexturing first showed up as a specialized terrain texturing technique, but then quickly moved to a texture-all-the-things general purpose technique.

Since no object can share a shaded texture I guess memory consumption must be high.
Another point is the authoring tool : every object must have "well flattened" textures. Flattening texture is generally difficult and often requires manual tweaking.

Yeah - they mention using "several" 4k 16bpp lighting sheets, which comes to 128MiB each (plus mips!).
They also mention that "our implementation requires artists to chart their models" and that they were already doing this anyway, but yeah, they probably had to do extra tweaking of those UV coordinates to work out some kinks per model... Combining this with a great automatic charting tool would be nice (e.g. ptex above doesn't require explicit UV coords), but would probably require a better texture filter to deal with the increase in seams.

And yeah - Great for VR (shade every 3rd/4th frame) and great for 4k monitors (allow weaker GPU's to shade at lower resolution but keep high res rasterization).

That said, I don't get the comparisons to REYES and overall it seems like a very special purpose, application-specific approach to rendering

Yeah, I agree that the frequent mentioning of REYES is misleading. The only real commonality with REYES is the idea of not shading per-pixel, and even in that regard REYES has a very different approach (dicing into micropolygons followed by stochastic rasterization).

I also agree that it's pretty well-tailored to their specific style of game, and the general requirements of that genre (big terrain, small meshes, almost no overdraw). I would image that to adopt something similar for more general scenes you would need to a much much better job of allocating appropriately-sized tiles, and you would need to account for occlusion. I could see maybe going down the megatexture approach of rasterizing out tile ID's, and then analyzing that on the CPU or GPU to allocate memory for tiles. However this implies latency, unless you do it all on the GPU and rasterize your scene twice. Doing it all on the GPU would rule out any form of tiled resources/sparse textures, since you can't update page tables from the GPU.

ptex would be nice for avoiding UV issues (it would also be nice for any kind of arbitrary-rate surface calculations, such as pre-computed lightmaps or real-time GI), but it's currently a PITA to use on the GPU (you need borders for HW filtering, and you need quad->page mappings and lookups).

I didn't get any of this. So they have a ton of 4K x 4K textures. What is in those textures? A bunch of pre-computed light maps?

They compute the screen space size of an object.

Somehow this reserves some space in a 4k x 4k texture.

What is in the texture.

What comes of the texture? Is the object re-drawn using it's normal vertex data and applying the portion of the 4k texture on it?

Or does the 4k texture hold something else that is used is some other way?

They compute the screen space size of an object.

Somehow this reserves some space in a 4k x 4k texture.

What is in the texture.

What comes of the texture? Is the object re-drawn using it's normal vertex data and applying the portion of the 4k texture on it?

Or does the 4k texture hold something else that is used is some other way?

The object is only draw once.

What happens is that they allocate some space in the 4kx4k texture given object screen space (but without drawing it).

Then a compute shader fills this space.

Then the object is draw on screen for real. The space is passed as a texture to the fragment shader (which is very simple ie "gl_FragColor = texture(tex0, uv);" ).

What happens is that the compute shader renders shaded color in the suballocated space instead of doing it in the fragment shader. In this case it does all the lighting computation using normal and diffuse color textures. Since there is no vertex data the position information are passed via a precomputed "position" texture too (which means this technic makes deformable mesh quite unpracticable).

That's what I thought it was, but I didn't get the benefit. Because you cant run pixel shaders on several 4K textures every frame. You could choose to not update certain things but, but anything moving/rotating has to be updated. And specular won't work if the camera is moving.