reepblue

I would follow the standard regardless how they did it. This is really good. I wanted this when I started using Leadwerks coming from Source. This will be very helpful.

Understandable, but that would be wonderful if that gets added. I really don't want to touch Vulkan shaders for simple effects. Speaking of which, do you still have texture scrolling and rotation in the shader? Options for that should be in the material editor too. If I were to make Cyclone on Ultra, I would need material variants and texture scrolling and rotation. The cyclones themselves are tricky because I rotate 2 sheets at a different rate so that would need a custom shader unless I were to animate them in the DDS texture. This is how Valve did their portals before adopting the current look as each texture was 200mb animating at 30 fps, and it needed to run on the Xbox 360. If I were to animate my cyclones, I probably would try to compress it to basis, or simply not worry about it.

Hey, would it be possible for a gltf to support multiple diffuse textures or multiple sets without copying the model? Like you have a barrel model but you have a texture where it's blue but another one that's red with a fire icon on it It would be nice to have one model with all the variations. Another example: Portal 2 has multiple skins for it's weighted storage cube. There's a clean skin, clean activated, dirty, dirty activated, etc. Having this support would also make it easier to change emission colors without a shader edit like I had to do in Cyclone. Since shaders are more complicated in Ultra, I would like to just change one or more texture sheets for that instance of the model.

Maybe there should be something upfront informing the user if the model is using an optimized texture or if the gltf is still using the image.

If I can create a both solidand concave collision meshes in blender with a unique name like ULTRA_COLLIISION_xx and have the ability to set a universal default mass value for that model within the gltf, that would be terrific!

Not liking this idea since I used prefabs for rooms, gameplay elements and light fixtures. Actually, if you can just load multiple scenes into the world as groups keeping all actor logic, that would be great.

Agreed. What's not broke, don't fix.

I think having multiple windows is better than tabs. I easily loose what I'm working on and like you said, is annoying to see changes. You currently have no functionality to delete or rearrange the tabs so it's even more annoying. Removing it will also save you work for the time being.

Since there wasn't a thread created for this, might as well start one. Base Window: First bug: the splash screen doesn't display correctly. Second, the window position isn't being saved correctly. The window's position increases by 31 on both the x and y values when first setting it to 0 by modifying the Settings.json file. This will eventually create the window off screen, Missing the + icon here. Some images and icons will be drawn upside down. When browsing through packages, folders are included as blank files. Files from here don't draw correctly. There's no preview thumbnail for .tex files. I think this is because Windows Explorer doesn't make one, but it's still a bummer. Opening them seem to work fine, but I did have one texture (Beam01.tex) that caused an Assert error. Model Editor: Models load and program acts as expected, However, when interacting with the UI, the model stops drawing until the viewport is selected again. This is also missing a collision shape builder/importer, but that's probably on the to-do list. Material Browser: The sphere's UVs aren't correct, and the viewport suffers the same issue as the model viewer. Also, a horizonal slider would be nice. And please add back in Zoom in the material browser like you had in Leadwerks. The big bugs are the window positioning and the issues with the 3D viewport. Other than that, this seems usable in its current state.

Ok, now there's an extra step but it makes sense.

Running through old samples we were testing during the beta and noticed that this example doesn't have the framebuffer fill the window anymore after it's been "resized". #include "UltraEngine.h" #include "ComponentSystem.h" using namespace UltraEngine; int main(int argc, const char* argv[]) { //Get the displays auto displays = GetDisplays(); //Create a window auto window = CreateWindow("Ultra Engine - Normal", 0, 0, 1280, 720, displays[0], WINDOW_CENTER | WINDOW_TITLEBAR); //Create a world auto world = CreateWorld(); //Create a framebuffer auto framebuffer = CreateFramebuffer(window); //Create a camera auto camera = CreateCamera(world); camera->SetClearColor(0.125); camera->SetFov(70); camera->SetPosition(0, 0, -3); camera->SetViewport(200, 0, framebuffer->size.x - 200, framebuffer->size.y); auto uiCamera = CreateCamera(world, PROJECTION_ORTHOGRAPHIC); uiCamera->SetRenderLayers(2); uiCamera->SetClearMode(CLEAR_DEPTH); uiCamera->SetPosition((float)framebuffer->size.x * 0.5f, (float)framebuffer->size.y * 0.5f, 0); auto ui = CreateInterface(world, LoadFont("Fonts/arial.ttf"), iVec2(200, framebuffer->size.y)); ui->SetRenderLayers(2); auto sz = ui->root->ClientSize(); auto listbox = CreateListBox(5, 5, sz.x - 10, 200, ui->root, LISTBOX_DEFAULT)->As<ListBox>(); auto tabber = CreateTabber(5, 205, sz.x - 10, sz.y - 205, ui->root)->As<Tabber>(); tabber->AddItem("Settings", true); tabber->AddItem("Output"); tabber->SetLayout(1, 0, 1, 1); for (int i = 0; i < 100; i++) { listbox->AddItem("Item " + String(i)); } //Create a light auto light = CreateBoxLight(world); light->SetRotation(35, 45, 0); light->SetRange(-10, 10); //Create a box auto box = CreateBox(world); box->SetColor(0, 0, 1); //Entity component system auto actor = CreateActor(box); auto component = actor->AddComponent<Mover>(); component->rotation.y = 45; //Main loop while (window->Closed() == false and window->KeyDown(KEY_ESCAPE) == false) { while (PeekEvent()) { auto ev = WaitEvent(); ui->ProcessEvent(ev); switch (ev.id) { case UltraEngine::EVENT_WINDOWCLOSE: if (ev.source == window) exit(0); break; default: break; } } // Rebuild the window. if (window->KeyDown(KEY_SPACE)) { static bool bSwapped = false; framebuffer = NULL; window = NULL; if (!bSwapped) { // Make it a tad bigger window = CreateWindow("Ultra Engine - Resized", 0, 0, 1400, 800, displays[0], WINDOW_CENTER | WINDOW_TITLEBAR); framebuffer = CreateFramebuffer(window); } else { window = CreateWindow("Ultra Engine - Normal", 0, 0, 1280, 720, displays[0], WINDOW_CENTER | WINDOW_TITLEBAR); framebuffer = CreateFramebuffer(window); } // Reposition the camera. uiCamera->SetPosition((float)framebuffer->size.x * 0.5f, (float)framebuffer->size.y * 0.5f, 0); //Resize the interface ui->SetSize(iVec2(200, framebuffer->size.y)); bSwapped = !bSwapped; } world->Update(); if (framebuffer) world->Render(framebuffer); } return 0; }

While this will cut compile times down, it'll go against the idea of the applications using the same cpp files. UAK changed some functions and has several old bugs that have been fixed in the engine. I'm also sure UAK will not load the most recent plugins. Thought of that, but I can see it becoming a mess if you wish to build more than a few applications. I also have a remote console that sends commands to the game application with enet and I'd like that to be its own application. I guess what I can do is make any tool that is just a simple main.cpp (Like an image converter) a default Ultra Project. Anything that has to interact or needs to reference a system (Like the input system) will be code shared in the game project made with premake. I can probably get away with the action mapper application being the same application as the game, but the remote console needs to be a standalone application. I'll just put it in the engine's "Tools" folder instead of my game's folder. My input library will just be merged into the game code using the engine's polling for input. For sound, I might not continue using FMOD unless I can get events and raw sounds to play correctly together without calling OpenAL. Although having a daw interface for games was really nice, the sound implementation is much better in Ultra so I don't think I need a replacement. Also, the less decencies, the better.

Ok, this is what I came up with fitting the existing mold. I created a new directory called "Premake" in the Project root's folder. This holds Premake and the lua scripts for each project. While each script is literally the same thing minus the name of the code project due to limitations, I guess it's good if you want to add custom defines to one project. Premake builds the Visual Studio projects and solution under "Projects" like Leadwerks had it set up. I didn't divide project types by platform as that would take more code and I don't think it's necessary. The build objects and the hidden .vs folder will also be created under the Projects directory making it really easy to omit when committing to git and svn repositories. All source code will still remain under "Source". I'm still thinking about how to arrange shared files and project specific ones. Right now, I have it so files like the cpp needed for the precompiled header and the needed for macOS under the root directory and each separate project will have its own private folder. I didn't battle test this yet, but it looks promising so far.

I know the asset browser isn't out yet, but can you include a "Camera Settings" grid for setting the camera's position and view ranges? This would be very helpful for previewing weapon view models.

I was poking around in the engine headers and noticed that headers for the Hub (Client) and Editor are in the include folder with the rest of the engine. It got me thinking if there was a better way of handling multiple applications within the same project. For Cyclone, I use premake to build everything and have it set up like Source. Every product has it's own folder minus the public folder which has shared headers and code. This works in the Cyclone repo, as only the game links with Leadwerks, and I use UAK for the action mapper application since I needed a Win32 binary. The rest rely on the standard library and WinAPI. However, when I translated this workflow to with Ultra Engine in-mind, everything was going great until Ultra Engine was introduced. It became hard to decipher what was using the engine library and what wasn't. I also wanted to create functions and classes that can be used by multiple applications without it being hpp files and preprocessor locks to prevent code from compiling if it's ever built by a non-Ultra application. There's now a lot more of redundant code with my core library and the engine having the same quality of life methods as the engine, plus I no longer need to build ZipLib as the engine has it already. The only thing I would need to merge is my input library to be compatible with the Engine's enum values. but that should be really easy to do. Plus, the code will be more C++ friendly as it'll not be a dynamic library, What I'm asking is if there's a good workflow (Such has how the Hub and Editor co-exist) to have multiple applications share one Ultra Engine Project. I don't want to have multiple projects to keep up to date, nor I want to copy and paste code across. I know I could just copy the Visual Studio project but that's a pain in the butt and my root directory will just be filled with IDE Projects. Maybe we should go back to dedicated Projects directories like how we had it in Leadwerks?

Ahh ok. It's just that the black splotches went away from what look like are from gaps made by the point light radius values.

Oh cool, so this makes it so the room isn't lit by multiple point lights? Also Phil, is that a post process shader that'll work in Leadwerks? I'm eager to try it out!

Would it be possible for a recursive override? I'm trying to locate every wav file within the package and add it to a list. I can only get a list of files and folders in that directory only.

Thanks for these. Really interested in the scroll panel.

Seems the old method has been undocumented to I expect this to be the new standard in a future update.

No sliders for intensity, roughness and metalness? Also interested to see how the tab system can be updated to support closing and reorganizing. Everything looks good, it's going to get really exciting once the map tools start to be made.

GPT along with this DAN protocol is literally like the angel and devil sitting on your shoulder. I'm laughing while I still can...