klepto2

thats it I have tested the template a bit and found a few things: the settings.bat file is not updated with the template name it would be nice to have the console enabled in the sample by default adding the console window and sending an empty command causes a crash closing the console window doesn't resume the scene TODOS: Terminate behavior (IDEAS) Add a callback function to the terminate method default show a message box "Do you really want to quit?" This could be extended to allow something like Back to Main menu or Back to Desktop Using the sample scene (don't know if this is a bug in UltraEngine or the template) saving a quick save and reloading disables the door component. The close or open state works, but after the closing or opening the trigger will not work anymore Some ideas for the template itself: Try to add some more samples showing the intended workflow (e.g.: Main-Menu, loading and saving, in game options) Provide an in game console which did not need an actual window. (the console is very nice, but it is a bit of the mainstream if another window is opening, especially when the app is running in full screen)

I have a seventh reason 7. It is simply awesome and easy to use. Very nice work.

Valid point. It is always good to use the provided api. Also, it is not hard to switch this out when needed. Just a small snippet I used in the Texture Gen to get proper redirection in windows apps which have no console: if (!AttachConsole(ATTACH_PARENT_PROCESS)) { if (AllocConsole()) { freopen("conin$", "r", stdin); freopen("conout$", "w", stdout); freopen("conout$", "w", stderr); } } else { auto consoleHandleOut = GetStdHandle(STD_OUTPUT_HANDLE); auto consoleHandleIn = GetStdHandle(STD_INPUT_HANDLE); auto consoleHandleErr = GetStdHandle(STD_ERROR_HANDLE); if (consoleHandleOut != INVALID_HANDLE_VALUE) { freopen("conout$", "w", stdout); setvbuf(stdout, NULL, _IONBF, 0); } if (consoleHandleIn != INVALID_HANDLE_VALUE) { freopen("conin$", "r", stdin ); setvbuf(stdin, NULL, _IONBF, 0); } if (consoleHandleErr != INVALID_HANDLE_VALUE) { freopen("conout$", "w", stderr); setvbuf(stderr, NULL, _IONBF, 0); } } This is useful if you compile an UltraEngine app in release, but also want to mix cmdline features with a standard window app. This redirects the output to the console window if possible (e.G: when running from a batch file) otherwise it creates a new console (eg when it is used without a batch, but with a link-file).

yeah, this https://github.com/graphitemaster/incbin is the same i want use now. The idea is to supply a basic set of plugins (or directly needed) directly in the executable itself. The idea is to have the ability to include everything in the executable and provide single file tools. This would make distribution easier. Lets say you have a tools folder with a lot of tools. every folder needs the plugins, but have different search pathes for the plugins (eg:plugins or plg) each tool might be dependend on a specific version of a plugin and is not updated to use the plugins which are there. the executable will be bigger, but it may be worth it.

4k generated specular map from a 8k hdri image with a max sample count of 1024.

I am currently working through this nice gem: https://placeholderart.wordpress.com/2015/07/28/implementation-notes-runtime-environment-map-filtering-for-image-based-lighting/ and i just made one small adjustment to the ibl shader pipeline (i simply reduce the samples based on the roughness, roughness = 0 --> samples = 32, roughness = 1.0 --> samples = maxSamples(default 1024)) and with this i was able to generate even 4k cubemaps without the lost device error and nearly the same quality. of course this has be altered to be used only, when x mipmaps are available. But maybe i can integrate some other ideas from this blog as well.

yes i noticed this as well, in an early version it was as soon as I created a cubemap > 512px. Unlike the method of the IBL Sampler from Khronos I am using a compute pipeline for this, which means i could reduce the errors by maximizing the Workgroup sizes to the allowed maximum. I have multiple compute shaders with different Local sizes and choose the correct one based on the current MipMapsize. It still happens with textures > 1024 (not everytime but from time to time) as i currently have just added 2 shaders one with a localSize of 1 and one with a local size of 32. But i will try to optimize it. Some suggestions to speed it up are not included in the IBL sampler code (e.g: precalculations of some values).

Wow, this is really amazing and it is very nice to share this gem. I am looking forward for the blog entry. Some small ideas after a short look into the code: The Print outputs in some classes could be managed by some kind of log manager. With redirecting to error logs etc... While the ParseCommandline and the table class is very powerful, I would use a more abstract and typesafe way for the commandlines in the PBR Texture Generator i use this gem: https://github.com/jarro2783/cxxopts/tree/master for command line handling: the usage is very simple and straight forward: bool showhelp = false; bool batch = false; bool cubemap = false; bool panorama = false; string outdir; string dir; string file; int samples; float lodbias; float exposure; int diffuse_res; int specular_res; cxxopts::Options options("UltraPBRTextureGen.exe", "this tool generates the required PBR textures from panorama HDR files or Cubemaps (*.dds or *.tex) files"); options.allow_unrecognised_options(); options.add_options() ("b, batch", "Batch operations", cxxopts::value<bool>(batch)->default_value("false")) // a bool parameter ("c, cubemap", "Convert cubemaps (dds, tex)", cxxopts::value<bool>(cubemap)->default_value("false")) ("p, panorama", "Convert panoramas (hdr)", cxxopts::value<bool>(panorama)->default_value("false")) ("d, dir", "path to search the files (only used with batch option)", cxxopts::value<std::string>(dir)) ("o, out", "output folder", cxxopts::value<std::string>(outdir)) ("f, file", "file to convert (only when not used with batch option)", cxxopts::value<std::string>(file)) ("e, exposure", "Exposure to be used when importing HDR images", cxxopts::value<float>(exposure)->default_value("4.0")) ("s, samples", "Samples to be used", cxxopts::value<int>(samples)->default_value("1024")) ("lb, lodbias", "LodBias to be used", cxxopts::value<float>(lodbias)->default_value("0.0")) ("dr, diffuse_resolution", "Resolution for the diffuse map", cxxopts::value<int>(diffuse_res)->default_value("128")) ("sr, specular_resolution", "Resolution for the specular map", cxxopts::value<int>(specular_res)->default_value("1024")) ("h,help", "Show help", cxxopts::value<bool>(showhelp)->default_value("false")); auto result = options.parse(argc, argv); if (showhelp) { Print(options.help()); return 0; }

Well, no need for mentioning it. It was very obvious Filtering is very difficult with the current log messages, maybe the engine logging should be something like this: "[UltraEngine] Timestamp : Texture "xyz" loaded. This way a developer could simply filter out everything which begins with "[UltraEngine]", otherwise this could collide with mesages intended by the developer. Another way, which might be useful is some kind of log format setting. A simple function ptr which receives the msg and outputs a custom formatted msg. (Could be added to EngineSettings)

For reference: Panorama with exposure set to 4.0: With exposure set to 12.0:

UltraPBRTextureGen_v0_8.zip New Version with exposure added to the import of hdr images. Changes: HDR files are now loaded as real HDR images and not converted to LDR before processing Exposure parameter added (default 4.0) Gui: Added Exposure controls and rebuild panorama button When you import a panorama or cubemap, the initial build is triggered.

It would be nice to have the out of the box ability to include files into the main engine and load them from there. Also it would be nice to have a LoadPlugins method with the ability to load from a stream. I know this is not possible with the default windows options, but maybe this lib will help for this: https://github.com/fancycode/MemoryModule

Here it is a first release of my PBR Texture generator made with UltraEngine: UltraPBRTextureGen.zip [New-Version with real hdr and Exposure] UltraPBRTextureGen_v0_8.zip Features: Standalone UI-App with preview and settings Allows single import of panorama (*.hdr) and cubemap (*dds and *.tex) files Adjustments for samples / lodbias and resolutions Saving is limited (it currently saves only to appdir and the names are fixed to sky_diffuse/sky_specular CLI Allows batch and single operations on folders or single files Full set of parameters here: Usage: UltraPBRTextureGen.exe [OPTION...] -b, --batch Batch operations -c, --cubemap Convert cubemaps (dds, tex) -p, --panorama Convert panoramas (hdr) -d, --dir arg path to search the files (only used with batch option) -o, --out arg output folder -f, --file arg file to convert (only when not used with batch option) -s, --samples arg Samples to be used (default: 1024) --lb arg LodBias to be used (default: 0.0) --dr arg Resolution for the diffuse map (default: 128) --sr arg Resolution for the specular map (default: 1024) -h, --help Show help In the folder cli-samples is a subfolder for HDRI images, for the sample commands to work you first need to download one or more HDR images from a source like https://polyhaven.com/hdris Screenshot: the generated files can directly be used in the UltraEngine Editor under MAP/Environment/(Background/Specular/Diffuse) to provide proper PBR lighting. Planned Features: Fix save behaviour in the GUI-App Add more image formats Add Exposure control for generation like here: https://matheowis.github.io/HDRI-to-CubeMap/ provide a small cpp lib to enable on the fly (realtime) generation of these textures.

ok, this prevents any message to be displayed. So, if i want to still use Output i need to write my own print functions, but this is an unforunate step maybe the print functions need an optional source parameter. In case someone wants a small sample: bool PrintHook(const Event& ev, shared_ptr<Object> extra) { if (ev.data == 1) { fwprintf(stdout, ev.text.c_str()); fflush(stdout); return true; } return false; } void PrintLog(const std::string& s) { EmitEvent(EVENT_PRINT, 0, 1, 0, 0, 0, 0, 0, s); } void PrintLog(const String& s) { PrintLog(std::string(s)); } void PrintLog(const WString& s, const bool linereturn = true) { EmitEvent(EVENT_PRINT, 0, 1, 0, 0, 0, 0, 0, s + (linereturn ? "\n" : "")); }; void PrintLog(const unsigned int i, const bool linereturn = true) { PrintLog(WString(i), linereturn); } void PrintLog(const uint64_t i, const bool linereturn = true) { PrintLog(WString(i), linereturn); } void PrintLog(const int i, const bool linereturn = true) { PrintLog(WString(i), linereturn); } void PrintLog(const float i, const bool linereturn = true) { PrintLog(WString(i), linereturn); } void PrintLog(const double i, const bool linereturn = true) { PrintLog(WString(i), linereturn); } void PrintLog(const bool i, const bool linereturn = true) { PrintLog(WString(i), linereturn); } void PrintLog(const char* i, const bool linereturn = true) { PrintLog(WString(i), linereturn); } void PrintLog(const wchar_t* i, const bool linereturn = true) { PrintLog(WString(i), linereturn); } void PrintLog(const table& t) { PrintLog(string(t)); } int main(int argc, const char* argv[]) { ListenEvent(EVENT_PRINT, NULL, PrintHook); PrintLog("My-Message"); return 0; }

As i am currently working on a cli tool, i found that the constant "spamming" of UltraEngine logs is quite annoying. While these messages are good for debugging or even for release builds,It would by nice to disable them, or redirect them. Espescially the messages with just an infomative character should be optional, like "Texture xxx loaded..." othe messages like errors should go to the stderr and everything else should be managed by the developer.

This is true. It is very easy to modify the current pbr shaders into a new shader family to achieve a water effect. But therefore a few other things need to be (re)added: animated textures (currently not included, but can be achieved by creating a new shader family with a modified fragment.glsl file) adding some advanced material options: Refractionindex (is already in there, but not used) Thickness (also included, but not used) a custom alpha calculation method based on visibility If this is all included, i can only think of one case, where a special surface is needed (mainly for performance) is the usage of oceans.

Like Leadwerks, the Standard-Edition will support Lua, while the professional Edition will also support C++. The Lua integration is much more advanced than in Leadwerks, More or less everything which is publicity available by the cpp api is also available in LUA. As a bonus point the Editor has a plugin system which allows simple or advanced lua scripts and cpp (dll) plugins to add functionality to the editor.

I know that i can render to a texture, but i want to run the Vulkan Pipeline without using a window like this: #include "UltraEngine.h" using namespace UltraEngine; void RenderHook(const UltraEngine::Render::VkRenderer& renderer, shared_ptr<Object> extra) { Print("RENDER_HOOK called..."); } void TransferHook(const UltraEngine::Render::VkRenderer& renderer, shared_ptr<Object> extra) { Print("TRANSFER_HOOK called..."); } int main(int argc, const char* argv[]) { auto cl = ParseCommandLine(argc, argv); EngineSettings settings{}; settings.asyncrender = false; //Create a world auto world = CreateWorld(); //Create a framebuffer auto framebuffer = CreateTextureBuffer(512,512); auto camera = CreateCamera(world); world->AddHook(HOOKID_TRANSFER, TransferHook, world, true); world->AddHook(HOOKID_RENDER, RenderHook, world, true); //Main loop for (int frame = 0; frame < 100; frame++) { world->Update(); world->Render(framebuffer); //camera->Render(); } return 0; } but this leads to an assert error at world->Render(), one solution is to create a hidden window, but it would be nicer if it would work even without the need of a window and a correct framebuffer.

You requested a feature for my IBl Generator, while i have managed to get it to work as a cli, i still need a Hidden window to get all the work done. As far as I know vulkan is allowing headless rendering for this, where you don't need an actual surface. https://github.com/SaschaWillems/Vulkan/blob/master/examples/renderheadless/renderheadless.cpp It would be nice to have the ability to create a Framebuffer without having a window.

To limit the confusion for users, you might consider to add a small info where the Material selection would be, which states something like: "No Terrain selected"

I promote this suggestion because: In the latest weeks you made a great progress with the editor, but while testing the editor with lots of files i found some things which could be made easier if a small clear cache function is integrated: Also this function is more or less a very easy one to implemnt. In the latest updates you suggested multiple times to delete the thumbnail folder The overall cache can grow extremely in size and to easily clean it up from the editor would be handy the clear cache should be optionally global or per project

Fixed the blurriness: The color is not as bright as the one from the ibl sampler as it uses dds or tex files to gnerate the filtered cubemap, which is different to the hdr format. Maybe i can find a soltuin for that as well.

The code is the same as the one from Khronos. What might be, is that I have one step missed. But the mipmaps are generated the same way. And before downloading they look smooth. But will take a closer look.