[Stretch goals revealed for Leadwerks for Linux Kickstarter campaign]

It was originally going to be a stretch goal for Linux, but on Linux it can be difficult to run 32-bit libraries on a 64-bit OS.

[A first look at the terrain editor]

I'm going to focus on the essentials first, but this toolset will have a much longer life and allow more features than we could do before.

[A first look at the terrain editor]

I updated the screenshot. It's not necessary to totally obsess over the layout like I did with the core tools, we just need to make sure everything is easily accessible and easy enough to use.

[Virtual Texture Terrain]

I'm guessing the texture stages are generated on the GPU? So this doesn't give you the constant VRAM usage that mega-textures traditionally do, but does give you unlimited texture layers and decals w/ only a small VRAM overhead?

Yes, it's all created on the GPU. The VRAM usage is constant, and probably will weigh in at just 24 mb.

[Virtual Texture Terrain]

I will have to experiment some more and see what it can do. This is by far the most flexible terrain system I've ever worked with.

[Virtual Texture Terrain]

Back to textures, what if I have surface imagery of Oahu Hawaii (say it was a car racing game like Test Drive Unlimited) and want texture stages 4-5 to be a raw sat image. For low altitude rendering, stages 0-3 as m-textures. What different approaches would facilitate handling this kind of game scenario? We might want to graduate between sat images with pre-computed splats based on altitude.

The base map / blend method I used in LE2 worked well for large-scale satellite images. The splatted images are blended together to create one large baked texture for long-range rendering.

 

Tessellation and displacement are hard to marry with collisions. I know one unreleased engine does this, it doesn't seem trivial.

I don't think this is a problem because tessellated geometry is small compared to the physics geometry.

 

Would the mega-textures be computed at run-time, or during map load time or a longer tool export operation? Your description implies you're having much success with small drawing operations, but how far will it scale I wonder?

The whole megatexture never exists at once, but parts of it are drawn on-the-fly. Since it's working now, it will work independent from terrain size. Distant terrain is slightly blurred, but in Leadwerks 2 we actually went to great lengths to get this effect, with the special "blur mipmaps" setting. The reason is that blurred terrain textures in the distance actually look better because it eliminates obvious tiling.

[Greenlight Status]

Yes, you get a much higher success rate that way:

http://steamcommunity.com/sharedfiles/filedetails/?id=145716110

[Greenlight Status]

It's in the site header at the top. We'll get there, it just won;t be a four-week sprint like I originally thought.

[Leadwerks on OUYA]

The marginal cost of OUYA support is pretty low, and if the Kickstarter stretch goal is reached it pays for itself.

[30% goal reached in less than 48 hours]

That's awesome. How is the Greenlight campaign going?

Our goal is to be in the top ten. We're 16 days into the Greenlight campaign, and well above what the #10 item had at the same time.

[Leadwerks for Linux]

I think it's still great for us to have mobile support, it just didn't provide the initial boost in users we were looking for.

[Leadwerks for Linux]

This gives us a way to provide a lot of those graphical features users are asking for. A high-end renderer on Linux means a high-end renderer on Windows and Mac.

[Leadwerks for Linux]

I'm stuck in two minds. I want to support the growth of LE as I see huge potential in it, but by supporting this it's putting a huge obstacle between what I want and when i'm likely to get it.

 

I do see Linux as a big part of LE's future, but im not sure why that is coming before other things.

 

Wouldn't it be simpler to port a finished product than to port an unfinished product, then port each individual module your create after.

What is "finished"? To some people, that means more CSG features. To some people that means high-end graphics. To some people, that means more mobile features.

 

I've got to test these markets and find out what people respond to, so that we have an overall direction. Small features and fixes are important, but it's all for nothing if we don't have an overall plan.

 

So far, I'm seeing a way stronger response from Linux users than we saw from mobile. Which is the opposite of what I would have thought.

[Leadwerks Seeks to put Game Development on Linux]

If you wish to go that route, you can get Leadwerks 3.1 through the KS campaign. I won't comment on upgrade pricing at this time because there's too many unknown factors.

 

From my point of view, I don't really care where the campaign goal amount comes from, as long as it is hit. If it succeeds, that tells me there's probably a good market for a Linux product with high-end graphics. If it fails, that tells me Linux users probably wouldn't have been interested anyways.

 

I think it's more up to the Linux community than the existing Leadwerks users. This tells me whether Linux is a growth market or whether we should ignore it. It's not perfect, but this is so much more efficient than building first and then finding out whether there is demand.

[Leadwerks for Linux]

This is too awesome! I am so happy to see this

About 55% of Leadwerks users were interested in Linux support, but it will really be up to the general Linux community whether we do this or not.

 

The wonderful thing about Kickstarter is I don't have to actually build the product to find out whether people will buy it or not. We can get a pretty good idea of the demand by presenting it to the Linux community and seeing their response.

[Leadwerks for Linux]

Does this meaning kickstarter people will get directly 3.1 and the "old" community has to buy it ?

 

2) If seen on kickstarter site, the BACKER Pledge (100$) gives full access to lua and c++ leadwerks 3d (without windows/mac) and PRO BACKER (200$) gives full access to all 3 platforms.

 

I personally don't need mac, so do we get 100$ refund or linux as third (second) platform ?

If you don't find it valuable, I'm not going to make it.

[Beginning work on Leadwerks 3.1]

In terms of graphics, Leadwerks 2 had a deferred renderer. Leadwerks 3 does not yet have as many graphical bells and whistles, because we have been focusing on the editor and art pipeline, which are much stronger than Leadwerks 3.

 

Our plan, as always, is to release paid upgrades approximately every 12 months. So people who bought 3.0 can upgrade to 3.1 at a discounted rate.

[Leadwerks 3 Update Available]

There are three major aspects of the script system in Leadwerks 3. First, scripts are attached to objects from a file, rather than having to be named the same as a loaded model. Second, we tried attaching multiple scripts per objects. Third, the flowgraph allows the user to create visual connections between the scripts.

 

All of these were new ideas, and they were all theoretical designs. We didn't really know how practical they would be until we started using them in depth. Fortunately, two out of those three ideas turned out to be good ones.

 

Once we got into more advanced scripted gameplay, we found that a component approach turned out to be very tedious from a programming perspective. It creates an extra layer of abstraction that's confusing for both beginners and advanced users.

 

We believe we should expand on the strength of the flowgraph editor in the future. One way we can do this is by adding purely logical entities...that is, an entity that only exists in the flowgraph, and gets used for connecting logic.

[Teaching Leadwerks]

DevMaster.net has some nice shader tutorials, too.

[Teaching Leadwerks]

We will separate the lessons into categories as they evolve. Right now, there would only be two categories, so it's not worth doing yet. (The features I just added allow programming lessons to be both C++ and Lua.)

[Leadwerks 3 Brings Native Code to Mobile Games]

You may be right about the indie market. For the professional market, native code is a big deal. We're still learning what our user base looks like as we gain more customers.

[Leadwerks 3 Rendering Enhancements]

Ha, that's because they must not be using Leadwerks. I always thought that was rather lazy programming.

[Leadwerks 3 Rendering Enhancements]

Projected shadows can be enabled or disabled by calling Entity::SetShadowMode. I might consider a global setting as well, that would toggle these type of shadows on and off completely.

 

You can explicitly choose a renderer, but if you don't do anything the best one will be chosen automatically. It is possible to change the renderer in-game, but it requires a complete reload of all assets, since it switches between entirely different graphics APIs. This is a level of scalability I haven't actually seen any AAA games ever attempt.

[Lighting enhancements and fixes in Leadwerks 3]

If you just run the editor once, it will automatically convert that png file.

[Lighting enhancements and fixes in Leadwerks 3]

What we might be able to do is add an "Update project" feature that would copy over only the files that have changed since you created your project.