Jump to content
Search In
  • More options...
Find results that contain...
Find results in...


  • Content Count

  • Joined

  • Last visited

Community Reputation

178 Excellent

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

8,774 profile views
  1. Rastar

    Realistic Penumbras

    Wow, great stuff, congrats!
  2. 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 accord
  3. 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.
  4. 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)?
  5. 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.
  6. 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.
  7. Parallels only supports OpenGL 2.1 (I think it's similar with other VMs), so Leadwerks won't run, no matter what GPU you have.
  8. 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.
    1. Show previous comments  7 more
    2. Rastar


      As I understand it, Vulkan can (finally) do multi-threaded rendering. But asynchronically loading maps and assets is done on the CPU and should work already (provided the engine supports it)

    3. Genebris


      I think there really should be support for dynamic map loading. And also ability to have several terrains in one level.

      Otherwise we can't make open world games.

    4. nick.ace


      Vulkan supporting VRAM stacking sounds pretty cool too. I wonder if SLI will finally be a more widely used in the future.

  9. 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.
  10. 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 sa
  11. 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?
  12. Mmmmh, it's been a while since I did some programming in Leadwerks, and things seem to have changed slightly... If I see this right, for C++ projects the Main.lua script is executed in App::Start(), which contains the game loop. And when this is ended, the C++ execution continues in App::Start(), then App::Loop() (which basically does nothing). Also, since everything is done in Main.lua, the World, Context, Camera and Window member variables are all null. I can change this according to my needs, but I think for C++ projects there should be a template with a clean lifecycle implementation d
  13. When running an app from the IDE, the following line in App.Start() (I don't have an App.lua, so it's trying to execute Main.lua) //Invoke the start script if (!Interpreter::ExecuteFile(scriptpath)) { will throw an error First-chance exception at 0x76C23E28 in MTLighting.debug.exe: Microsoft C++ exception: common::CNamedArgsUndefinedNameException at memory location 0x00CFE7A4. First-chance exception at 0x76C23E28 in MTLighting.debug.exe: Microsoft C++ exception: common::CNamedArgsUndefinedNameException at memory location 0x00CFE774. The execution jumps out here and
  • Create New...