klepto2

I have reported that originally here: But i would like to bring this up again. I have now working a lot with the polyhaven api and their textures to generate materials out of them. The textures or better the metadata of the PBR materials have a property called wideness, which for some is 1m and for others eg: 15m. Polyhaven itself use this in their blender plugin to fix the texturesize on brushes by scaling the uvs according to this wide parameter. This would be nice to have in UltraEngine itself, not only for imported materials, but also for tiling on planes etc.

@Josh I have found some additional things (I know the api is still in development) program:OpenAsset is the only method to open the AssetEditor no Asset(model) / Asset(entity) is available --> currently it is not possible (at least no way i know about) to open a model file in the AssetEditor via lua. consider to make the Options in optionswindow a treeview to reflect the actual json layout of the settings. Maybe an addition to the AddSettings where you can specify the node where this is stored in the settings.json. eg: I have this: program.settings.extensions.polyhaven.material.downloadSize = "1k" now i want a method like opt:AddSettings("Polyhaven", "Material DownloadSize", PROPERTY_STRING, { "1k,"2k",4k",8k" }, "program.settings.extensions.polyhaven.material.downloadSize") a settings property with multiple combo values would be nice as well. eg: PROPERTY_STRING and a array of Strings as possible values In my case i have a setting where you can choose between (1k,2,4k and 8k) resolutions I can add my own settings dialog, but it would be nice to have the ability to let plugins have its configuration at the same place as the other options. In general it would by nice if you could expose more Editor-Scripting possibilities for lua in the near future. This would increase the power of the editor by magnitudes (IMHO)

Unfortunaltly it still doesn't work as expected. Here is a smaple material, one working and the other one not. mat_test.zip

If a material is saved via code, then the thumbnails not get generated correctly. when you create a Material in code, Load a texture and assign it to a slot. The following is saved using Material:Save: "texture0": "Materials/XXX/textures/brown_brick_02_diffuse.dds" where it should be : "texture0": "./textures/brown_brick_02_diffuse.dds" the above code leads to thumbnails with just a white ball. The later one displays correctly.

The first case is solved, the second case is still bugged and can be reproduced like it is shown in the gif.

Here are some small samples which are still causing problems: 1. i guess it has something to do with folder renaming: 2. I guess this is the issue reepblue is refering to:

There are some issues with the updating the folder hierarchy whithin the editor. When you add a folder to the project structure in windows explorer, the folder is visible within the editor, but selecting it doesn't update the Assetbrowser (also when you copy files into the folder they will only appear after an editor restart) if you copy a more complex folder structure in the windows explorer or extract a zip file with multiple folders in the project directory, some directories are added multiple times and when you select one of the duplicates the selection goes to the first original entry.

As the title says, generate a Material and change some values / texture later. The thumbnail is not updated.

Hi, i am trying to create some PBR materials based on the great Polyhaven archive. I download the following files: Diffuse, nor_gl, displacement and arm images in PNG format. A sample zip is attached. When you right-click on the diffuse file in the editor and choose to generate material, a material with all slots filled correctly, but the arm and diffuse textures seems to be stored in BC7 which doesn't seem to work. metal.zip

while developing the PBR Texture generator I have found some flaw with the current hook system. It is somewhat inflexible. Soi tried to add my own Hook Manager: enum class HookState { IDLE, PENDING, RUNNING, FINISHED, }; class HookManager; class Hook : public Object { friend class HookManager; private: void* _function; shared_ptr<Object> _extra; HookState _currentState; bool _stopping = false; bool _repeating = false; shared_ptr<HookManager> _manager; public: Hook(shared_ptr<HookManager> manager, void callback(const UltraEngine::Render::VkRenderer&, shared_ptr<Object>), shared_ptr<Object> extra, bool repeat = false) { _function = callback; _extra = extra; _currentState = HookState::IDLE; _repeating = repeat; _manager = manager; } void Start() { _currentState = HookState::PENDING; } void Stop() { _stopping = true; } HookState GetState() { return _currentState; } void SetExtra(shared_ptr<Object> extra) { _extra = extra; } }; class HookManager : public Object { friend class Hook; private: static void UpdateDispatch(const UltraEngine::Render::VkRenderer& renderer, shared_ptr<Object> extra) { auto hookManager = extra->As<HookManager>(); if (hookManager != NULL) { for (auto hook : hookManager->_hooks) { if (hook->_stopping) { hook->_currentState = HookState::IDLE; hook->_stopping = false; } if (hook->GetState() != HookState::FINISHED) { if (hook->GetState() == HookState::PENDING) { hook->_currentState = HookState::RUNNING; auto f = (void(*)(const UltraEngine::Render::VkRenderer&, shared_ptr<Object>))hook->_function; f(renderer, hook->_extra); } else if (hook->GetState() == HookState::RUNNING) { if (!hook->_repeating) { hook->_currentState = HookState::FINISHED; } else { hook->_currentState = HookState::PENDING; } } } } } } inline static map<HookID,map<shared_ptr<World>, shared_ptr<HookManager>>> _mapWorldHookManager; vector<shared_ptr<Hook>> _hooks; shared_ptr<World> _world; HookID _hookId; public: static shared_ptr<HookManager> Get(shared_ptr<World> world, HookID hookId) { if (_mapWorldHookManager.size() == 0) { _mapWorldHookManager[HOOKID_RENDER] = {}; _mapWorldHookManager[HOOKID_TRANSFER] = {}; } if (HookManager::_mapWorldHookManager[hookId][world] == NULL) { auto mgr = std::make_shared<HookManager>(world, hookId); mgr->StartDispatching(); HookManager::_mapWorldHookManager[hookId][world] = mgr; } return HookManager::_mapWorldHookManager[hookId][world]; } void StartDispatching() { _world->AddHook(HookID::HOOKID_TRANSFER, HookManager::UpdateDispatch, Self(), true); } void Start(shared_ptr<Hook> hook) { auto position = std::find(_hooks.begin(), _hooks.end(), hook); if (position != _hooks.end()) { hook->Start(); } } void Stop(shared_ptr<Hook> hook) { auto position = std::find(_hooks.begin(), _hooks.end(), hook); if (position != _hooks.end()) { hook->Stop(); } } HookManager(shared_ptr<World> world, HookID hookId) { _world = world; _hookId = hookId; } shared_ptr<Hook> AddHook(void callback(const UltraEngine::Render::VkRenderer&, shared_ptr<Object>), shared_ptr<Object> extra , bool repeat = false) { auto hook = std::make_shared<Hook>(Self()->As<HookManager>(), callback, extra, repeat); _hooks.push_back(hook); return hook; } void RemoveHook(shared_ptr<Hook> hook) { auto position = std::find(_hooks.begin(), _hooks.end(), hook); if (position != _hooks.end()) _hooks.erase(position); } }; It allows to dispatch, Start/Stop hooks like a thread and also adds the ability check the state of a hook. static void checkCallback(const UltraEngine::Render::VkRenderer&, shared_ptr<Object>) { } auto hookManager = HookManager::Get(_world, HOOKID_TRANSFER); auto checkHook = _hookManager->AddHook(checkCallback, _world, false); hookManager->Start(checkHook); while(checkHook->GetState() != HookState::Finished) { world->Update(); world->Render(); } This makes it a bit easier to watch the Hook execution. I use it in my PBRTextureGen and in my current state of Computeshader Implementation. It makes it much easier to manage the hooks. It might stll have a few bugs in it as i haven't fully tested every usecase, but for the basics it works

I know, but you can map/unmap just a region of the buffer to a shader or upload and download to that particular region. we just need the offset of the surface and the actual buffer

I have done something similar for my PBRGenerator, and will post the class to download data from the gpu soon. Syncing memory is always at a cost this goes for downloading and uploading the data. There are some tricks you can use to increase the speed a lot, but most of the time you just use staging buffers (these are buffers which are bound to eaither gpu or cpu sepending on the direction you want to transfer the data) create a buffer object map the buffer to the memory commit the upload or download commands unmap the buffer and retrieve the data (the buffer can be still mapped) There are muliple ways to retrieve data from the gpu. The slowest is to use vkCmdCopyImage, then vkCmdBlitImage (slightly faster and already does format conversion and filtering, is not available for all formats). The fastest way is to use vkCmdCopyBuffer, this copies the pure gpu memory of a bound resource into the host memory. This is mostly used for data readbacks for compute shaders (shader storage buffers), but also useful for image synchronsation. The usage of snycing between gpu and host should be used carefully, it can slow down an application fast, and should only be considered for debugging or useful info, lets say a generated water heightmap, where you want the to calculate eg: the height an object is on. This being said, it would be nice to get access to the index or vertex buffer elements of a specific surface (speaking of particle systems etc.)

I don't know exactly if this is the right place for this, but feel free to move it where ever you like, After the debugging fix in the latest release, I have started to experiment with the Lua extension integration. Some things I noticed: Currently, there is no way to dynamically down cast an entity to its derived class, e.g.: Entity → Model This is not supported by sol out of the box, but might be needed later as well for type checking. Currently, you can access all entities in the world, but not determine if it is something other than an entity. Some things are not yet accessible for extensions: The objects in the scene (I found out how to add items, not very hard) but I can't find a way to access the already added items in the scene. (using the world property of the program is not very useful because of the first problem (cast/type check) I have mentioned) Currently, there are no advanced extensions available, and as I understand that the focus lies on the release on bug fixing I would appreciate some documentation on how to properly script extensions (usage of the Undo/Redo, scene access) It would be nice to see some more advanced scripting options soon. I especially like some of the syntaxes which are available through sol3: local ent = world:GetEntitiesInArea(min,max) for i = 1, #ent do local e = ent[i] local name = getmetatable(e).__type.name -- unfortunatly only returns "UltraEngine::Entity" and nothing else. No way to cast Print(name) end

As i wanted to investigate some editor scripting possibilities, I tried using VSCode to debug the editor like it is described here: Clicking on Debug in VSCode starts the Editor, but the devcat debugger is waiting for the editor to connect. Without the ability to debug it is hard to guess, what objects and things are available to script the editor (the available current scripts mainly add some menu item only)

Searching for anything in the Map-Tab leads to a crash to desktop. The search in the Project-Tab works.

In the current release the Timer::Stop is not defined and not exposed in the libs.

Found the bug in the component itself:

The sliding door component has a small bug in the load method: if (t["enabled"].is_boolean()) enabled = t; should be: if (t["enabled"].is_boolean()) enabled = t["enabled"]; otherwise after reloading the scene from a saved game the door becomes inactive.

I think the same, will investigate it further and file a bug report on this That is fully understandable, I just wanted to point out that, once the system is stable and feature ready enough (and UltraEngine itself as well), you should consider to add some advanced sample as a documentation. But to be fair, this is a free piece of code and is a already a great starting point for anyone who wants to start developing with Ultraengine. One thing that comes into my mind is: why doing a pause generally. The easiest solution might be to don't pause at all and leave it up to the developer. As a reference the ingame consoles in most games don't pause (i can't really think of any game which pauses the game in this case) maybe an optional parameter can be used, something like "Terminate(bool force = false, int closeReason = 0);". This could be used in case of errors.

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.