Jump to content
Ultra Engine Community

Josh

Staff
 View Profile  See their activity

  • Posts

    23,142

  • Joined

  • Last visited

 Content Type 

Blog Entries posted by Josh

  1. Josh

    Bindless Textures

    By Josh,

    The clustered forward renderer in Leadwerks 5 / Turbo Game Engine required me to implement a texture array to store all shadow maps in. Since all shadow maps are packed into a single 3D texture, the shader can access all required textures outside of the number of available texture units, which only gives 16 guaranteed slots.
    I realized I could use this same technique to pack all scene textures into a few arrays and completely eliminate the overhead of binding different textures. In order to do this I had to introduce some restrictions. The max texture size, by default, is 4096x4096. Only two texture formats, RGBA and DXT5, are supported. Other texture formats will be converted to RGBA during loading. If a texture is smaller than 1024x1024, it will still take up a layer in the 1024x1024 texture array.
    This also makes texture lookups in shaders quite a bit more complicated.
    Before:
    fragColor *= texture(texture0,texcoords0); After:
    fragColor *= texture(textureatlases[materialdefs[materialid].textureslot[0]],vec3(texcoords0,materialdefs[materialid].texturelayer[0])); However, making shaders easy to read is not a priority in my design. Performance is. When you have one overarching design goal these decisions are easy to make.
    Materials can now access up to 256 textures. Or however many I decide to allow.
    The real reason for this is it will help support my goal to render the entire scene with all objects in just one or a few passes, thereby completely eliminating all the overhead of the CPU/GPU interaction to reach 100% GPU utilization, for ultra maximum performance, to eliminate VR nausea once and for all.
    Also, I went out walking yesterday and randomly found this item in a small shop.

    There's something bigger at work here:
    Most of my money comes through Steam. Valve invented the technology the HTC Vive is based on. Gabe Newell gave me the Gigabyte Brix mini PC that the new engine architecture was invented on. The new engine makes VR performance 10x faster. If this isn't a clear sign that divine providence is on our side, I don't know what is.
  2. Josh

    Development Days

    By Josh,

    Some of the Leadwerks Game Engine design was originally developed to run on PC and mobile. In order to supported multiple renderers (OpenGL and OpenGLES) I implemented a system that uses an abstract base class with an API-specific class derived from that:
    Texture OpenGLTexture All OpenGL code was contained in the OpenGLTexture class. This worked fine, and theoretically it would have allowed us to support multiple renderers within one build, like OpenGL and DirectX. In practice it's a feature that was never used, and created a lot of complicate class hierarchies, with functionality split between the base and derived classes.
    In the new engine, all rendering code is completely separated in a separate thread, and we have a separate class that is a stripped-down representation of the object the programmer interfaces with:
    Texture RenderTexture When the programmer calls a command that makes a change to the Texture object, an instruction is added to a queue of commands that is sent to the rendering thread, and their change is also made on that RenderTexture object, although not instantaneously.
    Right now I am stripping out the derived classes and turning classes that were previously abstract into full classes. It's quite a big job to restructure a complex program like this but it needs to be done. Even when we switch over to Vulkan / Metal I don't see us every supporting multiple APIs within a single build, and I am glad to get rid of this aspect of the engine.
    I'm also doing the same thing for physics. An Entity object in the main thread can have a PhysicsNode object that lives in the physics thread. However, this does not get created unless there is some physics command performed on the entity, like setting the mass or adding a collision shape.
    Other stuff I want to change:
    Get rid of GetClass() / GetClassName() method. Get rid of Object::ModelClass etc. constants. Replace all static class constants with global variables, i.e. WINDOW_FULLSCREEN instead of Window::Fullscreen. It's actually best to declare constants with enum because then they get evaluated as a constant and can be used in array declarations and switch statements. It only needs to be declared once, in the header, but unlike a macro it stays contained within the namespace it is declared in:
    enum { MAX_PHYSICS_THREADS = 32 }; The next step is to create a usable programming SDK with models, lights, scene loading, scripting, and physics. This will allow beta testers to actually start developing games. The lack of a visual editor is a challenge, but at the same time we are now using more standard file formats like DDS and GLTF, which gives us better consistency with the output of various modeling programs. I'd like to start looking at a Lua debugger for Visual Studio Code soon. There seems to be some debuggers out there already, but I have no idea how the communication between the debugger and the game is supposed to work. I invented my own network data protocol in Leadwerks and there isn't any standard I am aware of.
    2D graphics in the new engine are quite different from in Leadwerks, which used drawing commands to control what gets displayed on screen. Since the rendering all occurs asynchronously on another thread, this approach does not make sense at all. I also had a problem with the GUI in this design. The GUI system uses a script with a drawing command to redraw each widget, but we don't want any Lua code running in the rendering thread.
    The solution is to make 2D graphical elements persistent objects:
    auto window = CreateWindow(); auto context = CreateContext(window); auto world = CreateWorld(); //Create some 2D graphics auto rect = CreateRect(context,10,10,200,75,true); rect->SetColor(0,0,1); auto line = CreateLine(context,10,10,200,200); line->SetColor(1,0,0); auto text = CreateText(context,"Hello!",0,0,200,75,TEXT_CENTER); text->SetPosition(10,10) text->SetFont(LoadFont("Fonts/arial.ttf",18); while (not window->Closed()) { world->Render(context); } Just like with an entity, you can set the variable to null to stop drawing the element.
    while (not window->Closed()) { if (window->KeyHit(KEY_SPACE)) rect = nullptr; world->Render(context); } 2D elements can have a hierarchy, so you can create one element that gets drawn on top of another:
    auto rect = CreateRect(context,10,10,200,75,true); rect->SetColor(0,0,1); auto rect2 = CreateRect(rect,4,4,rect.size.x-8,rect.size.y-8,true); rect2->SetColor(1,1,1); We need the GUI working for some VR projects I want to use the new engine in soon. Once the items above are all working, that will give us everything we need to start working on the new editor.
  3. Josh
    It turns out GLTF is actually three different file formats. ? Textures can be loaded from external files, embedded in a binary .glb file, but they can also be saved in an ASCII GLTF files using base64 encoding. Having three different ways to store textures is not a good design decision, but at least it's better than the disaster called Collada. (Note to Khronos: If your file format specification has more pages than a Tom Clancy novel it probably sucks.)
    Our GLTF loader now supports files with textures embedded in the file, in both binary (.glb) and embedded formats. We also support the Microsoft DDS extension, and support for the Microsoft LOD extension is on the way. The new editor will be able to save loaded models as GLTF files, and we can pack our own information away in our own file extensions, while keeping the file loadable by other applications.

    Additionally, the new engine now supports textures loaded from DDS, PNG, JPG, BMP, PCX, PSD, GIF, ICO, TIF, EXR, and HDR formats, as well as Leadwerks TEX files. I'd like to get a new update out soon for the new engine, and then continue working on bug fixes for Leadwerks Game Engine 4.6.

  4. Josh

    Loading Assets from Streams

    By Josh,

    Since the GLTF file format can pack textures into a single file with the model, I needed to implement asset loading directly from a stream:
    auto stream = ReadFile("image.png"); auto tex = LoadTexture(stream); This was interesting because I needed to add a check for each supported image type so the loader can determine the file type from the contents instead of the file path extension. Most file formats include a string or "magic number" at the beginning of the file format to indicate what type of file it is:
    //BMP check pos = stream->GetPos(); if (stream->GetSize() - pos >= 2) { if (stream->ReadString(2) == "BM") isbmp = true; } stream->Seek(pos); The TGA file format is weird though because it does not have one of these. It just launches straight into a header of information, already assuming the file is a TGA file. So what you have to do is read some of the values and see if they are reasonable. With a little help from the BlitzMax source code, I was able to do this:
    //TGA check pos = stream->GetPos(); tgahdr hdr; if (stream->GetSize() - pos >= sizeof(hdr)) { const int TGA_NULL = 0; const int TGA_MAP = 1; const int TGA_RGB = 2; const int TGA_MONO = 3; const int TGA_RLEMAP = 9; const int TGA_RLERGB = 10; const int TGA_RLEMONO = 11; const int TGA_COMPMAP = 32; const int TGA_COMPMAP4 = 33; stream->Read(&hdr, sizeof(hdr)); if (hdr.colourmaptype == 0) { if (hdr.imgtype == TGA_MAP or hdr.imgtype == TGA_RGB or hdr.imgtype == TGA_RLERGB) { if (hdr.psize == 15 or hdr.psize == 16 or hdr.psize == 24 or hdr.psize == 32) { if (hdr.width > 0 and hdr.width <= 163284 * 2) { if (hdr.height > 0 and hdr.height <= 163284 * 2) istga = true; } } } } } stream->Seek(pos); In fact the whole idea of having a list of loaders that read the file contents to determine if they are able to load the file is an idea I pulled from the design of BlitzMax. It is strange that so many good tech products have fallen away yet we are growing.
  5. Josh

    GLTF Materials

    By Josh,

    I'm now able to load materials from GLTF files. These can use external textures or they can use textures packed into a GLTF binary file. Because we have a standardized material specification, this means you can download GLTF files from SketchFab or Turbosquid, and your model materials will automatically be loaded, all the time. There's no more generating materials or messing around trying to figure out which texture is the normal or specular map. An extension exists for DDS texture support, fortunately.
    Here are the preliminary results.
     
  6. Josh

    Back in Action

    By Josh,

    So, most of December was eaten up on some NASA VR projects. There was a conference last week in Seattle that I attended for a couple of days. Then I had meetings in northern California and Arizona.
    Unfortunately, I can't really talk much about what I am doing with those. Rest assured I am working on a plan to grow the company so we can provide better products and support for you. I'm taking a hit on productivity now in order to make a bigger plan happen.
    Today is my first day back home after all that, and I now have time to focus on the software. Thanks for your patience while I get this all sorted out.
  7. 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.
  8. Josh

    Plugins Expanded

    By Josh,

    This month I was working on a lot of NASA projects using Leadwerks. My goal with this is to build up enough business that I can start hiring more people to help. It's nice to make money using my own tools, and it gives me a lot of ideas for the new engine.
    This morning I felt like experimenting with the design of plugins in the new editor a bit. I came up with two types of plugins. One will add an new menu item to the model editor that flips the normals of the current model. The ProcessEvent() function intercepts a GUI event in the editor and performs new functionality:
    Plugin.title = "Flip Model Normals" Plugin.description = "Reverses the faces of all triangles in the model editor." function Plugin:Load() local menu = Editor.modelEditor.menu:FindMenu("Plugins") if menu~=nil then self.menuitem = menu:AddItem("Flip Normals") end end function Plugin:Unload() if self.menuitem~=nil then self.menuitem:Free() end end function Plugin:ProcessEvent(event) if event.id = EVENT_MENUACTION then if event.source = self.menuitem then if Editor.modelEditor.model~=nil then self:FlipNormals(Editor.modelEditor.model) Editor.modelEditor:Redraw() return false end end end return true end function Plugin:FlipNormals(model) local n,k,lod,mesh,i,a,b,c for n=0,#model.lods do lod = model.lods[n] for k=0,#lod.meshes do mesh = lod.meshes[k] mesh:Unlock() for i=0,#mesh.indices/3 do a = mesh.indices[i*3+0] b = mesh.indices[i*3+1] c = mesh.indices[i*3+2] mesh.indices[i*3+0] = c mesh.indices[i*3+2] = a end mesh:Lock() end end end Another type of plugin adds some new functionality to your game. This one is different because it loads a function from a dynamically linked library and passes the Lua state to a function: In this case, I decided to try separating analytics off into its own plugin, simply because it is a self-contained system that doesn't interfere with the rest of the engine:
    Plugin.name = "Example" Plugin.title = "Example Plugin" Plugin.description = "This is an example plugin." function Plugin:GetPath() local ext="" if GetOS()=="Windows" then ext = "dll" elseif GetOS()=="Linux" then ext = "so" elseif GetOS()=="MacOS" ext = "dylib" end return self.name..ext end function Plugin:Load() local f = package.loadlib(self:GetPath(),"Load") if type(f)=="function" then f(GetLuaState()) end end function Plugin:Unload() local f = package.loadlib(self:GetPath(),"Unload") if type(f)=="function" then f() end end The source code for the dynamic library would be something like this:
    #include "GameAnalytics.h" bool Load(sol::state* L) { L->set_function("EnableAnalytics", EnableAnalytics); } void Unload() { } bool EnableAnalytics(const bool state) { return true; } Once the plugin is loaded, the Lua state would be passed to the DLL (or .so, or .dylib) and the new commands would get inserted into the Lua state.
    So what does a plugin consist of?
    A ,lua or precompiled .luac file is required. If the plugin uses C++ code, a .dll, .so, and .dylib are required. Optional source code and project(s) for the dynamically linked library. And what can a plugin do?
    Add new features to the editor. Add new Lua commands to use in your game. That's all for now.
  9. 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.
  10. 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!
  11. 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.
     
  12. 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.
  13. 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.
  14. 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.
  16. 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.
  17. 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  
  18. 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  
  19. 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.
  20. 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.
  21. 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.
  22. 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.

  23. 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.
  24. 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.
  25. 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.

Copyright © 2024 Ultra Software.
All rights reserved.
×
×
  • Create New...