OrbWeaver

That is a planned feature for the much-needed model browser interface. I might integrate this into the tree view, so that a model with skins could be opened up to have alternative skins displayed as its children.

Yes, that's a GtkColorSelection. There is a need for a dedicated Property Editor to provide this interface for adjusting _color keys.

Good idea, DoomEdit does this. One thing I would like to do with light radii is provide an option to overlay the light texture onto the light radius in the 2D view, so that it would be easier to see which parts of the radius are actually lit.

Rotation does work in DarkRadiant - all objects rotate around a common centre. Presently the location of the centre is automatically calculated based on the objects' positions, but presumably it would be not too difficult to allow the user to set the centre point manually.

A foglight isn't really a light, so don't worry about the performance.

For that you might use a foglight. Particle fog is not really appropriate for underwater, but the foglight gives you a nice "growing more opaque with depth" effect.

"Not consciously remembered" is not equivalent to "pointless".

Dual core allows the processor to "do two things at once", in certain circumstances. Many applications cannot take advantage of this, since they require things to be done in a certain order and cannot easily parallelise their operation. The main advantage appears when you are running several applications simultaneously, like encoding an MP3 in the background while playing Doom.

That's a marketing myth. Dual-core does not give you twice the performance of single core.

I don't quite see how the y component can be identically 0 - surely the up vector must have all three components since it is perpendicular to the direction vector which can point anywhere? E.g. with a direction vector of [0 1 0], start tilting backwards. The up vector will start to point in the negative y direction.

Basically yes, although the up vector does not have to be perpendicular to the direction vector. In fact for most purposes you would never touch the up vector, it would always be [0 0 1], but it is necessary to change it if you want the camera to pitch past the vertical.

I understood normals to be unit-sized, which means they should not be scaled. The direction of the normals would not change whether scaled with the model or not, so the issue would be whether their size is scaled and whether the renderer has a problem with this or not.

You can skip step 1 if you want - entities with a "fixed size" such as models do not require a brush to be drawn first.

Don't try it too hard, I am almost certain my x and y formulae are wrong. In fact I am not sure you can use a linear transformation of the direction vector, it might need separate trig functions. Ishtvan seems good with this stuff, maybe he would know how to do this?

It might be something like: x_up = - x_dir; y_up = y_dir - 1; z_up = 1 - cos(pitch); Assuming that y goes into the screen and z goes upwards which i think it does from your example. EDIT: very unsure about x and y, z looks reasonable though I think.

Can you continuously modify the up vector along with the direction vector, so that it is always at right angles? I am not good enough at visualising vector spaces to come up with a formula but I imagine it would look similar to the one you are using to calculate <x, y, z> for the direction vector (but with the odd minus sign and swapped sin/cos).

It is a related issue actually - as you say the camera does not need to go past the vertical in the "pitch" direction in order to address every point on the sphere, so generally this does not become a problem. I imagine you could get round this problem by ensuring that whatever transformation is applied to the direction vector is also applied to the up vector.

Freeware usually refers to the sort of small, freebie software applications you get on magazine coverdisks. It is typically written by one person and is not available under an open-source licence, although the binary is distributed without charge. FOSS (Free/Open Source Software) is available under an open-source licence whereby the users are granted the right to modify and distribute the software at will. Free Software has the added restriction that users are not allowed to make proprietary, closed-source derivatives of the original software, whereas some Open Source licences (such as the BSD licence) do allow this.

Water does not need any kind of additive blend. It should be a filter blend that darkens whatever is beneath it, plus the reflection which gives the impression of illumination by reflecting lit surfaces above it.

A camera actually needs two vectors - the direction vector and the up vector. My guess is that as you approach the vertical position, the camera tries to orient itself so that both the up vector and the direction vector are pointing "upwards", thus causing the rotation. Once you are past the vertical, the camera would in fact be upside down so it flips over so that the up vector is still pointing "upwards". There is a problem that sounds a bit like this in Blender, when you extrude a profile along a path and it approaches a point where it is travelling vertically and then back on itself - the profile will flip 180 degrees as the up direction gets changed.

Minor nit: open source != freeware. Tor seems good but the problem is it is prohibitively slow for many things, due to the requirement for your traffic to pass through an encrypted tunnel of 3 randomly-selected international servers before it reaches you.

Anybody who uses IE loses the right to complain about pop-ups. Seriously, that's like going to a malaria-infested zone without any jabs and complaining about the ensuing sickness.

You should check the console tab in the editor, it provides useful clues: Changing "specular" to "specularmap" fixed this (commited to CVS).

That's how it was modelled, there is no bottom half to those rings. It seems to work out OK if you put it on the floor, just means that the fence is shorter than the gate but this doesn't look too bad in practice (makes the gate stand out).

The reason there are four different materials is that the UV-map is not unique, therefore you can only use tileable, repeating textures. By having separate materials you can add more variety by using a different texture for the individual components. If you would rather use a single material, just edit the ASE in notepad and change all of the *BITMAP lines to the same value.