OrbWeaver

Strange, I've renderbump'd plenty of ASE files. As long as you don't mix and match (low-poly ASE, hi-poly LWO) it should be OK.

That renderbump expression needs to be on a single line. It looks like you have split it over three lines which is causing the material parser to complain.

We discussed this as I recall, the general feeling was the shadow meshes would be a good idea but there might be considerable work involve in adding them to AI meshes and making sure they animated properly. In theory this could be a big win performance-wise, shadows are extremely performance-intensive.

The local map is the file that is generated when you run the renderbump command in Doom 3. The basic workflow is to export your low-poly model as normal, create a material from it in the usual way but add a renderbump line similar to the above which details the size, the path to the hi-poly model and the destination normalmap. Then when you call renderbump on your low-poly model in the console, it will pick up this information, load the high poly model and generate the normalmap.

I have actually fixed this (since it was trivial), but this is still not a good way to make a light falloff texture. Vertical falloff textures should be 1-dimensional.

Are you trying to achieve something in particular, or just learn about the techniques? For simple models like crates, you probably don't need renderbump at all.

I recommend using ORB (http://engineering.soclab.bth.se/tools/177.aspx) rather than Doom 3's renderbump. It is more interactive and does not require setting up MTR files to define the parameters. Otherwise, you have to have a renderbump global keyword in your low-poly model's material definition, giving the renderbump parameters and the path to the high-poly version.

You could try creating a collision model manually by adding a second, identical cube textured with common/collision (or whatever it is). I find it hard to believe that there is a grid resolution in the calculations, but there may be one in the automatic generation of collision models. Yes you can, but it rules out using stock textures, collision or shadow meshes and the like. Excellent, I'm glad something finally worked in your Blender setup.

No problem, we'll implement it this afternoon.

It's unlikely you would have a 2000 poly model that was supposed to be unsmoothed, but in this case there is a script that will help you - Mesh/Unweld as I recall, which allows you to unweld every face on the model. Normally you would select groups of faces that should remain smoothed, and unweld them from other groups if necessary. Don't bother using LWO with Blender. There is some support for it, but it can be a right PITA trying to get things working correctly (in particular, Blender has a 19-character material name limit which isn't enough for a typical Doom 3 material name).

It makes no difference whether it is smoothed in Blender - when the ASE is loaded into Doom 3 it will be smoothed automatically unless you unweld vertices to prevent this. This means in Blender you have to select each face, and press Y to "split" the face away from the mesh. To split a cube in this way you need to do this four times - top, bottom, left, right (and the last two will be split as a consequence). As a hint, when modelling in Blender make sure smoothing is turned ON for the whole model, this will then simulate Doom 3's rendering and allow you to see what you need to unweld and what you don't.

First we need an Official Zombie Consultant, though.

If you open up the .MAP file in Notepad you can see what coordinates are saved. I would suspect that the light_center is indeed in light space, it's just a bug in DarkRadiant that the point representing the centre is placed in world space.

I added the light_center as a recognised property, so it can be edited as a simple vector3 (not yet committed to SVN though). It appears though that dragging the centre like in D3Ed is not possible, and it also seems to be using world coordinates which is a bit strange (unless D3Ed does this as well and I never noticed). I would expect that a centre of <0, 0, 0> would be at the geometric centre of the light, not at the world origin. DarkRadiant uses the same child windows as D3Edit, which you position where you wish. I have mine set up exactly the same as D3Edit.

FIXED

No, the extensions are ignored anyway, but Doom 3 looks for a TGA in this situation. I had a go at using a DDS as the "original", by putting it in the location where the TGA would be loaded from, but Doom 3 ignored it. I will do a bit more digging, like many things it may turn out to be easier than expected. Is there some way CVS can be used to do this on the client PC? I wouldn't want to exclude low-bandwidth users like Dave by adding a whole load of hires data to the repository (although I can't imagine it would be 12 megs per texture, since diffusemaps rarely need to be 1024 and speculars never do).

As if I needed another reason for recommending NOT to strip out TGA textures from the main respository, after spending some time chasing what I thought was a renderer bug, I discovered that the reason certain textures were not rendering properly (e.g textures/darkmod/tile/floor/marble_002_center5_gear) was because they refer to TGA files which do not exist. Obviously Doom 3 is automatically substituting the DDS version in game, but DarkRadiant needs the original TGA in order to render correctly in the preview window. This means we have the choice between a slightly larger main repository, or broken rendering in DarkRadiant. Although there are a few references to DDS in the source code, I cannot see any easy way of adding "fallback to DDS equivalent" functionality if a TGA is missing, and I'm not sure how much time I would want to spend on it given the large number of other enhancements requiring attention.

What makes you think he's using brushes?

No you don't, you can use a precompiled binary: http://sourceforge.net/project/showfiles.p...ckage_id=182228 (unless you are editing on Linux, for which there is no binary package as yet). Still, kudos on getting it compiled and running without any assistance. It's ironic that the only people to build anything substantial with DarkRadiant are not even members of the team.

It depends how hard you try I guess.

The plan is that all of the Dark Mod stuff will be customisable via the game file and won't get in the way of regular editing, so DarkRadiant will be usable as a better Doom 3 editor as well as a Dark Mod editor.

I guess it might allow quads, but it's probably triangles. It certainly won't be n-gons (five-sided or more).

What normalisation filter are you using? Looks like one of the larger ones, like 9x9 or so. I prefer to use the smaller filters to avoid things looking too much like layered plastic.

Yes, it did work. I used it to fix the iron gate for Springheel. I can't remember which version of Blender or Python I had installed at the time however. Unfortunately the Blender guys have a habit of thoroughly breaking existing scripts with every point release, due to API changes and the like.

I wouldn't say I'm particularly bothered by any of them, they all look pretty good even with the rounding. The example that jumps out at me is this one: Notice how jagged and craggy the diffusemap picture looks, and compare with the bumpmap where each stone looks really smoothed. Maybe this is the effect you were going for, but I think a version of this texture with the original rough stones would look good as well.