Search the Community

You'll want to learn Normals for sure but they can always be added later in a mtr file. The collision and shadow are more critical as the model needs redone again later if not there. You should check out polycount forums for any information on modelling techniques. Our Wiki has all the basic infor but almost any modeller can learn alot from polycount. Some amazing stuff gets done there and everyone is really helpful. I am using XNormal for normal maps and AO baking right now, it seems to work really well. Normal map basics. I'm not gonna get in depth as there are tuts. Basically you need a low poly and a high poly version of your model. It's best if the low poly is fully encased within the highpoly and has bevelled edges. The high poly deffinately needs beveled edges, straight 90 degree edges don't get transfered as the normal map contains info on sides not depth. Also, each polygon on the model needs unique uv space, overlapping polys will leave black spots that get no light. Then you export the hi and low seperately and use a program like Xnormal or Doom3 to bake the hi-poly details onto your low poly map (the high poly model doesn't need UV coords).

Bah, that page is just marketing hype - it's just an interview with the developer, not actual performance tests. You need an independant 3rd party for a reliable source. I made a post on how XP runs games faster than Vista, but decided it should be a new thread. http://forums.thedarkmod.com/index.php?showtopic=8089 The bottom line is - the numbers are out, and XP runs games faster than vista, and they look identical in terms of image quality, even the DX10 ones.

The "rippling" happens because the patch is internally subdivided into a series of triangles for rendering, each of which only has three texture coordinates which means the texture cannot "bend" within the space of a single triangle. You could improve the smoothness of the distortion by adding more triangles, but this would obviously have a performance impact.

I'm sorry? What exactly do you mean? The patch itself is distorted, so the texture will be distorted as well. Or did you mean something different?

Hey, Jerboa, welcome to our forums! We can always use more of such models, "everyday stuff" is good for the mission toolset. I suggest you drop a PM to New Horizon to apply for Model Contributor status. We can create an applicant thread for you, where we review your stuff and introduce you to how to get your model in-game. Have you a copy of Doom 3 around? The process of getting models in-game is not hard at all, but it may take some non-obvious steps.

Fair enough. If only there was a more intuitive inteface than triple-modifier-clicks -- perhaps I can stick in a dialog or something at some stage (the best solution is probably Blender's little pop-up menus, but those don't exist in GTK as far as I can tell and would probably be more confusing as they are a non-standard idiom). I think we should soon be ready for a 0.8.0, we have some fairly important new features (fixed patch texturing, light inspector, projected light support, draggable light centres, entity chooser hierarchy based on key in DEF file). I have recently started on the generic skin selection dialog, but this could conceivably wait until 0.9.0 (along with at least one of the new Dark-Mod specific editors) depending on how long it takes.

Continuing from this idea: http://forums.thedarkmod.com/index.php?s=&am...st&p=155603 Hmm, it strikes me that this might also be a very easy way to add variety to large groups of AI. It would be extremely easy to have a "tall" "medium" and "short version" of just about every AI we have. In fact, rather than every character needing animations exported separately, why not establish a series of default sizes for AI? We could have something like: Very Tall (6' 3") Tall ( 6') Average (5' 9") Short (5" 6") Instead of having unique md5anim files for each AI, we just make one animation set for each of those heights, and then create separate AI defs that point to each one. That means we could have, for example, 4 different heights of the same townsfolk model without any extra work. It might not always be appropriate for every AI (a Short elite guard would look weird, as would a Very Tall forger), but it gives a lot of extra variety (and saves a lot of exporting and nearly duplicate md5anims). The only downside I can think of is that you wouldn't be able to have a 5'11" or a 6'2" character--but since character heads are all slightly different sizes, I really don't think anyone would notice that AI come in only 4 different heights. Squill, any reason you can think of why that wouldn't work?

Was just browsing through the BCG forums, and stumbled upon this: Thank god.

Okay, I'm done adding a few points. I eventually got stuck on fixing the rotation, so someone with a 3d program can probably do those much faster than me. Documentation for how to do it is here: http://forums.thedarkmod.com/index.php?showtopic=8070 These have been added: Base Humanoid def file (tdm_ai_humanoid): - palm of hand (left/right) - front-right and front-left of belt - back-left and back-right of belt - back-center of belt Builder def file only: - slung across back (left to right or right to left) - stacked across back (left to right or right to left). This is offset one unit farther back so that two weapons may be worn crosswise across the back without obvious clipping) TODO: We can move this to the humanoid base def file, so that other AI can optionally sling swords across the back, but I wasn't sure if all humanoids have Spine2 joint, or is it just the Builder? - Sword at hip (WIP) (I know the builder won't have swords, but wasn't sure if the citywatch mesh was up to date or not). I think the position is okay, but I couldn't get the rotation right by hand. Need a 3d program to generate Euler angles or something.

There is more to come: at the moment, I'm trying to handle such a sitation (note the distorted texturing of some patch parts): If things go well, I will be able to solve this during this day, but this will be a lot tougher than the other task!

Yeah, that's the sort of thing. You will no doubt have a much better idea than me regarding what functionality such an interface has to expose. The downside is that in order to do this you will probably have to rewrite most of the primitive-handling code, since I suspect it sucks badly. Seriously, WTF is the point of ArrayReference in patch.h? How many stupid reimplementations of std::vector do we need?

It might be worth considering whether you want to define proper interfaces for brushes/patches, for example IBrush and IPatch which go in their respective include files, which could (amongst other things) return this sort of information. At some stage I am planning to rewrite the import/export code such that the mapdoom3 plugin walks the scenegraph itself and reads/writes brush and patch data using such interfaces, rather than having brushes/patches export themselves into tokens (which breaks separation between the primitive data and the map text format).

Very, very nice, especially with such limited resources. I love that door texture, did you make that yourself? You definitely have the artistic and mapping skills necessary. The only other thing we ask of beta-mappers is enough dedication to stick it out and not disappear after a few weeks. I echo what Komag says about downloading the Thiefs Den alpha (you can use the wiki link at the top of the forums to find it). It includes a set of limited art assets, including some AI, that you could use. If you're willing to stick around for a week or two, you'll be a shoe-in for beta-mapper status.

I found two conversion functions TexMatToFakeTexCoords and FakeTexCoordsToTexMat which convert a texture matrix into what's called "fake" texture coordinates (shift, scale and rotation). I assume that the fake texture coordinates are the ones that are presented in the surface inspectors. At least I know now where to look for the actual transformations. Overall, the code organisation is a terrible mess, the classes are distributed somewhere in the brush.h / brush_primit.h / .cpp and brushmanip.cpp files. It seems to me like they were thrown into the next best place as they were created. Without Eclipse's Ctrl-H search function I would be completely lost... Maybe I will extract some of these classes into new files, if I get too sick of always having to search for the class names. edit (just saw your post): yes, the problem is indeed related to patches. I lack some basic understanding of how textures are handled in the code, so I started at the map files. As soon as I will have understood the brush code (which I will need if I want to extract texture information from the faces) I will move on to the patch texture code.

I had some exposure to this when I was updating the map writing code (really all of this stuff should be in the mapdoom3 plugin rather than having hardcoded knowledge of the mapformat in the brushes and patches themselves). I too would like to know more about the map format, in particular what sort of precision the floating points should be and whether they can accept exponential notation -- currently I am just using the default options for writing floats as text which sometimes uses an exponent, and although Doom 3 hasn't crashed yet I am not 100% certain that this is acceptable. I worked out the plane equation but never figured out what the texture coordinates were doing, so that is useful. It is unsurprising that they are expressed in U/V values rather than pixels, since (1) the brushes have no knowledge of the texture sizes involved, and (2) OpenGL deals entirely with U/V (or S/T as they are called) coordinates. I am guessing that when each brush face is rendered, the UV-coordinates sent to OpenGL for the face must be looked up by sampling the "texture plane" (as specified by the offset/scaling factors) at specific points corresponding to the bounding vertices (called the "winding"). Copying textures across coplanar brush faces might be achieved simply by ensuring that both windings were sampling the same texture plane, which in turn MIGHT involve little more than copying the values from one face to another. I haven't looked deeply at the code for this. I think a large part of the problem was related to patches -- when you originally raised this issue I think you mentioned being unable to copy a planar texture onto an adjacent deformed patch so as to create a seamless transition -- which I suspect might be considerably more complex in terms of texture coordinates.

That would probably be better. I can upload the original freeware texture image if you want which is much higher res but I scaled it down to 1024 and cut the rounded corners. There is also a nice old leather book cover if you want. It is deeply 'embossed' (not sure if that is the right word) so would look good with a nice bumpmap. There is a small collection of stuff but I think not much else useful to TDM I don't think but if curious you can get it here... http://www.ttlg.com/forums/showthread.php?...766#post1751766 I also download skybox textures but not looked at them yet.

Well, I deleted those before Saint Lucia I'm sure. I don't know how they got back. But I don't want them put back in and released. Thiefs Den already uses a chest that's outdated, I'd like to not release more outdated stuff. chest1.ase (and chest1_lid.ase) are now chest_wood.ase and chest_wood_lid.ase chest2.ase is now chest_metal.ase and chest_metal_lid.ase chest3.ase is now footlocker_wood.ase and footlocker_wood_lid.ase Like I said, uv coords, centers, grid alignment, lid/grid alignment, locks have all been updated as have the names to better reflect what they actually look like. Here's a link to the post when I did it, was before thiefs den rleease http://forums.thedarkmod.com/index.php?s=&am...st&p=138312

Just added three new colours for the light center, and the upgrade paths are growing already, so I will have to come up with something to make the upgrading a bit easier. I think this will be the next thing after the light center, but should hopefully be done this weekend. edit: Another possiblity would be to have the light center inherit the colours from the patch vertices, but somehow I would prefer that being customisable.

Yeah, this is immensely disappointing. Gothic 3 WAS on my "have to buy at full price" list, but now I'm not planning to buy it for at least 6 months, maybe longer, till I read that a massive full-game fixing patch has been released (which may never happen)

Sounds like you're set to apply to Contributor status then - just drop a PM to New Horizon and let him know that you want to contribute textures. We'll set up a thread for you where I can guide you through the texture creation process plus set up your SVN access. To summarise what has to be done for these textures you can have a look at this article: http://wiki.thedarkmod.com/index.php/...to_The_Dark_Mod For your textures, this would boil down to: Find a suitable name, according to our conventions on the wiki Create the DDS diffuse maps (and specular maps, if there exist any) Create the JPG editor image (256 pixels max.) Create a shader which contains the frob-highlighting and ambient stages Send that package to me and I'll see if anything's missing. Upload to darkmod + darkmod_hires As soon as you have contributor status, you can also upload the textures yourself once you have your SVN account readily set up. We have a startup thread in the internal forums, which will explain all the details.

Just committed the reorganised patch files. I again added tons of comments, some sure will be helpful, some maybe not I also removed Quake3 and Wolfenstein stuff from plugins/entity, as I assumed them to be unneccessary. I'm still not entirely sure where to start with the light center, but I'm (slowly) getting there...

Ah, it is used in Patch::updateFiltered() but this function itself is not called anywhere. This explains everything. I thought, the compiler would immediately stop if the actual implementation is missing. Good to know.

I don't fully understand it neither, but at least I could learn a lot about the selection system and how the manipulators are used. The next thing I will document is the file patch.cpp, as the information about how the control vertices are handled will come in handy for the light center.

I'm almost certain Dram tried a smaller version but we decided to revert back. edit: Ah, here's the thread: http://forums.thedarkmod.com/index.php?showt...;hl=arrow++size I notice that broadheads don't really sink into AI very much (usually just the tip of the arrow) so that might make them look a bit larger when they're sticking out.

I have switched S/R Editor and particle editor, added the patch texture alignment thing and ordered the tasks approximately as I think they should be prioritised. Feel free to suggest alternative priorities if there is something I have missed.