All Activity

How can I share the project with you? It's a test project started from the fps example and the project folder is to much big (3GB)

The whole computer locks up when I mouse hover over models. Had to restart several times. Also on the downloads page when I click a pic no option for downloads is appearing. It may work a few times but then stops showing up. Also, not sure if related but lights are not lighting up textures in scene, as if they're not working. I'm on an Acer vega 6, if that's important. Saw some other folks on AMD having issues. Any help appreciated. 5 looks awesome I wanna mess with it. Thanks.

I'll have some more stuff for you after Christmas. I did some work on the timing and found a way to run the logic and rendering thread in sync at any frequency. It feels like playing new Doom games at 200 FPS. I think you will like it.

GeForce RTX 4070

@vega I have added an experimental mouse look feature in 5.0.2 on the beta branch that gets run in the rendering thread. This operates in a manner similar to how the VR headset orientation updates, right before a frame is rendered: https://www.leadwerks.com/community/topic/61318-release-notes/page/37/#findComment-320702 This will provide very low-latency mouse input controls.

What GPU do you have?

5.0.2 beta Added experimental Camera:SetMouseLook command. This handles mouse looking in the rendering thread, right before a frame is drawn, in the same way that our VR orientation updating code operates. This will provide you with very low-latency mouse feedback, ideal for fast-paced games. The arguments are mode, speed, and smoothness and it should be called like this: camera:SetMouseLook(true, 0.1, 0.5)-- 0.1 degree / pixel moved, 0.5 smoothness Speed (second value) should be greater than zero. Smoothness (last value) should be less than 1.0, 0.0 for no smoothing. You only need to call this command once. You should not mix this with your own mouse look code. The camera rotation will be retrieved back from the rendering thread automatically. Note this does not yet handle objects parented to the camera, like a weapon view model. Here is a version of the CameraControls.lua script, adjusted to use this feature. Since the looking behavior is controlled in the rendering thread, you need to disable it before switching to the menu, or is it keep control of the mouse. Hit Alt + F4 to close the window if you get stuck. ---@class CameraControls : Entity CameraControls = {} CameraControls.mousesmoothing = 0.5--"Mouse smoothing" CameraControls.mouselookspeed = 1.0--"Look speed" CameraControls.movespeed = 4.0--"Move speed" ---@param self CameraControls function CameraControls:Start() local camera = Camera(self) if camera ~= nil then camera:SetMouseLook(true, self.mouselookspeed * 0.1, self.mousesmoothing) end self:ListenEvent(EVENT_WORLDPAUSE, self.world) self:ListenEvent(EVENT_WORLDRESUME, self.world) end ---@param self CameraControls ---@param event Event function CameraControls:ProcessEvent(event) local camera = Camera(self) if event.id == EVENT_WORLDPAUSE then if camera ~= nil then camera:SetMouseLook(false, self.mouselookspeed * 0.1, self.mousesmoothing) end elseif event.id == EVENT_WORLDRESUME then if camera ~= nil then camera:SetMouseLook(true, self.mouselookspeed * 0.1, self.mousesmoothing) end end end ---@param self CameraControls function CameraControls:Update() local window = ActiveWindow() if window == nil then return end local speed = self.movespeed / 60.0 if window:KeyDown(KEY_SHIFT) then speed = speed * 10.0 elseif window:KeyDown(KEY_CONTROL) then speed = speed * 0.25 end if window:KeyDown(KEY_E) then self:Translate(0, speed, 0) end if window:KeyDown(KEY_Q) then self:Translate(0, -speed, 0) end if window:KeyDown(KEY_D) then self:Move(speed, 0, 0) end if window:KeyDown(KEY_A) then self:Move(-speed, 0, 0) end if window:KeyDown(KEY_W) then self:Move(0, 0, speed) end if window:KeyDown(KEY_S) then self:Move(0, 0, -speed) end end

Same issue, sent you the project. Might be a Nvidia thing..

I'm still seeing the same issue on my end. I'm updating my Nvidia Drivers right now to see if that'll fix it. If not, I'll share my project and request you to test on the 591.59 Drivers.

Is this still occuring? Can it be reproduced reliably?

@Vladimir Sabantsev I really appreciate your in-depth feedback. I am planning to fix all bugs that can be fixed right now (a few things depend on internal refactoring) before I proceed with a new deep dive into modifications to the renderer for 5.1. The plan is to move lighting shader code into a deferred step (as Leadwerks 4 does) which I think will probably provide better optimization for low-end hardware and simpler shader code.

Carving a 32-sided cylinder out of another one, at a 90 degree angle...this may be as good as it gets. Every other CSG program I've ever seen has simi;ar issues when the geometry gets complex. The crash is fixed on the beta branch, so I will call this finished for now.

5.0.2 beta Several bugs fixed.

6 should work just fine. 1 is not very deep. Is it possible to upload your project so I can try it out? Maybe it is somehow going into an infinite loop, although I don't think that is possible?

What a great implementation and tutorial for Pathfinding! The only miss I can see is that API lacks an ability to get a path that a NavAgent is currently aiming to take. It would be great for strategy games (display the path so that one can plan intermediate steps before sending the troops in) and for multiplayer games (ensure sync btw server and client). I can see there is a Leadwerks::NavMesh::PlotPath method, but it's not quite the same. Maybe it will make sense to separate Navigate into SetDestination, StartNavigate, StopNavigate, GetCurrentPath.

Hi, I've noticed that a neither tutorial page for Collision or API documentation mention an "in-out" trigger volume implementation - they only mention "on enter" trigger (which is in fact "is in" trigger), but no "on exit" trigger. Would be nice to logically separate Leadwerks::Component::Collide into Leadwerks::Component::ColideBegin, Leadwerks::Component::ColideContinues, Leadwerks::Component::ColideEnd to ease implementation of trigger volumes switches (e.g. a pressure plate). Also, there should be an easy way to visually debug collision meshes and physics movement vectors - it eases prototyping by a lot. Not sure if it still applies because I have quite an old version of engine right now, but I've noticed that all the default C++ components have a "virtual method" syntax instead of "method override"- it's a bad practice, because it silences the E1455 "member function declared with 'override' does not override a base class member" which will be triggered in case if the base class method declaration has been changed. As a result, anyone who is using this syntax together with rich inheritance structure and non-pure virtual methods risks to define a method that won't be called after introducing a change in the base class declaration. This semantic mistake can be very irritating and confusing for someone who is learning C++, it's better to teach people to be precise about it. Merry Christmas to everyone reading it on the day it was posted!

With debug levels to 6 the results are the same (not work). With debug levels to 1 all is working well. Maybe this value should be 1 by default.

Set the debug levels to something like 6. 16 is very high and it might just be taking a long time to iterate through the stack.

That's just the result of slicing objects to make multiple convex shapes. Brushes must be convex, so concave shapes are made out of multiple convex shapes.

I don't use any antivirus (only the Windows one). The network is accessible. The problem is not about this project, the same occurs on every project. also, have another minor bugs, like this one where I search for a word an the editor highlight displaced: