Josh

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.

The scene browser lets you see every entity and brush in the scene, and also lets you arrange entities in a hierarchy. You can add a light to the scene, position it onto a lamppost, then use the scene browser to parent the light to the lamppost model and save the whole thing as a prefab. There's no "mesh" class in the new engine, and entities inherit a lot of the properties that models in LE2 had, like scripts and physics. Models are just MDL files, and generally just contain model and bone entities. A prefab, on the other hand, can contains models loaded from other files, lights, particle emitters, and anything else you can create in the engine. Whereas in Leadwerks Engine 2 you would use a script to create special entities in code and parent them to a model, in the new engine you can place and parent them visually, then save them as a prefab to be used again and again. Top-level models can be dragged around in the hierarchy, but limbs (children contained within a model file) are a bit more problematic. If we allowed the user to create a character, then parent the character's arm to another model in the scene, then delete the character, leaving the arm...you can see how that could cause a lot of issues. What I'm leaning towards is a rule that it's fine to parent the top-level model to something else, and you can add entities within the model's sub-hierarchy, but changing the parent of a model's limb is not allowed. I hope this doesn't confuse people using it, but it makes sense; if you really need to alter an model file's hierarchy, it should be done in the model editor (similar to the texture and material editors you have seen). You can still set different properties like color, script settings, etc. for limbs of different instances of the same model. The map file will just store data that says "attach these scripts to limb number 7 of this model after you load it". This way models will always be reloaded from their original files, and if you alter your model the whole map will be updated. Actually, the more I think about it, the more this makes sense...this is a map editor, not a modeling program. Not shown here, but I am adding a filter at the bottom so you can type in a name and a list will appear of all objects in the scene that contain that name, so you can type in "tree" and find all relevant objects. Hmmmm, come to think of it, maybe I should also add a drop-down box to search by either object name or the name of the file the object was loaded from. The check marks will toggle visibility recursively, though they don't work yet. I'm writing the grid and object selection rendering into the engine, so they'll be some commands like Entity::SetSelectionState(bool mode). I found this easier than a bunch of rendering callbacks, especially when the engine is designed to run multiple renderers. This might come in handy if you are writing any kind of editor.

I've changed my mind on this, but we're going about it our own unique way and it may not be in the first release. Instead of a rigid "plugin" design that attempts to anticipate every possible use, I think a hook/script system is better. 1. The editor runs all scripts in the "Scripts/Start" folder at startup. 2. Scripts can add a hook. Hooks can be added for an event, or they can be added for a bunch of predetermined points in the program. For example: AddHook(HOOK_MATERIALEDITOR_OPEN,"MyMaterialPluginInit") AddHook(HOOK_EMITEVENT,"MyMaterialPluginHook") AddHook(HOOK_MATERIALEDITOR_SAVE,"MyMaterialPluginSave") You can add a menu action the user can add to the menu to call your plugin: function AIEventHook(event) if event.id==EVENT_MENUACTION if GadgetExtra(event.source)=="OpenAIEditor" aiwindow=CreateWindow("AI Editor",0,0,800,600,mainwindow,WINDOW_CENTER|WINDOW_TITLEBAR) okbutton=CreateButton("OK",20,20,80,30,aiwindow) end end if event.id==EVENT_WINDOWCLOSE if event.source==aiwindow ActivateGadget(mainwindow) HideGadget(aiwindow) end end end] CreateMenuAction("AI Editor","OpenAIEditor") AddHook(HOOK_EMITEVENT,"AIEventHook") So instead of being a "plugin" system, it's more like the editor is semi-open source, while remaining more structured than an open-source program, and preventing the branching that always occurs with open source stuff. It seems almost too good to be true, but as far as I can tell it seems like this would allow for unlimited flexibility, without screwing up the editor source code. You could use this to add a plugin with an interface for PureLight, or any number of other things, and everything would occur right in the editor, within the same interface.

I did contact both of them, and even offered to convert their models for them. It sounded like Steve was getting ready, then one day he asked me what I thought sales would be like. I honestly answered I didn't think they would be much at first, but a year from now it could be significant, and it's about getting the system in place and ready. Haven't heard anything from him since. What I really want are the FPSC model packs. Rick is interested, but he's busy right now with their new app maker program.

Actually, I don't think a non-programmer will be any more likely to be able to write script code than C++. It's all the same commands and concepts. If they can't understand code, putting it in another language (Lua) isn't going to help. They might be able to edit a few variables, but that's it...it just opens the door to endless requests for examples for this and that and the other, and then when an example isn't written to their tastes another request comes for a trivial change. At some point, requests for examples just become requests to write their game for them, to their specification. That's why I have implemented our flowgraph system. It's something completely new that largely replaces the need for code, and lets designers use pre-made interactive objects. You'll have to wait and see how that works. This is an example of when listening to literal customer recommendations is suicide. I don't mean you, YouGroove, I mean the hundreds of non-customers who have said the kinds of things I am describing. You want to listen to your customers' problems. You don't want to listen to their proposed solutions, because even if you carried them out exactly as specified there's no guarantee that would solve their problem. Additionally, if you just carry out a recommendation, you won't necessarily even understand the problem, so your solution can completely miss what they are after.

What I'm really attempting to acquire are animated characters, since that is something there is a high need for.

I don't meant 5% of the Leadwerks community, I mean 5% of the larger potential market. Right, and it was a big challenge to figure out how to make things simple without crippling the system, because frankly if I had to make an easy-to-use ****ty engine, I would rather go write high-speed trading algorithms or do something else for work. I mean, simply making easy to use low-quality stuff has no appeal to me. I like to think the design I worked out will make life easier for everyone, without holding back the expert programmers. I started as a map designer.

Cool, looks like recast?

CSG brushes will be saved into the map, or you can save them as prefabs, or convert them to models, or convert them to physics shapes. But normally, CSG brushes will be considered to be unique geometry for a given map. I haven't thought about how much CSG commands will be exposed. Probably everything, because I am building it into the engine anyways, and I have to access it all from the editor. Most days my progress is something like "that thing that used to crash the program no longer causes a crash" so I don't know if that is very interesting.