Jump to content
Ultra Engine Community

Josh

Staff
 View Profile  See their activity

  • Posts

    23,313

  • Joined

  • Last visited

 Content Type 

Blog Entries posted by Josh

  1. Josh

    Dynamic Voxel Updates

    By Josh,

    I've been working to make my previously demonstrated voxel ray tracing system fully dynamic. Getting the voxel data to update fast enough was a major challenge, and it forced me to rethink the design. In the video below you can see the voxel data being updated at a sufficient speed. Lighting has been removed, as I need to change the way this runs.
    I plan to keep two copies of the data in memory and let the GPU interpolate smoothly in between them, in order to smooth out the motion. Next I need to add the direct lighting and GI passes back in, which will add an additional small delay but hopefully be within a tolerable threshold.
  2. Josh
    A launch option has been added to Leadwerks on Steam that allows you to launch the Leadwerks Game Player outside of the editor. When you launch Leadwerks Game Engine from Steam, a dialog box appears and lets you choose whether to run the editor or the Leadwerks Game Player. (If you just launch the app from a desktop or start menu shortcut, the editor is run automatically.) You can subscribe to other users' games in the Leadwerks Workshop on Steam, and play them by launching the game player. The option is not yet available on Linux, since this requires an additional shell script the current stable build does not have yet.
     

     
    One of the Leadwerks 3.3 features that's built into the current beta is the ability to select which Workshop packages get packed into your game when you publish, as a standalone or to the Leadwerks Workshop. In the current beta branch on Steam you can right-click on a Workshop folder and choose the "Add to Project" menu item. This will tell the publisher to include the contents of this package when your item is published. You must add each package you want to include, or it will not be included when your project is published.
     
    This allows you to publish games without including every single Workshop package you are subscribed to.
     

     
    These changes are available now on the beta branch on Steam.
  3. Josh

    Early Z-Pass in Vulkan

    By Josh,

    Vulkan is pretty wonderful because I can take all the optimal techniques I worked out in OpenGL and it just makes everything much faster. I've successfully completed the implementation of early Z-pass, which is important for our lighting system. We are using a forward clustered renderer, similar to the technique id Software's new DOOM games use. Because the fragment shader is fairly intensive, a depth pre-pass is rendered to ensure we only process each screen pixel once.

    This technique also easily supports transparency with multiple layers of shadows.

    Vulkan has a feature called subpasses specifically designed for this type of functionality. It's really fantastic to have this kind of fine control over the hardware, even if it does involved some pretty convoluted code.
    You can read more about this rendering technique below.
     
  4. Josh
    I've been doing some work on the sound system in Leadwerks 5 beta, and I added EAX effects in. If you have a dedicated sound card this can be used to add some nice reverb effects that make your sound environment sound a lot more real:
    Here's the simplest usage:
    auto fx = LoadSoundEffect("Sound/FX/sewerpipe.json"); auto listener = CreateListener(world); listener->SetEffect(fx); This will apply the effect to all mono sources. Stereo sources are assumed to be music or GUI noises, and will be unaffected. Eventually, the way I see this being used is a script attached to a CSG brush that changes the listener's EAX effect when the player enters and leaves the volume, but the above shows the API approach.
    I exported all the EAX presets into JSON files like so. You can load one of the existing files, or if you are feeling really creative you can try making your own:
    { "AirAbsorptionGainHF": 0.99426, "DecayHFLimit": 0, "DecayHFRatio": 0.89, "DecayLFRatio": 0.41, "DecayTime": 2.76, "Density": 1.0, "Diffusion": 0.82, "EchoDepth": 0.17, "EchoTime": 0.13, "Gain": 0.316228, "GainHF": 0.281838, "GainLF": 0.0891251, "HFReference": 2854.4, "LateReverbGain": 0.891251, "LateReverbPan": [0.0, 0.0, 0.0], "LFReference": 107.5, "LateReverbDelay": 0.02, "ModulationDepth": 0.0, "ModulationTime": 0.25, "ReflectionsDelay": 0.029, "ReflectionsGain": 0.354813, "ReflectionsPan": [0.0, 0.0, -0.0], "RoomRolloffFactor": 0.0 } Here's the full list of available presets:
    CastleSmallroom CastleMediumroom CastleLongpassage CastleLargeroom CastleHall CastleCupboard CastleCourtyard CastleAlcove FactoryAlcove FactoryShortPassage FactoryMediumRoom FactoryLongPassage FactoryLargeRoom FactoryHall FactoryCupboard FactoryCourtyard FactorySmallRoom IcepalaceAlcove IcepalaceShortPassage IcepalaceMediumRoom IcepalaceLongPassage IcepalaceLargeroom IcepalaceHall IcepalaceCupboard IcepalaceCourtyard IcepalaceSmallRoom SpacestationAlcove SpacestationMediumRoom SpacestationShortpassage SpacestationLongPassage SpacestationLargeRoom SpacestationHall SpacestationCupboard SpacestationSmallRoom WoodenAlcove WoodenShortPassage WoodenMediumRoom WoodenLongPassage WoodenLargeRoom WoodenHall WoodenCupboard WoodenSmallRoom WoodenCourtyard SportEmptyStadium SportSquashCourt SportSmallSwimmingPool SportLargeSwimmingPool SportGymnasium SportFullStadium SportStadiumTannoy Workshop SchoolRoom PractiseRoom Outhouse Caravan Dome Tomb PipeSmall DomeSaintPauls PipeLongThing PipeLarge PipeResonant OutdoorsBackyard OutdoorsRollingPlains OutdoorsDeepCanyon OutdoorsCreek OutdoorsValley MoodHeaven MoodHell MoodMemory DrivingCommentator DrivingPitGarage DrivingInCarRacer DrivingInCarSports DrivingFullGrandstand DrivingEmptyGrandstand DrivingTunnel CityStreets CitySubway CityMuseum CityLibrary CityUnderpass Dustyroom Chapel SmallWaterRoom I might consider implementing Steam Audio in the future (formerly Phonon) but for now OpenAL does everything I want.
  5. Josh

    Editor Development Continues

    By Josh,


    Articles
    I wanted to take some time to investigate geospatial features and see if it was possible to use GIS systems with Ultra Engine. My investigations were a success and resulted in some beautiful lunar landscapes in a relatively short period of time in the new game engine.

    I have plans for this, but nothing I can say anything specific about right now, so now I am working on the editor again.
    Leadwerks had a very well-defined workflow, which made it simple to use but also somewhat limited. Ultra goes in the opposite direction, with extremely flexible support for plugins and extensions. It's a challenge to keep things together because if you make things to flexible it just turns into indecisiveness, and nothing will ever get finished that way. I think I am finding a good balance or things that should be hard-coded and things that should be configurable.
    Instead of separate windows for viewing models, textures, and materials, we just have one asset editor window, with tabs for separate items. The texture interface is the simplest and just shows some information about the asset on the left-side panel.

    When you select the Save as menu item, the save file dialog is automatically populated with information loaded from all the plugins the engine has loaded. You can add support for new image formats at any time just by dropping a plugin in the right folder. In fact, the only hard-coded format in the list is DDS.

    You can save to an image format, or to the more advanced DDS and KTX2 formats, which include mipmaps and other features. Even more impressive is the ability to load Leadwerks texture files (TEX) and save them directly into DDS format in their original pixel format, with no loss of image quality. Here we have a Leadwerks texture that uses DXT1 compression, converted to DDS without recompressing the pixels:

    There are several tricks to make the new editor start up as fast as possible. One of these is that the various windows the editor uses don't actually get created until the first time they are used. This saves a little bit of time to give the application a snappier feel at startup.
    I hope the end result will provide a very intuitive workflow like the Leadwerks editor has, with enough power and flexibility to make the editor into a living growing platform with many people adding new capabilities for you to use. I think this is actually my favorite stuff to work on because this is where all the technology is exposed to you, the end user, and I get to carefully hand-craft an interface that makes you feel happy when you use it.
  6. Josh

    Editor Documentation

    By Josh,

    I got the editor documentation written pretty quickly. It was hard to start, but once I figured out how I wanted to lay out the information, it all started flowing pretty easily.
     
    Documentation in Leadwerks Engine 2 was a weakness, especially in stuff other than the programming reference. This is unfortunate, because I have come to see documentation as the final product. Everything in the development cycle leads up to the ability to write good documentation.
     
    Good documentation starts with good program design. It would have been difficult to give the same attention to detail in Leadwerks Engine 2 as I am now, because there was much more behavior that was undefined, or left up to the user. Because Leadwerks 3 absorbs a lot of that complexity, I can definitively say "if you want to do X, press this button". It makes for documentation that is nice to read, and kind of fun to write.
     
    Here's a screenshot, just to give you an idea of the formatting and style I am using.

     
    I usually feel overwhelmed by the documentation when I look at game engines. It's hard to know where to start, and I just feel like I am picking up random bits of disorganized information. I am hoping the manner in which I have organized our docs will provide a streamlined learning experience, with the ability to drill down to more detail when needed. My organization is as follows:
     
    Editor
    This covers the entire Leadwerks workflow and art pipeline. You can find answers to all non-programming questions here.
     
    Script Reference
    This section describes all the object scripts included with Leadwerks, and how to use them to make game interaction.
     
    Programming
    This section discusses general information about programming with Leadwerks, in C++ and Lua.
     
    Command Reference
    This section provides detailed descriptions and examples for the entire Leadwerks API.
     
    Index
    This is a list of all pages in the documentation, in alphabetical order.
     
    It feels very easy to navigate and it doesn't take long to learn how the entire workflow and art pipeline work, but it's not lightweight by any means. The docs have more than 600 pages! Most of that is for individual class functions, which is information you will usually specifically seek out, rather than just reading through them all for fun.
     
    --EDIT--
    I added some additional fields for C++ and Lua examples, with a tabbed interface to view each:

  7. Josh

    Editor Enhancements

    By Josh,

    I've always believed strongly that a native UI presents a cleaner, more consistent, and more beautiful interface for the user to interact with. Not only do they look better, but they present less of a learning curve because the user already knows how to interact with them. When applications move beyond competing to see who can make a better home-made button, they can focus on greater underlying functionality and stop wasting time reinventing the wheel that the operating system already provides.
     
    Leadwerks 3 uses the native UI on both Windows and OSX, and it's turning out really beautiful. Since one picture = 1000 words, I'm going to let the images do the rest of the talking.
     

     

     

     

     

     

  8. Josh

    Editor Scripting API

    By Josh,


    Articles
    The Ultra Engine editor is designed to be expandable and modifiable.  Lua script is integrated into the editor and can be used to write editor extensions and even modify the scene or the editor itself in real-time. 
    We can create a scene object entirely in code and make it appear in the scene browser tree:
    box = CreateBox(editor.world) box.name = "box01" o = CreateSceneObject(box) --make editor recognize the entity and add it to the scene browser o:SetSelected(true)
    We can even modify the editor itself and start adding new features to the interface:
    editor.sidepanel.tabber:AddItem("Roads") p = CreatePanel(0,0,300,500,editor.sidepanel.tabber) button = CreateButton("Create",20,20,100,30,p)
    Of course, you would usually want to put all this code in a script file and either run the script by selecting the Script > Run Script... menu item, or placing the script in the "Scripts/Start" folder so it automatically gets run at startup. But it sure is cool to be able to experiment live with Lua right in the console and see the result of your code instantly.
  9. Josh

    Entering data...

    By Josh,

    I did not expect this many upgrades over the weekend! I'm entering data as fast as I can.
     
    Already I can see the private sections are a big improvement. It totally changes the feel of the forum. It feels like it's more our own area, instead of just a random bulletin board floating around in cyberspace. If that makes any sense.
  10. Josh

    Entities and scripts

    By Josh,

    Below you can see the properties editor. When you select a script attached to an entity, the properties for that script appear on the right. Here we have a simple "Pulse" script that changes the color of the entity along a sine curve. This can be used for making lights that pulsate slowly, or continually turn on and off.

     
    Here's what the script looks like. The "--in" tag at the end of the Pause and Resume functions indicate that these functions can be activated in the flowgraph editor. (A node can be connected to them to call them.)

    --float speed 1 --color color0 0,0,0,0 --color color1 1,1,1,1 --bool recursive function actor:Pause()--in self.paused=true end function actor:Resume()--in self.paused=false end function actor:Update() if ~self.paused then local i = math.sin(AppTime()*self.speed*0.01) self.entity:SetColor(i*self.color0+(1-i)*self.color1,self.recursive) end end
    Here's our "mover" script, which just performs simple movement and rotation without physics:

    --vec3 translation 0,0,0 --vec3 rotation 0,0,0 --bool global true function actor:Start() self.paused=false end function actor:Pause()--in self.paused=true end function actor:Resume()--in self.paused=false end function actor:SetTranslation(translation)--in self.translation = translation end function actor:SetRotation(rotation)--in self.rotation = rotation end function actor:Update() if ~self.paused then if self.movespeed~=Vec3(0) then self.entity:Move(self.translation[0],self.translation[1],self.translation[2],self.global) end if self.turnspeed~=Vec3(0) then self.entity:Turn(self.rotation[0],self.rotation[1],self.rotation[2],self.global) end end end
    Want an entity to animate in a loop? Attach this script to the entity:

    --int sequence --float speed 1 --bool paused false function actor:Start() self.frame=0 end function actor:Pause()--in self.paused=true end function actor:Resume()--in self.paused=false end function actor:Draw() if ~self.paused then self.frame=self.frame+AppSpeed() self.entity:Animate(self.frame,self.sequence) end end
    What if we wanted a one-shot animation that plays when something triggers it? We can define an "Enable" function, connect another node to it, and some other event can cause the script to play the animation through once. Here's "PlayOnce.lua":

    --int sequence --float speed 1 --bool enabled false function actor:Start() self.frame=0 self.enabled=true end function actor:Enable()--in self.enabled=true self.frame=0 end function actor:Disable()--in self.enabled=false end function actor:Draw() if self.enabled then local length=self.entity:GetAnimationLength(self.sequence) self.frame=self.frame+AppSpeed() if self.frame>length then self.frame=length self.enabled=false end self.entity:Animate(self.frame,self.sequence) end end
    By using these general-purpose scripts we can set up game interactions and interesting behaviors, without coding...but if we need to code something new, the tools are a couple clicks away.
  11. Josh
    A new update is now available on the beta branch. This is a refinement of the new entity script fields, which rely on the object name, rather than the awkward drag and drop motion that was originally implemented. I've modified the code so that when a map is loaded, any targeted objects will be renamed with a name that is unique in the scene. For example, if two objects named "WaypointA" exist in the scene, and one of them is linked to from another object, the object will be renamed "WaypointA-1".
     
    This even works with copy and paste operations. Let's say you have a platform that travels between two waypoints. If you select the platform and both waypoints, then copy and paste them (or CTRL+drag) the waypoints will be renamed with unique names, so your copied assembly will all work together.
     
    This does not mean that all objects in a map will always have unique names, but that is something that may be implemented in the future.
     
    Your old maps should be usable with no changes. Please let me know how well this design works for you.
  12. Josh

    Entity Script System

    By Josh,

    We've had a lot of discussion with the community about the Leadwerks3D script system. The current design is based on a combination of user feedback, lessons learned from Leadwerks Engine 2, stealing ideas from other game engines, and my own judgement. Our goal is to make a really easy and powerful game scripting system, without overwhelming the user with complexity. With that said, I thought I would let you in on how the script system presently is working in our own builds, and the process of using it.
     
    To attach a script to an entity, open the Properties Editor. Click and drag the script file from the Asset Browser onto the Properties Editor. A tab appears where all the script properties are displayed:

     
    Here's an alternate approach we are playing with. Here, the properties editor is embedded in the scene tab in the side panel. Since assets can't be dragged from the Asset Browser to the Properties Editor (since they are in different tabs) we just right-click on the entity in the Scene Browser, and a standard file request dialog appears, allowing you to choose a script file:

     
    Which do you like better?
     
    The visual logic editor in Leadwerks3D is called "Synapse". To add an entity into Synapse, drag the entity from the Scene Browser into the Synapse window. The entity will appear as a block, with its attached script components displayed below it in order. The color of the logical block corresponds to the object color in solid and wireframe viewports:

     
    You can see the script defines the output and input functions that are displayed in Synapse. Next I'll show you how entities in Synapse can be strung together to make sequences of events and gameplay logic.
  13. Josh

    Environment Probes

    By Josh,

    Note: this is highly experiment and subject to cancellation, change, revision, etc. Now on with the blog...
     
    Shadmar and Reepblue have paved the way for this research, and I am experimenting with some of these ideas in Leadwerks.
     
    Environment probes in Leadwerks are an experimental entity that creates a vantage point from which a cubemap is generated. The cubemap provides a 360 degree view of the surrounding environment in a single texture. This texture can then be used in the deferred lighting routine to provide more realistic ambient lighting and reflections.
     
    Let's start off with the limitations. These are not an end-all be-all solution to global illumination or reflections. Environment probes must be placed by hand, and like a light, only cover a restricted area. The smaller the area, the more accurate they can be, but they will never provide 100% physically accurate reflections. They also do not reflect dynamic objects and can only enhance static lighting. Rendering the cubemaps is a fairly expensive step and should not be performed in real-time.
     
    It was fairly simple to implement a new entity type and make it render the surrounding scene into a cubemap. A new parameter was added to the Camera::SetRenderTarget() command to allow the user to specify a cubeface index, from zero to six. The resulting cubemap is displayed on a sphere in the editor.
     

     
    The next problem is what to do with the generated cubemaps. Source Engine uses the closest environment probe to each object when rendering reflective materials. This results in popping as objects move between different probes. We don't want that.
     
    It occurred to me that we could perform an additive step in the ambient light calculation, by uploading the closest 4-8 cubemaps into the ambient light full-screen shader. This is basically like performing a forward rendering though, and I realized it was better for each probe to be rendered on its own, in a deferred step, just like a point light. So now instead of thinking of environment probes as area hints of what reflections should look like, I am now considering them to be "ambient lights".
     
    Environment probes / ambient lights would add two types of lighting to the scene. They would first use a low-frequency sample of the cubemap (probably by just using a low-res mipmap) and use this to add ambient light to the scene. This would do things like make a neon sign cast lighting onto the surrounding environment. Another calculation could be performed at the same time for reflective surfaces, possibly using the material's specular term as the reflectivity at each pixel. You would probably want to use pure black ambient light with this, so that the lighting just came from the environment itself.
     
    The good of this is that with some extra care, you could create an environment with detailed reflections, more varied ambient lighting, and it would be completely compatible with how we do everything right now.
     
    The downside is you will have to place a lot of overlapping environment probes to fill up your map, and it may be tedious to cover every part of the map, and your reflections won't react to dynamic objects or changes in lighting, without expensive re-renders of the cubemaps.
     
    If it works out as described above, I see this as an additional tool you can use if wanted, to achieve some kinds of new looks in some maps. It isn't an end-all solution to completely dynamic reflections, but it could be used to enhance some types of maps.
     
    More as it develops.
  14. Josh

    EuroTrip II

    By Josh,

    I am now in possession of the official Leadwerks USB drives.  Weighing in at 16 GB, they look fantastic.

    These will be shipped out shortly, along with the posters from the last game tournament.  I've been working behind the scenes on some big things that took my attention, but I am not yet ready to reveal any of this.  Because of the timing on this, we are going to do a Leadwerks Fall Games Festival starting in September.
    I am going to spend the rest of the summer in Europe, where I will be accompanied by my handy-dandy Gigabyte Brix Pro provided to me by Intel at the first Steam Dev Days.  Thanks Intel!:

    I will be working on NAT punch-through, Leadwerks 5, and making bug fixes.  I will also be meeting with developers in countries with a much cheaper cost of living, for the purpose of potentially expanding the company's development capabilities so I can bring you more cool stuff.
  15. Josh

    Even Deeper

    By Josh,

    Lua's debug hooks are a little funny, because they don't appear to allow line-by-line calling of your own function. The description here is pretty vague:
    http://pgl.yoyo.org/luai/i/lua_sethook
     
    The line and count hooks look like they might be what I wanted, but the docs have one big caveat:
    This makes me wonder what the point of these hooks even is. The way I have it set up now, "Step" continues to either the next Debug:Stop() call, or to the next point where a Lua function is called. Not C++ functions, Lua functions only, as shown in the code below.

     
    Additionally, I found that each time the hook was actually being called twice. No idea why, but I added a flag to discard every other call. I'm not too happy with the documentation of this or it's design, but the important thing is that the Debug:Stop() function be usable to set a program breakpoint, which it can. I sent a query to the Lua mailing list, and I'll work on it some more if anyone indicates that it's supposed to be able to do line-by-line stepping.
     
    I did some additional work on the shader editor, adding a few ideas I got from the script editor. The tabs for errors and warnings will show a number indicating how many items each tab has. I also made it so the compiler output gets printed even when the shader is successfully compiled, which wasn't the case before. As you can see in the screenshot below, the shader editor can be very useful for catching problems that might occur on other cards. I have an NVidia GEForce 480 in right now, but I can see from the warnings list this shader probably would not work on other hardware! This is becoming very useful as a diagnostic tool.

     
    Well, that was my day today. What did you accomplish today?
  16. Josh
    This code added to main.lua actually works:

    --Create a window local windowstyle = window.Titlebar if System:GetProperty("fullscreen")=="1" then windowstyle=windowstyle+window.FullScreen end window=Window:Create(title,0,0,System:GetProperty("screenwidth","1024"),System:GetProperty("screenheight","768"),windowstyle) window:HideMouse() --Create the graphics context context=Context:Create(window,0) if context==nil then return end --Create a GUI local gui = GUI:Create(context) local widget = Widget:Create(20,20,75,30,gui:GetBase()) widget:SetScript("Scripts/GUI/Button.lua")
     
    And then "Button.lua" is super simple:

    function Script:Draw() self.widget.gui:SetColor(64,64,64)
    self.widget.gui:DrawRect(self.widget.position.x,self.widget.position.y,self.widget.size.width,self.widget.size.height)
    end
     
    I'll probably be around RTX this weekend, just because I watched RvB back in the day, and it's only a few blocks away at the Austin convention center. Here's what started it all:
     


  17. Josh
    I've been working a lot on the business side of Leadwerks lately, and although the results aren't yet visible, it's important to ensure our long-term goals are achieved. I wish I could say more right now.
     
    My main machine is back on Windows XP. I don't want to discuss the relative merits of operating systems, but for me Windows XP is more productive. Other people might not work the way I do, so they will have their own preferences, and no one is "wrong". That said, I am surprised with how simple everything feels. Instead of "experiencing" someone else's idea of what a computer should be like, I feel like I have things back under my control. I looked up a lot of registry tweaks, and am tuning XP to work just the way I want. Here are some of the modifications I made:

    Modified Explorer search to include all file types.
    "Computer" now opens with file tree on the left.
    Shortcuts don't display an arrow.
    Modified places bar shown on the left with file request dialogs.
    Disabled Autoplay on all drives.
    Disabled logon screen.
    Yeah, I know it is funny that a programmer is talking about Windows XP like it's 2001, but I like it.
     
    TweakUI is a neat little application I found handy that you might like, and it's offered on Microsoft's website, so it might be a little more reliable than some others.
     
    Another good aspect of my setup on XP is security. I love Sygate Personal Firewall. It prompts the user for every single connection that is attempted, and gives you the option to allow, deny, and save your setting to use again later. There's probably other Firewalls for Windows 7 that work just as well, but none of the ones I tried were as intuitive.
     
    I'm surprised with how few program I actually need. It's also interesting to see how they have changed over the years. Here's a partial list of installed apps:
     

    Firefox
    Digsby (I had a brief quarrel with this program, but I love it.)
    SmartFTP (inexpensive and fantastic)
    OpenOffice
    Microsoft Visual Studio
    BlitzMax
    BLIde Plus
    XNView
    Media Player Classic (I like Media Player 12 a bit, but it's not available for XP, and I always keep this installed anyway)
    WinAmp 2.95 with Blackdawn skin.
    Paint.NET
    Sygate Personal Firewall
    Avast Antivirus
    CDBurnerXP (very good free program!)
    Steam (of course)
    WinRar
    TGA thumbnail viewer
    DDS thumbnail viewer
    Windows Texture Viewer
    Adobe Reader
    So I have everything the way I want, in my own little obsessive-compulsive method of organizing my computer. I think today will shape up to be a very productive day, programming-wise.
     
    What common programs do you find useful? How have these changed over the years? Now that I have Digsby, I don't need Windows Messenger. I'm attempting to replace Microsoft Office with OpenOffice.org. What about you?
  18. Josh

    Evolution

    By Josh,

    This is a good time to write about some very broad changes I expect to come about over the next year in our community as our new engine "Turbo" arrives. Turbo Game Engine, as the name suggests, offers really fast performance using a groundbreaking Vulkan-based renderer, which is relevant to everyone but particularly beneficial for VR developers who struggle to keep their framerates up using conventional game engines. I want to help get you onboard with some of the ideas that I myself am processing.
    Less emphasis on how-to tutorials, more emphasis on API documentation
    The new engine assumes you are either an artist or a programmer, and if you are a programmer you already know basic C++ or Lua. More attention will be paid to precisely documenting how commands behave. There will be a more strict division between supported and unsupported features. There will be less "guessing" what the user is trying to do, and more formal documentation saying "if you do X then Y will occur". For example, every entity creation function requires the world object be explicitly supplied in the creation command, instead of hiding this away in a global state. There will not be tutorials explaining what a variable is or teaching basic programming concepts.
    More responsiveness to user requests, especially for programming features
    Leadwerks 4 features have been in a semi-frozen state for a while now. Although many new features have been added, I have not wanted to create breaking changes, and have been reluctant to introduce things that might create new bugs, because I knew an entire new infrastructure for future development was on the way. With the new engine I will be more receptive to suggestions that make the engine better. One example would be an animation events system that lets users set a point in an animation where an event is called. These changes need to be implemented within the design philosophy of the new engine. For example, I would use an Actor class method to call the event function rather than a raw pointer. Emphasis should be placed on what is practical and useful for competent programmers and artists, and how everything fits into the overall design.
    Less attempts at hand-holding for new developers
    The new engine will not attempt to teach children to make their own MMORPG. Our marketing materials will not even suggest this is possible. The new engine will deliver performance faster than any other game engine in the world, period. Consequently, I think the community will gain a lot more advanced users, and though some of them will not even interact on the forum I do think you will see more organic creativity and quality. In its own way, the new engine actually is quite a lot easier to work with, but the sales pitch is not going to emphasize that, it will just be something people discover as they use it. I love seeing all the weird and cool creations that comes from people who are completely new to game development, but those people were new to game development and did well with Leadwerks had a lot of natural talent. Instead of trying to come up with a magic combination of features and tutorials to turn novices into John Carmack, we are going to rely on the product benefits to draw them and expect them to get up to speed quickly. Discussions should be about what is best for intermediate / experts, not trying to figure out what beginners want. Ease of use is subjective and I feel we have hit the point of diminishing returns chasing after this. If beginners want to jump in and learn that is great, but it is not our reason for existing.
    Stronger focus on the core essentials
    At the time of this writing, there are only eight entity types in the beta of the new engine. We can't win based on number of features, but we can do the core essentials much better than anyone else. Our new Vulkan renderer offers performance that developers (especially VR) can't live without. Models, lights, and rendering are the core features I want to focus on, and these can be expanded by the end user to create their own. For example, a custom particle system with support for all kinds of behaviors could easily be created with the model class and a few custom shaders, without breaking the performance that makes this engine valuable. Our new technology is very well thought out and will give us a stable base for a long time. I am planning on a plugin / extensions system because its best for this to be integrated in the core design, but you should not expect this to be very useful for a couple of years. Plugin systems require huge network effects to offer anything valuable. We can only reach that type of scale by offering something else unique that no one can match us on. Fortunately, we have something. It's right in the name.
    More formal support for good standards
    Vulkan has turned out to be a very good move. I don’t think anyone realizes how big a deal GLTF support is yet: you can download thousands of models from Sketchfab and other sources and load them right now with no adjustments. I may join the Khronos consortium and I have some ideas for additional useful GLTF extensions. I'm using JSON for a lot of files and it's great. DDS will be our main texture file format. There are more good standards today than there were ten years ago, and I will adopt the ones that fit our goals.
    Different type of new user appearing
    With Leadwerks, the average new user appears on the forum and says “hey, I want to make a game but I don’t really know how, please tell me what I need to know.” With the new engine I think it will be more like “hey, I’m more or less an expert already, I know exactly what I want to make, please tell me what I need to know.” I expect them to have less tolerance for bugs, undefined behavior, or undocumented features, and at the same time I think it will be easier to have frank discussions about exactly what developers need.
    In very general terms that is how I want to focus things. I think everyone here will adjust to this more strict and well-defined approach and end up liking it a lot better.
  19. Josh

    Expansion

    By Josh,

    Jorn Theunissen has been hired on a part-time basis to help design a new set of documentation for Leadwerks. We're taking a top-down approach whereby he designs an outline that encompasses everything you need to know, assuming the reader starts with zero knowledge. The goal is to explain everything in one set of information, down to the level of describing what a mipmap actually is.
     
    The organization of the material will be a linear list of lessons, with no nesting or sub-sections. This makes it easy to track your progress as you go through the material, and it's very clear where information is, with big thimbnails and descriptions for each chapter. Here is a mock-up of what the organization might look like:
     

     
    Benjamin Rössig has also been hired on a part-time basis to work on various features I don't have time to. He has contributed to Leadwerks in the past with the original program update system from Leadwerks 2, some of the Steamworks API calls, and wrote the Scintilla text editor. He is well-versed in C++, 3D graphics, and BlitzMax, which made this an easy choice.
     
    Plans for adding paid items to the Workshop are underway and I am working with about 20 third-party artists to bring their content to the Leadwerks Workshop. If you are interested in selling your game items in the Leadwerks Workshop and want to get in before the launch, please contact me.
     
    Leadwerks Game Player is in testing. There are various challenges as some of this technology is very new, but we'll keep iterating on this, improving it, and come up with a polished result for the end user. There is a major event coming in June that will give your Leadwerks Lua games major exposure. If you have a game you want to publish in the Game Player please contact me.
     
    Finally, Leadwerks 3.5 is schedule for release at the end of April. This will include CSG boolean operations, scene filters, groups, a new game project template, and possibly some features Benjamin is researching now.
  20. Josh

    Exporting a glTF model from 3ds Max

    By Josh,


    Articles
    Autodesk 3ds Max now supports export of glTF models, as well as a new glTF material type. The process of setting up and exporting glTF models is pretty straightforward, but there are a couple of little details I wanted to point out to help prevent you from getting stuck. For this article, I will be working with the moss rocks 1 model pack from Polyhaven.
    Getting geometry into 3ds Max is simple enough. I imported the model as an FBX file.

    To set up the material, I opened the compact material editor and set the first slot to be a glTF material.

    Press the button for the base color map, and very importantly choose the General > Bitmap map type. Do not choose OSL > Bitmap Lookup or your textures won't export at all.

    Select your base color texture, then do the same thing with the normal and roughness maps, if you have them. 3ds Max treats metal / roughness as two separate textures, although you might be able to use the same texture both if it grabs the data from the green (roughness) and blue (metal) channels. This is something I don't know yet.

    Select the File > Export menu item to bring up the glTF export dialog. Uncheck the "Export glTF binary" option because we don't want to pack our model and textures into a single file: I don't know what the baked / original material option does because I don't see any difference when I use it.

    At this point you should have a glTF file that is visible in any glTF model viewer.

    Now something slightly weird max does is it generates some new textures for some of the maps. This is probably because it is combining different channels to produce final images. In this case, none of our textures need to be combined, so it is just a small annoyance. A .log file will be saved as well, but these can be safely deleted.

    You can leave the images as-is, or you can open up the glTF file in a text editor and manually change the image file names back to the original files:
    "images": [ { "uri": "rock_moss_set_01_nor_gl_4k.jpg" }, { "uri": "M_01___Defaultbasecolortexture.jpeg" }, { "uri": "M_01___Defaultmetallicroughnesstex.jpeg" } ], Finally, we're going to add LODs using the Mesh Editor > ProOptimizer modifier. I like these settings, but the most important thing is to make sure "Keep textures" is checked. You can press the F3 key at any time to toggle wireframe view and get a better view of what the optimizer does to your mesh.

    Export the file with the same name as the full-resolution model, and add "_lod1" to the end of the file name (before the extension). Then repeat this process saving lod2 and lod3 using 25% and 12.5% for the vertex reduction value in the ProOptimizer modifier.
    Here is my example model you can inspect:
    mossrock1a.zip
    Now it is very easy to get 3D models from 3ds max to your game engine.
  21. Josh
    PBR materials look nice, but their reflections are only as good as the reflection data you have. Typically this is done with hand-placed environment probes that take a long time to lay out, and display a lot of visual artifacts. Nvidia's RTX raytracing technology is interesting, but it struggles to run old games on a super-expensive GPU, My goal in Leadwerks 5 is to have automatic reflections and global illumination that doesn't require any manual setup, with fast performance.
    I'm on the final step of integrating our voxel raytracing data into the standard lighting shader and the results are fantastic. I found I could compress the 3D textures in BC3 format in real-time and save a ton of memory that way. However, I discovered that only about 1% of the 3D voxel texture actually has any data in it! That means there could be a lot of room for improvement with a sparse voxel octree texture of some sort, which could allow greater resolution. In any case, the remaining implementation of this feature will be very interesting. (I believe the green area on the back wall is an artifact caused by the BC3 compression.)
    I think I can probably render the raytracing component of the scene in a separate smaller buffer and the denoise it like I did with SSAO to make the performance hit negligible on this. Another interesting thing is that the raytracing automatically creates it's own ambient occlusion effect.
    Here is the current state, showing the raytraced component only. It works great with our glass refraction effects.
    Next I will start blending it into the PBR material lighting calculation a little better.
    Here's an updated video that shows it worked into the lighting more:
     
  22. 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.
  23. Josh

    Field Trip

    By Josh,

    I was at a shopping center this afternoon wasting time, and came across a hobby shop. I can't quite articulate what it is about stuff like this that I like, but this is what I want game development with Leadwerks3D to be like. This is why I set up the Leadwerks Asset Store and make the effort to make nice thumbnails with transparency to show off items in 3D. I want more game development to be a process of producing reusable components, and then at the design level, of picking and choosing which components to utilize.
     
    This is the kind of stuff I used to do as a kid, which undoubtedly paved the way for my future work in 3D graphics. I particularly like the packaging on the box in the first image: "You can do it!" I should use that. B)
     
    Post your thoughts below.
     

     

     

     

  24. Josh

    Final details on decals

    By Josh,

    I'm doing what I think is the final 3.6 build now. I've got the finished decal textures from Rich, and I made some small adjustments to the way these work.
     
    During development, I was not a fan of the "Decal Mode" material setting. It's terribly confusing, and it's unrealistic to expect that everyone is going to adjust all their materials for an obscure setting that isn't intuitive at all.
     
    Basically decals tend to have two kinds: Big decals are used to add detail to the map. Small decals are used for bullet marks. There are other uses, but this covers 95% of what you would want to do with them.
     
    I set it up so decals have a checkbox in the properties that allows you to select which types of entities they appear on, brushes, models, and/or terrain. You can also call Decal::SetRenderMode(classid, mode) to control whether they appear on a per-class basis:

    decal:SetRenderMode(Object.BrushClass,true)
     
    The build will be up on the beta branch shortly.
     

  25. Josh

    Final sound recording API

    By Josh,

    My Gigabyte Brix pro lacks an audio in port and I was not able to find a USB microphone yesterday. However, I found a cheap webcam with audio support and have been using this to test voice recording, and it works great. Here is the final voice recording API:
    bool Sound::StartRecording(const int frequency = 22050, const int format = Sound::Mono8, const int buffersize = 20480) Sound* Sound::StopRecording() bool Sound::StopRecording(Lobby* lobby) lobby->SetVoiceFilter(const uint64 steamid, const bool block) And in Leadwerks 5:
    bool StartRecording(const int frequency = 22050, const int format = SOUND_MONO8, const int buffersize = 20480) shared_ptr<Sound> StopRecording() bool StopRecording(shared_ptr<Lobby> lobby) lobby->SetVoiceFilter(const uint64 steamid, const bool block) The first overload of the StopRecording function will return a Leadwerks sound object you can play, and then second version of the function will broadcast your recorded audio to all players in the specified lobby. The SetVoiceFilter() method in the Lobby class can be used to block some players from receiving your voice audio, so the game can make voice chat private for your team.
    The lobby and peer-to-peer networking system are also done, so in theory we have everything we need right now to make multiplayer games. An update will be out soon on the beta branch so you can start testing these new features.
Copyright © 2024 Ultra Software.
All rights reserved.
×
×
  • Create New...