Jump to content

Josh

Staff
  • Posts

    23,222
  • Joined

  • Last visited

Blog Entries posted by Josh

  1. Josh
    Following my previous update about correcting file path cases, I am now able to load all our maps in Leadwerks. The power of this tool running natively on Linux is starting to show:
     

     
    The next step is to implement a file system watcher to detect file changes. Leadwerks automatically monitors the current project directory, and will reload assets whenever the file changes. This allows you to keep an image open in an image editor like GIMP, and any time you save your changes will be reflected inside Leadwerks. It's a great workflow for artists and just the kind of feature I wanted to bring to Linux with this project.
     
    Linux has a built-in file system watcher class called "inotify". Interestingly, this class was added to Linux in 2005, the same year the iPod was released, but there appears to be no connection. The "i" in "inotify" stands for "inode". Dennis Ritchie explains:
     
    In truth, I don't know either. It was just a term that we started to use. "Index" is my best guess, because of the slightly unusual file system structure that stored the access information of files as a flat array on the disk, with all the hierarchical directory information living aside from this. Thus the i-number is an index in this array, the i-node is the selected element of the array. (The "i-" notation was used in the 1st edition manual; its hyphen was gradually dropped.)
     
    The inotify system is pretty straightforward to implement, with a procedural C interface. One thing that tripped me up was an odd layout of the inotify_event structure. It actually has a char pointer built into the structure, so technically the structure does not have a determined length. I don't believe I have ever encountered this design before, but I also am usually dealing with std::string classes.
     
    One drawback of inotify is that it isn't recursive. While searching for information on the design, I came across this post by Robert Love, one of the two guys who wrote it (the other being John McCutchan). I disagree with his rational for omitting recursion; just because the performance is not as optimal as he would like does not mean the end user's tastes and preferences will change. I can't imagine a scenario when you wouldn't want the system to work recursively, or at least have the option to. In any case, implementing a recursive watch system was fairly easy. The entire file watch system from zero to finished only took about half a day. So we can mark this as one of the features where I overestimated the time and complexity of implementation.
     
    File creation, deletion, and modify events are now firing reliably so I am going to plug this code into the editor and start testing it out. Because the editor already works reliably on other Windows and OSX, I don't anticipate any problems. I do not have a firm release date yet, but as you can surmise, we are nearing completion of Leadwerks for Linux.
  2. Josh
    An update has been posted with the following fixes:
    http://www.leadwerks.com/werkspace/topic/7847-undo-does-not-refresh-gizmos/
    http://www.leadwerks.com/werkspace/topic/7842-bsp-mesh-export/
  3. Josh
    Things have gone so remarkably smoothly so far in the process of building Leadwerks Linux, that it makes sense we would encounter some issues sooner or later. In this update I will talk about some of the challenges recently encountered.
    GDB
    I was able to get GDB to debug an application built with the Leadwerks static library, in this case our editor. It took me a while to realize you have to hit "continue" once or twice when the application starts, because GDB pauses the program when it connects. This is a bizarre design choice that lead to lost hours of productivity. GDB itself is not a complete debugger; it shows variables only in the top-most function in the call stack, and does not allow you to examine other functions without manually adding "watches" for specific variables. When you don't know exactly what you're looking for, this is an onerous task. Limitations like this may be the reason Valve is working on a debugger for LLVM. I will be sure to ask about this when I attend Steam Dev Days in January, although I do not expect it to be ready soon enough for us to use. So the limitations of GDB are annoying, but I can deal with it. It's great to have the editor running and debuggable on Linux!GTK
    I have been able to get the Leadwerks editor sort of kind of working in just a couple of days, which is fantastic. It looks great, although some Windows-themed icons need to be replaced, and some of the widget sizes are a little off. Functionality is sort of hit and miss at this point; for some reason menu and viewport events aren't registering, and there is lots of broken functionality. However, all the problems have to do with the UI rather than the underlying application. A lot of it is simply because I have a preprocessor definition for Windows, a different one for Mac, and nothing declared yet for Linux. In most cases, either the Mac or Windows default is appropriate. For example, our application menu switches depending on which window is active, whereas on Windows each window just has its own menu. This is mostly a matter of "test and discover" rather than writing new code and I will continue working to make it 100% functional.
    Revenge of the Drivers
    I wanted to switch my main dev machine back to an Nvidia card to do some testing. (I started with an Nvidia card, installed proprietary drivers, and switched to an ATI card with no issues.) Unfortunately, the reverse does not seem possible. I uninstalled the ATI proprietary driver, got some message about "jockey". I swapped in the Nvidia card, and I can only get a black screen with an unresponsive cursor. I put the ATI card back in, and it's using the open-source default driver, and the "Additional Drivers" dialog doesn't detect any available drivers. I ran some other stuff in the terminal I found online, but nothing worked. Typically I have found once I get to the point of entering random terminal commands I find from Google, it's over anyways, and the only thing to do is reinstall the OS. 
    The lesson here is that you really can't swap out GPUs once you install your drivers. (I'm sure there's a way to by someone who is a driver expert, but it's beyond me and the average smart person.) As things stand now, Linux is great for pre-configured hardware (Steam Machines, anyone?), but the driver uninstallation process should be cleaned up in order to meet the needs of PC gamers. I will likely end up running three installations of Ubuntu side by side, one for each graphics vendor.
     
    While we're talking about PC gamers coming to Linux, there is one serious problem that I think is going to hurt a lot of people. To put it simply, installing a dual-boot system is not a solved problem. I recently had one user who wanted to try out Ubuntu, so he made a dual-boot install and it made his Windows driver unbootable. My approach has been to remove all other drivers, install Linux on its own physical hard driver, then replace the other drive and use BIOS to switch back and forth between boot drives. I also considered a physical switch mounted in one of the 5.25" bays, which is kind of cool but I worry about the implications of switching power to different components, and whether they are properly grounded. With this approach, there is absolutely zero opportunity for operating systems to interfere with one another, and I can easily reinstall an OS when needed.

    Challenges Met
    At this stage of development, I feel like we've knocked out all the risks and challenges I identified at the beginning of this campaign. Let's look back at what I said about Linux graphics drivers: It turns out these worries were unwarranted, as the drivers I have tested work flawlessly on Linux. (I'm presently talking to the Mesa developers about their upcoming drivers for Intel HD graphics.) 
    Although there are lots of little issues with our GTK UI at this stage, it's debuggable and basically working. So I'm confident the fundamental things we need to complete this are there.
     
    In conclusion, we've been through the difficult parts of porting a complex application to Linux. Although some annoyances and limitations have been discovered, overall I have found Linux to be a completely viable platform for application development.
  4. Josh
    The OpenGL 4 renderer for Leadwerks 3.1 is well underway. I began implementing deferred lighting in earnest last Friday. Previous work included setting up MSAA on deferred buffers, as well as implementation of the Leadwerks Buffer class, which functions as a thin wrapper around OpenGL FBOs (frame buffer objects). The engine already tracks relationships between objects and lights, and this system was able to be used to provide a list of shadow-casting objects for each point and spot light.
     
    Because I've been working with deferred rendering since 2008, I've had time to study the bottlenecks and invented my own optimizations to improve performance with this type of renderer. Leadwerks uses special proprietary techniques to make shadow map rendering extremely fast.
     
    I began with the simplest light type, a spot light. These use a perspective projection onto a single shadowmap. This took about two days to implement.

     
    Point lights work by projecting six images onto a cubemap shadowmap. This was a little trickier but I got it done after another two days:

     
    The hardest to implement was directional light shadows. We began using cascaded shadowmaps back in 2008, and the industry has since concluded they are in fact the best choice for performance and quality. It took a few extra days to get this one working, but now it's done:

     
    This video is a very nice illustration of the technique:


     
    And here is my implementation in action. With just a little more adjustment, it will be perfect:


     
    The Leadwerks 3.1 deferred renderer has a number of advantages over the Leadwerks 2 renderer:
    Deferred renderer can now use 32x hardware MSAA instead of "fake" antialias techniques.
    Shadow edge filtering is much softer, less "grainy".
    Cubemap shadow maps are used to render point lights in a single pass.
    Higher default resolutions and settings to take advantage of modern hardware.

     
    These factors combine to provide an extremely clean and beautiful rendered image. When I'm done, I think the Leadwerks 3.1 renderer will look more like high-quality cg than what we think of as real-time renders.
  5. Josh
    All stickers have been shipped, and they look absolutely fantastic:

     
    I've never been a "sticker on my laptop" kind of guy, but I am putting one of these on mine as soon as I get home.
     
    Physical items are a little different from getting software to customers. With software, there is at most a delay of a couple hours between the time I have it ready to go, and the customer is using it. I did not anticipate much of a turnover time for the shirts, and I still don't have all the ones I need. However, I am getting the last batch Monday and will ship them out the same day, or at least get them packaged, labelled, and ready to ship for the next day.

    Leadwerks in the Wild
    It's time to celebrate victory with your fellow backers and Linux gamers. Let's see your creative use of Leadwerks schwag! Post a photo on Google+ of your sticker or T-Shirt with the hashtag #LeadwerksInTheWild.
  6. Josh
    A bug fix patch has been uploaded. Run the Leadwerks updater to download the new files. You may need to update projects (see File > Project Manager) and recompiled.
     
    Recent bug fixes can be viewed here:
    http://www.leadwerks.com/werkspace/forum/80-bug-reports/
     
    Additionally, the following improvements were made:
    Physics interpolation will be much smoother now.
    Character controller was adjusted, works great on terrain.
    A bug in the PhysicsSetRotation() command was fixed, though it was not reported.
    Terrain will appear much nicer since normal mapping is working properly now.

  7. Josh
    Compatibility testing for the new terrain system ended up taking an entire week. Most of the problems revolved around OpenGL ES and some iOS driver bugs. Once I got it running on iOS, Android was able to run it with only one small change. The quality settings in this video are lowered for mobile, but the new Google Nexus 7 can actually handle quite a lot, at an impressive 1920x1200 resolution! With a price tag of only $200, this is a great choice for an Android tablet.
     


  8. Josh
    I've added new rewards including international shipping for our T-Shirt and sticker, as well as an indie team and professional site license. A lot of people have been asking for international shipping for the T-shirt and sticker rewards, but I wanted to make sure I knew what the shipping would cost first. It's a good thing I checked because it costs $16.75 to ship. The good news is its a flat rate for any country, so I can rely on that cost when I price things. To sweeten the deal, I am including the Leadwerks sticker in all international orders.
  9. Josh
    I was sorry to hear the news of Stonetrip's liquidation earlier this month. Shiva3D pioneered multi-platform publishing, and I enjoyed killing zombies in "The Hunt". I know that many of you are wondering what to do next. So, let me just get it out on the table that Leadwerks might be an option for your team.
     
    We just released Leadwerks 3, our first cross-platform product for mobile. Leadwerks 3 is completely redesigned to accelerate developer productivity with new advances in tools and workflow. These include native code and Lua support, a new rapid art pipeline, automatic asset reloading, built-in level design tools, plus many others.
     
    I'd like to extend an invitation to any former Shiva users looking for a new home. We're offering a 30% discount on the Leadwerks 3 add-ons for iOS and Android this month to Shiva developers. Enter the coupon code "SHIVA3D" at checkout before June 1, then just email us your invoice from your purchase of Shiva3D, and we'll process your order.
     
    Leadwerks doesn't support all the platforms Shiva did, but we provide "write-once, publish everywhere" deployment to the most important ones: iOS, Android, Windows, and Mac. Shiva developers will feel right at home with our Lua integration, complete with debugger, code stepping, and a built-in script editor. We've even taken Lua a step further, with a built-in flowgraph editor for visually connecting scripted objects. And when you're ready, you also have the option to write games in pure native code with C++, for maximum performance.
     
    Leadwerks 3 is new, but it's built on the lessons learned from our history of delivering high-end graphics on PC since 2006 We provide lots of advanced features, but are able to maintain a competitive price. I welcome you to join other "Werkers" as we move forward. This is going to be a very exciting year for the game industry, and we have some big advances coming down the pipeline.
     
    I realize that it must be a shock to see the predicament that Shiva is going through right now, but for you and your team, it doesn’t have to be the end. I welcome you to join our community and trust that the steps taken above will underscore our commitment to helping out the best we can.
     
     
    Regards,
     
    Josh
    CEO
    Leadwerks Software
  10. Josh
    Leadwerks.com now features a video gallery where our members can post movies of their games made with Leadwerks Engine. Instead of slowly uploading a huge video file, you can simply enter a YouTube video ID to submit movies. Check out some of the cool videos like Legos falling over to a techno soundtrack, fly through floating islands in Aerora, and of course there's Dave Lee's excellent Chernobyl Exclusion Zone.
     
    We've also created a random rotating banner image in our website header. Leadwerks developers can now submit their own Leadwerks.com banners and have them appear on our site.
    -Banner images must be 980x128 pixels in size, in JPG format, with 10% compression (high quality).
    -Your profile will be linked to from the small box in the upper right corner of the banner.
    -The title you submit will appear in the URL popup title.
    -Banners will appear in the rotation after they are approved by the staff.
    -If we have used one of your gallery images, feel free to resubmit it so you can get it linked to your account, and get full credit.
     
    We hope these new community features give our users even more ways to interact and have fun making games.
  11. Josh
    The Rocks and Stones Model Pack by Pure3D is now available here:
    http://leadwerks.com/werkspace/index.php?/page/products/_/assets/rocks-and-stones-pack-r1
     
    You can also still get the Industrial Cargo Model Pack for the low introductory price of just $9.95 until Monday, September 6, before the price goes up:
    http://leadwerks.com/werkspace/index.php?/page/products/_/assets/industrial-cargo-model-pack-r8
  12. Josh
    Leadwerks Engine 2.32 is now available.
     
    2.32
    -"Render" Lua object function renamed to "Draw".
    -Added Draw entity callback.
    -Entity draw callback and Lua "Draw" object function will only be called at most once per frame. Perform animation in this function.
    -Entity LOD distance parameters changed for better performance.
    -LoadAnimation now works without exact hierarchy matches, so LOD meshes can all use the full-res animation.
    -Implemented entity octree with hierarchical culling and picking.
    -Rewrote vegetation rendering routine.
    -Added vegetation collision.
    -Added optional terrain color map.
    -Fixed some problems that prevented custom buffers from working.
    -Fixed render elements bug.
    -Fixed camera culling bug.
    -Fixed recursive AABB update bug.
    -Fixed surface save bug.
    -Adjusted bloom and SSAO shaders.
    -Eliminated unnecessary pick filter calls.
  13. Josh
    Leadwerks Engine SDK 2.31 is now available. A new SDK installer in the download area allows you to download different versions of the SDK. You must have an activated Leadwerks account to download the new SDK installer.
     
    New features include lighting optimizations for point and spot lights. You can read about this feature in detail here. Another new feature is character controller crouching behavior. Note that the origin of character controllers has been moved to the very bottom of the controller, instead of the vertical center. In addition, particle emitters will now store the particle velocity in the first texture coordinate array of the surface. This allows the implementation of directional particles, for elongated sparks or other non-circular particles.
     
    Shadow updating can be a bottleneck in rendering. To make matters worse, point lights require a total of six passes when its shadow is refreshed. We solved this problem by only redrawing shadows of objects that moved. The shadow is then combined with the rest of the cached shadow buffer, to make the final shadow map. The net result is fully dynamic point light shadows using a proper six-sided shadow map, with less rendering cost and better quality than dual parabolic shadow maps.
     




  14. Josh
    Finally, the evaluation kit for Leadwerks Engine 2.3 is released. Get it here. The evaluation kit allows saving and script editing for a period of 30 days. C/C++ programming is not possible with the evaluation kit. An NVidia GEForce 7000 or ATI Radeon 2000 series graphics card is required. An NVidia GEForce 8800 or ATI Radeon 3870 graphics card is recommended.
  15. Josh
    Leadwerks Engine 2.3 has been released. This major update includes a new editor, Lua script integration, forest rendering, roads, and more.
     
    Lua Script Integration: Write object scripts and write your game in any programming language, or you can write your entire game in Lua.
     
    New Editor: Leadwerks Editor is our new tool for creating enormous terrains, placing objects, and creating worlds. You can even edit scripts and see the results instantly.
     
    Forest Rendering: An advanced new rendering algorithm makes it possible to render hundreds of thousands of trees and plants, at playable framerates. Make dense forests that stretch for miles.
    Roads: Build spline-based roads and paths in the editor. Roads can branch, stretch, and fade out. You can even go for a drive on your highways and byways in the editor.
     
    Terrain Holes: Remove patches of terrain and go underground with caves and bunkers. This feature brings a new subterranean dimension to your games.
     
    High Dynamic Range (HDR): Brights are brighter, and darkness is darker. High dynamic range allows a greater range of color to be displayed, with automatic iris adjustment to correct for the ambient lighting environment.
     
    Animation Improvements: Characters can have up to 256 bones, with fast hardware skinning performed on the graphics card.
     
    Rendering Framework: It's easy to toggle advanced effects on and off, in any combination, with commands like SetBloom() and SetHDR().
     
    On Lua
    Like many programmers, I used to consider scripting languages to be a "toy": They are nice and easy to use, but ultimately I thought it was just programming for people who don't want to install Visual Studio. I started playing with Lua back in June of 2009, and the potential for this wonderful language quickly became apparent. Our integration of Lua allows script to be written on both a global and per-object basis; You can write your entire program in Lua, like you would with C++ or another language, or you can write a script specifically for one object class, with different predefined functions to be called during the program. There are functions that can be called when an object hits something, when it is created, or once every frame to update the object. Object scripts can be used together with C++ or another programming language. This means that anyone who uses Leadwerks Engine, with any language, can download a scripted object, drop it into their program, and have the same behavior working in their own game. The implications of this are immense.
     
    Suddenly we found that instead of being a collection of a few hundred individual programmers, the community suddenly became a collaborative, collective group. If one developer writes a script for a scary monster and posts it online, another user can download it, drop it into the editor, and see the results, with no code changes. You can even edit the script in Leadwerks Editor, save it, and instantly see the results. For the first time, developers could easily work together and share their creations, and still use whatever programming language they preferred. Lua has changed the whole feel of the community to a more social and cooperative group.
     




    Keeping it Real-time
    Our design philosophy for Leadwerks Engine is that everything should run in real-time, and thus be editable in real-time. Lighting and physics are already editable in real-time with instant feedback, but it took some time before I realized we can extend this approach to something else: programming. The new editor has an integrated script editor. To edit an object's script, you simply double-click on its node in the scene tree. You can view all the code that makes the object to whatever it is doing. You can also make changes to the script, save it, and the object's behavior is instantly updated! The lack of a compiling phase allows you to fine-tune behavior to get it just the way you want. Plus, it's a just lot of fun to use. For an in-depth description of our Lua implementation, see here:
    http://www.leadwerks.com/files/Tutorials/Lua/Getting_Started_With_Lua.pdf
     
    The Road to Perfection
    Roads look nice, but the reason I really like them is they allow new dimensions of gameplay. When I started off writing the road editor, I had a few requirements. I wanted the roads to be written entirely with Lua object scripts. This was a challenge, and forced me to add several features to the script integration to make it work. I also wanted roads that aligned perfectly to the terrain, like they do in Crysis. First I wrote the mesh generation routine that makes a spline-based road. This is fairly simple, but it is only part of the problem. The biggest challenge was slicing the road up by the terrain grid, so that every vertex on the road lined up along the terrain, and the whole road lay perfectly snug. UV mapping the tessellated road was another major challenge, but a clever solution was found after many attempts. The resulting roads look great and conform perfectly to the terrain. And they're fun to go driving on!
     
    Seeing the Forest for the Trees
    The forest rendering algorithm is my favorite new rendering feature. The bulk of this was written in the spring of last year, but there were a few details I didn't complete until recently. I spent hours playing with the Crysis editor and trying to figure out how they heck they were able to render so much foliage. I read article after article, but no one seemed to have a good approach. Most of the forum discussions on graphics development sites seemed to amount to just saying "use billboards". The problem is that rendering 100,000 billboards is still a major challenge. The solution was found by analyzing what format data the GPU will render most efficiently, and then working backwards to find a way to get the vegetation in that format. The solution is elegant, and seamless to the end user. There's no baking or pre-processing. You paint as many trees and plants on the terrain as you want, and it just works. I still have some more ideas to implement, like destructable trees and even better efficiency, but I am quite happy with how it turned out.
  16. Josh
    This is my opinion of Windows 7. When I tried Vista, I immediately disliked it, but used it for eight months. At the end of that period I still disliked it for all the same reasons.
     

     
    Source
  17. Josh
    ...and head over to www.dexsoft-games.com to buy the Northern vegetation pack. I don't care if you don't even need it, just give them money so they will continue making incredible media. This is the artistic savior independent developers have been waiting for.
     

    http://forum.leadwerks.com/viewtopic.php?f=32&t=5509
     
    Source
  18. Josh
    I am working out the advanced logic and interaction by applying it to different problems. Messaging the way the original Quake engine was set up is pretty straightforward. Half-Life 2's input-output system is interesting, but requires an additional mechanism beyond the existing keyvalues system. Lua allows some really powerful stuff. You could enter a string in the property editor, and the script itself could execute this string! But if it's confusing for me, it's going to be really confusing for an artist.
     
    It's easy to make a button open a door:
     
    -Set the door to be the target of the button.
    -When the button is pressed send a message "Activate" to the door.
    -The door receives this message and interprets it to mean that it should open.
     
    How would you do the following in your favorite game engine, without scripting?:
     
    Buttons 1, 2, and 3 can be switched on and off. Only when buttons 1, 2, and 3 are all turned on, a door opens.
     
    Your ideas?
     
    Source
  19. Josh
    I finally found a good reason to upgrade the renderer to OpenGL3. This will allows MSAA with deferred lighting. It might possibly also yield some performance gains, but that is speculation. This will occur some time in 2010.
     
    Source
  20. Josh

    Articles
    Now that I have the downsampled reflection data working, I can start casting rays. The cone step tracing is not a 100% perfect representation of physical light, but it gives a very favorable balance of quality and performance. Somehow I came up with a few formulas that eliminate light leaks and other artifacts.

    Quite honestly I did not think the results would be this good. Indoor / outdoor scenes with thin walls are very difficult to prevent light leaks in, but somehow it's working very nicely, even with a blurry reflection. I am seeing some banding, but I'm sure that can be ironed out.

    It's good to test reflections first because global illumination is just a bunch of reflection raycasts.

    Adding in the GI component will be the next step.
  21. Josh
    Working to improve the implementation of the code known as framework. It needs to be able to talk to Lua, with all programming languages. I can't really go on documenting the script until this is finalized, so the time to do it is now.
×
×
  • Create New...