Josh

I finished the collision editor, and now came across a pretty significant design issue. The approach the main editor has always taken is that by the time assets get into it, they are finished and ready for usage. Now I am making it so the model editor can change the structure of a model, save it, and have the main editor reload all instances of it. However, the Lua class scripts cause some problems with this. If I load a model with it's script enabled, the script might delete limbs fromt he model, replace them with other entities, or add new limbs. For example, the monster truck script frees the wheel meshes and creates vehicle wheels in their place. If this is allowed, then the tree view for the model will not be the same as what the GMF file originally contains. If the model is resaved, it will overwrite the existing GMF, and no longer contain the same limbs the script looks for. I could disable the class script in the model editor, but I also want to be able to view a finished model with the script enabled. For example, if I have a street light with an added corona, I want to be able to look at that in the nice big model editor window. Probably the best I can do is just leave it up to the end user not to do anything in the script that will break the model if it is resaved. Either that, or we have two separate applications built into the editor: a model viewer, which uses script, and a model editor, which disables the script. One kind of neat thing I did was set it up so the surface tree nodes only get populated when the user opens them. You might remember early versions of the model editor were slow to load large meshes because a ton of vertex data had to be turned into tree nodes. This will allow full display of all data, but it won't slow down loading. The worst that might happen is a brief pause when a surface node is opened. I'm planning to make all the data in each vertex editable, so you can clean up meshes by brute force, if you choose to. A few options like "Update Normals" will be available on a global and per-surface basis.

Yes, I am planning to have a node-based material/shader editor both as part of the main editor, and compiled in a standalone app.

One of the most frequent requests I consistently hear is that people want a visual interface for everything. I personally don't think stuff like that adds much value to the engine, but all the artists feel otherwise. Sometimes you have to deliver what the market wants, not what you feel like doing. It won't take too long to do, and it does make the editor feel a lot nicer.

For vegetation layers, you can set the distance the billboard appears at, the distance for LOD changes, and the distance at which the object disappears completely, all in the vegetation layers options. Billboards are generated automatically, and as you can see, it is possible to have hundreds of thousands of trees onscreen at once.

Shaders.pak does not have to be in the same folder, but it should be somewhere in your game path, which by default if the same folder as the editor.

The integrated model editor will be able to solve that problem, for most models.

What makes an ocean place an ocean plane?

This is contrary to the design of associating a script with a model entity. What are you creating bodies for?

What kind of game are you making? FYI, our raycast commands have an optional radius parameter, but as of now it doesn't do anything since it isn't implemented yet.

The networking code is pretty much done, but I don't think it's quite ready to release. We're redesigning the site to integrate the forum and community features together with the whole site, and an official documentation section is being created. In the meantime, I am going to start the model editor. This will be an app to replace the "Model Viewer" which will allow viewing and resaving of .gmf files. It will also include some editing features so you can adjust some of your meshes that might not have been converted or exported successfully. I'm planning for the app to be both integrated into the main editor, and compiled as a standalone app, the same way the script editor is. I'm also kicking around an idea for a GUI system.

Maybe add "le" to the beginning of each function and constant.

It doesn't make sense for a vertex shader to describe an "alphatest" setting because alpha discard is performed in the fragment shader.

It won't make any difference what program or even engine you use. An ATI card with drivers 9.11 or 9.12 will perform a discard in any GLSL fragment shader with a cubemap lookup. The problem has been confirmed by ATI, and according to them will be fixed in the 10.1 drivers.

LoadScene loads the vegetation the editor makes. You do not have to have a framework object created.

It will load a second instance of the sound from the loaded reference. In pragmatic terms, this simply means you'll increase memory usage by about 12 bytes and have no loading from the hard drive. When both instances are deleted, the reference will be deleted, which is where the real sound data is stored. So go ahead and do it if you want.

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.