OrbWeaver

It's probably not fair to compare the two, since with DoomEdit you have the whole game loaded as well. Nevertheless DarkRadiant having acceptable memory usage is a good start. I agree, this is much easier to use. Glad you like it. Yep, this should improve with the Media Browser, which will allow you to load any individual texture or group of textures into the texture preview window. These won't take the form of buttons, but of Property Editors in the Entity Inspector. I.e. when you select the "model" or "skin" property, a widget will be displayed allowing you to browse these DoomEdit-style. Initially I was planning to do a separate light inspector, but decided to merge this functionality into the Entity Inspector. I might consider a dedicated dialog for lights if enough people request it, but it's not a priority at the moment. The usage information is parsed directly from the entity definitions, there won't be any way to expand on the information that the developers put into the DEF files.

Heh, there's more than one species, Argiope probably being the most interesting. I suspect what happened is that the All Properties dialog got hidden behind one of the other windows, giving the illusion that the program had crashed when in fact the application was just waiting for the dialog to close. I haven't yet found a solution to this problem which works reliably across both Linux and Windows. I see what you mean. I don't actually remember such as function in DoomEdit, suggesting that I never found cause to use it. As New Horizon said, this function will be handled by the right-click Create Entity dialog rather than as a separate button on the Entity Inspector.

The entity inspector works differently to the DoomEdit version, and more like the Thief/Dromed system. The idea is that all standard properties are available in the existing list, which allows a different GUI to be used for different types of property (text, vector, texture etc). You can add properties manually using All Properties but any standard properties that are missing (and there are plenty) should be posted in this forum so that they can be added to the list. You are correct, attempting to turn a brush into a func_door seems to have no effect (the entity is created, but the door is not generated from the brush). Investigating. A create button where, to do what? Please be more specific as to what you are requesting. Yes, adding the usage information is on the todo list. Is this using the All Properties dialog? I tried this and it works fine, the "unrecognised properties" line is a warning and does not crash the program. Did you do anything else before the program crashed?

Both. You can select a single brush, right click, "Create Entity", then select the desired entity and choose "Add", to turn the selected brush into an entity. Alternatively you can do that same but with no brush selected, and the entity will be created where you right-clicked. This is in fact the same behaviour as DoomEdit, it just adds an extra dialog between creating the brush and selecting the entity. This allows "Add model" and "Add light" to be given more prominence, as well as avoiding the problem associated with a huge and ever-expanding context menu.

DarkRadiant 0.5.2 is available from Sourceforge: http://sourceforge.net/project/showfiles.p...lease_id=440419 UI enhancements New light texture selector widget with OpenGL preview and shader info display light_center property added for lights (doesn't show correctly in 3D views at present) Renderer fixes Ambient lights now work correctly Textures without normal/specular maps render correctly (previously these would be unshaded) DDS-only textures supported Configurable light-scale parameter (all lights are multiplied by this) Light Z falloff texture sampled at V=0.5 rather than 0.0 (to "support" incorrect use of 2D images for the Z falloff) It should now be possible to view mansion_alpha.map in preview mode without rendering problems (except the obvious lack of shadows and the atrocious performance).

Bear in mind I am not actively maintaining the other view styles - although they will remain available, there is a chance that any new UI widgets won't look right in them. In particular, to add a Doom 3-style media browser requires the group dialog window to be available, which won't be the case in splitpane mode.

It would probably affect the rendering in DarkRadiant preview mode as well. All windows can be dragged or resized, they are just normal windows. Are you sure you don't have DarkRadiant set up in split-pane (Q3Ed-style) mode? I thought I set the Doom 3 child-window mode as the default.

Yes, it uses the low-poly UV map to identify a coordinate on the normalmap image, and then uses the high-poly mesh to calculate what the normal should be at that point.

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.