Search the Community

Well basically, having worked in companies before, I'm naturally mindful about saying anything about the project - because you're essentially speaking on behalf of the team, which you may not be in a best position to do. To be on the safe side, I don't consider myself that way at all, and leave it to NewHorizon. Never had a need to speak publically on the forums about it. Only to people I know personally. It shouldn't be too hard to realise you're speaking publically and use the "-like" and "inspired" suffixes.

That's right, a freak accident. No he wasn't poking it, just swimming near it. You see people on TV caressing the things, having schools of them swim around them and brush over them, and all sorts of stuff. The only explanation they have is maybe with both he and the cameraman around the stingray, it felt threatened, and lashed out randomly. Making him only the 4th person to die by a stingray in the last 60 years.

I'm experiencing some issues while creating readable entities with DarkRadiant. The problem is: when I create an entity out of my two brushes (the parchment and the entitygui) the "origin" key is not created by DarkRadiant. DoomEdit however does create the key (its value should be at the geometric center of the two brushes). As a result, I'm unable to read the parchment, it never appears on the screen after frobbing (the screen fades out and in very quickly, as it is supposed to do). I suspect that the missing origin value is assumed to be "0 0 0" and the readable appears somewhere out of my field of view. As a consequence the readable_face_tolerance value is kicking me out of reading mode. This problem only seems to occur when creating entities out of brushes, as lights and other entities that can be created without a brush selected (I tested with atdm:loot_vase) get their origin value set correctly. I'm using the latest compile from SVN (but the problem appears in version 0.5.3 as well). Perhaps this is a known issue, but I thought I'd post it here. I can post the differences of the two map files (from DarkRadiant and DoomEdit), if it is helpful.

I don't think that any laywers are lurking here right now (well I probably wouldn't know it if he is smart). But in worst case it might happen that the forums have to be opened for them, so you shouldn't assume that this is a safe haven where you can say whatever you want. If the intentions of the mod have to be proven in court, a judge might easily order that the forum has to be made accessible.

Obscurus, I had a collegue in one company who also was an ehtuisast for bikes, and the picture you draw here, is pretty much the same that I learned from him as well. So even though his is enthusiastic about it, he still managed to give me the fear of the price tags and I must say I believed him. He also told me, that he drove without leather often in the beginning, but then he had an accident, where he had it on, and he said, from that day on he would never go without it. If he hadn't had it strapped on that day, he would have a lot of injuries, so I wouldn't really go without it, but that's also quite an expensive part.

I think the reason why some people (including me) are so fussy about it, is that if we're not it might get used on the public forums (ours and others) and that might be trouble.

The Thief Universe is the single point of reference we are all familiar with, so it's only natural to refer to it in conversation. If you can imagine it there, you can imagine it in a Dark Mod universe. I used it to help try to drive my point home, since it wouldn't have the same impact or meaning if I said, "Imagine this hammer/gear in The Dark Mod!" Oh, forget it, why am I bothering. For any lawyers that may lurk in our internal forums and who may potentially whistle-blow us, I would like to take the time to clarify that any mention of "Thief Universe" is meant to be "Thief-like Universe." The Dark Mod aims to be a dark and moody stealth game inspired by the Thief series by Looking Glass Studios. It is not Thief and will not be Thief.

You guys seen these for inspiration? http://www.ttlg.com/forums/showthread.php?t=108516

Ah, didn't know that. So I guess anything that could be used as a brush texture would also need to have the entire pathname in the material. With the models that just got extremely frustrating, since the material name would be something like "models/props/darkmod/pot" but the textures were actually in "models/darkmod/props/textures" and the model was in "models/darkmod/props/kitchen". Too much room for confusion and error.

They do have a specific function (or nonspecific depending on your point of view). They can be used for meshes or walls which can't be said for the rest of tdm's textures, with a few exceptions. Sorry guys, but I'm going to rant . . . [rant] There's other reasons for pushing this idea though. A lot of people working on this mod do not have the skills to have a clean uvw map & this kind of urks me When I started looking at the textures for the models, I was astonished on how messy the textures looked, especially the characters. Another reason is I can't apply another skin to a model because the texture is model specific & if I don't like the look, I'd have to figure out how that modeler mapped the mesh & create a new texture and skin. With this idea, all I have to do is apply another gen* skin to it. The problem with a community mod is the skill levels of each person vary so the quality of the work varies. Some people submit textures that don't tile and others submit broken models. This causes grief down the road because someone has to take the time to fix these things which delays more important tasks. I can't imagine how much further this mod would be if things were close to being right the first time. For example, the character models are being redone so we can have facial expressions. This should have been brought to the table in the first place. Another thing that urks me are decisions that could have been made on certain features are not in the mod yet because people disagreed about it. UI design and the back story are a couple of those "features" that's been delayed due to disagreements. Either vote on it or just implement one of them until a concensus has been made.That's why most forums have voting features & I wonder why voting isn't utilized more often in this mod. I went against the design documents for the noisemaker because I didn't look that the design documents (I should have). But when I presented the new noisemaker design, the mod team liked it. That's one example of implementing something, without all the discussion/voting, that actually worked. It definately doesn't work all the time but it's something to keep in mind. *Good grief I have to stop complaining here, but here goes . . .* The Dark Mod is held in high esteem & high quality is expected by this mod. When those expectations are not met, people can be total asswipes: Sure were not going to please everyone but when any "pros" take a look behind the scenes, then we'll definately hear about it. I'm not saying GBM is a pro btw In short, I think we should be more consistant with voting proceedures because a lot of discussions so far have been counterproductive. Either that or just implement the damn thing. Don't get me wrong on community projects (or this one for that matter), I love them, but these problems rub me the wrong way. Sorry to keep being a thorn in the members' sides. [/rant]

Hey Arumakani, Unreal ED is completely different from Doom3ED, one is additive and the other is subtractive - Unreal editing consists of carving out the level with the brush tool, while Doom 3 consists of adding brushes like walls etc. This means that a veteran of Unreal ED will have a hard time adjusting at first etc. Just trying to warn you so you don't spend too much time on Unreal ED if you were planning to map for TDM.

These textures could be either model or brush textures which was the point of bringing this subject up. I might convert some of the models to use this too (i.e. the water pump).

Right now our model textures are in a different place than our brush textures. If we do this I would think they should go wherever they are most appropriate as a brush texture, and then model materials can just reference them as needed.

You can copy a brush face texture onto other brush faces by Ctrl-Shift-MMB (you have to copy the face texture beforehand). Or did you mean something different? What I really miss is D3Ed's feature for copying brush face textures onto a patch (the MMB feature in D3Ed). I could not find any function like this in DarkRadiant, which is my main reason for switching between D3Ed and DarkRadiant at the moment. But I could imagine, that this would be a feature hard to implement.

I just wanted to add another wish of mine; better texturing capabilities. D3ed's texturing drives me nuts. For example, if you scale a texture, it scales it around the world origin, which is usually very inconvenient. It'd be very useful if you could choose where the centerpoint to scale around was. Also the align to top/bottom/left/right features from Hammer are sorely missed by me. Another thing that I can't seem to find is the ability to project one brush face onto another. (except that you can project a brush face onto a patchmesh) And finally, some kind of "wrap" feature would be nice. Something like, select the face you want to texture, then ctrl/alt/whatever+middle-click another face, and your selected face will be textured so that the two faces share the same texturing along the intersection of their planes) Also, a rotate to line up with edge feature would be great for texturing beams that are diagonal on all 3 axiis.

For stuff like that I'd say just do a search on doom3world forums Bob. They've basically got a two year archive of exactly that kind of stuff.

Fair enough crispy. Basically Oddity sent me a PM calling me names and saying that the team members forums were slagging me off. I PM people when I want to know something usually game related, but sometimes I'm interested in the person. This seems to have annoyed some people. They should say that they are busy or prefer not to have PM's. Then it would be finished. However having a bitch in a forum where the person being bitched about can't defend themselves is below the belt. SO being a bit annoyed I decide to call Oddity some names in reply to his rude PM and am willing to call anyone else names too in defence.

Well the forums are dead anyway so who the fuck cares, you half arse. The reason why more people from TTLG don't come here or you guys don't get any help is because a few of you are so up your own arses. You're decent at what you've done, Oddity, but no way near as good as you think you are. D*ckHead

Way back, yeah, but it's changed. I've got a couple new ones, if you want replacements for the site (see internal forums).

Forgot to add the banner, @148 polys. For completeness: Edit: Also, http://forums.thedarkmod.com/index.php?s=&am...ost&p=84195

Well, as an individual, an observer and frequenter to the forums not in anyway associated with the team, it's sad that there are so many simple minded people out there. It's most often not even the issue at hand that gets them in a tizzy. They just enjoy vehemently playing opposition simply because they know it will drive you crazy. I'm actually glad to see he is a free spirit. It kind of fits the personality I've seen him as portrayed on the forums. I wish him luck in the future and hope he can continue pushing forward.

Yes, oDDity is no longer actively making models for us as an official Team Member. He has moved on to some other projects so he can continue to push himself in new directions, as an artist of his skill should. His membership is still active however as he may contribute a model here and there in the future and he left us with his character templates so that all of our future models will still fit with the rest of the characters. As for 'individual opinion' not speaking for the team, that has always been in place. It's far too easy for someone in the community to say, "I HATE that mod because 'such and somebody' said something sucks...so the entire team must feel that way". Unless we voted on something in our development forums, it certainly wouldn't be considered a "Team Stance". Heh...even then, it's only the opinion favored by the majority of the vote. So, you see...there is never really any hardcore team opinion and it drives me NUTS when people base a ridiculous argument on something like that.

Ok, I've been trying out a few different ways of doing specular-based windows, and each has advantages/disadvantages... The basic idea is to have at least two textures that work together: a texture that receives normal light, acting as the frame and window, and a texture that receives a second spectrum of light, acting as the light that shines through the window. Note that these experiments are for the kind of glass that the player would be nearby... I'd also make a kind of glass that's easy to place and cheap to render, but it's not covered here. Method 1: Separate frame and window textures. This method uses 3 textures all placed in the same spot. (depth-fighting isn't an issue because their brushes are the exact same size/position) A texture showing only the wood frame. A texture showing only the glass, in a normal spectrum. (so if a player shines a light at it, it shines back) A texture showing only the glass, in a special specturm. (so the mapper can control how the window is lit) This method has a couple of advantages: the glass and frame are kept separate, allowing the mapper to easily mix-and-match glass and window frames, and the transition between frame and window has an anti-aliased appearance. The disadvantage is that the window is twice as expensive to render (with regard to fill-rate) so it would be very important to keep the number of lights hitting the window very low. (the reason I don't consider it 3-times as expensive to render is because I assume the third texture will only be hit by one light) I should mention that as a convenience to mappers, I believe it would be possible to set things up so that a single material contains render passes for textures 1 and 2, allowing the mapper to only place two brushes per window, instead of 3. In an attempt to decrease fill-rate usage, I tried to resize things so that the frame and window were kept somewhat separate, with overlap only at the boundary between frame and window. Unfortunately, since the brushes were merely coplanar, rather than having the exact same size/position, z-fighting occured. Method 2: Combined frame and window textures. This method uses 2 textures placed at the same spot. (depth-fighting isn't an issue because their brushes are the exact same size/position) A texture showing the wood frame and the normal-spectrum glass. A texture showing only the glass, in a special spectrum. (so the mapper can control how the window is lit) This method has the advantage that it's not much more expensive than a normal texture, but it has a severe disadvantage: Since the normalmap for the frame and window are combined onto a single texture, they interfere with eachother in all but the first mip-map level. Thus as the player gets farther away from the window, ugly graphical glitches start showing up on the glass near the frame. Method 3: Using an alphatest frame This method is similar to Method 1, except the frame is alphatested and its brush is placed slightly in front of the glass. This allows the engine to avoid rendering the frame's lighting in places that contain only glass and vice versa; in other words, this method isn't much more expensive than a normal texture. Unfortunately the boundary between glass and frame is aliased. For thick wooden frames, the aliasing isn't noticable, but for thin wire frames it can be severe.

And here's after a bit of levels adjustment and a gaussian blur to add back in some removed sharpness (edit: duh, I mean smoothness). Decent results, I think? (compressed as JPG here of course) Compare to the first attempt: http://forums.thedarkmod.com/index.php?s=&am...ost&p=82172 Edit: as always, thanks for the guidance guys, you're a wealth of information.

I covered this a year ago in the documentation forum. http://forums.thedarkmod.com/index.php?showtopic=2341