Josh

Of course you can do that, a variety of ways. The easiest would be fixed joints. The "proper" way would be to use zero for the default mass, and then change the mass of an object when shot. You'd want to add a setting for some pieces to be "base" segments that cause the entire structure to collapse when that piece is broken. With all these types of systems, including PhysX, it takes so much work to set up the art assets that people usually don't bother. You can construct a shack out of individual pieces like that, but it's a lot of effort for something that isn't really worth it. I'm much more interested in real dynamic breakage, but no one has done it yet. I think our CSG solids can be used for this because they can be split and carved in real-time. We'll see how it goes.

Models will be effortless. It will just be done for you. Code will be mostly the same, but don't expect your code to compile without some changes.

The name of the third version of our engine is going to be "Leadwerks3D". Why? "Engine" is a term associated strongly with older FPS engines, and typically describes a system with a more primitive workflow and a programming-centric design. I think the term has negative connotations. Leadwerks Engine was designed to be a programming library. Our new software is a visual game design tool. I want to make that clear to the public. "Leadwerks Engine" is two long words. Trying to promote a product with a two-word name is harder. A lot of people don't know what an "engine" even means, and will think we make cars or something. Having 3D in the name gives people at least an idea of what we do. The company name is being legally changed to "Leadwerks Software" (from Leadwerks Corporation). We can't just call the product plain "Leadwerks", because it is not clear whether the company or the product is being referred to. It also looks funny in the editor titlebar. The "3D" suffix punctuates the name and gives balance to the capital "L" at the beginning. In retrospect, naming the product "Leadwerks Engine" was a good idea, because this whole time we have only had to promote one name. I think a company like Stonetrip (Shiva) has a harder time putting their name out, because they always have to choose which they should promote.

Even LE3 won't have dynamic physics scaling without breaking the simulation, but unless you are making a slow-motion weight gain sim I think it will be okay.

So I talked to the product manager of PhysX today on the phone, and I was telling him about our current vegetation technology, and my desire to go beyond the bounds of 32-bit floating points in the next version. I was told they are currently trying to ramp PhysX 3.0 up to handle tens of thousands of bodies, because in the past it hasn't been able to handle as much. I told him that it's perfectly possible to handle millions of static instances, and they just need to think of vegetation and other static geometry differently than dynamic bodies. We had an interesting conversation, and he's interested in pursuing this, but of course it would be a long time until we actually had some results. At this time, PhysX doesn't come close to being able to handle the number of vegetation instances we are used to using. I have developed the technology, and NVidia is interested in pursuing this in the future, so maybe they will end up licensing our C++ code when I implement it. The actual code is pretty trivial, and the valuable asset I have is the knowledge of how this works together with rendering, and how to optimally manage and store the data. Where does that leave us for the present? I don't know exactly, and I would be reluctant to start with PhysX knowing that it cannot support our vegetation goals. However, I have NVidia's attention now, and if they want to move in this direction, I have the knowledge to help them do that. I am posting this in the private forum since this is a little more sensitive than I would want to post in a blog.

Crytek has their own physics system, so who knows. For individual entities, scaling will be done by internally recreating different physics shapes to the specified scale.

It is. I think Lua may be faster in L3D because the binding with C++ will probably be a lot more efficient than what we are doing now. Don't have any numbers to back that up, but it's just my guess.

The capabilities are about the same as the Source engine, so you use lightmaps together with projected shadows. I've done these in the past, so it's easy for me to do.

This is due to the physics system not being able to handle scaled matrices. I found out Bullet and PhysX also both have this limitation. In the future, I will work around this by automatically creating 5-10 pre-scaled physics bodies that are variations of the original and using those...so the vegetation won't be really randomly scaled, it will just have a few pre-set sizes that are randomly chosen. If I use enough presets the outcome will be the same as if they were totally random.

Unwrap3D is not required, and I'm sorry you were given that advice. However, if you want to buy it I would encourage you to either contact Brad Bolthouse, or see if you can work something out through an intermediary.

I meant the second thing, but the "somewhat usable" qualifier raises doubt.

Is it really? I didn't know that.

That's interesting. That's actually a third way of getting the height, normally used when rendering the composite views in the editor. Should work fine.

Oh, okay that is easy to do.

Leadwerks 3 is compiling for Android. There's presently a problem with the file system that is preventing any 3D rendering, but we'll get that worked out shortly. We're targeting Android 2.2. In order to compile C++ for Android on Windows, we had to install the following: -Java SDK -Eclipse IDE -Android SDK -Android NDK -CygWin -GDB We also learned that OpenGL ES 2.0 does not run in the Android simulator. For the time being, we have to run the engine on an actual Android device. That was rather surprising, but I think Google will have this functionality added fairly soon. I also learned there is an x86 version of Android, but no one uses it. Debugging C++ on Android is done with GDB, a command-line debugger. You definitely don't want to use this to do any heavy work. In this case, the cross-platform nature of coding with Leadwerks comes in handy, and you can debug on Windows or OSX and then just compile your finished code for Android, without much testing. The plan is to allow one-step publishing for Android when you use Lua. You write your program in script, test it on PC or Mac, then you can export a package for Android that's ready to install on your phone, without even having to install the Android SDK. You can also use C++, and it takes more work, but it's not too hard and we'll have instructions on how to get set up. Behold the mighty blue screen running on an HTC Evo, and tremble!:

I am not clear on what you did. What does your shader look like now? Ati says they fixed it, so if it isn't in their latest drivers, it should be out soon, and either method will work properly.

No, that won't have any effect. If you look at terrain.frag around line 97 you should see this: //No idea why this changes behavior: height = texcoord0.y;//vertexposition.y; That's what fixed the bug you are seeing.

I don't think you're using the version 2.5 shaders then, because I have the same card and it was fixed.

This is a known issue. If you upgrade your graphics driver it should fix the problem: http://support.amd.com/us/gpudownload/Pages/index.aspx

I prefer the FBX to GMF converter because it retains the model hierarchy.

Well said. This way programmers and designers can work together. The programmer writes logical scripts and the designer makes them do interesting things in a particular map.

Once again, I like to attack the things I haven't done in the past first. I know how to make a CSG editor. What I haven't done in the past is a visual editor for gameplay and logic. In the shot below, you can see the properties editor, with the "Scripts" tab selected. I moved the name and angle editor outside the tabbed panel, with the idea that these are so important they belong in the main window, but the real reason was to break up the boredom of a full-window tabbed panel. Under the scripts tab, there's a list on the left where you can drag scripts onto to assign a script to an entity. You can also drag the scripts around within the list to rearrange the order they are executed in. When a script item is selected in the list, its properties appear on the right in the bordered area. This has a border because if the number of controls exceeds the available height, a scrollbar will appear to allow you to scroll down and access all of them. Now I personally am not a fan of this, because I think it makes things more complicated, but the user feedback overwhelmingly suggests users want multiple scripts attached to a single object. I think this is so users can combine behaviors and adjust them through trial and error. This doesn't occur to me because for me it's no big deal to just open a single script and program it to do exactly what I want. However, this isn't as trivial for everyone, and for every programmer out there, there are probably 99 non-programmers. This is a good example of why we need to understand how everyone uses the software. The resolution we have satisfies the need for trial and error design, without restricting what you can do with it. You can drag an entity script or an entity into the flow graph editor to make its attached scripts appear. Each script has inputs and outputs, and you can connect one to another. I think I am going to put both script output functions and exposed attributes on the right, with a different icon for the two. Output functions can be linked to inputs on other scripts, while attributes can be linked along the curved line connecting the two, as function arguments. This is a cool idea I think will make it unique, and it only works due to the flexibility of Lua; you can skip function arguments, and the function call will be executed anyways without any problem. I'll have some special flowgraph nodes that only appear in the flowgraph editor for logic, timing, etc. It is not my goal to make a visual script editor. I don't think the challenge of programming is because people don't understand text code. The problem is thinking in an extremely logical and meticulous manner. A visual script doesn't get rid of this requirement, it just uses a different method to display the logic, one that will baffle both programmers and non-programmers alike. Think about (most) artists trying to design "Pong" with a flowgraph; I don't think it would work. Trying to code behavior through a visual representation of script is not something I want happening in the flowgraph, except on a fairly lightweight level. People are welcome to try it, but if we expected that everyone would be able to write complex programs with it, I think it would fail and we'd be back to the drawing board. My goal for the flowgraph system is to allow a designer to connect behaviors to create interesting sequences of events in a game. Individual behavior of objects will still be coded in script, in a manner designed to be as general-purpose as possible. A button opens a door, a cat chases a mouse, a switch turns an elevator on, then opens a trap door, and turns on a machine ten seconds later. Leadwerks Engine 2 had individual entity scripts, but without a standard system for interactions, there's little you can code in a self-contained script, other than some looping behavior. Setting names and targets is functional but rather abstract and cumbersome when working with complex interactions. With the Leadwerks flowgraph editor, we're all working together on the same game...yet the programmer still has complete control and freedom.

All your requests are already written or in the design spec except terrain brush editing. Are you talking about the displacement brush stuff from the Half-Life 2 editor?

Yes, that idea was ripped shamelessly from 3ds max.

I've considered that, but the 2D views are actually rendered straight to the back buffer. Also, not all supported hardware the engine runs on even support render-to-texture! Now you get an idea of the constraints I deal with.