Josh

It's not as simple as "this vertex is weighted to this entity". The model has internal indexes of bones when it is loaded, and the vertex data references those indexes instead of the bone entity. The bone data is uploaded to the GPU in an array, and the vertices access this array with their bone indices.

At this time the editor is required to add vegetation.

In "Scripts\start\collision.lua": Collisions(COLLISION_PROP,COLLISION_PROP,1) Collisions(COLLISION_PROP,COLLISION_SCENE,1) Collisions(COLLISION_CHARACTER,COLLISION_PROP,1) Collisions(COLLISION_CHARACTER,COLLISION_SCENE,1) Collisions(COLLISION_CHARACTER,COLLISION_CHARACTER,1) Collisions(COLLISION_CHARACTER,COLLISION_TRIGGER,2) Collisions(COLLISION_AILINEOFSIGHT,COLLISION_SCENE,1) So we see the character collision type is identical to the prop collision type, except the character collision type will also collide with bodies with the trigger collision type.

The whole site is going to be made seamless as one, so yes. Official documentation besides the wiki will be part of the site. The wiki will continue to exist and be maintained as well.

Dedicated server mode will come once some networked games are up and running.

This is really good.

A "Resources" section is are available, and obviously in beta. Click the "Pages" link in the navigation bar, and you'll see them. Feel free to add your articles in the community resources section. I will do my best to retain the data for the final site design, but I don't recommend putting anything up there you don't have a back up of somewhere else.

Use the Lua command in the script, in the object creation function. http://www.leadwerks.com/wiki/index.php?title=Models#SetModelLODDistance

This adjusts how much more slowly the camera moves when the control key is held. The prop collision type is set up with the collision script in the "start" folder. The type is meant for all moving physically interactive objects, i.e. most objects you put in the scene, unless they are static, in which case the "scene" collision type is preferred. Of course, this is totally configurable by the end user, so you don't have to use my convention. The trigger collision type only registers the collision, and does not have any physical effect. This can be used to make the player activate a trigger by running into it, without actually blocking the player from moving through it. The linear offset is the distance by which the shadowmap depth is offset. A slight offset is needed to avoid "shadow acne". This controls the exact distance of each stage of the directional light shadow. You can use this to make the shadow extend to cover more of the scene, or you can adjust the distance (and thus the resolution) of each stage. You only have so many pixels per stage, and this setting allows you to adjust their allocation to get the best balance of distance and resolution. The linear offset should never be used with a point light because it will cause gaps to form in the corners of the cube shadow. In fact, I may remove the setting from the script. The multiplicative offset is a multiplier which determines the actual distance the shadowmap camera renders. For example, if the range is 10 and the multiplicative offset is 0.95, the shadowmap camera will only render a distance of 9.5, but the shadow depth will still be considered 10.0. This means the shadowmap pixels will be "stretched" to a length of ten, causing a small error that increases with distance from the light source. The shadow pixels that were cast at a distance of 9.5 will be offset all the way back to a distance of 10.0. It's just another way to avoid shadow acne. This is necessary for point lights, because it allows the seams of the cubemap to meet without any gaps. These are just settings the user can make use of in scripts. Any object can be activated or enabled. Activating a disabled object will have no result. An object can only be activated when it is enabled. For example, you might have a door that when activated, slides open. However, the door can be locked by setting the "Enabled" property to False. In that case, when the user pushed a button that activates the door, nothing would happen, because the door could not be activated until it was enabled. It is the user's responsibility to program behavior into their objects, and the enable/activate settings are just a suggested technique. This sets the entity rendering order, for z-sorted surfaces only. This can be used to make one road appear consistently on top of another road, when they both lie flush on the terrain. They are for static and kinetic friction, respectively.

I decided early on I did not want to have all that dynamically allocated data created each frame, when most of it would never get used, so there is no record of collisions saved. I suppose I could have used a bunch of arrays to record the data in, but the callback serves the same purpose.

You should be able to change graphics resolution without having to reload anything.

Unfortunately, I can't see what I am looking for examples of in those videos. I contacted the guy who made the FPSC character animations.

No, Steam just publishes good games. Many first-time developers have released games on Steam.

A GPU only has so many texture units available, so it's impossible to render large numbers of instanced lightmapped objects. UDK uses many different kinds of lighting and shadows, so it's often hard to tell what is going on.

For each class of objects, have a save and a load function.

That's because when you render in wireframe, the rasterizer no longer covers up what was behind the object.

Yep, that's how it is meant to be used.

3D World Studio does support vertex editing. There is no need for animation, since it is a program for making buildings, not characters.

You can make your models in a third-party modeling program, or download them from this site. Then you place them in the scene with Leadwerks Editor.

Yep, this is talked about in the end of the big Lua tutorial.

You can't even run a game without SM3 because the cards can't do basic things like a texture lookup in the terrain shader to set the terrain height, or for GPU skinning.

There's going to be a sort of open-source playable game written in Lua, but it takes time. Right now I am trying to find an artist to animate the soldier model.

The C++ tutorials cover the basics of different aspects of the engine. C++ was chosen because it is a standard everyone should be able to follow along with. There isn't much different between this: TModel model = LoadModel("thing.gmf"); And this: model = LoadModel("thing.gmf") There are two working examples in Lua, located in the "Script/Games" folder. I am not clear on what you are asking for. It seems you want a tutorial that goes through and makes a simple game in Lua piece by piece.

Why would you want to do this? If Leadwerks could run a a Shader Model 2 GPU, it would look like any other stuff that runs on SM2 cards.

I like Terminal, but I'm not sure that is accurate.