български (Bulgarsk) čeština (Tsjekkisk) Dansk (Dansk) Nederlands (Nederlandsk) English (Engelsk) Suomi (Finsk) Français (Fransk) Deutsch (Tysk) Ελληνικά (Gresk) Magyar (Ungarsk) Italiano (Italiensk) 日本語 (Japansk) 한국어 (Koreansk) Polski (Polsk) Português (Portugisisk) Português-Brasil (Brasiliansk-portugisisk) Română (Rumensk) Русский (Russisk) 简体中文 (Forenklet kinesisk) Español (Spansk) Svenska (Svensk) 繁體中文 (Tradisjonell kinesisk) ไทย (Thailandsk) Türkçe (Tyrkisk) Українська (Ukrainsk) Hjelp oss å oversette Steam
Denne gjenstanden er blitt bannlyst fordi den er i strid med Steams vilkår for bruk. Den er bare synlig for deg. Om du mener at din gjenstand er blitt bannlyst ved en feiltakelse, vennligst kontakt Steams kundestøtte.
Denne gjenstanden er inkompatibel med Greenlight. Vennligst se instruksjonsiden for årsaker til at denne gjenstanden ikke kan fungere innenfor Greenlight.
Gjeldende synlighet: Skjult
Denne gjenstanden vil kun være synlig for deg, administratorer, og alle markert som en skaper.
Gjeldende synlighet: Bare venner
Denne gjenstanden vil kun være synlig for deg, dine venner og administratorer.
31. juli, 2013 - Leadwerks Software
About a year ago, before the release of Leadwerks 3, one of our users posted an image I thought was especially striking. I asked him if he could make a high-res render of it suitable for printing. After that, I saved it on my hard drive, not knowing when I would use it.
After getting the author's permission, I am creating a different kind of "stretch goal", one that aims for engagement rather than dollars.
A Thousand Linux UsersIf we reach one thousand backers, choosing any reward, I will provide all backers, at all levels, with the full-size version of the image above. At a resolution of 6000x2435 pixels, this image can be printed to make a 20" wide picture with a resolution of 300 DPI (typically used for professional printing).
Why?This isn't a very expensive proposal. At the time of this writing, it would take about $370 to meet. What it does is it gives us a quotable statistic we can use to promote Linux gaming. One thousand is a big number. If we can repeat again and again that a thousand Linux users backed a gaming project specifically aimed at Linux (not just tagged on as an afterthought), we can use that metric to convince people that Linux gaming is a rising star. In fact, I am going to the IGDA Summit in a couple of days to rub elbows with the game industry leaders, and would love to have that sound bite.
How?This is up to you and the Linux community. We're seeking engagement with this goal, so outreach with social media is key, on Facebook, Twitter, and Google+. I want to be able to tell people a thousand Linux users backed Leadwerks for Linux, so I can convince developers I know that Linux is a great platform to build games for.
You can view the Kickstarter campaign here.
26. juli, 2013 - Leadwerks Software
I've been seeing glimpses here and there over the last couple of years of a project by one of our users in Iran. He didn't give much detail in the past, but what he did show the community looked stunning. Now, after two years of work, FSR Game Development has finally unveiled the official trailer for Death Statue, and it's spectacular!
Although this was made in the old version of Leadwerks (which isn't surprising, considering how long they've been working on it), this is representative of the quality of games we can bring to Linux with Leadwerks 3.1.
17. juli, 2013 - Leadwerks Software
With two weeks left to spare, I'm pleased to announce our stretch goals for the Leadwerks for Linux Kickstarter campaign:
$26,000 - Android + Ouya for All: We will provide all backers who pledged $100 or more with Android support. We’ll also add support for OUYA, the Android-based open game console. This will let you build games for Android and OUYA, without ever leaving the Linux operating system.
$30,000 - Blender integration: We want to integrate Leadwerks with the free 3D modeling package Blender. We’ll start with a Blender exporter that saves a model and all materials ready-to-use in Leadwerks, and look for other Blender features we can put to work in our engine.
$35,000 - 64-bit Builds: We’ll provide 64-bit builds of the Leadwerks engine library, along with the 32-bit library. (We decided to provide this for Linux by default. The stretch goal is for 64-bit builds on Windows and Mac.)
$45,000 - Visual GUI Editor: We want to build a fully integrated GUI editor right into Leadwerks. This will let you create game menus with buttons, sliders, switches, and more, in a fully skinnable GUI system. GUI elements will even integrate with our flowgraph system, so you can visually attach GUI elements to scripted events and C++ callbacks.
$55,000 - Oculus Rift + Omni in Linux: We want to integrate the great virtual reality headset Oculus Rift with Leadwerks, all running natively in Linux. We’ll even include support for the Omni VR treadmill, so Linux developers can create the full VR experience.
$85,000 - Broaden Your World: We’ll implement full 64-bit floating point math and streaming terrain data to create worlds beyond the limits of 32-bit floating point precision. Want to create detailed worlds ten times bigger than Crysis maps? We can make it happen.
$150,000 - Choose Two Flavors of Linux: Variety is the spice of life, and Linux is baked with plenty of it! We’ll work with the top two distros backers choose to provide full Leadwerks integration and ongoing support for two years.
$200,000 - Plugin-Free 3D Web Games: We’ll work with asm.js to compile Leadwerks in web-ready format so you can distribute 3D web games for supported browsers, with no proprietary plugins required.
11. juli, 2013 - Leadwerks Software
In just three weeks, the Linux community has successfully funded the development of Leadwerks for Linux. This means we're going to bring Leadwerks 3.1 to Linux, with native support for developing Linux games...so Linux games can now be completely free from Windows.
GreenlightIt's been an amazing few weeks. During this time, we also successfully completed our Greenlight campaign to make Leadwerks available on Steam and take advantage of features like the Steam Workshop. You can see from the graph below that our campaign did better than any other software in Steam we had data for. The votes look like they would have gone a lot higher, but Valve approved us early!
MegatexturesI also had a chance to prototype the major feature of Leadwerks 3.1 I was most concerned about. I wanted to implement a new terrain system that would remove the limitations of our old one, and thought that a technique I call "dynamic megatextures" would be a good solution. Basically, this works like id Software's megatexture technology, only the virtual textures are generated on-the-fly rather than being paged from the hard drive. This means the entire terrain can be uniquely textured, but it doesn't require the hard drive space megatextures usually need:
Getting that knocked out of the way makes me confident we can deliver Leadwerks 3.1 for Linux according to our original vision.
Congratulations, Linux community! I'm happy to make Linux a core part of our company's focus moving forward.
8. juli, 2013 - Leadwerks Software
The Leadwerks 2 terrain system was expansive and very fast, which allowed rendering of huge landscapes. However, it had some limitations. Texture splatting was done in real-time in the pixel shader. Because of the limitations of hardware texture units, only four texture units per terrain were supported. This limited the ability of the artist to make terrains with a lot of variation. The landscapes were beautiful, but somewhat monotonous.
With the Leadwerks 3 terrain system, I wanted to retain the advantages of terrain in Leadwerks 2, but overcome some of the limitations. There were three different approaches we could use to increase the number of terrain textures.
- Increase the number of textures used in the shader.
- Allow up to four textures per terrain chunk. These would be determined either programmatically based on which texture layers were in use on that section, or defined by the artist.
- Implement a virtual texture system like id Software used in the game "Rage".
Since Leadwerks 3 runs on mobile devices as well as PC and Mac, we couldn't use any more texture units than we had before, so the first option was out. The second option is how Crysis handles terrain layers. If you start painting layers in the Crysis editor, you will see when "old" layers disappear as you paint new ones on. This struck me as a bad approach because it would either involve the engine "guessing" which layers should have priority, or involve a tedious process of user-defined layers for each terrain chunk.
A virtual texturing approach seemed liked the ideal choice. Basically, this would render near sections of the terrain at a high resolution, and far sections of the terrain at low resolutions, with a shader that chose between them. If done correctly, the result should be the same as using one impossibly huge texture (like 1,048,576 x 1,048,576 pixels) at a much lower memory cost. However, there were some serious challenges to be overcome, so much so that I added a disclaimer in our Kickstarter campaign basically saying "this might not work"..
Previous Workid Software pioneered this technique with the game Rage (a previous implementation was in Quake Wars). However, id's "megatexture" technique had some serious downsides. First, the data size requirements of storing completely unique textures for the entire world were prohibitive. "Rage" takes about 20 gigs of hard drive space, with terrains much smaller than the size I wanted to be able to use. The second problem with id's approach is that both games using this technique have some pretty blurry textures in the foreground, although the unique texturing looks beautiful from a distance.
I decided to overcome the data size problem by dynamically generating the megatexture data, rather than storing in on the hard drive. This involves a pre-rendering step where layers are rendered to the terrain virtual textures, and then the virtual textures are applied to the terrain. Since id's art pipeline was basically just conventional texture splatting combined with "stamps" (decals), I didn't see any reason to permanently store that data. I did not have a simple solution to the blurry texture problem, so I just went ahead and started implementing my idea, with the understanding that the texture resolution issue could kill it.
I had two prior examples to work from. One was a blog from a developer at Frictional Games (Amnesia: The Dark Descent and Penumbra). The other was a presentation describing the technique's use in the game Halo Wars. In both of these games, a fixed camera distance could be relied on, which made the job of adjusting texture resolution much easier. Leadwerks, on the other hand, is a general-purpose game engine for making any kind of game. Would it be possible to write an implementation that would provide acceptable texture resolution for everything from flight sims to first-person shooters? I had no idea if it would work, but I went forward anyway.
ImplementationBecause both Frictional Games and id had split the terrain into "cells" and used a texture for each section, I tried that approach first. Our terrain already gets split up and rendered in identical chunks, but I needed smaller pieces for the near sections. I adjusted the algorithm to render the nearest chunks in smaller pieces. I then allocated a 2048x2048 texture for each inner section, and used a 1024x1024 texture for each outer section:
The memory requirements of this approach can be calculated as follows:
1024 * 1024 * 4 * 12 = 50331648 bytes
2048 * 2048 * 4 * 8 = 134217728
Total = 184549376 bytes = 176 megabytes
176 megs is a lot of texture data. In addition, the texture resolution wasn't even that good at near distances. You can see my attempt with this approach in the image below. The red area is beyond the virtual texture range, and only uses a single low-res baked texture. The draw distance was low, the memory consumption high, and the resolution was too low.
This was a failure, and I thought maybe this technique was just impractical for anything but very controlled cases in certain games. I wasn't ready to give up yet without trying one last approach. Instead of allocating textures for a grid section, I tried creating a radiating series of textures extending away from the camera:
The resulting resolution wasn't great, but the memory consumption was a lot lower, and terrain texturing was now completely decoupled from the terrain geometry. I found by adjusting the distances at which the texture switches, I could get a pretty good resolution in the foreground. I was using only three texture stages, so I increased the number to six and found I could get a good resolution at all distances, using just six 1024x1024 textures. The memory consumption for this was just 24 megabytes, a very reasonable number. Since the texturing is independent from terrain geometry, the user can fine-tune the texture distances to accommodate flight sims, RPGs, or whatever kind of game they are making.
The last step was to add some padding around each virtual texture, so the virtual textures did not have to be complete redrawn each time the camera moves. I used a value of 0.25 the size of the texture range so the various virtual textures only get redrawn once in a while.
Advantages of Virtual TexturesFirst, because the terrain shader only has to perform a few lookups each pixel with almost no math, the new terrain shader runs much faster than the old one. When the bottleneck for most games is the pixel fillrate, this will make Leadwerks 3 games faster. Second, this allows us to use any number of texture layers on a terrain, with virtually no difference in rendering speed. This gives artists the flexibility to paint anything they want on the terrain, without worrying about budgets and constraints. A third advantage is that this allows the addition of "stamps", which are decals rendered directly into the virtual texture. This allows you to add craters, clumps of rocks, and other details directly onto the terrain. The cost of rendering them in is negligible, and the resulting virtual texture runs at the exact same speed, no matter how much detail you pack into it. Below you can see a simple example. The smiley face is baked into the virtual texture, not rendered on top of the terrain: