Josh

You can use them with any character, as long as it is used exclusively in our engine. +1 reputation to whoever has our little guy running around first.

See page 7: http://www.leadwerks.com/files/Level_Design_in_2009.pdf

Lots of things are happening around here right now! First up, we've got some free professionally made animations for you to use with our futuristic soldier character. You can download the files here. Michael Betke of Pure3D has been cranking out AAA-quality 3D models ready to use in Leadwerks Engine. The following sets are available: Birch Trees 1.x (€22,00) Pine Trees 1.x (€22,00) Ground Plants 1.x (€19,00) Each set features new unreleased content. Buy a couple today and help support low-cost AAA media for independent developers. I've been spending a little time with C++, and it's not that bad. Mika Heinonen was kind enough to investigate a method of integrating Lua with C++. Here are the findings he reported: At this point, we have a simple C++ project with some math classes the engine uses, and we're making sure it compiles for all the various platforms I want to support. Finally, we're getting ready for the release of version 2.32. There are some physics features that need to be finished to support huge amounts of trees and rocks, and that information has been sent to the author of Newton Game Dynamics. Numerous bugs in the tracker have been resolved recently, and more fixes are on the way for small issues. That's all for now!

File Name: Soldier Animations File Submitter: Josh File Submitted: 05 Apr 2010 File Category: Models Triangles: No Information LOD Versions: No License: Free for use with any Leadwerks Engine game. Here is a set of animations for use with our futuristic soldier character. The following sequences are included: -run -strafe left -strafe right -run backwards -idle They're in FBX format and need to be converted to GMF. Enjoy! Click here to download this file

I can't produce any problems in this demo. The only error I see is the oildrums should have their step mode set to 0.

Use a string value and convert it from and to a float.

The reason Lua was implemented this way was so people could get their level "as is" in the editor, with no extra processing. It was unacceptable to many people that they would have to use code to add lights from entity properties, and I didn't want to hard-code those things into the engine. Give it a chance and I think you'll like it.

Don't post any bugs for this.

Yep. I made that scene for Julio to examine. Seems I am the first person to use his scene collision features (for repeating instances of static geometry). This beta is not usable by any means, but I thought you guys would like seeing some of the new features, and I needed something for the physics programmer to test with.

Fixed already.

Fixed for 2.32.

Do you know of any decent searchable documentation systems, where I can have the docs engineer enter his text, add images, attach code and files, without having to edit html files? Something like a wiki, but cleaner?

lol I'll figure it out.

I know that sucks, but the only other option is to be stuck at an old version of Newton. This is why I am saying the Newton serialization format can't be relied on in the future, and an intermediate step is needed.

You can use the global variable "luastate", but you are right the function should be added.

Version 2.32 will feature some internal improvements that ensures your games run their best when conditions get demanding. I've totally rewritten the vegetation rendering routines with a highly specialized quad tree algorithm. There's a lot more to it than that, and I could write ten pages about the technique, but the bottom line is its fast and dynamic. Rendering with many vegetation layers is much faster, and since the visibility determination routine is so optimized, the engine can perform a separate visibility determination step for each stage in a directional light. The amount of shadow polygons that have to be rendered was less than half what version 2.31 required, in our test scene. Realistically, you can now render more trees with Leadwerks than Crysis. For entities, a scene octree has been implemented. This ensures that the engine only has to deal with objects in the near vicinity of the camera, even if there are tens of thousands of objects offscreen or far away. For scenes that have lots of little objects, you'll see a big performance gain, especially if you use the view distance feature. In version 2.32, each entity has a view distance setting which can be set to near, medium, far, or infinite. The engine stores lists of objects by view distance for each leaf in the octree, and skips object sets that are too far away, without having to iterate through each one. In the future, I would like to implement an update radius...this is how S.T.A.L.K.E.R. games are able to have so many AI characters walking around a map, and it's not too hard to add! Another improvement is the hierarchical rendering and picking algorithm. In version 2.31, every entity was stored in the scene graph. In version 2.32, only entities with no parent are stored. The top-most entity has a recursive bouncing box that encompasses all its children and sub-children, and is automatically updated once a frame when anything in the hierarchy changes. Let's say you have a truck. The truck consists of a chassis, four wheels, and a rotating turret. In version 2.31, all six sub-objects would be stored in the scene graph and iterated through for rendering. In version 2.32, only the top-most entity is stored in the octree. If the top-most entity is not visible, the entire truck is skipped. If the top-most entity is visible, its children are iterated through until they are all rendered. What about the case of animated characters, which might have 100 or more bones in their hierarchy? Wouldn't it be inefficient to have to iterate through the whole skeleton, especially when most of the time there won't even be anything that needs to get drawn? Yes, you are right. I got around this problem by adding a "renderable" setting to each entity. Meshes, coronas, emitters, etc., have the renderable setting set to True. Pivots, bodies, and other invisible entities have it set to False. Each entity also stores a recursive attribute that stores the number of children in its subhierarchy that are renderable. So when a bone is encountered in the rendering algorithm, if it doesn't have any renderable children in its sub-hierarchy, it will be skipped, and the engine won't have to iterate through all those bones for nothing. If the bone connects to a shoulder that connects to a forearm that connects to a hand that has a gun attached to it, the engine will iterate through those entities to get to the renderable gun mesh. It's the best of all worlds. If you only have a simple scene running, you probably won't see any speed improvements. However, these features will make the difference between your game running or not when you get further along in development, and will ensure you get the best possible performance. I would like to be working on some more high-level features that make the development experience nicer for the end user, but the most important thing for me to do is make sure your games are the best they can be. That's why I thought it was important to devote time to the described areas.

I haven't thought it all the way out yet.

No, this is only for PHY files. You'll have control over how they are created.

A beta of version 2.32 is available. This features a rewritten vegetation rendering system, octree implementation, and a more optimal hierarchical rendering technique. If you enable the scenegraph display, you'll be able to view the octree and vegetation structure data visually. If you enable entity box display, hierarchies of entities form a recursive AABB for the top-most parent. The technique I am using is quite complex, but it will ensure games run fast even when they have very large numbers of objects. The entity view distance setting is no longer just a simple float value set per entity. You now specify an integer for near, medium, far, or infinite range. This allows the engine to group and dismiss large numbers of entities without having to iterate through all of them. Vegetation collision is sort of implemented, but has problems. One of the reasons for posting this was to allow Julio to download and test it himself. The character controller will cause a crash when combined with vegetation collision. The Newton serialization format changed. PHY files have to be reserialized. In the future we are going to rely on OBJ files and the PHY file will be automatically created by the editor. There's a new option for terrain to set a background image. You can then adjust the blend amount for each layer to combine with the background image.

It's really easy to just use Lua to automatically create lights and things in your scene. You just load the model, and it's automatically taken care of, with the same code the editor uses.

The installer works fine with your reg key.

I am downloading the installer to try it. It should work fine.

Please post an example we can run ourselves to test.

I can't find any purchase with this email address. Please email your registration key to support at leadwerks dot com.

Unwrap3D gets my vote. It can import and export anything.