OrbWeaver

Arguments over "true black" are specious. You won't see true black until you are standing at the bottom of a mineshaft with no light sources. It may be true that a CRT gives a better contrast ratio than an LCD, but what the eye perceives as "black" is entirely relative to whatever else it can see at the same time. My LCD gives perfectly acceptable blacks during gaming or movies, and it is not even a particularly decent or expensive one.

By "performance", are you referrring to the blurring/response time? I don't see any way in which a hardware operation in the monitor could affect the actual game's performance.

Make sure you use a screen resolution of 640x480 when doing the envshot, otherwise the proportions will be wrong.

You can get better results using a pre-rendered cubemap. You need to stand in the position where the cubemap should be taken from, and type "envshot" in the console. This should write out six cubemap images which you can then apply to your material using the "cubemap" stage keyword. I have never tried doing this myself, but it was used in a lot of the original Doom 3 and Quake 4 levels where you see a reflection on a possibly non-flat object.

I think the way it works is by positioning a second camera the other side of the mirrored surface, and taking a render back towards the player. This becomes the texture which is put onto the surface. I believe the upshot of this is that there must be no geometry in the mirrors "reflected space" that could get in the way of this rendering step.

What's broken about it? It worked fine for me. You do have to add a couple of standard lines to scale and translate the mirrorRenderMap stage, there should be tutorials on Doom3World. Oh, and don't ever add a mirror texture to two sides of the same brush, you will get a weird colour wheel or possible the Doom 3 burning planet image.

Do we know for sure that an in-model CM will work? I have never actually tested this but if it works it would certainly give better results than chopping up a brush.

I will have a look into this. Initially I thought that the light texture was ignored, which would mean the functionality was missing from the renderer, but further tests reveal that some textures do work (lights/biground1 for instance). This is encouraging since it suggests that the code is already in place to handle this; hopefully it should be possible to recognise the ambientlight keyword as well.

The way it works is that Add Entity gives you the complete list, while Add Light and Add Model just give you a quick path to two very common specific types of entity ("light" and "func_static"). I could theoretically add more hardcoded shortcuts like this (perhaps "Add moving light" or something), but I wouldn't want to go down the route of special-case subsearches. A Doom 3-style media browser is on the to-do list. Not sure what you mean - are you referring to a shortcut key with ALT? Glad you share the vision. Hopefully I can prove wrong my own previous assertion that there is not a game level editor in existence that isn't unfriendly and bug-ridden.

Yes. Yes. If you zoom in small you should be able to fit the brush to the size of the model fairly well. You can also shave off parts of the brush with the clipper tool before exporting, as long as it remains a single convex brush.

DarkRadiant 0.5.1 is available from SourceForge: http://sourceforge.net/project/showfiles.p...lease_id=434137 Fixes: - Changing an entity keyvalue now sets the map status to changed so it can be saved - Dragging a model now updates in realtime, rather than waiting for the drag to finish - Textures should now display correctly on ASE models - Application should not crash on Window 2000 due to the presence of global.xlink (which has been removed anyway). Enhancements: The huge right-click entity menu is GONE. Instead there is a context menu with options to add a light, model, entity and (eventually) a prefab at the current location. The selection of an entity uses a separate dialog with an alphabetical list of all entity classes (with typeahead search).

7 out of 10. Most of them were guesses, I really had no idea.

Fixed upstream in GtkRadiant, merged into trunk.

I wonder if this is related to what Gildoran was saying about Doom 3 expecting hardware to be fillrate-limited rather than transform-limited. Perhaps in a Geforce 4 the two are more or less the same, so that sometimes one dominates the other and vice versa.

There is a render mode, available by pressing F3. Currently it is very limited and only displays a rough approximating to Doom 3, with simple lights (no custom textures) and no shadows. Hopefully the framework is enough for further improvements; unfortunately I am not yet much of an OpenGL/graphics programmer so I don't know how easy it will be to add these features.

Funny, I was just thinking about posting this bug yesterday. In fact the preview window completely ignores light textures as far as I can tell, and assumes a simple spherical falloff in all cases.

No it doesn't. You can use multiple light sources, including some with a suitable ambient lightshader applied. Only if you make it so. You can use as many light sources as you wish, although don't go too far above 2 or 3 if you can avoid it for performance reasons. Pitch black shadows do not exist in real life because there is always another source of light.

More detail, less flat texturing and blocky architecture. More subtletly, fewer extremes of light and dark (most of those shots only have one light source, everything in shadow is black). Less garish, cartoony colours. More of a coherent visual impression, less ad-hoc placement of random objects and brushes with no overriding style. HTH.

I wouldn't describe it as awesome, but it's certainly improving.

Yeah, the only way to do true volumetric fog is by using a particle effect. Perhaps you could modify your snow/rain emitting texture to emit very large, slow-moving smokepuff particles (which look good as fog if they are sufficiently faint). You might not even have a performace issue if you used large enough sprites, as you would not need that many.

ASE model/shader not found issue now fixed in trunk. Trees are textured correctly in tavern.map.

Instead of binding to player you could also just use a huge foglight that encompasses the whole level (which can itself be the receipient of scripted events based on player position). Since a foglight is not really a light this will not impact performance.

Least Squares Conformal Map (also Laser Scanning Confocal Microscopy). It has something to do with the algorithm and the way it tries to preserve local angles. Cool spider BTW, I have made several attempts to model a spider in Blender but never quite managed to get the proportions right.

I get the impression that LSCM support is actually rare, and Blender is one of the few applications that has it (and quite possibly the only Free one).

Do you mean LSCM? I can look at an LWO in Blender and tell if it definitely is UV-mapped, although I don't have sufficient confidence in the import script to declare that it isn't (since it may have one, but the script failed to import it).