Rastar

Wow, great stuff, congrats!

Very excited that you're considering large-scale terrain for Leadwerks 5, that topic's been an interest of mine for ages. I particularly find the algorithm for "Real-Time Deformable Terrain Rendering with DirectX 11" by Egor Yusov in GPU Pro 3 interesting. They basically observe that terrain at any point on the grid usually only deviates slightly from a value linearly interpolated from its neighbors. They use that to only store the delta from that interpolation and get a data set that can be very efficiently compressed. The terrain is then reconstructed at run time from those delta sets according to the required LOD level. There might be some interesting ideas for you in there (and by now OpenGL also provides the relevant features like texture arrays etc.)

That's cool, have to try them out. I had already started working on some environment probes myself for my PBR experiments, but without accessibility to the editor the workflow is a little cumbersome. Question: Is there/will there be an API to generate the cubemaps at runtime? I know this is time consuming, but for changing outdoor conditions (time of day) it would be nice if the maps could be generated at runtime, like every 10mins or so.

Ooooooh, that's one feature I've been eagerly waiting for Really happy that you're improving the graphics of Leadwerks again. Question: I'd be interested to play around with several tone mapping operators (I guess similar to what the "iris adjustment" does) - will the iris adjustment be a simple post processing effect attachment to the camera (in which case it could be easily replaced)?

Which reminds me: Ages ago I did a couple of blog posts here a bout tessellation http://www.leadwerks.com/werkspace/blog/117/entry-1185-pass-the-tessellation-please-part-1/ http://www.leadwerks.com/werkspace/blog/117/entry-1195-pass-the-tessellation-please-part-2/ Maybe there's something helpful in there as well.

Well, you can't divide a triangle into an arbitrary number of triangles, because the tessellation factors are limited (iirc factors of 64 are guarantueed, more might be available). But usually that's sufficient. A good approach often is to calculate the tessellation factors based on the screen-space size of the triangle edge. That way the tessellation automatically changes based on the distance from the camera. Here is an example http://codeflow.org/entries/2010/nov/07/opengl-4-tessellation/ The author's doing that for terrain tessellation, but the principle is the same.

Well done, will check it out! Yeah, I was thinking along similar lines. By the way, I used the upper 4 bits of the material flags (normal alpha) channel to store metalness (it should normally just be 1 or 0 anyway), and roughness in fragData2.a, thus could leave the transparency alpha as is.

Unfortunately I can't post those textures, since these are proprietary ones by gametextures.com. You could get them with a trial account. But I will make some better comparison screenshots soon.

Yes, that works. But I am trying to get the content of a render buffer Texture* tex = Texture::Create(width, height); Buffer* buffer = Buffer::Create(width, height, 1, 0); buffer->SetColorTexture(tex); buffer->Enable(); buffer->Clear(); world->Render(); buffer->Disable(); Context::SetCurrent(context); tex = buffer->GetColorTexture(); const char* pixelBuf = new char[tex->GetMipmapSize(0)]; tex->GetPixels(pixelBuf); A call to mat->SetTexture(tex) works, probably because the texture handle is being passed, but the above call to GetPixels() doesn't. As I said, I assume the texture isn't actually retrieved from the GPU to the main memory.

When I try to get the pixels of a Buffer's color texture, I get an exception. The texture is fine and can e.g. be set to a texture slot, so I guess the data isn't actually retrieved from the GPU? Is there a way to do this?

Actually I did, but in all those back and forth changes between the two pipelines I must have made a mistake, I created a clean new project and did the "classic" shot again: http://images.akamai.steamusercontent.com/ugc/318997198277429861/AA729F838AEFA16B397DE94A706744F4ED18E51C/ But the direct comparison is really difficult. E.g. in this new shot the light intensity is higher (1.2 instead of 0.8) than in the PBR shots to show some highlights.

That's actually not too easy, because the assets have to be so different. I tried the following: Used a barrel model from Dexsoft's Industrial3 collection and applied a rusted steel texture from gametextures.com (that is available in both classic and PBR variants): Classic http://images.akamai.steamusercontent.com/ugc/318997198276597375/6C91BE3851233BE9365238615B71AC72E1012060/ and PBR http://images.akamai.steamusercontent.com/ugc/318997198276599144/73A9480C1634DF36C7D0BE8E3DBBAF46143C8179/

Genebris, that question is a great excuse to post yet another screenshot: Of course it is ;-) http://steamcommunity.com/sharedfiles/filedetails/?id=620641512 To be fair, no small of this goes towards the texture quality - the status uses a single 4k texture created by the Quixel suite, using one of its smart materials.

I am using spherical harmonics (think Marmoset Skyshop) which have 9 float parameters, so the 4 channels of the ambient color aren't sufficient. Come to think of it: I am currently using just one cubemap, but there could be many in the scene, so the coefficients (and reflection cubemap values) would depend on the object's position. It might be best to keep these calculations in the materials.

I can't give you a direct comparison. It should be slower, but not by an awful lot. Apart from the ambient lighting there aren't more texture lookups, and that would be an unfair comparison since it's an additionl feature. But yes, the shader calculations are more involved (more dot product, a pow() for the Schlick approximation etc.). My code isn't yet optimized, and some optimizations would actually need changes to the Leadwerks engine: the conversion of textures from linear space to gamma can be don eby the GPU using its sRGB sampling. Right now I have to transform the colors using pow(col, 2.2) and back using pow(col, 1/2.2) I am currently doing the ambient lighting in the materials because I don't know how to pass the required data to the lighting shaders,