Jump to content
Ultra Engine Community

Josh

Staff
 View Profile  See their activity

  • Posts

    23,347

  • Joined

  • Last visited

 Content Type 

Blog Entries posted by Josh

  1. Josh

    Vehicle Development

    By Josh,

    I've made progress with the new vehicle system and it is shaping up nicely. The vehicle wheels consist of a slider joint with a spring (the strut) connected to a pivot, connected to the wheel by a hinge joint (the axle). If the wheel can be steered, an additional pivot is inserted between the strut and axle, with a motorized hinge to control steering. There were two big problems in addition to this that need to be solved in order to make a vehicle that is stable at high speeds.
    First, the mass matrix of the tires needs to be spherical. The mass matrix is the distribution of mass across an object. A brick and a 2x4 piece of lumber probably have about the same mass, but have a different mass matrix. Therefore the brick should spin more easily than the lumber. If you don't make the mass matrix for the tires spherical you will get bad wobbling at high speeds, like this video shows:
    When the mass matrix is fixed this problem goes away. The vehicle gets up to 90 MPH, and although there are other issues, there is no tire wobble.
    The other issue that needs to be solved can be seen in the video above. At high speeds the tire collisions become inaccurate and the vehicle bounces a lot. We need to replace the default collision with a volume raycast coming from the top position the wheel can sit on the shock, going down to the extended position of the strut. This is the part I haven't done yet, but I know it can be done.
    I think the new vehicle system will offer a lot of flexibility and possibilities for future features since it is mostly made with the standard physics features.
  2. Josh

    Vehicle WIP in Leadwerks 4.6

    By Josh,

    Here's a look at the new vehicle system that is being developed. The API has been simplified so you simply create a vehicle, add as many tires as you want, and start using it. The AddTire() command now accepts a model and the dimensions of the tire are calculated from the bounds of the mesh.
    class Vehicle { int AddTire(Model* model, bool steering=false, const float spring=500.0f, const float springrelaxation = 0.1f, const float springdamping = 10.0f); void SetGas(const float accel); void SetBrakes(const float brakes); void SetSteering(const float angle); static Vehicle* Create(Entity* entity); }; A script will be provided which turns any vehicle model into a ready-to-use playable vehicle. The script searches for limb names that start with "wheel" or "tire" and turns those limbs into wheels. If they are positioned towards the front of the car, the script assumes the wheels can be turned with steering. You can also reverse the orientation of the vehicle if the model was designed backwards.
    There is one big issue to solve still. When a vehicle drives on flat terrain the tires catch on the edges of the terrain triangles and the whole vehicle bounces around badly. I'm looking into how this can be solved with custom collision overrides. I do not know how long this will take, so it might or might not be ready by Christmas.
  3. Josh
    I'm wrapping up the new multiplayer capabilities for Leadwerks 4.6, and I am very excited about what this offers developers.
    We saw previously how the lobby system is used to create or join games, and how to retrieve Steam IDs for messaging. Once we have joined a game we can start sending messages with the P2P::Send command, which includes a few overloads:
    static bool P2P::Send(uint64 steamid, const int messageid, const int channel = 0, const int flags = 0); static bool P2P::Send(uint64 steamid, const int messageid, std::string& data, const int channel = 0, const int flags = 0); static bool P2P::Send(uint64 steamid, const int messageid, Bank* data, const int channel = 0, const int flags = 0); static bool P2P::Send(uint64 steamid, const int messageid, Stream* data, const int channel = 0, const int flags = 0); static bool P2P::Send(uint64 steamid, const int messageid, const void* data, const int size, const int channel = 0, const int flags = 0); Each message has an ID and can be followed by additional data in the form of a string, bank, or stream. Voice chat is handled automatically, but the rest is up to you to decide what data the messages should contain. I provide examples for text chat, joining and leaving a game, and movement.
    Receiving messages from other players is extremely simple:
    static Message* P2P::Receive(const int channel = 0); The message object has information contained within it:
    class Message { public: int id; Stream* stream; uint64 userid }; We can evaluate messages based on their ID. For example, here is a text chat message being received:
    auto message = P2P::Receive() if (message) { if (message->id == MESSAGE_CHAT && message->stream != nullptr) { Print(message->stream->ReadString()); } } A new multiplayer game template will be included, with out-of-the-box support for text and voice chat, public servers, and player movement.

    You can download the test app and try it out here:
    Thanks to everyone who has helped me test this!
  4. Josh
    The next update will include a new networking system with built-in voice chat for multiplayer games.
    Voice communication is built into your game and can be enabled simply by turning it on when a specific key is pressed:
    void Voice::SetRecording(window->KeyDown(Key::T)) You can selectively filter out users so your voice only gets sent to your own team or to a specific player:
    void Voice::SetFilter(const uint64 steamid, const bool state) When another player sends their voice data to you, the engine will automatically receive and play the sound. You can also retrieve a sound source for a specific player and make adjustments to it. This can be used to enable 3D spatialization and position the sound source where the player is, for VR voice chat.
    Source* Voice::GetPlayerSource(const uint64_t steamid) When I first implemented this the sound was sometimes choppy. I added some automatic adjustment of the pitch to slow down the sound a bit if new data is not received yet, and to speed it up if it falls too far behind. This seems to work really well and I'm sure it must be a common technique in applications like Twitch and Skype.
    A new multiplayer game template will be provided that shows how to set up the framework for a multiplayer game. Here's a video preview of the voice communication in action.
     
  5. Josh
    The new Lobby system in Leadwerks 4.6 allows you to create a public listing of your multiplayer game for others to join. This uses the Steamworks library. You can tap into the Steamworks lib by piggybacking on the default "SpaceWar" example game, which uses the Steam app ID 480. This is set up by default when you create a new Leadwerks project.
    Now you might think of a lobby as a place where people hang out and chat before the game starts. You can treat it like this, but it's best to keep the lobby up as the game is running. This will allow other people to find the game to join, if it isn't full or if someone leaves the game. So a lobby is better described as a publicly advertised game others can join.
    Creating a new lobby to advertise our game is easy. We just call a command to create it, and then we will set two string values. The game title is set so that we can later retrieve only lobbies that are running this particular game. (This should be done if you are using the SpaceWar app ID instead of your own Steam ID.) We also add a short description that can display information about the game.
    Lobby* mylobby = Lobby::Create(); mylobby->SetKey("game", "MyGameTitle"); mylobby->SetKey("description", "Here is my lobby!"); It's also easy to retrieve a list of lobbies:
    int count = Lobby::Count(); for (int i = 0; i < count; ++i) { Lobby* lobby = Lobby::Get(i); } We can use GetKey() to look for lobbies that are running the same game we are:
    if (lobby->GetKey("game") == "MyGameTitle") We can retrieve the owner of the lobby with this command that will return a Steam ID:
    uint64 steamid = lobby->GetOwner(); Once you have that Steam ID, that is all you need to start sending messages through the new P2P networking system. More on that later.
    And we can also retrieve a list of all members in the lobby:
    int count = lobby->CountMembers(); for (int k = 0; k < count; ++k) { uint64 steamid = lobby->GetMember(k); } After a lobby is created, it will have one member, which will be the same Steam ID as the owner.
    Joining a lobby is simple enough:
    if (lobby->Join()) System::Print("Joined lobby!"); And leaving is just as easy:
    lobby->Leave() Now here's the magical part: When the owner of the lobby leaves, the lobby is not destroyed. Instead, the system will automatically choose another player to become the owner of that lobby, so the multiplayer game can keep going! The lobby will not be destroyed until everyone leaves the game.
  6. Josh
    A new build is available on the beta branch. This changes the model picking system to use a different raycasting implementation under-the-hood. Sphere picking (using a radius) will also now correctly return the first hit triangle. You will also notice much faster loading times when you load up a detailed model in the editor!
    Additional parameters have been added to the Joint::SetSpring command:
    void Joint::SetSpring(const float spring, const float relaxation = 1.0f, const float damper = 0.1f) The classes for P2P networking, lobbies, and voice communication have been added but are not yet documented and may still change.
  7. Josh

    Digital Reorganization

    By Josh,

    It's nice to have my big monster computer back, and everything is just the same as I left it. I have a triple-boot machine with Windows 10 and both 32 and 64 bit versions of Ubuntu 16.04. This is easier than trying to set up multi-arch compiling on one install of the OS, though I look forward to the day I no longer have to bother with it.
    I'm running out of hard drive space on my Windows 10 500 GB SSD so I ordered a 1 TB SSD, and I plan to transfer the 500 GB SSD into my laptop to replace the small SSD it came with. The laptop also contains a terabyte HDD, which was supposed to function as an add-on storage drive, but I am going to install Ubuntu on that. Then I will be able to develop for Windows and Linux on the go, wherever I am. The only thing that would be better than this would be a triple-boot Macbook Pro (maybe someday). Actually, that wouldn't be better. A 17" screen is something I can actually work on, and a 15" screen is no good for programming. So this is the best there is.
    A 3 TB external HD is being used to back up the Amazon S3 bucket (nearly 60 GB now!), and I copied the entire contents of the 32-bit Ubuntu install onto it as a backup. There was 20 or so "special files" the system could not copy so I don't know if it a true backup, but I think I will be okay. I am attempting to do the same with the 64-bit install files running from the 32-bit OS, but so far I keep getting errors during the copy process. I know you can make an image of the disk, but the disk image is the full size of the hard drive, not just the files it contained, and frankly since it is Linux I expect something else will break in the restore process, so I am not worrying about that.
    I'm also porting our SVN repositories over to a new service that offers more storage space, although it is quite a lot more expensive.
    My local Leadwerks working copy has been reverted back to the exact version that was used to release the last build. I'm going to go through manually and re-insert the changes I want from the last six months, because most of the work done was on the new engine. I think there will be less mistakes if I do it this way, since the source got chopped up a lot with #ifdef statements before I finally broke Turbo off from Leadwerks and put it in its own repo.
    The next Leadwerks update will include bug fixes, a new vehicles system, and peer-to-peer networking through Steam.
  9. Josh

    Basic Scene Benchmarks

    By Josh,

    I did some work optimizing the new renderer to discrete cards and came up with a new benchmark. This scene is interesting because there is not much in the scene, so the culling does not benefit much xrom multithreading, since there is so little work to do. The screen is filled with a spotlight in the foreground, and in the background a point light is visible in the distance. Both engines are running at 1280x720 resolution. This is really a pure test of deferred vs. forward lighting.
    AMD R9 200
    Leadwerks: 448 FPS
    Turbo: 648 FPS (44% faster)
    On this older AMD card we see that forward rendering automatically gives a significant boost in performance, likely due to not having to pass around a lot of big textures that are being written to.


    GEForce 1070M (Laptop)
    Leadwerks 4: 120 FPS
    Turbo: 400 FPS (333% faster)
    Here we see an even bigger performance boost. However, these are two very different cards and I don't think it's safe to say yet if one GPU vendor will get more from the new engine.
    Intel Graphics 4000
    Leadwerks 4: 67 FPS  (18% faster)
    Turbo: 57 FPS
    This is an interesting result because integrated graphics tend to struggle with pixel fillrate, but seem to have no problems with texture bandwidth since they are using regular old CPU memory for everything. Although I think the new engine will run faster on Intel graphics (especially newer CPUs) when the scene is loaded down, it seems to run a bit slower in a nearly empty scene. I think this demonstrates that if you build a renderer specifically to take advantage of one type of hardware (discrete GPUs) it will not automatically be optimal on other types of hardware with different architectures. I commented out the lighting code and the framerate shot way up, so it definitely does seem to be a function of the pixel shader, which is already about as optimized as can be.
    Overall, I think the new engine will show higher relative performance the more you throw at it, but an empty scene may run a bit slower on older Intel chips since the new renderer is optimized very specifically for discrete GPUs. The parallel capabilities of discrete GPUs are relied on to handle complex lighting in a single pass, while texture bandwidth is reduced to a minimum. This is in line with the hardware trend of computing power increasing faster than memory bandwidth. This also shows that low to mid-range discrete GPUs stand to make the most gains.
  10. Josh
    Here is a script for a first-person player. All of this is actually working now. It's very interesting that physics, rendering, culling, and Lua game code are all executing at the same time on different threads. CPU usage in a simple scene and some physics is about 35% on a quad core processor, which is good.
    I think the most interesting thing here is that to break the kinematic joint used to control an object the player picks up, you simply set the variable to nil. However, I did run into one problem with the garbage collector. If you do not call collectgarbage() after setting the joint variable to nil, the joint will not get deleted, and it will still affect the entity. This is not good. I got around this by placing a call to collectgarbage() immediately after getting rid of the joint, but I don't think I like that.  I could just make the engine call the Lua garbage collector once before the world update and once before the world render. Originally, I thought Lua would be a big problem for VR applications but since the Lua game code gets its own thread, with a maximum execution time of about 16 milliseconds just for your game code, that is plenty of time to be wasteful with the GC, and I think we will be just fine even with high-performance VR games! Remember, the rendering thread runs at 90 hz but the game logic thread only runs at 60 or even 30 hz, so it's no big deal.
    However, I am leaning towards adding a Destroy() function that frees everything it can from an object without actually deleting it.
    Also note that window and context are global variables. There is no "current" window or context, so this code expect that these have been created in Lua or C++ and set as global variables.
    Script.lookspeed=0.1--float Script.movespeed=3--float Script.maxcarrymass=10--float Script.throwforce=100--float function Script:Start() --Player physics if self.mass==0 then self.mass=70 end self:EnablePhysics(PHYSICS_PLAYER) self.collisiontype=COLLISION_PLAYER --Set up camera self.camera=CreateCamera(self:GetWorld()) local cx=Round(context:GetWidth()/2) local cy=Round(context:GetHeight()/2) window:HideMouse() window:SetMousePosition(cx,cy) self.camerarotation=self:GetRotation(true) end function Script:Update() --Mouse look local cx = Round(context:GetWidth()/2) local cy = Round(context:GetHeight()/2) local mousepos = window:GetMousePosition() window:SetMousePosition(cx,cy) local mx = mousepos.x - cx local my = mousepos.y - cy self.camerarotation.x = self.camerarotation.x + my * self.lookspeed self.camerarotation.y = self.camerarotation.y + mx * self.lookspeed self.camerarotation.x = Clamp(self.camerarotation.x,-90,90) self.camera:SetRotation(self.camerarotation,true) --Player movement local jump=0 if window:KeyDown(KEY_SPACE) then if self:GetAirborne()==false then jump=6 end end if self:GetAirborne() then jump = 0 end local move=0 if window:KeyDown(KEY_W) then move=move+1 end if window:KeyDown(KEY_S) then move=move-1 end local strafe=0 if window:KeyDown(KEY_D) then strafe=strafe+1 end if window:KeyDown(KEY_A) then strafe=strafe-1 end self:SetPlayerInput(self.camerarotation.y, move*self.movespeed, strafe*self.movespeed, jump, false,0,0,true,0) self.camera:SetPosition(self:GetPosition(true),true) self.camera:Translate(0,1.7,0,true) --Update carried object if self.carryjoint~=nil then --Update kinematic joint local position=TransformPoint(self.carryposition,self.camera,nil) local rotation=TransformRotation(self.carryrotation,self.camera,nil) self.carryjoint:SetTarget(position,rotation) --Throw if window:MouseHit(MOUSE_LEFT) then self.carryjoint.child:AddForce(TransformNormal(0,0,1,self.camera,nil)*self.throwforce) self.carryjoint.child:EnableGravity(true) self.carryjoint=nil collectgarbage() end end --Interact with environment if window:KeyHit(KEY_E) then if self.carryjoint~=nil then --Drop carried object self.carryjoint.child:EnableGravity(true) self.carryjoint=nil collectgarbage() else --Find new object to interact with local pickinfo = PickInfo() if self.camera:Pick(0,0,10,pickinfo,0,true,0) then local entity=pickinfo.entity if entity.Activate~=nil then --Activate the object entity:Activate(self) else --Pick it up if its light enough if entity.mass>0 and entity.mass<=self.maxcarrymass then if self.carryjoint~=nil then --Drop carried object self.carryjoint=nil collectgarbage() end local p=entity:GetPosition(true) entity:EnableGravity(false) self.carryjoint=CreateKinematicJoint(p.x,p.y,p.z,entity) self.carryposition=TransformPoint(entity:GetPosition(true),nil,self.camera) self.carryrotation=TransformRotation(entity:GetQuaternion(true),nil,self.camera) end end end end end end  
  11. Josh
    I've successfully converter the sliding door script over to the new API. This will all look very familiar, but there are some cool points to note.
    The entity mass can be retrieved and set with a property as if it was just a regular variable. Underneath the hood, the engine is making method calls. I decided to prefix most field names with "slidingdoor_" to prevent other scripts from accidentally interfering. The "enabled" value, however, is meant to be shared. The Entity is the script object. No more "entity.script.entity.script..." stuff to worry about. All of this actually works in the new engine. Entity.enabled=true--bool "Enabled" Entity.slidingdoor_openstate=false--bool "Start Open" Entity.slidingdoor_distance=Vec3(1,0,0)--Vec3 "Distance" Entity.slidingdoor_movespeed=1--float "Move speed" 0,100,3 Entity.slidingdoor_opensoundfile=""--path "Open Sound" "Wav File (*wav):wav|Sound" Entity.slidingdoor_closesoundfile=""--path "Close Sound" "Wav File (*wav):wav|Sound" Entity.slidingdoor_loopsoundfile=""--path "Loop Sound" "Wav File (*wav):wav|Sound" Entity.slidingdoor_manualactivation=false--bool "Manual activate" Entity.slidingdoor_closedelay=2000--int "Close delay" function Entity:Start() self:EnableGravity(false) if self.mass==0 then self.mass=10 end --In Leadwerks 4: --if self.entity:GetMass()==0 then self.entity:SetMass(10) end -- :) self.slidingdoor_sound={} self.slidingdoor_sound.open = LoadSound(self.slidingdoor_opensoundfile) self.slidingdoor_sound.loop = LoadSound(self.slidingdoor_loopsoundfile) self.slidingdoor_sound.close = LoadSound(self.slidingdoor_closesoundfile) if self.slidingdoor_sound.loop~=nil then self.slidingdoor_loopsource = CreateSource() self.slidingdoor_loopsource:SetSound(self.slidingdoor_sound.loop) self.slidingdoor_loopsource:SetLoopMode(true) self.slidingdoor_loopsource:SetRange(50) end --if self.slidingdoor_manualactivation==false then self.Use=nil end self.slidingdoor_opentime=0 --Create a motorized slider joint local position = self:GetPosition(true) --You could also do this: --local position = self.mat[3].xyz local pin=self.slidingdoor_distance:Normalize() self.slidingdoor_joint=CreateSliderJoint(position.x,position.y,position.z,pin.x,pin.y,pin.z,self) if self.openstate then self.slidingdoor_openangle=0 self.slidingdoor_closedangle=self.slidingdoor_distance:Length() else self.slidingdoor_openangle=self.slidingdoor_distance:Length() self.slidingdoor_closedangle=0 end self.slidingdoor_joint:EnableMotor(true) self.slidingdoor_joint:SetMotorSpeed(self.slidingdoor_movespeed) end function Entity:Use() self:Open() end function Entity:Toggle() if self.enabled then if self.slidingdoor_openstate then self:Close() else self:Open() end end end function Entity:Open() if self.enabled then self.slidingdoor_opentime = CurrentTime() if self.slidingdoor_openstate==false then if self.slidingdoor_sound.open then self:EmitSound(self.slidingdoor_sound.open) end self.slidingdoor_joint:SetTarget(self.slidingdoor_openangle) self.slidingdoor_openstate=true if self.slidingdoor_loopsource~=nil then self.slidingdoor_loopsource:SetPosition(self:GetPosition(true)) if self.slidingdoor_loopsource:GetState()==SOURCE_STOPPED then self.slidingdoor_loopsource:Play() end end end end end function Entity:Close() if self.enabled then if self.slidingdoor_openstate then if self.slidingdoor_sound.close then self:EmitSound(self.slidingdoor_sound.close) end self.slidingdoor_joint:SetTarget(self.slidingdoor_closedangle) self.slidingdoor_openstate=false if self.slidingdoor_loopsource~=nil then self.slidingdoor_loopsource:SetPosition(self:GetPosition(true)) if self.slidingdoor_loopsource:GetState()==0 then self.slidingdoor_loopsource:Play() end end end end end function Entity:Disable() self.enabled=false end function Entity:Enable() self.enabled=true end function Entity:Update() --Disable loop sound if self.slidingdoor_sound.loop~=nil then local angle if self.slidingdoor_openstate then angle = self.slidingdoor_openangle else angle = self.slidingdoor_closedangle end if math.abs(self.slidingdoor_joint:GetAngle()-angle)<0.1 then if self.slidingdoor_loopsource:GetState()~=SOURCE_STOPPED then self.slidingdoor_loopsource:Stop() end else if self.slidingdoor_loopsource:GetState()==SOURCE_STOPPED then self.slidingdoor_loopsource:Resume() end end if self.slidingdoor_loopsource:GetState()==SOURCE_PLAYING then self.slidingdoor_loopsource:SetPosition(self:GetPosition(true)) end end --Automatically close the door after a delay if self.slidingdoor_closedelay>0 then if self.slidingdoor_openstate then if CurrentTime()-self.slidingdoor_opentime>self.slidingdoor_closedelay then self:Close() end end end end  
  12. Josh

    Leadwerks 4.6 Development

    By Josh,

    With Christmas approaching I am now turning my attention to finishing Leadwerks Game Engine 4.6. The major features planned are peer-to-peer networking and a new vehicles system, as well as miscellaneous bug fixes. A beta build will be made available early on Steam for testing.
  13. Josh
    A big update for the beta of the upcoming Turbo Game Engine is now available, adding support for VR and Lua script!
    VR Rendering
    Turbo Game Engine now supports VR rendering, with support for true single-pass stereoscopic rendering on Nvidia GPUs. Other hardware will use a double-rendering path that is still faster than Leadwerks. To turn VR on simply call EnableVR(). Controllers are not yet supported, just rendering.
    Lua Scripting
    Lua script is now supported in Turbo! The amount of classes and functions is limited, but the foundation for full Lua support is in. Here are some of the great features in the new system.
    No Script Object
    All scripts operate on the entity itself. Instead of this:
    function Script:Update() self.entity:Turn(1,0,0) end You type this:
    function Object:Update() self:Turn(1,0,0) end This is especially nice when it comes to functions that retrieve another entity since you don't have to type "entity.script" to get Lua values and functions:
    function Object:Collision(entity,position,normal,speed) entity:Kill() end Smart Pointers
    Lua garbage collection now works together with C++11 smart pointers. You will never have to deal with invalid pointers or object deletion again. There is no Release() anymore. Just set your variable to nil to delete an object:
    local box = CreateBox(world) box = nil If you want the object to be collected immediately, you can force a GC step like this:
    local box = CreateBox(world) box = nil collectgarbage() Best of all, because Lua runs on the game logic thread separate from the rendering thread, it's perfectly fine to use Lua high-performance applications, even in VR. A pause in the game execution for Lua garbage collection will not pause the rendering thread.
    Multiple Scripts
    You can add any number of scripts to an object with the AddScript command:
    entity->AddScript("Scripts/Object/test.lua") Scripts on Any Object (Experimental)
    Now all object types can have scripts, not just entities:
    material->AddScript("Scripts/Object/Appearance/Pulse.lua") Set and Get Script Values in C++
    You can easily set and get values on any object, whether or not it has had a script added to it:
    entity->SetValue("health",100); Print(entity->GetNumberValue("health")); Vector Swizzle
    Using getters and setters I was able to implement vector swizzles. If you write shaders with GLSL you will be familiar with this convenient  feature:
    local a = Vec3(1,2,3) local b = a.xz --equivalent to Vec2(a.x,a.z) In Lua you can now return any combination of vector elements, using the XYZW or RGBA names. The code below will swap the red and blue elements of a color:
    local color = Vec4(1,0,0.5,1) local color = color.bgra Not only can you retrieve a value, but you can assign values using the swizzle:
    local v = Vec3(1,2,3) v.zy = Vec2(1,2) Print(v) --prints 1,2,1 Note there are presently only two engine script hooks that get called, Start() and Update().
    Simpler Uber Shaders
    I decided to do away with the complicated #ifdef macros in the shaders and use if statements within a single shader:
    //Diffuse Texture if (texturebound[0]) { color *= texture(texture0,texcoords0); } This makes internal shader management MUCH simpler because I don't have to load 64 variations of each shader. I am not sure yet, but I suspect modern GPUs will handle the branching logic with no performance penalty. It also means you can do things like have a material with just a color and normal map, with no need for a diffuse map. The shader will just adjust to whatever textures are present.
    A C++ Turbo program now looks like this:
    #include "Turbo.h" using namespace Turbo; int main(int argc, const char *argv[]) { //Create a window auto window = CreateWindow("MyGame", 0, 0, 1280, 720); //Create a rendering context auto context = CreateContext(window); //Create the world auto world = CreateWorld(); //This only affects reflections at this time world->SetSkybox("Models/Damaged Helmet/papermill.tex"); shared_ptr<Camera> camera; auto scene = LoadScene(world, "Maps/start.map"); //Create a camera if one was not found if (camera == nullptr) { camera = CreateCamera(world); camera->Move(0, 1, -2); } //Set background color camera->SetClearColor(0.15); //Enable camera free look and hide mouse camera->SetFreeLookMode(true); window->HideMouse(); while (window->KeyHit(KEY_ESCAPE) == false and window->Closed() == false) { //Camera movement if (window->KeyDown(KEY_A)) camera->Move(-0.1, 0, 0); if (window->KeyDown(KEY_D)) camera->Move(0.1, 0, 0); if (window->KeyDown(KEY_W)) camera->Move(0, 0, 0.1); if (window->KeyDown(KEY_S)) camera->Move(0, 0, -0.1); //Update the world world->Update(); //Render the world world->Render(context); } return 0; } If you would like to try out the new engine and give feedback during development, you can get access now for just $5 a month.
    I am now going to turn my attention to Leadwerks 4.6 and getting that ready for the Christmas season.
    The next step in Turbo development will probably be physics, because once that is working we will have a usable game engine.
  14. Josh
    During development of Leadwerks Game Engine, there was some debate on whether we should allow multiple scripts per entity or just associate a single script with an entity. My first iteration of the scripting system actually used multiple scripts, but after using it to develop the Darkness Awaits example I saw a lot of problems with this. Each script used a different classname to store its variables and functions in, so you ended up with code like this:
    function Script:HurtEnemy(amount) if self.enemy ~= nil then if self.enemy.healthmanager ~= nil then if type(self.enemy.healthmanager.TakeDamage)=="function" then self.enemy.healthmanager.TakeDamage(amount) end end end end I felt this hurt script interoperability because you had to have a bunch of prefixes like healthmanager, ammomanager, etc. I settled on using a single script, which I still feel was the better choice between these two options:
    function Script:HurtEnemy(amount) if self.enemy ~= nil then if type(self.enemy.TakeDamage)=="function" then self.enemy.TakeDamage(amount) end end end Scripting in Turbo Game Engine is a bit different. First of all, all values and functions are attached to the entity itself, so there is no "script" table. When you access the "self" variable in a script function you are using the entity object itself. Here is a simple script that makes an entity spin around its Y axis:
    function Entity:Update() self:Turn(0,0.1,0) end Through some magic that is only possible due to the extreme flexibility of Lua, I have managed to devise a system for multiple script attachments that makes sense. There is no "component" or "script" objects itself, adding a script to an entity just executes some code that attached values and functions to an entity. Adding a script to an entity can be done in C++ as follows:
    model->AttachScript("Scripts/Objects/spin.lua"); Or in Lua itself:
    model:AttachScript("Scripts/Objects/spin.lua"); Note there is no concept of "removing" a script, because a script just executes a bit of code that adds values and functions to the entity.
    Let's say we have two scripts named "makeHealth100 and "makeHealth75".
    MakeHealth100.lua
    Entity.health=100 MakeHealth75.lua
    Entity.health=75 Now if you were to run the code below, which attaches the two scripts, the health value would first be set to 100, and then the second script would set the same value to 75, resulting in the number 75 being printed out:
    model->AttachScript("Scripts/Objects/MakeHealth100.lua"); model->AttachScript("Scripts/Objects/MakeHealth75.lua"); Print(entity->GetNumber("health")); Simple enough, right? The key point here is that with multiple scripts, variables are shared between scripts. If one scripts sets a variable to a value that conflicts with another script, the two scripts won't work as expected. However, it also means that two scripts can easily share values to work together and create new functionality, like this health regeneration script that could be added to work with any other scripts that treat the value "health" as a number.
    HealthRegen.lua
    Entity.healthregendelay = 1000 function Entity:Start() self.healthregenupdatetime = CurrentTime() end function Entity:Update() if self.health > 0 then if CurrentTime() - self.healthregenupdatetime > self.healthregendelay then self.health = self.health + 1 self.health = Min(self.health,100) end end end What about functions? Won't adding a script to an entity overwrite any functions it already has attached to it? If I treated functions the same way, then each entity could only have one function for each name, and there would be very little point in having multiple scripts! That's why I implemented a special system that copies any added functions into an internal table. If two functions with the same name are declared in two different scripts, they will both be copied into an internal table and executed. For example, you can add both scripts below to an entity to make it both spin and make the color pulse:
    Spin.lua
    function Entity:Update() self:Turn(0,0.1,0) end Pulse.lua
    function Entity:Update() local i = Sin(CurrentTime()) * 0.5 + 0.5 self:SetColor(i,i,i) end When the engine calls the Update() function, both copies of the function will be called, in the order they were added.
    But wait, there's more.
    The engine will add each function into an internal table, but it also creates a dummy function that iterates through the table and executes each copy of the function. This means when you call functions in Lua, the same multi-execution feature will be available. Let's consider a theoretical bullet script that causes damage when the bullet collides with something:
    function Entity:Collision(entity,position,normal,speed) if type(entity.TakeDamage) == "function" then entity:TakeDamage(20) end end If you have two (or more) different TakeDamage functions on different scripts attached to that entity, all of them would get called, in order.
    What if a function returns a value, like below?:
    function Entity:Update() if self.target ~= nil then if self.target:GetHealth() <= 0 then self.target = nil --stop chasing if dead end end end If multiple functions are attached that return values, then all the return values are returned.

    To grab multiple returned values, you can set up multiple variables like this:
    function foo() return 1,2,3 end a, b, c = foo() print(a) --1 print(b) --2 print(c) --3 But a more practical usage would be to create a table from the returned values like so:
    function foo() return 1,2,3 end t = { foo() } print(t[1]) --1 print(t[2]) --2 print(t[3]) --3 How could this be used? Let's say you had a script that was used to visually debug AI scripts. It did this by checking to see what an entity's target enemy was, by calling a GetTarget() function, and then creating a sprite and aligning it to make a line going from the AI entity to its target it was attacking:
    function Entity:UpdateDisplay() local target = self:GetTarget() self.sprite = CreateSprite() local p1 = self.entity:GetPosition() local p2 = target:GetPosition() self.sprite:SetPosition((p1 + p2) * 0.5) self.sprite:AlignToVector(p2 - p1) self.sprite:SetSize(0.1,(p2-p1):Length()) end Now let's imagine we had a tank with a main gun as well as an anti-aircraft gun that would ward off attacks from above, like this beauty I found on Turbosquid:

    Let's imagine we have two different scripts we attach to the tank. One handles AI for driving and shooting the main turret, while the other just manages the little machine gun. Both the scripts have a GetTarget() function, as the tank may be attacking two different enemies at once.
    We can easily modify our AI debugging script to handle multiple returned values as follows:
    function Entity:UpdateDisplay() local targets = { self:GetTarget() } --all returned values get put into a table for n,target in ipairs(targets) do local sprite = CreateSprite() self.sprites.insert(sprite) local p1 = self.entity:GetPosition() local p2 = target:GetPosition() sprite:SetPosition((p1 + p2) * 0.5) sprite:AlignToVector(p2 - p1) sprite:SetSize(0.1,(p2-p1):Length()) end end However, any scripts that are not set up to account for multiple returned values from a function will simply use the first returned value, and proceed as normal.
    This system supports both easy mix and match behavior with multiple scripts, but keeps the script code simple and easy to use. Scripts have easy interoperability by default, but if you want to make your function and variable names unique to the script it is easy to do so.
    Let me know if you have any other ideas for scripting in Turbo Game Engine.
  15. Josh
    Virtual reality rendering is very demanding on hardware for two reasons. First, the refresh rate of most VR headsets is 90 hz instead of the standard 60 hz refresh rate most computer monitors operate at. This means that rendering must complete in about 11 milliseconds instead of 16. Second, we have to render the scene twice with two different views, one for each eye. Without any special optimizations, this roughly means that we have to pack 16 milliseconds worth of rendering code into five milliseconds.
    There are a few optimizations we can make to improve efficiency over a naive implementation. Although VR rendering requires two different views to be rendered, the two views are only a few centimeters apart.

    We can perform culling for both views at once by simply widening the camera frustum a little bit so that both eyes are included the camera volume.

    For rendering, Nvidia provides an extension for single-pass stereo rendering. This doubles up the geometry and renders to two different viewports at once, ensuring that the engine makes the same number of draw calls when rendering in stereo or normal mode. (The same can be done using a geometry shader with Intel graphics, although it has yet to be determined if VR will be possible on this hardware.) Here is the result:
    Combined with all the other optimizations I've packed into Turbo, like clustered forward rendering and a multithreaded rendering architecture designed specifically for VR, this makes VR rendering blazingly fast. How fast is it? Well, it's so fast that SteamVR diagnostics thinks that it is going backwards in time. Take a look at the timer in the lower left corner here:

    The obvious conclusion is that we have successfully broken the speed of light barrier and time travel will be possible shortly. Start thinking about what items or information you want to gift your past self with now, so that you can be prepared when I start offering temporal tourism packages on this site.

  16. Josh
    I'm using the excellent sol2 library to interface C++ and Lua in the upcoming Turbo Game Engine. I've decided not to create an automatic header parser like I did for tolua++ in Leadwerks 4, for the following reasons:
    There are a lot of different options and special cases that would probably make a header parser a very involved task with me continually discovering new cases I have to account for. sol2 is really easy to use. Each class I want available to Lua will have a static function the Lua virtual machine code can call when a new Lua state is created. The new_usertype method is able to expose a C++ class to Lua in a single command. At a minimum, the name of the class and the base class should be defined. This method can accept a lot of arguments, so I am going to break it up over several lines.
    void Vec3::InitializeClass(sol::state* luastate) { //Class luastate->new_usertype<Vec3> ( //Name "Vec3", //Hierarchy sol::base_classes, sol::bases<Object>() ); } We can export members to Lua very easily just by adding more arguments in the call to new_usertype:
    //Members "x", &Vec3::x, "y", &Vec3::y, "z", &Vec3::z, Metamethods are special operations like math operands. For example, adding these arguments into the method call will set all the metamethods we want to use.
    //Metamethods sol::meta_function::to_string, &Vec3::ToString, sol::meta_function::index, [](Vec3& v, const int index) { if (index < 0 or index > 2) return 0.0f; return v[index]; }, sol::meta_function::new_index, [](Vec3& v, const int index, double x) { if (index < 0 or index > 2) return; v[index] = x; }, sol::meta_function::equal_to, &Vec3::operator==, sol::meta_function::less_than, &Vec3::operator<, sol::meta_function::subtraction, sol::resolve<Vec3(const Vec3&)>(&Vec3::operator-), sol::meta_function::addition, sol::resolve<Vec3(const Vec3&)>(&Vec3::operator+), sol::meta_function::division, sol::resolve<Vec3(const Vec3&)>(&Vec3::operator/), sol::meta_function::multiplication, sol::resolve<Vec3(const Vec3&)>(&Vec3::operator*), sol::meta_function::unary_minus, sol::resolve<Vec3()>(&Vec3::operator-), sol::meta_function::modulus, &Vec3::operator%, And then finally the class methods we want to use can be exposed as follows:
    //Methods "Length", &Vec3::Length, "Cross", &Vec3::Cross, "Normalize", &Vec3::Normalize, "Inverse", &Vec3::Inverse, "Distance", &Vec3::DistanceToPoint In C++ you can not retrieve a pointer to a function, so we are going to create a quick Lambda expression and expose it as follows:
    //Constructor luastate->set_function("Vec3", [](float x, float y, float z) {return Vec3(x, y, z); } ); This allows us to create a Vec3 object in Lua the same way we would with a constructor in C++.
    Here is the complete Vec3 class initialization code, which makes Lua recognize the class, exposes the members, adds math operations, and exposes class methods:
    void Vec3::InitializeClass(sol::state* luastate) { //Class luastate->new_usertype<Vec3> ( //Name "Vec3", //Hierarchy sol::base_classes, sol::bases<Object>(), //Members "x", &Vec3::x, "y", &Vec3::y, "z", &Vec3::z, "r", &Vec3::x, "g", &Vec3::y, "b", &Vec3::z, //Metamethods sol::meta_function::to_string, &Vec3::ToString, sol::meta_function::index, [](Vec3& v, const int index) { if (index < 0 or index > 2) return 0.0f; return v[index]; }, sol::meta_function::new_index, [](Vec3& v, const int index, double x) { if (index < 0 or index > 2) return; v[index] = x; }, sol::meta_function::equal_to, &Vec3::operator==, sol::meta_function::less_than, &Vec3::operator<, sol::meta_function::subtraction, sol::resolve<Vec3(const Vec3&)>(&Vec3::operator-), sol::meta_function::addition, sol::resolve<Vec3(const Vec3&)>(&Vec3::operator+), sol::meta_function::division, sol::resolve<Vec3(const Vec3&)>(&Vec3::operator/), sol::meta_function::multiplication, sol::resolve<Vec3(const Vec3&)>(&Vec3::operator*), sol::meta_function::unary_minus, sol::resolve<Vec3()>(&Vec3::operator-), sol::meta_function::modulus, &Vec3::operator%, //Methods "Length", &Vec3::Length, "Cross", &Vec3::Cross, "Normalize", &Vec3::Normalize, "Inverse", &Vec3::Inverse, "Distance", &Vec3::DistanceToPoint ); //Constructor luastate->set_function("Vec3", [](float x, float y, float z) {return Vec3(x, y, z); } ); } To add your own C++ classes to Lua in Turbo, you will create a similar function as above and call it at the start of the program.
  17. Josh

    FBX Converter Updated

    By Josh,

    A small update has been published to the default branch of Leadwerks Game Engine on Steam. This updates the FBX converter so that the scene units (meters, feet, etc.) are read from the file and used to convert the model at the proper size. Previously, the raw numbers for position, scale, and vertex positions were read in as meters. The new importer also supports both smooth groups and per-vertex normals, so models can be imported more reliably without having to recalculate normals.

    An error in the probe shader that only occurred when the shader was compiled for VR mode has also been fixed.
  18. Josh

    Ultra Engine Beta Updated

    By Josh,

    An update is available for the new Turbo Game Engine beta.
    Fixed compiling errors with latest Visual Studio version Fixed compatibility problems with AMD hardware Process is now DPI-aware Added high-resolution depth buffer (additional parameter on CreateContext()). Subscribers can download the new version here.
  19. Josh
    TLDR: I made a long-term bet on VR and it's paying off. I haven't been able to talk much about the details until now.
    Here's what happened:
    Leadwerks 3.0 was released during GDC 2013. I gave a talk on graphics optimization and also had a booth at the expo. Something else significant happened that week.  After the expo closed I walked over to the Oculus booth and they let me try out the first Rift prototype.
    This was a pivotal time both for us and for the entire game industry. Mobile was on the downswing but there were new technologies emerging that I wanted to take advantage of. Our Kickstarter campaign for Linux support was very successful, reaching over 200% of its goal. This coincided with a successful Greenlight campaign to bring Leadwerks Game Engine to Steam in the newly-launched software section. The following month Valve announced the development of SteamOS, a Linux-based operating system for the Steam Machine game consoles. Because of our work in Linux and our placement in Steam, I was fortunate enough to be in close contact with much of the staff at Valve Software.
    The Early Days of VR
    It was during one of my visits to Valve HQ that I was able to try out a prototype of the technology that would go on to become the HTC Vive. In September of 2014 I bought an Oculus Rift DK2 and first started working with VR in Leadwerks. So VR has been something I have worked on in the background for a long time, but I was looking for the right opportunity to really put it to work. In 2016 I felt it was time for a technology refresh, so I wrote a blog about the general direction I wanted to take Leadwerks in. A lot of it centered around VR and performance. I didn't really know exactly how things would work out, but I knew I wanted to do a lot of work with VR.
    A month later I received a message on this forum that went something like this (as I recall):
    I thought "Okay, some stupid teenager, where is my ban button?", but when I started getting emails with nasa.gov return addresses I took notice.
    Now, Leadwerks Software has a long history of use in the defense and simulation industries, with orders for software from Northrop Grumman, Lockheed Martin, the British Royal Navy, and probably some others I don't know about. So NASA making an inquiry about software isn't too strange. What was strange was that they were very interested in meeting in person.
    Mr. Josh Goes to Washington
    I took my first trip to Goddard Space Center in January 2017 where I got a tour of the facility. I saw robots, giant satellites, rockets, and some crazy laser rooms that looked like a Half-Life level. It was my eleven year old self's dream come true. I was also shown some of the virtual reality work they are using Leadwerks Game Engine for. Basically, they were taking high-poly engineering models from CAD software and putting them into a real-time visualization in VR. There are some good reasons for this. VR gives you a stereoscopic view of objects that is far superior to a flat 2D screen. This makes a huge difference when you are viewing complex mechanical objects and planning robotic movements. You just can't see things on a flat screen the same way you can see them in VR. It's like the difference between looking at a photograph of an object versus holding it in your hands.

    What is even going on here???
    CAD models are procedural, meaning they have a precise mathematical formula that describes their shape. In order to render them in real-time, they have to be converted to polygonal models, but these objects can be tens of millions of polygons, with details down to threading on individual screws, and they were trying to view them in VR at 90 frames per second! Now with virtual reality, if there is a discrepancy between what your visual system and your vestibular system perceives, you will get sick to your stomach. That's why it's critical to maintain a steady 90 Hz frame rate. The engineers at NASA told me they first tried to use Unity3D but it was too slow, which is why they came to me. Leadwerks was giving them better performance, but it still was not fast enough for what they wanted to do next. I thought "these guys are crazy, it cannot be done".
    Then I remembered something else people said could never be done.

    So I started to think "if it were possible, how would I do it?" They had also expressed interest in an inverse kinematics simulation, so I put together this robotic arm control demo in a few days, just to show what could be easily be done with our physics system.
     
    A New Game Engine is Born
    With the extreme performance demands of VR and my experience writing optimized rendering systems, I saw an opportunity to focus our development on something people can't live without: speed. I started building a new renderer designed specifically around the way modern PC hardware works. At first I expected to see performance increases of 2-3x. Instead what we are seeing are 10-40x performance increases under heavy loads. During this time I stayed in contact with people at NASA and kept them up to date on the capabilities of the new technology.
    At this point there was still nothing concrete to show for my efforts. NASA purchased some licenses for the Enterprise edition of Leadwerks Game Engine, but the demos I made were free of charge and I was paying my own travel expenses. The cost of plane tickets and hotels adds up quickly, and there was no guarantee any of this would work out. I did not want to talk about what I was doing on this site because it would be embarrassing if I made a lot of big plans and nothing came of it. But I saw a need for the technology I created and I figured something would work out, so I kept working away at it.
    Call to Duty
    Today I am pleased to announce I have signed a contract to put our virtual reality expertise to work for NASA. As we speak, I am preparing to travel to Washington D.C. to begin the project. In the future I plan to provide support for aerospace, defense, manufacturing, and serious games, using our new technology to help users deliver VR simulations with performance and realism beyond anything that has been possible until now.
    My software company and relationship with my customers (you) is unaffected. Development of the new engine will continue, with a strong emphasis on hyper-realism and performance. I think this is a direction everyone here will be happy with. I am going to continue to invest in the development of groundbreaking new features that will help in the aerospace and defense industries (now you understand why I have been talking about 64-bit worlds) and I think a great many people will be happy to come along for the ride in this direction.
    Leadwerks is still a game company, but our core focus is on enabling and creating hyper-realistic VR simulations. Thank you for your support and all the suggestions and ideas you have provided over the years that have helped me create great software for you. Things are about to get very interesting. I can't wait to see what you all create with the new technology we are building.
     
  20. Josh

    Vector Image Support

    By Josh,

    Building on the Asset Loader class I talked about in my previous blog post, I have added a loader to import textures from SVG files. In 2D graphics there are two types of image files. Rasterized images are made up of a grid of pixels. Vector images, on the other hand, are made up of shapes like Bezier curves. One example of vector graphics you are probably familiar with are the fonts used on your computer.
    SVG files are a vector image format that can be created in Adobe Illustrator and other programs:

    Because SVG images are resolution-independent, when you zoom in on these images they only become more detailed:

    This makes SVG images perfect for GUI elements. The Leadwerks GUI can be rendered at any resolution, to support 4K, 8K, or other displays. This is also great for in-game VR GUIs because you can scale the image to any resolution.
    SVG images can be loaded as textures to be drawn on the screen, and in the future will be able to be loaded as GUI images. You can specify a DPI to rasterize the image to, with a default setting of 96 dots per inch.

  21. Josh

    Asset Loader Class

    By Josh,

    There's a discussion on the forum that sort of veered into talking about Khronos' GLTF file format specification:
    Some of this gave me some ideas for changes in the art pipeline in Turbo Game Engine. I was not feeling very concentrated today so I decided to do some easy work and implement a loader class:
    class Loader : public SharedObject { public: std::vector<wstring> extensions; virtual bool Reload(shared_ptr<Stream> stream, shared_ptr<SharedObject> o, const int flags = 0)=0; }; Then I created a TEX texture loader class:
    class TEXTextureLoader : public Loader { public: virtual bool Reload(shared_ptr<Stream> stream, shared_ptr<SharedObject> o, const int flags = 0)=0; }; When the engine is initialized it creates a TEXTexLoader object and saves it in a list of texture loaders:
    GameEngine::Initialize() { textureloaders.push_back(make_shared<TEXTextureLoader>()); } And the class constructor itself creates an array of file extensions the loader supports:
    TEXTextureLoader::TEXTextureLoader() { extensions = { "tex" }; } When a texture is loaded, the engine looks for a texture loader that matches the extension or the loaded file path.
    At this point, all we have done is restructured the engine to do the same thing it did before, with more code. But now we can add new loaders for other file formats. And that is exactly what I did. You can now load textures directly from PNG files:
    class PNGTextureLoader : public Loader { public: virtual bool Reload(shared_ptr<Stream> stream, shared_ptr<SharedObject> o, const int flags = 0)=0; }; I've done the same thing for model file loading as well, although I have not yet added support for any other file types.
    If we can add a C++ loader, we should be able to add one with Lua too. I haven't worked out the details yet, but it could work something like this:
    function LoadModelObj( stream, model ) while stream:EOF() == false do -------------- end end AddModelLoader(LoadModelObj) So with that, you could download a Lua script that would add support for loading a new file format.
    I think in the new engine we will support all common image formats, including Photoshop PSD, as well as DDS, KTX, and our existing TEX files. Textures loaded from image formats will be less optimal because mipmaps will be generated on loading. Settings like clamping and filter modes will be stored in the associated .meta files, which means these files will start getting published along with your game asset files. This is a change from the Leadwerks 4 way of doing things.
  22. Josh

    More Work on Shadows

    By Josh,

    I found and fixed the cause of the cubemap seams in variance shadow maps so we now have nice soft seamless shadows.

    I also changed the engine so that point lights use six 2D textures instead of a separate cubemap texture array. This means that all light types are sharing one big 2D array texture, and it frees up one texture slot. I am not sure if I want to have a hard limit on number of shadow-casting lights in the scene, or if I want to implement a system that moves lights in and out of a fixed number of shadowmap slots.
  23. Josh
    As I work with the new engine more and more I keep finding new ways it makes life happy and productive.
    Smart Pointers
    I have talked about how great these are at length, but I keep finding new reasons I love them. The behind-the-scenes design has been a lot of fun, and it's so cool to be able to write lines of code like this without any fear of memory leaks:
    LoadSound("Sound/Music/fully_loaded_60.wav")->Play(); What do you think that code does? It plays a sound, keeps it in memory, and then unloads it when the sound finishes playing (assuming it is not loaded anywhere else). Smart Pointers make the new API almost magical to work with, and they don't have the performance overhead that garbage collection would, and they work great with Lua script.
    User Interface
    Leadwerks GUI will be used in our new editor, which allows me to innovate in many new ways. But we're also using Visual Studio Code for the script editor, which gives you a sleek modern scripting environment.

    Better Scene Management
    Cached shadow maps.are a feature in Leadwerks 4 that separate geometry into static and dynamic shadow-casting types. Static shadows are rendered into a cache texture. When the shadow updates only the dynamic objects are redrawn on top of the saved static cache. This requires that you set the light shadow mode to Dynamic|Static|Buffered. In the new engine this will be automatic. By default lights will use a shadow cache, and if the light moves after the first shadow render, the cache will be disabled. Any geometry can be marked as static in the new editor. Static objects are more optimal for lighting, navigation, and global illumination, and will not respond to movement commands. (This can also be used to mark which brushes should get merged when the scene is loaded).
    If you don't explicitly select whether an object in the scene should be static or not, the engine will guess. For example, any object with non-zero mass or a script attached to it should not be automatically marked as static.
    If you didn't understand any of that, don't worry! Just don't do anything, and your scene will already be running efficiently, because the engine makes intelligent choices based on your game's behavior.
    It's all turning out really nice.
  24. Josh

    Ultra Engine Beta Update

    By Josh,

    The Turbo Game Engine beta is updated! This will allow you to load your own maps in the new engine and see the speed difference the new renderer makes.

    LoadScene() has replaced the LoadMap() function, but it still loads your existing map files. To create a PBR material, insert a line into the material file that says "lightingmodel=1". Blinn-Phong is the default lighting model. The red and green channels on texture unit 2 represent metalness and roughness. You generally don't need to assign shaders to your materials. The engine will automatically select one based on what textures you have. Point and spot lights work. Directional lights do not. Setting the world skybox only affects PBR reflections and Blinn-Phong ambient lighting. No sky will be visible. Physics, scripting, particles, and terrain do not work. Variance shadow maps are in use. There are currently some problems with lines appearing at cubemap seams and some flickering pixels. Objects should always cast a shadow or they won't appear correctly with VSMs. I had to include glew.c in the project because the functions weren't being detected from the static lib. I'm not sure why. The static libraries are huge. The release build is nearly one gigabyte. But when compiled, your executable is small. #include "Leadwerks.h" using namespace Leadwerks; int main(int argc, const char *argv[]) { //Create a window auto window = CreateWindow("MyGame", 0, 0, 1280, 720); //Create a rendering context auto context = CreateContext(window); //Create the world auto world = CreateWorld(); //This only affects reflections at this time world->SetSkybox("Models/Damaged Helmet/papermill.tex"); shared_ptr<Camera> camera; auto scene = LoadScene(world, "Maps/turbotest.map"); for (auto entity : scene->entities) { if (dynamic_pointer_cast<Camera>(entity)) { camera = dynamic_pointer_cast<Camera>(entity); } } auto model = LoadModel(world, "Models/Damaged Helmet/DamagedHelmet.mdl"); model->Move(0, 1, 0); model->SetShadowMode(LIGHT_DYNAMIC, true); //Create a camera if one was not found if (camera == nullptr) { camera = CreateCamera(world); camera->Move(0, 1, -3); } //Set background color camera->SetClearColor(0.15); //Enable camera free look and hide mouse camera->SetFreeLookMode(true); window->HideMouse(); //Create a light auto light = CreateLight(world, LIGHT_POINT); light->SetShadowMode(LIGHT_DYNAMIC | LIGHT_STATIC | LIGHT_CACHED); light->SetPosition(0, 4, -4); light->SetRange(15); while (window->KeyHit(KEY_ESCAPE) == false and window->Closed() == false) { //Rotate model model->Turn(0, 0.5, 0); //Camera movement if (window->KeyDown(Key::A)) camera->Move(-0.1, 0, 0); if (window->KeyDown(Key::D)) camera->Move(0.1, 0, 0); if (window->KeyDown(Key::W)) camera->Move(0, 0, 0.1); if (window->KeyDown(Key::S)) camera->Move(0, 0, -0.1); //Update the world world->Update(); //Render the world world->Render(context); } Shutdown(); return 0; }
  25. Josh

    Next Steps

    By Josh,

    I've got the basic GI algorithm working but it needs a lot of work to be correct. I tend to do very well when the exact outcome is well-defined, but I am not as good at dealing with open-ended "artistic" programming. I may end up outsourcing the details of the GI shader to someone else, but the underlying data management is solid enough that I am not scared of it anymore.
    There's a lot of aspects of the design I'm not scared of anymore. We worked out smart pointers (including Lua integration), physically-based rendering, and most importantly the crazy ideas I had for the super efficient architecture work really well.
    At this point I think I am going to put the GI on hold, since I could play around with that endlessly, and focus on getting a new build out to the beta subscribers. We're going to just use a single skybox for ambient and specular reflections right now, and when it's ready GI and environment probes will provide that. 
    After that I think I will focus on the physics and navigation systems, exposing the entire API to Lua, and getting some of the outsourced work started. There's a few things I plan to farm out:
    Visual Studio Code Lua debugger GI details Weather system Water and clouds systems Everything else is pretty well under my control. This started out as an idea for an impossible design, but everything has fallen into place pretty neatly.
Copyright © 2024 Ultra Software.
All rights reserved.
×
×
  • Create New...