Search the Community

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.

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.

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.

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.

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.

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.

But I can't get my custom launcher to work it. I am passing the arguments dmargs_Windowed.txt and dmargs_fullScreen.txt. Just searched the forums but can't find those mentioned. Must be here somewhere. No, it's searching correctly because it just found this post! I know I didn't dream them up so where did I get them from? Did you pm me? wiki?

I checked the forums and didn't see a topic in relation to this, so I apologize if this has been already brought up. Once I used the compass it stuck on my inventory items and made my inventory unusable. I couldn't turn the compass fully off but i could cycle through two of the items in my inventory, but I wasn't able to use them. I had to go outside and pick up another item for the inventory before I could use it correctly. Also once I had it working the gold status was displayed over the inventory. I don't know if this one was my fault or what. Aside from that this is an absolutely amazing piece of coding. The world was fully beautiful and the AI was smart as hell. The water and lighting effects were brilliant. I personally didn't like not being able to jump from ladders, but that's my preference and I'm not gonna knock it because that could mean more coding. If you need more info on this let me know and I'll try to reproduce. My stats for my pc in case you need them Windows XP 1 gig ddr ram amd 3800+ 2.4 ghz radeon x1650 EDIT: I have been play testing it again to see where it messes up and I have found that this is easily clearable in game cycling through the inventory with the [ or ] keys. The problem lies in the - key to get to the inventory. So I don't know if the compass is supposed to stay up when you use the - key for the inventory but that is what is causing the problem for me. Noticed another cool thing though. I hit the fat guy with a gas arrow while he was next to the torch in the courtyard and it knocked the torch out as well. I thought that was awesome, though I am not sure if that was intended. So if I wasn't clear let me know, and if I was just being dumb and breaking the game by doing something I wasn't supposed to let me know.

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.