rich_is_bored

Not to detract from the discussion too much but I found this noteworthy... Isn't something like this already implemented in the mod? I recall reading something about pre-computing sound propagation data during map load. Is this only used for alerting AI?

Try starting the training mission again only this time when it fails and kicks you back to the objectives screen, press CTRL + ALT + ~ to bring down the console and type "condump console.txt" to dump the contents of the console to a text file. Now attach console.txt to a post here so we can examine it for errors.

If we're strictly speaking about python, the task is reduced to file handling and a bit of math. The hard bit is understanding HL2's map format well enough to do the conversion in the first place. You might want to look into that first.

We had a member on D3W begin writing a gui editor prior to the release of Doom 3. But once the game was released and we learned of the built-in editor, he stopped working on it. It probably won't be of much use but if you're curious... http://hosted.zeh.com.br/flesh/about.html I should also mention that the source is included (Flash/ActionScript).

I don't know of an existing solution but Dark Radiant's python implementation is more than adequate for the task if you want to write a plugin. That's probably not the answer you were hoping for but it does mean such a conversion is possible.

@'TinyThief': The surface normals look like they might be inverted. But I don't have 3DSMAX and it's hard to say for certain what's wrong without being able to examine the model.

Blender has changed a lot (for the better) since last August...

Both the script and link in the first post have been updated. A dialog has been added to prevent the user from unknowingly overwriting an existing file and brushes with multiple textures applied are now exported as such.

Perhaps this will help? http://forums.thedarkmod.com/topic/10901-signs/

The general consensus is that Doom 3 does a much better job of removing unseen faces during compile than it's predecessors. But its just an observation. Nobody has done a proper test to see how effective it really is. It would be interesting if someone were to take a map that performs poorly, give it a once over with caulk, and then compare the FPS difference. Even more so, to run through both versions of the map with r_showtris in an attempt to identify the geometry that the compiler missed.

That didn't take long.

There may or may not be something wrong with the Blender import script. It's hard to tell given the Dark Radiant plugin is in a state of flux. I will say that the last time I worked on the Blender import script, I did a batch import of all the ASE files bundled with Doom 3 and there were no observable errors. But that doesn't mean much. At any rate, I've submitted a bug report for the python dialog not trapping key presses.

I'm not too concerned with the Blender import script at the moment but point taken. I'll address the problem once I've got this script in a more finalized state. Adding a confirmation dialog to prevent people from overwriting files won't be an issue. As for the dialog not trapping key presses, that is out of my control. I guess I need to file a Dark Radiant bug report.

I've updated the script. The link in the first post has changed. The normals for brushes were inverted and UV coordinates were flipped along the V axis. This along with the "No ASE material exists with id 1" error has been corrected. I have discovered one other issue with textures that I will need to address but the script is mostly functional in it's current state. It seems Doom 3 does not handle textures applied per face. Instead it falls back to textures applied per object. This isn't an issue with patches as you can't apply multiple textures to them. However, it is possible to texture brushes on a per-face basis. I'll need to revise how I'm handling brushes to account for this. Until that happens everything exported will be using the same texture.

To the best of my knowledge ASE doesn't support quads or n-sided polygons so reducing the mesh to triangles shouldn't be an issue. If it exports to ASE, it's comprised of triangles.

Nope that's not it. The DR export script converts all geometry to triangles. It never occurred to me to try exporting and then importing entirely within DR. I've always tested this in conjunction with Blender. At any rate I've experienced the same problem. However, it does give a clue in the console. PICO_ERROR: No ASE material exists with id 1 PICO_ERROR: No ASE material exists with id 1 PICO_ERROR: Could not find material/submaterial for id 1/0 PicoModelLoader: Could not load model << models/test/test.ase Apparently DR doesn't like when material id's start at zero. So I opened the file in a text editor and changed... *MATERIAL 0 { ... to ... *MATERIAL 1 { ... and it loaded up without error but not without problems. It appears the normals are inverted and I don't see a texture applied. Oh well I'll sort the bugs out soon enough. Thanks for testing it.

How did you go about UV mapping? It looks like each face is it's own island. Post a screen shot of the UV layout from within the UV/Image editor.

I can't speak for how the script works with any version of DarkRadiant currently in SVN. I assume most users are using the pre-compiled version hosted on the website. It's currently at 1.2.2. Anyway, I did notice a small bug with the script and I have corrected it. The link in the first page has been updated. Setting up the script is simple. ase_export.py goes in your DarkRadiant/scripts/commands folder. Once placed there it should appear as a menu item under Scripts the next time DarkRadiant is started. Then it's simply a matter of selecting the geometry you want to export, typing a filename and selecting a directory. You can verify that it worked by viewing the resulting ASE in a text editor. Here's just a small sample of what you should be seeing in the file... *3DSMAX_ASCIIEXPORT 200 *COMMENT "Dark Radiant ASCII Scene Export (*.ase) v0.0.1" *SCENE { *SCENE_FILENAME "unnamed.map" *SCENE_FIRSTFRAME 0 *SCENE_LASTFRAME 100 *SCENE_FRAMESPEED 30 *SCENE_TICKSPERFRAME 160 *SCENE_BACKGROUND_STATIC 0.0000 0.0000 0.0000 *SCENE_AMBIENT_STATIC 0.0000 0.0000 0.0000 } *MATERIAL_LIST { *MATERIAL_COUNT 1 *MATERIAL 0 { *MATERIAL_NAME "_default" *MATERIAL_CLASS "Standard" *MATERIAL_AMBIENT 0.5882 0.5882 0.5882 *MATERIAL_DIFFUSE 0.5882 0.5882 0.5882 *MATERIAL_SPECULAR 0.9000 0.9000 0.9000 *MATERIAL_SHINE 0.1000 *MATERIAL_SHINESTRENGTH 0.0000 *MATERIAL_TRANSPARENCY 0.0000 As for importing it into a modeling application, I have been working on an import script for Blender 2.5. The discussion thread for that is here. @_Atti_: If you're blending between two materials you use greyscale values. Black represents one texture. White represents the other. Values in between represent a mixture of both textures. Color tinting is also possible in which case you can use any color you like. The texture applied to the model will be tinted based on the vertex colors in game. I'm not sure how surfacetypes and sounds are handled on vertex blended surfaces. A member of the mod team will need to comment on that. I don't think OBJ format supports vertex colors. I can't find any documentation suggesting it does. At any rate, you can't use OBJ format in the Doom 3 engine. Only ASE and LWO can be used for static meshes.

You could always use props to keep zombies at bay. I just tried holding a board between myself and a zombie and it worked. He couldn't reach me. It probably works with hammers too. Think outside the box man.

You could try the ASE export script I made on those nails. http://forums.thedarkmod.com/topic/10906-ase-export-script-wip

Organic shapes are pretty much all you'll be able to do with it. You could make rectangular shapes if you were very patient but it's not really practical. That sort of thing could be done much easier in a traditional polygon modeling application.

I just recently purchased an ASUS Xonar DX (not a fan of Creative Labs) under the impression that it supported EAX 5.0 via software emulation in the driver and was looking forward to trying this out. Unfortunately it's EAX support is spotty. It seems to work so long as the EAX version supported is 1.0, 2.0 or 5.0. Unfortunately Doom 3 uses 4.0. It also might have something to do with OpenAL but I'm still trying to figure it out. It's a shame the game doesn't fall back to supported extensions the way a video card would. Otherwise I'm happy with the card. Sound quality is much improved over the onboard sound I was using. OpenAL does have an EFX extension that could be used instead of EAX. Better yet it's not Creative specific so it should work for everyone.

Are you talking about the warp effect or reflections?

It's also possible to add a description to each material. This field could be populated with tags and the editor could be made to search or filter the list based on those tags.

SVG logo is here.