klepto2

I hope you don't mind for hijacking this thread, but i would like to add some things (Having this all-in-one thread, might be easier for Josh to keep track of it): More viewport Configuration options (e.g.: view range for large terrain editing) Missing Primitives (Sphere, etc.) Global posteffect system (I know it's on the to-do list) Filter in the Project tab (filtering for scripts/textures/materials etc.) (optionally a filter system like in Visual Studio for CPP projects) Batch functions for folders (convert all textures, or create all materials in a folder) A folder like node in the Map Browser A way to extract meshes from bigger meshes A lot of 3rd party meshes come as one big mesh, and it would be nice to extract the individual meshes into new ones Advanced Terrain editing options Masked brushes Visibility brush Predefined layers (import and export multiple layers) Fill all in the added order (currently you can only fill one layer at a time) Advanced documentation for editor scripting (it is currently hard to guess)

@Josh: My issue was caused by a windows update which corrupted the nvidia driver. A reinstall of the nvidia drivers fixed it. The rendering looks much smoother now and nearly no artifacts are there. Only when resizing the viewport, then the viewports are not updated, otherwise a great enhancement.

No, Nvidia. I will investigate it further tomorrow. Maybe something was odd with the drivers.

Not only in the editor, even simple apps just render a white window with the latest release.

Have you changed something with the latest update? I can't see anything in the viewports anymore since today.

Ok, here is a first list of spinners: Map/Environment Gravity (should be in 0.01 steps at least) FogRanges and Angles (maybe both to 0.1 ranges) Transform All properties for position, scale and rotation should be with a lower increment. (position could maybe adjusted to the grid snap) Physics Mass should be float instead of int Friction/Damping and Elastacity should have at least 0.1 steps Light Range (at least 0.1) Probe Fades should be 0.01 or 0.1 Camera Ranges ( should be 0.1 steps) Navigation All float values should be at least 0.1 (some maybe better 0.01) Options: General Texel size should be 0.1 Viewport Gridsize should be 0.01 Additionally i would suggest to add some functionality to the spinners eg: holding ctrl while clicking increases the increment holding shift decreases the increment some editors add some timing to the spinners: if you do a single click it uses the lowest increment possible if you hold down the button it starts with the lowest increment, but raises the increment in time steps eg, after every second the increment goes up by one digit. also some editors support some dragging features to alter the value in the textboxes

@Josh, as UltraEngine uses Vulkan you might consider using the Vulkan Video extensions ( researched since 2018 and integrated since 2021 ) https://www.khronos.org/blog/an-introduction-to-vulkan-video It enables you to decode and encode H264 (mp4) and maybe other formats (don't know exactly) directly on the gpu and use the frames as normal VKImageViews / VKImages and VkBuffers. A good sample of the integration is located here: https://wickedengine.net/2023/05/07/vulkan-video-decoding/

I know you @Josh are still working in these things, but i think to document them here is practical as well: These are some minor bugs i encountered while using the Editor: The Spinner needs some adjustments, currently the up/down buttons in-/decrement in 1.0 steps, which is annoying on some properties like material displacement or near ranges The Generate-Material Option stores the textures relative to the material, not relative to the base path leads to empty materials when opened in editor some elements using a Scrollable area are initially not drawn correctly. (options-> Viewports(tab)) After first resize of the parent the items are displayed correctly Tab cycling through controls doesn't work Delete key is not supported in input controls Input-Boxes with spinning loose value if you first enter the a value in the textbox and directly use the array buttons without leaving the control prior to the button press. ColorControl: Using the spinner doesn't update the "color icon" (first click updates the button) Selecting a color via the dropdown and using the spinners afterwards resets the value to the previous one Thais it for know more to come.

In the CPP template, the Components are not updated to reflect the Change from Scene to Map. virtual bool Load(table& properties, shared_ptr<Stream> binstream, shared_ptr<Scene> scene, const LoadFlags flags); virtual bool Save(table& properties, shared_ptr<Stream> binstream, shared_ptr<Scene> scene, const SaveFlags flags);

A good starting point might be this topic: I haven't worked with LE since the UltraEngine Early Access, but the essential methods should all be located in Terrain.h and Vegetation.h . If i remember correctly it is also possible to use camera picking to get the actual instance, but that is not for sure.

No, at least not officially supported. In lua there is no way to achieve this. In the cpp version it is possible by using the not documented Vegetation methods of the terrain class, but as said, these are not supported to be used by the end user.

What error do you get? And how does the lua code look like?

Hi, if you mean in UltraEngine, then this is what you're looking for: https://www.ultraengine.com/learn/Terrain_GetElevation?lang=cpp https://www.ultraengine.com/learn/Terrain_GetHeight?lang=cpp GetElevation get the global height of the terrain (including the scale), whereas Getheight get the raw height value (0.0 - 1.0) of the heightmap at the specific position. For Leadwerks Engine the same commands exists.

You can give it a try now: https://github.com/klepto2/ImGui-UltraEngine Everything but MultiViewport rendering should work out of the box. Look at main.cpp for a more detailed sample.

Yes, I plan so. The repo is already Setup and will be filled soon. ( maybe tomorrow;))

You*re completely right. And with the new updates, it is even better The only thing is that in debug mode the culling takes a lot of time (10 - 13ms at average), which leads to a lower update even only one mesh is on screen. I remember that @SpiderPig has made the suggestion, to be able to disable the culling for certain cameras. And for orthographic cameras i fully agree with him. Normally in a 2d space it could be leed to the programmer, what to render and what not. Here are some progress screens of the current Statistics panel i have done with Dear ImGui:

I think so. Thts why i increased the sphere segments a bit. Otherwise the jitter is much more obvious at the segment points.

small experiment, i couldn't resist #include "UltraEngine.h" #include "Components/Player/CameraControls.hpp" using namespace UltraEngine; const float G = 667.4f; const float planet_mass = 1000.0; Vec3 calculateForce(shared_ptr<Entity> planet, shared_ptr<Entity> target) { Vec3 direction = (planet->GetPosition() - target->GetPosition()); float distance = direction.Length(); if (distance == 0) return Vec3(0.0); float forceMagnitude = G * (target->GetMass() * planet_mass) / pow(distance, 2); Vec3 force = direction.Normalize() * forceMagnitude; return force; } int main(int argc, const char* argv[]) { auto displays = GetDisplays(); auto window = CreateWindow("Ultra Engine", 0, 0, 1280, 720, displays[0], WINDOW_CENTER | WINDOW_TITLEBAR); auto world = CreateWorld(); auto framebuffer = CreateFramebuffer(window); auto camera = CreateCamera(world); camera->SetClearColor(0.125); camera->SetFov(70); camera->SetPosition(0, 10, -5); auto light = CreateDirectionalLight(world); light->SetRotation(35, 45, 0); world->SetGravity(0.0, 0.0, 0.0); auto planet = CreateSphere(world, 100.0, 128); planet->SetMass(FLT_MAX - 1); planet->SetPosition(0.0f, -100.0f, 0.0f); planet->SetMaterial(LoadMaterial("Materials\\Developer\\bluegrid.mat")); camera->SetPosition(0.0f, 0.0f, -3.0f); camera->AddComponent<CameraControls>(); camera->SetDebugPhysicsMode(true); vector<shared_ptr<Entity>> boxes; auto box_main = CreateBox(world, 4.0); for(int i = 0; i < 200; i ++) { auto box = box_main->Instantiate(world); box->SetMass(1.0); box->SetColor(1.0, 0.0, 0.0, 1.0); box->SetPosition(Random(120.0, -120.0), Random(120.0, -120.0), Random(120.0, -120.0)); box->Move(0.0, -100.0, 0.0); boxes.push_back(box); } box_main = NULL; bool stage = 0; while (window->Closed() == false and window->KeyDown(KEY_ESCAPE) == false) { if (window->KeyHit(KEY_F2) == true) { camera->SetWireframe(!camera->GetWireframe()); } if (window->KeyHit(KEY_F3) == true) { camera->SetDebugPhysicsMode(!camera->GetDebugPhysicsMode()); } bool hit_space = window->KeyHit(KEY_SPACE); for each (auto box in boxes) { box->AddForce(calculateForce(planet, box)); if (hit_space) { Vec3 direction = (planet->GetPosition() - box->GetPosition()).Normalize(); box->AddForce(-direction * 2500.0); } } world->Update(); world->Render(framebuffer); } return 0; }

If i remember correctly (@Josh correct me if i am wrong) , the gravity is applied to each object in the "NewtonBodySetForceAndTorqueCallback" which means, that while currently only a fixed gravity force is applied, this could be extended to add several "Attractors" or planets. So in theory you could simulate whole a whole universe with planets. and correct gravity. Maybe it would be an option to open up the Callback to override the force calculation for gravity? Maybe something like this (more or less pseudo code): vec3 world_gravity_callback(vec3 pos) { vec3 force = vec3(0); for(auto p : planets) { float distanceToPlanet = calcDistance(pos); force += calcForce(pos, distanceToPlanet); // as Newton engine uses real world units, you can actually use the real physics equations here } return force; } void cb_applyForce(const NewtonBody* const body, dFloat timestep, int threadIndex) { // Fetch user data and body position. UserData *mydata = (UserData*)NewtonBodyGetUserData(body); dFloat pos[4]; NewtonBodyGetPosition(body, pos); // Apply gravity. dFloat force[3] = world->Gravity; if(world->HasGravityCallback) // if custom gravity is used calculate this instead of the fixed gravity { force = world->CalculateGravityForPosition(pos); } NewtonBodySetForce(body, force); }

Indeed, a fresh install solved it. thx

With the latest update, the debug library is damaged.

One small addition: While this Ui-System is mainly for prototyping or debugging/dev things. It might come in handy, that it has a lot of lowlevel drawing functions. Which means, that when i have done the Rendertarget implementation, it could be possible to draw all kinds of 2d shapes, etc into a texture, which can then be rendered into a UltraEngine::Widget. Or you can combine these things and use the Widget system and ImGui together, e.g.: for something like this: https://github.com/thedmd/imgui-node-editor

yes, but that would mean, that the floor itself needs a mass otherwise the force methods will have no impact. To make it physically correct, ( i believe i read that somewhere on the Newtondynamics forums back in Blitzmax times ) Would be to turn off gravity at all and for each object apply a force pointing to the center of your "planet" or maybe in this case just downwards. Of course in the case of a plane you need to conquer the forces applied to the plane to make it stable.

Next Step: Finished the update to the "Dear ImGui" "docking"-branch. The docking branch is a stable dev branch which contains the latest features as docking or multi-viewport systems. Docking is self explaining and I show it in the image below. Essentially multi-viewport means, that you can move windows out of your application, i haven't tested that (new windows will be generated, etc.) Other remarkable milestones: Rendering is more or less optimized. (With some dirty hacks ) I have refactored the Model/Mesh generation and updating method and the main loop still updates with 60fps even with high complex ui's Multiple Fonts rendering is also possible Texture-System is in place. What needs to be done: Replace the current Win32 driver with a native UltraEngine way Add feature to allow render to texture and proper Input handling in this case and of course optimization

I think the Physicsmatrix is only updated for the box itself, not taking the parent into account. You can see this in the first sample: While the box is moving you can actually move through it even though the collision shape is displayed correct. When you move to the original Position the collison will occur.