vladislavbelov

It's not the hardest part. The most time consuming part is to make the lights be accounted during rendering. PBR isn't for details but for rendering consistency. With PBR an object will look well in all light conditions. Currently we have over-brighten or over-darken colors on some maps.

Currently we have at least two major problems: many different materials (different only by uniform value aren't different) and many draw calls (because of complex variations). I also plan to release Technical Art Guide but not sure when I'll have time to finish it. No, I mean industry standard PBR approaches.

Technically it's possible but it requires art optimization. I can't say it's the only biggest there is also PBR.

Nah, LODs are still needed.

Could you run the following test program? #include <iostream> #include <SDL2/SDL.h> int main() { if (SDL_Init(SDL_INIT_VIDEO|SDL_INIT_TIMER|SDL_INIT_NOPARACHUTE)) { return -1; } const int flags = SDL_WINDOW_SHOWN | SDL_WINDOW_RESIZABLE | SDL_WINDOW_VULKAN; SDL_Window* window = SDL_CreateWindow("vk-test", 10, 10, 512, 512, flags); if (window) { std::cout << "success" << std::endl; SDL_DestroyWindow(window); } else { std::cerr << "fail: " << SDL_GetError() << std::endl; return -1; } return 0; } Command to run: g++ -O2 --std=c++17 vk-test.cpp -o vk-test -lSDL2 -I/usr/include/SDL2 && ./vk-test

Maybe it's unavailable from AppImage? Is it possible to run vulkaninfo from AppImage envrionment?

I think it's not the expected difference. Could you show an example? Highly likely it's related to material refactorings. I'll investigate it further.

How do your screenshots look like? Do they have the same artifacts?

So if you're making a screenshot or recording a video the game looks correctly? Which version do you use? Could you attach a userreport log file (path to it you can find here: https://trac.wildfiregames.com/wiki/GameDataPaths)?

Updated.

Made a patch: https://code.wildfiregames.com/D4890

You might attach errors about a "model_solid_tex" material. Did notice any difference with OpenGL? If you enabled Feedback in the main menu then it should be enough.

Any other option maybe? It might mean limitation of 32bit application. Your GL crash says: "JavaScript error: out of memory", which means out of available RAM. Highly likely it's the same reason for Vulkan. Might want to build with --large-address-aware.

Your logs report out of memory (Vulkan says out of GPU memory). Does the shader or texture quality option changes the behavior? I suppose there is new more expensive art in A27.

Thanks! Updated.

Not yet. The first step is to reduce the number of driver dependent bugs and crashes and to have a more predictable performance.

Currently no, but we plan to make an RC relatively soon and it'll be bundled with this mod.

First you need to download it by the link in the first message and then install just like every other mod.

Vulkan is disabled in Atlas, as wxWidgets doesn't provide loader for that by default. Then it seems the known problem of broken materials.

Updated. Could you run the game with validation enabled? It'll cost too much my time now or too much space for shaders. So I chose a compromise, I believe there're not so many shaders left and I have a validation script to fill possible holes.

Now should be fixed.

The new version is now available at the same URL.

Thanks! Is that without any renderer.backend.debug*, right?

Could you try D4879?

Could you try Deep forest Large?