reepblue

Sorry for the bump, but I was wondering the status of this fix. I can't really get started what I want to work on until this is fixed.

This happens to me from time to time and I don't know why. One time, clearing out my ProgramData files for the engine worked, but when I had this happen again, it didn't work.

I'm curious if the Valve stuff still works as it's been a long time since I've tried the plugins.

Got it, here's a main.cpp example. I may want to consider revamping my settings panel since I now understand this. #include "UltraEngine.h" #include "CustomWidgets/ScrollPanel.h" using namespace UltraEngine; int main(int argc, const char* argv[]) { //Load plugins auto plugin_svg = LoadPlugin("Plugins/SVG.*"); //Get the displays auto displays = GetDisplays(); //Create a window auto window = CreateWindow("Ultra Engine", 0, 0, 800, 600, displays[0], WINDOW_CENTER | WINDOW_TITLEBAR | WINDOW_CLIENTCOORDS | WINDOW_RESIZABLE); //Create User Interface auto ui = CreateInterface(window); auto sz = ui->root->ClientSize(); auto scrollpanel = CreateScrollPanel(0, 0, sz.x, sz.y, ui->root); scrollpanel->SetLayout(1, 1, 1, 1); //Parent your widgets to scrollpanel->subpanel. auto panel = CreatePanel(0, 0, sz.x - 100, sz.y - 100, scrollpanel->subpanel); panel->SetColor(0, 0, 0, 1); //Call SetArea to set the size of the entire subpanel. scrollpanel->SetArea(1000, 1000); while (true) { const Event ev = WaitEvent(); switch (ev.id) { case EVENT_WINDOWCLOSE: return 0; break; } } return 0; }

Push an update today fixing VR support. I also changed how you define if your app is a dedicated VR app. See the config.json file for details. Removed the ConsoleWindow and SettingsWindow and put all the code into a PanelUI class which can be used both in a window and within the Vulkan Renderer. Lastly, I refreshed the solution files to reflect the changes made to the ones shipped in the stock C++ template.

Should be the same.

I'm having a hard time understanding the Scroll Panel widget found here. I tried parenting my custom panels to the subpanel pointer, but it doesn't draw the sliderbar. A main example would be appreciated as I need this for my settings panel.

I've been making my components into separated parts now and I gotta say, it's nice to only focus on one part of the system at a time, but I miss the "Place an entity in the world, and attach a script to it approach". A good example would be with a portal system. You can have one component be for the rendering, one for the collision and another for teleportation. I've been meaning to write about my experience, but I keep getting caught up in other things. I'm also waiting for bugs to get fixed and allowing other entities to be referenced in the component properties panel.

Pushed a new build today with VR Intergration! You can easily enable VR in your project in one or two ways; Use the -vr argument. If your game is a dedicated VR application, you can force VR by making a new table in the config.json file. "engine" { "vr": true } You can also use the engine table to define the rest of the engine settings, but tread carefully! If you wish to temporarily disable VR, then use the -novr argument. The Preprocessor was updated with the change today and I removed the GameObject class. I'm still playing with components so a future update will come eventually. The solution doesn't include the System Environment edit or any recent changes. I'm going to be syncing the solution files at a later date.

Fixed it, but still not getting this issue.

I was able to compile my project just fine with the delayload option, but it seems to be ignoring it. I'm probably going to refresh my projects being all the changes that happened recently.

This has been updated so the header generated will now be named ComponentSystem.h instead of RegisterComponents.h.

Can the installer create a System Environment Variable for where Ultra Engine is installed? I think this will help make installing tools and sharing C++ projects easier if we can just reference something like %ULTRAENGINEPATH% in batch scripts or the PropertiesSheet.props file. This is now more important as there's the Steam install and the standalone version.

Noticed this too but I couldn't tell if this was intentional or a feature. I agree with you regardless. I don't like this.

This looks like a huge time saver! With this enabled as a converter, no model will accidentally be left using png images.

The code will remain C++ but in the future I plan to expose the more useful classes to Lua. The idea is that you can still have your game component code as Lua while the backend stuff is C++. I'm not sure how to manage/distribute something like this as I would be required to build the executables for all platforms on every release.

Notice that components attached to entities with a parent don't save properly. I've ran into an issue where my camera (Which is a child of a pivot) rotation doesn't save automatically. I tried to patch this within the component, but then I noticed that the Load function is skipped when the scene is reloaded. Saving works fine. This example shows how the component load function is skipped on a scene reload call. #include "UltraEngine.h" using namespace UltraEngine; class TestComponent : public Component { public: TestComponent() { name = "TestComponent"; } void Start() { Print("Start"); } shared_ptr<Component> TestComponent::Copy() { return std::make_shared<TestComponent>(*this); } virtual bool Load(table& properties, shared_ptr<Stream> binstream, shared_ptr<Map> scene, const LoadFlags flags) { Print("Loading TestComponent"); return true; } virtual bool Save(table& properties, shared_ptr<Stream> binstream, shared_ptr<Map> scene, const SaveFlags flags) { Print("Saving TestComponent"); return true; } }; int main(int argc, const char* argv[]) { RegisterComponent<TestComponent>(); if (AllocConsole()) { freopen("conin$", "r", stdin); freopen("conout$", "w", stdout); freopen("conout$", "w", stderr); } //Get the displays auto displays = GetDisplays(); //Create a window auto window = CreateWindow("Ultra Engine", 0, 0, 1280, 720, displays[0], WINDOW_CENTER | WINDOW_TITLEBAR); //Create a world auto world = CreateWorld(); //Create a framebuffer auto framebuffer = CreateFramebuffer(window); //Load scene auto scene = CreateMap(); auto camera = CreateCamera(world); auto ent1 = CreatePivot(world); scene->entities.push_back(ent1); auto ent2 = CreatePivot(world); ent2->SetParent(ent1); ent2->AddComponent<TestComponent>(); scene->entities.push_back(ent2); //Main loop while (window->Closed() == false and window->KeyDown(KEY_ESCAPE) == false) { if (window->KeyHit(KEY_F5)) { //Save the starting scene to a file Print("Saving..."); scene->Save("game.sav"); } //Reload the starting scene when space key is pressed if (window->KeyHit(KEY_F6)) { Print("Loading...."); scene->Reload("game.sav"); } world->Update(); world->Render(framebuffer); } return 0; }

As first mentioned here. Normals don't return the right value with GetWorld()->Pick() on brushes. It's fine with models. auto end = LoadModel(GetEntity()->GetWorld(),"Models/Developer/Widgets/normal.gltf"); auto p0 = GetEntity()->GetPosition(true); auto p1 = TransformPoint(0, 0, viewdistance, GetEntity(), NULL); pickinfo = GetEntity()->GetWorld()->Pick(p0, p1, radius, true); bool lookingatvoid = !pickinfo.success; if (!lookingatvoid) { // Set the end point to the position. end->SetPosition(pickinfo.position); end->SetRotation(0, GetEntity()->GetRotation(true).y, 0); end->AlignToVector(pickinfo.normal); } Wanted to make this it's own thread so it doesn't get forgotten.

I've also seen files being identified as folders when a new file is added to the project when the editor is opened.

On the subject of a widget, I think it's more important for the 3D viewport than the 2D viewports. I love moving things around in the 2D viewport, but in 3D, it can get a little sloppy. I mostly liked the widgets because they automatically showed the origin point and the entity's rotation (In local mode) without anything else being needed.

I got to play with it and my first reaction was: The example models snap right into place where I want it to go. It feels so much better. For uniformed models, this is perfect, but I understand not every model is like this. Making brushes seems much better, but it might be a placebo effect. I'll have to play with it more. But I was the only one complaining about this, I guess let's see if anyone else finds this a step forward or backward.

Maybe a small viewport should draw within the existing 3D viewport showing the camera render when the camera entity is selected.

Most of the time, I place objects in the 2D view since it's closer to the File Browser panel. Maybe that should be more grid locked than the 3D view port? One of the few reasons I would use the 3D view to place objects would be to place objects on surfaces having the model's align to the surfaces normal which doesn't seem to be in the editor currently afaik. Also one feature (or bug) I don't like is when you place an object on the Top 2D grid view and the item gets placed on it's side. It's like the Top grid viewport is being handled the same way as Back/Side. I'll try to play with your changes tonight and get back to you.

Here's the glass shader I used in Cyclone. You'll have to write code that'll replace texture slot 7 of the material with the probe's cubemap texture. LeadwerksGlass.zip

Thought so (It's still a bug tho). This is why I thought it was the normal messing this up. Read this too fast. While the current system is correct I don't think it feels right. In Leadwerks, placing models in the scene snaps the model to the nearest grid point. This felt great especially when the model's origin accommodated the model. I don't want to manually type in the entity's position to get it back on the grid. This is what I want in the new editor with the option to turn it off for more natural placement of objects for rocks and such.