Jump to content
Ultra Engine Community

Josh

Staff
 View Profile  See their activity

  • Posts

    23,222

  • Joined

  • Last visited

 Content Type 

Blog Entries posted by Josh

  1. Josh

    2016 Plans

    By Josh,

    Leadwerks is about making games, first and foremost. Therefore, you can expect me to focus on the following in the next year:
    More and better AAA first-party content. We're working out the process right now. It's a lot harder to produce top-quality content, but the results are worth it. I figure once we get the process down it will be easier to go back and produce more.
    Easy to use networking will open up a lot more gameplay possibilities and give us some fun games we can jump in and out of. I want to shoot it out with you guys in a variety of games with different objectives.
    Paid Workshop items are something I am very interested in.

     
    These are the main ideas that I feel will move Leadwerks in the direction we want to go. There will be undoubtedly other features and improvements added, but these are the things that really move us forward. Overall, I want Leadwerks to become more like a moddable game, without losing the simplicity and flexibility we have to make anything.
  2. Josh
    One of my main goals in 2016 is to build a built-in store for Leadwerks users to buy and sell 3D models and other items through Steam. It took me a while to understand how this works:
    The client (Leadwerks Editor) sends a message to the Leadwerks.com server requesting that a purchase be made.
    The Leadwerks.com server sends a message to the Steam server requesting that a purchase be initialized.
    Steam displays a dialog to confirm the transaction in Leadwerks Editor.
    The Steam server returns the result of the transaction to the Leadwerks.com server.
    If the transaction was successful, the Leadwerks server stores a record of the transaction in an SQL database on the server.
    The editor receives a message confirming the transaction and downloads the purchased item.

     
    It's sort of complicated, and it's not really something I am used to dealing with. The first step is to restore our SSL certificate, which I let lapse because we aren't using it for anything anymore. I have a web developer I talked to a few months ago about this project, and put it on hold because of the holidays, but will contact him again soon.
  3. Josh

    Workshop Spam

    By Josh,

    It appears that items that were released within a certain time period, right when the Workshop was made public, received a lot of "spam" comments like below, from people who don't even own Leadwerks:
     

     
    I have nothing against TJHeldna's cola can, but I don't believe it is the top-rated item in the Workshop through genuine votes:
    http://steamcommunity.com/workshop/browse/?appid=251810&browsesort=toprated&section=readytouseitems&actualsort=toprated&p=1
     
    It's very obvious which items got spammed. They each have 30+ one-word comments. In order to fix this, the following items are going to be removed from the Workshop by banning, which is the only mechanism I have to do this:
    http://steamcommunity.com/sharedfiles/filedetails/?id=254432232&searchtext=
    http://steamcommunity.com/sharedfiles/filedetails/?id=281171208&searchtext=
    http://steamcommunity.com/sharedfiles/filedetails/?id=261126240&searchtext=
    http://steamcommunity.com/sharedfiles/filedetails/?id=304502026&searchtext=
     
    This does not mean I don't like your item, it just means your Workshop page got spammed and it messed up the ratings. I am downloading each item and will have it available for you if you wish to re-upload it.
  4. 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.
  5. Josh
    An often-requested feature for terrain building commands in Leadwerks 5 is being implemented. Here is my script to create a terrain. This creates a 256 x 256 terrain with one terrain point every meter, and a maximum height of +/- 50 meters:
    --Create terrain local terrain = CreateTerrain(world,256,256) terrain:SetScale(256,100,256) Here is what it looks like:

    A single material layer is then added to the terrain.
    --Add a material layer local mtl = LoadMaterial("Materials/Dirt/dirt01.mat") local layerID = terrain:AddLayer(mtl) We don't have to do anything else to make the material appear because by default the entire terrain is set to use the first layer, if a material is available there:

    Next we will raise a few terrain points.
    --Modify terrain height for x=-5,5 do for y=-5,5 do h = (1 - (math.sqrt(x*x + y*y)) / 5) * 20 terrain:SetElevation(127 + x, 127 + y, h) end end And then we will update the normals for that whole section, all at once. Notice that we specify a larger grid for the normals update, because the terrain points next to the ones we modified will have their normals affected by the change in height of the neighboring pixel.
    --Update normals of modified and neighboring points terrain:UpdateNormals(127 - 6, 127 - 6, 13, 13) Now we have a small hill.

    Next let's add another layer and apply it to terrain points that are on the side of the hill we just created:
    --Add another layer mtl = LoadMaterial("Materials/Rough-rockface1.json") rockLayerID = terrain:AddLayer(mtl) --Apply layer to sides of hill for x=-5,5 do for y=-5,5 do slope = terrain:GetSlope(127 + x, 127 + y) alpha = math.min(slope / 15, 1.0) terrain:SetMaterial(rockLayerID, 127 + x, 127 + y, alpha) end end We could improve the appearance by giving it a more gradual change in the rock layer alpha, but it's okay for now.

    This gives you an idea of the basic terrain building API in Leadwerks 5, and it will serve as the foundation for more advanced terrain features. This will be included in the next beta.
  6. Josh

    Multiple Light Bounces

    By Josh,


    Articles
    I have more than one light bounce working now, and it looks a lot nicer than single-bounce GI. The ambient light here is pure black. All light is coming off from the direct light, and bouncing off surfaces.

    It will take some time to get the details worked out, and more bounces will require more memory. I'm actually kind of shocked how good looking it is. This is just a single 128x128x128 volume texture at 0.25 meters per voxel. Light leaks seem to be not a problem, even at that low resolution, even with thin walls.
    You can see that absolutely no direct light is hitting the red wall on the left, and the ambient light is pure black. Yet light is still bouncing off the floor onto the wall, and then lighting the dragon very faintly with red light. (The exposure here is higher than it should be so it looks a little washed out):

    There's a lot here for me to take in. Real-time global illumination is such a rabbit hole that keeps unfolding new layers of complexity and possibilities. It seems like every few days my mind is totally blown and I look at the system differently, and the new way makes so much sense. In the last three days I have said to myself "I'll just try one more thing..." and then that thing opens up a lot of new possibilities. April is nearly over, and I have been working on just this feature since December!
    I've got a bunch of stuff to work out, but it looks like this will run really really well in VR.
  7. Josh

    Vegetation nation

    By Josh,

    I got my hands on the GDC showcase scene by Michael Betke, and it's much more beautiful than I thought. I used this scene to rewrite and test the vegetation rendering code. Collision isn't working yet, but it's built into the routine. The results speak for themselves.
     
    Fortunately, Pure3D is soon offering a set of game-ready vegetation models, so you can create gorgeous landscapes like this.
  8. Josh

    Improvements for 2.32

    By Josh,

    Version 2.32 will feature some internal improvements that ensures your games run their best when conditions get demanding. I've totally rewritten the vegetation rendering routines with a highly specialized quad tree algorithm. There's a lot more to it than that, and I could write ten pages about the technique, but the bottom line is its fast and dynamic. Rendering with many vegetation layers is much faster, and since the visibility determination routine is so optimized, the engine can perform a separate visibility determination step for each stage in a directional light. The amount of shadow polygons that have to be rendered was less than half what version 2.31 required, in our test scene. Realistically, you can now render more trees with Leadwerks than Crysis.
     
    For entities, a scene octree has been implemented. This ensures that the engine only has to deal with objects in the near vicinity of the camera, even if there are tens of thousands of objects offscreen or far away. For scenes that have lots of little objects, you'll see a big performance gain, especially if you use the view distance feature. In version 2.32, each entity has a view distance setting which can be set to near, medium, far, or infinite. The engine stores lists of objects by view distance for each leaf in the octree, and skips object sets that are too far away, without having to iterate through each one. In the future, I would like to implement an update radius...this is how S.T.A.L.K.E.R. games are able to have so many AI characters walking around a map, and it's not too hard to add!
     
    Another improvement is the hierarchical rendering and picking algorithm. In version 2.31, every entity was stored in the scene graph. In version 2.32, only entities with no parent are stored. The top-most entity has a recursive bouncing box that encompasses all its children and sub-children, and is automatically updated once a frame when anything in the hierarchy changes. Let's say you have a truck. The truck consists of a chassis, four wheels, and a rotating turret. In version 2.31, all six sub-objects would be stored in the scene graph and iterated through for rendering. In version 2.32, only the top-most entity is stored in the octree. If the top-most entity is not visible, the entire truck is skipped. If the top-most entity is visible, its children are iterated through until they are all rendered.
     
    What about the case of animated characters, which might have 100 or more bones in their hierarchy? Wouldn't it be inefficient to have to iterate through the whole skeleton, especially when most of the time there won't even be anything that needs to get drawn? Yes, you are right. I got around this problem by adding a "renderable" setting to each entity. Meshes, coronas, emitters, etc., have the renderable setting set to True. Pivots, bodies, and other invisible entities have it set to False. Each entity also stores a recursive attribute that stores the number of children in its subhierarchy that are renderable. So when a bone is encountered in the rendering algorithm, if it doesn't have any renderable children in its sub-hierarchy, it will be skipped, and the engine won't have to iterate through all those bones for nothing. If the bone connects to a shoulder that connects to a forearm that connects to a hand that has a gun attached to it, the engine will iterate through those entities to get to the renderable gun mesh. It's the best of all worlds.
     
    If you only have a simple scene running, you probably won't see any speed improvements. However, these features will make the difference between your game running or not when you get further along in development, and will ensure you get the best possible performance. I would like to be working on some more high-level features that make the development experience nicer for the end user, but the most important thing for me to do is make sure your games are the best they can be. That's why I thought it was important to devote time to the described areas.
  9. 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?
  10. Josh

    Some hints of 3.0

    By Josh,

    This is a quick blog to fill you in on some of the features planned for Leadwerks Engine 3.0.
     
    -Any entity can be a physics body. The body command set will become general entity commands, i.e. Entity.SetVelocity(). You can make an entity physically interactive with Entity.SetShape( shape ).
     
    -Any entity can have any number of scripts attached to it. The basic model script functions will be supported for all entities, plus specialized script functions for certain entities. For example, particle emitters will have an optional script function that is called when a particle is reset. This could be used to make a fire emitter "burn" a mesh. Script functions are called in sequence, so you can attach a chain of scripts to an entity to combine behaviors.
     
    -Prefabs will be supported, with the ability to drag entities together to make a hierarchy, add lights, emitters, and other entities, attach scripts, and then save a prefab.
     
    -Record screenshots and movies from the editor!
     
    -Tons of scripted behavior you can attach to your own models, and lots of scripted assets you can download. Basic AI features will be supplied.
     
    -The editor is being designed so you only need a mouse to make games. If you want to script or program or make artwork you can, but at the simplest level, the whole workflow can be controlled in the editor, with reloading assets, automated imports, and lots of drag-and-drop functionality.
     
     
    That's all for now. I can't tell you some of the coolest features, but this gives you an idea of where we are headed.
  11. Josh

    Picking Up St(r)eam...

    By Josh,

    I'm making good progress on LE3 now. First I had to write basic functionality for things like strings and file access. It was tedious, but now that it's done I've got a nice library of functions that make programming all that much easier. The string commands include Trim(), Split(), ExtractExt(), StripDir(), etc. I know the Boost library has some functionality like this, but I'd like to avoid relying on third party libs whenever possible. I've also got the file system working, with a FileFactory class that can be extended to handle internet or other files. The commands are simple and easy to use:

    Stream* stream = ReadFile("myfile.txt"); int n = stream->ReadInt(); delete stream;
    The regular file commands work for .pak file reading as well.
     
    These features will also be useful for Codewerks, my meta language that uses C++ compilers. I have put development of this on hold for now, but I am still very interested in picking it back up again at a later date. It's nice to see that everything I originally envisioned for that will work just fine.
     
    The OpenGL 3/4 renderer is started. The changes from OpenGL 2.1 to the latest version are pretty minor. Since I already know OpenGL pretty well, I don't think the LE3 renderer will be too hard at all.
     
    The texture class is working. Each texture has one or more "frames" for animated textures.
     
    So far everything should be cross-platform compatible, but I'll be picking up an iMac pretty soon so I can try it out on MacOS. I'm going to use XCode on Mac and Visual Studio on Windows. I'll probably use Code::Blocks or CodeLite for Linux.
     
    I'm comfortable with C++, and have enough knowledge of it now to finish the project.
     
    So I guess to sum it up, this week marks the end of the learning and experimenting phase, and the start of actual coding. Coding LE3 in C++ is about the same as coding it in BlitzMax, although a bit slower. The point is I am just dealing with my own code and design instead of worrying about learning new conventions, so I think things will speed up now.
     
    Thanks for all your ideas and feedback in the feature requests forum. Some really good suggestions have come from the community that I will incorporate in LE3.
     
    On a final note, LOL Week was a tremendous success. Here are some of my favorite images that were posted.
     






  12. Josh

    Leadwerks3D on Android

    By Josh,

    After some initial difficulty, Leadwerks3D is now running on Android, with the exact same code that runs on iPhone, iPad, Windows, and Mac. A big thanks for Aria for all his help and expertise with the Android platform. This means Leadwerks3D is now running on all platforms we intend to support at launch, and it can be easily extended to support new ones.
     


     
    To celebrate, here's another cartoon I drew:

  13. Josh

    Model Editor

    By Josh,

    When you double-click a model file in the asset browser, it's opened up in the model editor window within Leadwerks3D. You can drag materials onto a model to assign them, then just save the model and close the window. You can also drag textures straight onto the model, and Leadwerks3D will do a pretty good job of guessing what material to use. If no material exists, it will create one, and take a good guess at what textures should be added to it, then apply the newly created material to the model.
     


  14. Josh

    Project Manager

    By Josh,

    The Project Manager lets you manage multiple Leadwerks projects. A project includes assets, scripts, code, code projects for Visual Studio, Xcode, and Eclipse, along with your game's executable. The Project Manager lets you view and switch between your different projects.

     
    Projects can be exported into a .zip file for easy sharing and archiving. You can even have Leadwerks3D scan all source code files and only include the asset files that your game actually uses. (I'm still adding the password field to encrypt them):

     
    You can import projects back from a .zip file:

     
    And of course you can create new projects, for any supported language, with multiple platforms supported by each:

     
    Here's my list of things I have either recently gotten done, or postponed for some reason:
    X -Window order(?)
    X -Convex cast app (postponed)
    X -Script execution
    X -Script SaveAs, SaveAll, New, Open, etc.
    X -Directional light destructor bug
    X -Occlusion query / octreenode bug
    X -Delete thumbnails when folder deleted, if in deleted folder
    X -Send files/folders to recycle bin instead of deleting
    X -Project import from zip passwords
    X -Project switching
    X -CRC32 zip password checks
    X -Improve project import events and process
     
    And still to go:
    -Add password export zip field
    -Animation
    -CSG Editing
  15. Josh

    Amazing Tools

    By Josh,

    This is just so cool. You can generate simple primitives for any entity. A convenient "Fit Shape" button will wrap the primitive around the entity, with an option to include the entity's children. However, the real power comes when you generate physics shapes from models. You can right-click on any model and get a menu to generate a physics shape. The polygon mesh and convex hull will look familiar if you've used the PhyGen tool in Leadwerks Engine 2. There's also a new option called "Convex Decomposition".

     
    Convex decomposition is an advanced algorithm that takes a polygonal mesh and outputs a series of convex shapes. This is helpful because real physics calculations require geometry with actual volume instead of just being a polygon soup. Convex decomposition can turn any polygonal mesh into a physics shape, such as the Stanford bunny shown below:

     
    This means you can generate accurate physics shapes for any model, without creating special physics models in 3ds Max or Blender.
     
    Take complex objects like this Utah teapot and generate a physics shape for it, then attach that shape to the model and save it as a prefab. Here you can see the physics shape that was calculated for the teapot using convex decomposition. Navigation is turned on to make the teapot into a dynamic obstacle AI will avoid going through:

     
    It's taken a long time to build a game development platform that accelerates development without restricting you, but I think the results are worth it. I hope you are looking forward to using these tools as much as I am.
  16. Josh

    iOS 6 Blues

    By Josh,

    Apple's problems in iOS 6 aren't limited to maps. Their OpenGL drivers in iOS 6 are absolutely non-functional.
     
    First I was experiencing a BAD_EXC_ACCESS error when rendering certain surfaces. Feedback on the Apple dev forum suggests I am not alone in this. I took a guess and switched my position vertex buffers to use vec4s instead of vec3s, and it appears to have solved that problem (even though both should be fine).
     
    Second, all 3D objects just stopped appearing, completely. I've debugged it to the point of absolute barebones, and still can't get anything to show up...but only on the iPad 3 device itself. My iPhone 4 (also running iOS 6.01), the iOS simulator, and even my HTC Evo all appear fine, running the same code.
     
    My guess is that the Apple driver team was given a directive to get the speed of their graphics chip up to be competitive with the latest 12-core NVidia Tegra, and that they gained speed by fine-tuning the drivers for specific applications they were testing with, at the expense of compliance with the OpenGL ES specification.
     
    In a world where the graphics device performance between all targeted hardware can vary by 1000x, compliance with the OpenGL spec is paramount. Performance at the cost of reliability is not an option.
     
    I also have come to the conclusion that OpenGL is just a fundamentally flawed API. Programmable shaders have been around since 2003-ish, and the vendors still can't write drivers that work. I take this as an indication that the OpenGL specification is just too complicated.
     
    Anyways, this is one of my more emo blogs, and I will solve the problem, but that's where I'm at today. Considering the amount of non-working **** we deal with on both Android and iOS, it's clear to me that for most developers, cross-platform development is just infeasible. I'm glad we can figure this stuff all out for you, so you can just use our API and not worry about all the mistakes third parties make with their APIs, drivers, and tools.
  17. Josh
    A new update on the beta branch on Steam adds selective file inclusion on publishing a project. This works by scanning map files and building a list of required files, and only packing up files that are actually used in your game. Here's how it works:
    All map files are always included, and scanned for required files.
    All script files are always included, and scanned for required files.
    Included prefab files are scanned for required files.
    Included model files are scanned for required material files.
    Included material files are scanned for required texture files.
    All shaders are always included.

     
    The bulk of file sizes in any project are textures, and to some extent, model files. Although it is possible for this system to generate some "false positives" it will greatly reduce the size of published projects, and errs on the side of caution.
     
    I am concerned some required material files may not be caught. If you find a situation where this feature is not working properly please upload your project and send me a link to download it.
     
    This is the default behavior, and is always active when publishing your project.
     
    I hope to have this up on the default branch in time for the last few days of the Winter Games tournament.
  18. Josh

    Vegetation

    By Josh,

    There's basically two kinds of vegetation, trees and grass.
     
    Grass is plentiful, ubiquitous, dense, but can only be seen at a near distance. Its placement is haphazard and unimportant. It typically does not have any collision. ("Grass" includes any small plants, bushes, rocks, and other debris.)
     
    Trees are fewer in number, larger, and can be seen from a great distance. Placement of groups of trees and individual instances is a little bit more important. Because these tend to be larger objects, they have physics collision.
     
    Now figuring out how to take advantage of modern GPU architecture with both of those types of objects is an interesting problem. I started with geometry shaders, thinking I could use them to create duplicate instances on the fly. This geometry shader will do just that:

    #version 400  
    #define MAX_INSTANCES 81
    #define MAX_VERTICES 243
    #define MAX_ROWS 1
     
    uniform mat4 projectioncameramatrix;
    uniform mat4 camerainversematrix;
     
    layout(triangles) in;
    layout(triangle_strip,max_vertices=MAX_VERTICES) out;
     
    in mat4 ex_entitymatrix[3];
    in vec4 ex_gcolor[3];
    in vec2 ex_texcoords0[3];
    in float ex_selectionstate[3];
    in vec3 ex_VertexCameraPosition[3];
    in vec3 ex_gnormal[3];
    in vec3 ex_tangent[3];
    in vec3 ex_binormal[3];
    in float clipdistance0[3];
     
    out vec3 ex_normal;
    //out vec4 ex_color;
    out vec3 ex_jtangent;
    out vec3 ex_jbinormal;
    out vec3 ex_jjtangent;
     
    void main()
    {
    //mat3 nmat = mat3(camerainversematrix);//[0].xyz,camerainversematrix[1].xyz,camerainversematrix[2].xyz);//39
    //nmat = nmat * mat3(ex_entitymatrix[0][0].xyz,ex_entitymatrix[0][1].xyz,ex_entitymatrix[0][2].xyz);//40
     
    for(int x=0; x<MAX_ROWS; x++)
    {
    for(int y=0; y<MAX_ROWS; y++)
    {
    for(int i=0; i<3; i++)
    {
    mat4 m = ex_entitymatrix;
    m[3][0] += x * 4.0f;
    m[3][2] += y * 4.0f;
    vec4 modelvertexposition = m * gl_in.gl_Position;
    gl_Position = projectioncameramatrix * modelvertexposition;
    ex_normal = ex_gnormal;
    //ex_color = ex_gcolor;
    ex_jjtangent = ex_gnormal;
    ex_jtangent = ex_gnormal;
    ex_jbinormal = ex_gnormal;
    EmitVertex();
    }
    EndPrimitive();
    }
    }
    }
     
    I soon discovered some severe hardware limitations that make geometry shaders unusable for this type of application. There's a 255 limit on the number of vertices that can be emitted, but there's an even harsher limit on the number of varying you can output from the shader. Once you add values for texcoords, normals, binormals, and tangents, geometry shaders actually only allow 16 instances per render...making them inappropriate for this purpose.
     
    What's really needed is an "instance shader" that could control how many times an object is rendered. This would simply discard an entire instance if it isn't in the camera frustum:

    uniform vec4 cameraplane0; uniform vec4 cameraplane1;
    uniform vec4 cameraplane2;
    uniform vec4 cameraplane3;
    uniform vec4 cameraplane4;
    uniform vec4 cameraplane5;
     
    uniform objectradius;
     
    uniform instancematrix[MAX_INSTANCES]
     
    bool PlaneDistanceToSphere(in vec4 plane in vec3 point, in float radius) {}
     
    main ()
    {
    mat4 mat = instancematrix[gl_InstanceID];
    vec3 pos = mat[3].xyz;
    float radius = objectradius * max(max(mat[0].length(),max[1].length),mat[2].length);
    if (PlaneDistanceToSphere(cameraplane0,position,radius) > 0.0) discard;
    }
     
    I realized I could render a number of instances without actually sending their 4x4 matrices to the GPU, and just generate the positions along a grid. This would start with an n X n grid and then add some noise to randomly rotate and scale each instance. The randomized positions would use the object's XZ position on the grid as the input, so I could dynamically generate the same orientation each time, without ever storing the object's actual position in memory. (This is why some Leadwerks 2 maps could be hundreds of megs of data.)
     
    Here is the code in the vertex shader that randomizes object scale and rotation:

    #define ROWSIZE 15 #define SEED 1
    #define randomness 3.0
    #define density 3.0
    #define scalevariation 1
     
    int id = gl_InstanceID;
    int x = id/ROWSIZE;
    int z = id - x * ROWSIZE;
     
    float angle = rand(vec2(SEED-z,SEED+x))*6.2831853;
     
    //Random rotation
    mat4 rotmat = mat4(1.0);
    rotmat[0][0] = sin(angle);
    rotmat[0][2] = cos(angle);
    rotmat[2][0] = -sin(angle+1.570796325);
    rotmat[2][2] = -cos(angle+1.570796325);
    entitymatrix_=rotmat*entitymatrix_;
     
    float scale = rand(vec2(SEED+z,SEED-x));
    float sgn = sign(scale-0.5);
    scale = (abs(scale-0.5));
    scale *= scale;
    scale = (scale *sgn + 0.5);
     
    scale = scale * scalevariation + 1.0-scalevariation/2.0;
    entitymatrix_[0] *= scale;
    entitymatrix_[1] *= scale;
    entitymatrix_[2] *= scale;
    entitymatrix_[3][0] = x*density + rand(vec2(SEED+z,SEED-x))*randomness;
    entitymatrix_[3][2] = z*density + rand(vec2(SEED+x,SEED-z))*randomness;
     
    Here is the result with trees randomly oriented entirely on the GPU:
     

     
    Of course you can have issues like no way to prevent two instances from being too close together, but a random seed, density, and randomness values are adjustable. It would also be possible to calculate a neighbor's position and use that to weight the position of the current instance.
     
    There are still many questions to be answered, but I think this approach is going in the right direction to design a more powerful and lower overhead vegetation rendering system for Leadwerks 3.
  19. Josh

    Beta update available

    By Josh,

    A new build is available on the beta branch with the following changes:
    Fixed sidepanel tab switching bug.
    Improved compatibility with intel graphics.
    Fixes instance rendering bug with instance count over 256.
    Added terrain hardware tessellation.

     
    To enable hardware tessellation, select the Tools > Options menu item, select the Video tab, and set the tessellation value. Terrain layers much have a displacement map to display displacement mapping. Each terrain layer has an adjustable displacement value to control the strength of the effect. Displacement maps look best when they are rendered from a high-polygon sculpt. The terrain wireframe shader has alsod been updated to visualize the tessellation in wireframe view. You must update your project to get the new versions of the terrain shaders.
     
    At this time, terrain will always use tessellation when it is enabled, even if no texture layers contain a displacement map. This will be changed in the future.
  20. Josh
    To provide support for advanced GUI rendering, some of the features I implemented in the refactored window class are being brought into the 2D drawing command set. This includes a lot of text rendering features like word wrap, multiline, horizontal and vertical centering, and viewport clipping.
     
    A new text drawing function includes additional parameters for better control:

    Context::DrawText(std::string text, int x, int y, int width, int height, int style)
     
    The style parameter can be a combination of the following options:

    Text::Left Text::Center Text::Right Text::VCenter Text::WordWrap Text::Multiline
     
    Context-based GUIs are now rendered to a texture first, and then the texture is drawn onscreen. This allows GUIs to be partially drawn (only invalidated parts of the GUI are re-rendered). That means if you move the mouse over a button or something, only that button re-renders, and the rest of the UI is just cached in the texture and doesn't have to be redrawn. This makes the GUI performance fast, even when lots of text is shown onscreen. This is perfect for dialog boxes or help screens.
     
    The alpha blend drawing mode has also been changed to use a separate blend function for the alpha values. When a primitive is rendered with alpha blending, the maximum alpha value will be left in the rasterizer. This makes it so the resulting GUI rendered image blends correctly when drawn on top of the screen with alpha blending enabled.
     

  21. Josh

    Using analytics in your game

    By Josh,

    As noted previously, Leadwerks 4.2 now support built-in analytics. To enable this in your game you need to create an account at www.gameanalytics.com and create a new product. You can find your keys on the Game Settings page.
     

     
    At the beginning of the main lua script, some code has been added to initialize analytics. By default this is commented out:

    if DEBUG==false then Analytics:SetKeys("GAME_KEY_xxxxxxxxx", "SECRET_KEY_xxxxxxxxx") Analytics:Enable() end
     
    Uncomment this and insert your game's game key into the first argument. Insert your secret key into the second argument.
     
    The main Lua script has already been set up to record a progress event when the player starts your level, and another when they complete it. Below the initial map loading code, a progress event is sent indicating the player has started the level:

    --Load a map local mapfile = System:GetProperty("map","Maps/start.map") if Map:Load(mapfile)==false then return end prevmapname = FileSystem:StripAll(changemapname) --Send analytics event Analytics:SendProgressEvent("Start",prevmapname)
     
    When a new map is loaded in the game loop, another event is sent to indicate that the previous level was completed, and the new level is beginning:

    --Send analytics event Analytics:SendProgressEvent("Complete",prevmapname) --Load the next map if Map:Load("Maps/"..changemapname..".map")==false then return end prevmapname = changemapname --Send analytics event Analytics:SendProgressEvent("Start",prevmapname))
     
    The FPSPlayer script has a new line of code in the OnDead() function that sends an event indicating the player failed to complete the level:

    if type(prevmapname)=="string" then Analytics:SendProgressEvent("Fail",prevmapname) end

    Viewing Data
    Once your game has accumulated enough data, you can look at your results in the Explore section and clicking on Look up metric. Your progress events will be shown here. 

     
    You can even set up a custom funnel in the gameanalytics.com web interface, which will give you a better visualization of player progress through your game.
     


    Interpreting Data
    If you see a lot of people starting a level, but few are finishing it, it may indicate your game is too hard, or the objective is not clear. If there is a large number of failed attempts, consider reducing the difficulty. If there is just a lot of starts and no completes, maybe the player is just bored. If you see some trouble spots in your game, try making changes, collect new data, and see if your changes improve the user experience. 
    Most importantly, you need a good amount of players in order for any analytics data to be useful. A sample size of 20 is statistically significant, and gives you enough information to make decisions. Analytics will give you objective data and help reveal problems you might not otherwise realize, but you need to have a fun game people like playing in order to collect the data in the first place.
     
    MartyJ was a huge help in figuring the implementation of this out.
  22. Josh

    Leadwerks 4.3 RC2

    By Josh,

    I've uploaded a full build for Windows and Linux, and updated the game launcher beta branch. This adjusts some very minor issues that you probably won't even notice.
     
    Some of your characters might need to have their character controller angle setting set to 180, depending on how you have them set up. This is because some previously incorrect behavior has been fixed. You can use my third-person player script for testing.
     
    My only concern at this point is that some of HaydenMango's games now have characters that are walking too slowly. I haven't seen this problem in any other games, so it is hard to guess what could be causing that.
  23. Josh

    Leadwerks 4.3 RC3

    By Josh,

    A full build is available for Windows and Linux on the beta branch on Steam. This fixes a problem with the character controller physics and with the Alt key on Windows.
     
    To upgrade 4.2 C++ projects to 4.3, you must add the following search paths:
    $(LeadwerksHeaderPath)\Libraries\libvorbis\include
    $(LeadwerksHeaderPath)\Libraries\libogg\include

     
    I'm pretty sure it's ready, but please give it a good thrashing. This will go up on the default branch tomorrow morning.
  24. Josh

    The path we are on

    By Josh,

    Previously, I have talked about my plans for Leadwerks and how to get there. In that blog I started with technical specs and went backwards with the path we would follow to achieve those goals. Now I have begun to put some of these ideas into practice and I want to review my plan with you.
     
    I met with a very large academic institution a few months ago and talked about using Leadwerks to teach game programming. This is the whole reason I wrote this blog and did the research included therein. When I put the graph up showing job requirements, it was a very easy sale.
     

     
    I then gave a short talk to a group of their students who had some web development background, but had zero game development experience. Perfect! These people are my bread and butter. The purpose of this was to gauge interest in a class in game development, and they were very interested.
     
    As I was talking to these people I realized I could not meet their expectations. No one else could either, but I knew at the end of a two week course they would only have very rudimentary ugly games made, not the dreams they had in their head. These people did not know anything about mipmaps, debuggers, texture coordinates, and they did not care. They just wanted to make games.
     
    I cancelled my plans to hold a class because I knew we weren't ready to give them what they really needed. Leadwerks is the easiest way to build your own 3D games, but we are not all the way there yet. No one out there is really giving complete beginners the means to learn to make their games quickly, but we can be the first to do it with a bit more work.
     
    As I stated previously, the documentation is being revised, including an offline copy of the docs. This takes an enormous amount of time because I have to copy, paste, and edit hundreds of pages. I am also revising all the code examples to only use the main .lua and .cpp files and get rid of the App::Start() stuff, which is a holdover from mobile.
     
    The next step is to create a broader selection of high quality game templates. This is the final step that is needed to bridge the gap between game development technology and a complete beginner. The templates have to be polished and feel like a game you would actually want to play. This must happen or everything I have done has been a waste of time.
     
    We are in a race against time to connect with a large audience in a way where they can't imagine life without Leadwerks. If I fail to do that, we will go the way of every other abandoned open-source game engine out there.
     
    So that is what I am working on.
  25. Josh
    I have proven beyond a shadow of a doubt that I am very bad at shipping posters.  The Winter Game Tournament was completed in January and I have yet to deliver your prizes.  If you have a job opening for someone to ship prizes, or to ship anything at all, I am probably the worst candidate you could ever hope to find to fill said position.  Seriously.
    Part of the problem (although it's still not an excuse) has been that it is actually incredibly difficult to have custom USB keychains made.  These took a long time because my description of black monochrome printing with the text vertical aligned was too apparently too complicated.

    The first proof I got used a beautiful white-on-silver-so-light-it's-practically-white color scheme.

    The second attempt's failure was slightly more subtle.  Slightly.  Is it just me, or does the logo obviously beg to be centered by the vertical center of the text, instead of the image dimensions?  Is this really that hard?:

    At this point I was all like:

    So I drew them a picture of something that to me seemed extremely obvious.  Finally, I got the corrected proof of our glorious USB keychain and have authorized a limited production of this one-of-a-kind item.  I will give props to the graphics designer for choosing the dark gray (subtle blue?) print color, which is much better than #000000:

    All I wanted was a little taste in design.
    So here's what I am going to do.  Each entrant in the Winter Games Tournament will receive one limited-edition poster, with one limited-edition Leadwerks USB keychain inside the poster tube, plus one Leadwerks sticker (which I have a ton of).  Because of the delay and the fact that I suck at shipping prizes, I am bumping up the 4GB USB drive to a whopping 16GB.  That's four times the jigglebytes, and enough to back up the entire Leadwerks.com website on.
    In other news, the acquisition of American Apparel by Gilden Activewear has actually affected our supply chain for the fabulous Leadwerks line of clothing.  The official Leadwerks hoodie in our signature gray color is currently only available in sizes small and extra small.

    I contacted SpreadShirt.com about the matter and received the following explanation:
    The first and most pertinent question is why is the little mermaid working in customer service for SpreadShirt?

    The second question is when will the official Leadwerks hoodie become available again?  The garment can be gotten in other colors, but I do not feel that any of these less appealing colors adequately represent the brand of our game engine.  This is most distressing and I will continue to look for a solution.
    The 2017 Summer Game Tournament will proceed once I have shipped the prizes out from the previous tournament.  However, as I have proven that I am not a reliable shipper of prizes, the tournament is going back to our original prizeless model.  A roundup of entries from all game developers will be posted at the end and fun will be had by all.
Copyright © 2024 Ultra Software.
All rights reserved.
×
×
  • Create New...