Josh

The engine uploads an array of matrices and draws a batch of like objects in one call. The texture offset idea is not bad. You could use the per-instance color to control the texcoords for it.

You can enable physics debugging so you can see where everything is.

Since it's all one state, you can just use a global lua variable.

This community rocks.

It's up.

An update is available if you rerun the update tool. The version is still 2.3. The Lua design needs to be talked about. You will notice the class scripts are an object-oriented single state system. It is possible for you to mess up the Lua state with a bad class script or a script you run in the integrated script editor. For example, if you do not free a class it will remain in memory and may interact in unexpected ways. If you follow the design of the template.lua script, you will be okay. Just contain per-class variables within the class object as I did in the examples. Whenever you load or create a new scene, the Lua state is recreated, so you start with a clean state. The class scripts syntax is as follows: An "object" in lua is the analog to the model instance in the engine. I decided to call the variable "object" instead of "entity" to avoid confusion with engine entities. The object is just a Lua table associated with a model in the engine. The object "Kill" method is renamed to "Free" because the OO design allows redundant function names (thus, object:Free won't clash with class:Free). A class is the table associated with an engine ModelReference object. This is a Lua table that is used to create all the objects. The class has a reference to the model reference, and has an instances table where all objects of the class are inserted into. So on the engine side you have a ModelReference with an instances list where all the models of that type are stored. On the Lua side you have the class table, which has an instances table (like a list) where all the objects of that class are stored. A function renaming trick in class.lua (the replacement to base.lua) makes it so you can call the base class' original functions in extended class functions: function object:Free() --do some stuff self.super:Free() end When you open or write a script in the integrated script editor, the Lua state is not recreated after the script runs. This allows you to modify internal values or set variables, but the editor will not clean up any damage you do. Conversely, when the "Switch to Game" mode is enabled, the editor reloads the scene from memory and creates a clean new Lua state when the you switch back to the editor. Whenever the lua state is created (at startup or with a new scene) all scripts in the "Scripts/start" folder are run in no particular order. Remember, these script are using the same lua state as the class scripts, so you can access information defined in the startup scripts. Finally, the single lua state allows class scripts to access each others' data. This allows for much deeper interactions between classes. This design is final. I'm sorry for the misstep in development, but I think you will agree this design will give the best results. Have fun and be safe. I am happily now going to focus on tutorials and examples for a few weeks.

There's a camera spline script in the editor that can make these movies much smoother.

Their system is basically a visual way of writing shader code. All the "input nodes" in their system are variables or texture lookups, and it probably uses that to generate a new pixel shader for each material created.

This is how I did vertex lighting in very old versions of the engine. Each instance had a unique color array that was switched when instances were drawn. This is not part of the design of the modern engine.

You can delete the scilexer DLL and the editor will use a different method of rendering text. It won't look as nice, though. There were earlier problems with scintilla crashing, but they seem to have been fixed, or so I thought.

Fixed, thanks.

Well, they're probably just going to write documents and use email for those machines.

I would not be surprised if 70% of computers have an Intel integrated graphics chip. Don't know if that is correct or not, but it sounds reasonable.

That's not a bad idea.

What do you want to use this for?

Documentation and tutorials come next. I have a nice big chunk of time to work on them now. The terrain editing probem on SM3 cards was easily fixed, so the update will be available tomorrow.

Terrains in id tech are just a mesh made in a modeling program, so the geometry is very limited in size.

Is the Crysis AO calculation a step that has to be processed and saved, or is it dynamic?

From the technical specs I have read of RAGE, it doesn't even allow terrains as big as what we have.

I have no objection to a converter being made from gmf to another format.

I have to say, I love the idea of an infinite world streamed from the hard drive. It's a long way off, but I dream of a world like STALKER that's completely continuous.

I see no evidence of any special surface technique. It looks like a plain normal map to me. Just a really good texture. The SSDO effect I have working produces results similar to those trees, although I don't know if they are doing a dynamic effect or if they simply darkened the interior vertices.

Physicists, not physicians.

Angular velocity is commonly referred to as omega: http://en.wikipedia....ngular_velocity

256.