Search the Community

would it be a problem if i had darkradiant befor i installed doom3 i had forgoten to reinstal doom 3 first but i instaled later and thats when i had the not found problem. edit: i uninstaled and reinstaled it still has same problem. but some worked before and still do but only like 1 hell texture shows up in darkradient oh well ill live

If there is confusion, perhaps we don't need the numeric entry fields at all? Provided the good realtime texture manipulation tools are available (which it sounds like they are), I suspect mappers are not likely to care about entering floating-point values exactly. As I recall, T3Ed just provided manipulation buttons, rather than trying to display the alignment numerically.

Hey, I just report 'em; don't shoot the messenger. So, they must be displayed this way, because of the matrix reason above? I guess it would matter if they were using math to determine what their texture alignments should be. Aside from that, the only thing that really strikes me as weird is that they both affect the vert value, instead of one doing that, and the other doing horiz. If it is the same value after running through some calculation, then running the calculation backwards would give the value for display. *shrug* I guess ultimately, who cares.

Hi, I've been following the Dark Mod since it first went into production. I've always wanted to help but I never had a computer that could sufficiently fun Doom3. Recently I got such a computer and my interest in the mod was renewed by a post on www.planetdoom.com. I'd very much like to help out by doing what I'm best at, which is mapping. However I'm aware that you guys probably get a lot of offers from under-par and new mappers who's map quality isn't very good, so I'd like to make an "audition map" if you will, to demonstrate what I am capable of bringing to your team. Because I have only recently gotten a good computer I have only dabbled with mapping of older games [halflife 1, theif series, UT] and since I had to sell my older computer to buy this new one, I have no reference images to display. My first question is: Is it necessary to have the dark mod installed? On your mod's wiki page there is no link to the download, instead it says "[insert link here]" and my second question, what are the texture and poly limits? My computer has the following specs: 1.87 ghz core 2 duo, x1950 256 pro, 1 gig of ram, and I would like to make a map which ran sufficiently on that. However I know not all people have such a good system. So is there limits of the resolution of textures or the source of textures? I would like to use 1024x1024 if possible because I know that is what the Doom3 engine can handle. Thanks I look forward to your replies.

Well, does it really matter which values are actually displayed in the inspector as long as the resulting texture is ok? I can think of at least a hundred times where I just kept clicking on the left/right up/down buttons till the result was looking ok (with the old surface inspector, that is). Trial and error usually is faster in a lot of the cases instead of thinking about what those values actually mean. And a horizontal scale is geometrically the same as a vertical flip and a subsequent rotation by pi.

Yup! That's why I've been very keen on using them...sure, you lose a bit of quality...and there are a few cards that won't like them, but overall you're winning on both ends. Then there are the mip maps. With a 1024 x 1024 TGA, that texture is going to be the same size...from any distance, with DDS...depending on how far away you are from it...it will scale from 1024 x 1024 all the way down to 1 x 1, since dds files store all the varying sizes in the file. So, that 1.3 megs of a dds file is not really the 1024 image...it's all the smaller versions of it too. DDS gives you BANG for your BUCK.

Looking into a command for doom 3 called image_writeprecompressedtextures. Not sure how the heck it works really, I guess you just set it to 1 and open a map textured completely with TGA's in a setting that only uses DDS, low for example, and I think the game will write them up automatically and store them for later use. I think. Compressonator isn't so bad really. Just do all your TGA work in photoshop, and then when you're finished working on a texture set..do a batch process on your normals.

So let's summarize, to make sure all points are considered at the same time. DDS Pro: -one format -less space -high res -can still have separate repository for TGA -Mip Maps (depending on how far away you are from the texture, it scales to smaller resolutions, based on distance) -unlike RLE compressed TGA's, DDS files do not expand at load time. A 1.3 meg DDS remains 1.3 megs. Con: -lack of DR support (currently) -lack of support on older cards -some difficulty handling the files (e.g., can't simply open in photoshop) TGA Pro: -ease of use -already supported in DR -works on all video cards Con: -messy repository of patchwork files (sizes, some DDR, some TGA, etc) -more space -lower res (or even more space) -RLE compressed TGA's are not supported natively by video cards, must be expanded at load time. Anything else to consider? ----- My biggest gripe with DDS right now is the need for this damn compressonator thing, yet another program I don't want on my system, and the difficulty in use, as compared to simply opening a TGA in PS6. DarkRadiant support is also vital. The space savings would be more than welcome though. Textures (geometry and characters) are currently more than a gig of space, which is obscene, considering how little we actually have. -EDITED New Horizon added a few exta Pros for DDS...Mip Maps and 'non-expansion at load time'

Well it should only affect the load performance, not the rendering performance, since once the texture is sent the graphics card it doesn't matter how it was stored on disk. However I tend to agree that using RxGB would be the better option for now, since everybody (I think) has a DX9-compatible card and the hi-res repositor will still be available for those who want it. Also, for final distribution it would be trivial to create two archives -- one with the TGAs and one without, so people could choose according to their bandwidth needs and desired quality.

It depends very much on the texture. Smooth normal maps at sharp lighting angles can look very poor with DXT compression (above is uncompressed, below is DXT5): Obviously the motivation at ID was to maximise image quality, which was reasonable since the game was released on a DVD and not constrained by network bandwidth.

He's the least realistic character of the bunch & he's . . . um . . . weird . . . Nothing a texture makeover can't fix . . . I hope animations (pathetic): idle, walk, run EDIT: Not on cvs yet (connection time out)

I really don't think the results of doing a standard DXT on a texture are that bad. John P's higher res textures in T3 look just fine. I just don't really buy into their need to do this.

This is interesting. I just found out that the compressonator texture I tested with today (linked above) doesn't give me normalmaps in DarkRadiant. Is there a setting in DR to tell it to use the image compression of this type? I get flat walls in 0.8.1, and the creeping shadow of doom and 'shader not found' in latest snapshot. Say the word if we need a defect entry. I'm getting so confused with everything this way and that that I'm wanting to just go to bed.

Since ATI is no longer supporting that particular compression technique, I wonder if they would be willing to spill the beans on it? Edit: Would this be of any use? Looks like it's the source code for their texture compression program. http://ati.amd.com/developer/compress.html

Originals were always meant to be uploaded to the darkmod_hi-res repository. Maximum 1024 x 1024. Then we had the downscaled TGA's in the Mod repository. Max 512 x 512 But DDS files in the Mod repository can be stored at full res 1024 x 1024 at half the file size. I'm going to revise the sticky to make things more clear. @Orb There are several motivations really. 1. to reduce mod bloat. 2. to eliminate this texture redundancy, when dds is perfectly capable of giving us high quality graphics. 3. Improve performance. You definitely notice a performance gain when 4 meg TGA's are replaced with DDS textures of less than half that file size (1.3 megs for a 1024x1024). Right now, our mod TGA's are low res, compared to what they could be. Of course, not all textures need to be 1024...but it's nice to have the option...without the performance impact...and having to download them from CVS. Since Gil is taking a step back from things, I can fill in and coordinate what needs to be done.

Okay, that image works for me. Whether that means all of them will, or those with alphas will, I don't know. Looks like it's about half size of the original TGA. I can't open it in photoshop6 though... that sucks. So the way I see it at this point: 1. Who else has/had compressed normalmap texture probs? They must try this file and let us know! 2. If we swap to full DDS usage for TDM's default repository, then having TGAs for those who can't use them is something we don't really need to lose sleep over . They can be batch-generated periodically, or at the end. People who have no problem with DDS at all never have to touch or even see them. 3. More opinions are needed - this affects everyone, so we should get a pretty clear consensus; it's a big deal. If all of a sudden we find, "oh shit, um, guys? I can't see anything!" that's a big mess to clean up. 4. Or, to be really safe, we could just leave it alone. (hehe, *dodges rock thrown by NH*) If no one on the team is having any issues, a full DDS switch is probably a good thing to do (although that PS6.0 thing really sucks...). At the end, should people need them, TGAs could be generated easily.

What? I'm not talking about the hi-res repository, I'm talking about our mod repository and storing TGA and DDS versions of every single texture within the mod. I guess I should have phrased it more clearly. I meant it's silly to be storing both TGA and DDS in the same mod repository. The hi-res repository is a different matter completely and will remain. Counting the hi-res repository, we're actually keeping 3 versions of the textures. Hi-res, a medium set of TGA's and DDS. It's a bit much. Given what we've seen with the quality we would be able to keep with hi-res DDS files, it's really quite redundant to bo be keeping middle of the road TGA files and the hi-res. The middle road should go. DDS for the main release and TGA for the ultra hi-res upgrade at a later date.

Ah, you are right. I was thinking that the TextureMap stores CShaders, but as you say it only stores the Texture objects.

This should not happen, because the checkBindings() just checks the TexturePtr's uniqueness and not the ShaderPtr's (CShader). The checkBindings() is called in the CShader::~CShader destructor and is supposed to remove unused Textures from OpenGL. If the GLTextureManager finds anything unused, it destroys the Texture object, not the Shaders, therefore it should not be fired recursively. Does this actually happen or is this a general question?

Why? I thought the purpose was that we have a high-res repository, that people can use if they want to, and we release with the DDS scaled down textures? Also, wouldn't texture artists create a TGA version anyway? Or do they create DDS directly? I thought that DDS can be created only with a converter.

Just give the light texture lights/ambientlightnfo and you'll get what you want. You can extend its dimensions so it covers entire map or give diffrent ambient lights in diffrent parts of the map.

I was curious and re-enabled the compilation of this ominous TexTool (which was disabled compiler directives) and surprisingly it compiled without complaints. This is what I found: Pretty damn cool, if you ask me. It basically visualises the location of the selected brush face in texture space and allows you to manipulate the thing with mouse clicks (translation/rotation). The behaviour is similar to the UV mapper in blender, but without vertex drag manipulation. And it only works for single brush faces. Judging from the comments in the code, it most probably has some major flaws (being the reason why it was disabled in the first place), but I feel an urge to get that tool working! I put up a new snapshot for this tool so that SneaksieDave can have a look at it too: http://208.49.149.118/TheDarkMod/download/...8.x.rev1004.zip

Oh, I see. I think. No, if you want to actually curve it you will need to use mesh geometry. You could partially fake it using normal maps in certain situations but that might get complicated. Leaves are typically done with alpha maps. You have 1 poly (2 tris) for each leaf, but some texels (texture pixels) are not drawn. If I'm understanding you correctly this won't work for you here.

Yeah, I just checked the texture & it has no alpha so it's in the shader: models/weapons/waterarrow/waterarrow_tip { glass //twoSided noSelfShadow forceShadows deform turbulent sinTable 0.0175 (time*0.5) 10 { //vertexProgram heatHazeWithMask.vfp vertexProgram heatHaze.vfp vertexParm 0 time * 0.3 , time * 0.5 vertexParm 1 1.5 //fragmentProgram heatHazeWithMask.vfp fragmentProgram heatHaze.vfp fragmentMap 0 _currentRender fragmentMap 1 textures/sfx/vp1.tga fragmentMap 2 textures/water_source/vp_water.tga } { blend filter map models/weapons/waterarrow/waterarrow_tip.tga zeroClamp } }I just copied that from one of the water shaders. The rest of the water arrow (& other arrow) textures do have an alpha channel so you can see through parts of the arrow head.

Im probably confusing my terms somewhere, what I want is for the "panels" of hedgerow texture or material to be curved, so I can shape my hedge. But I don't want to use polys, I'm just drawing pixels here, at least I think I am. So can I bend the section of pixels that makes the image, without applying it to a polygon surface? The image of the hedge section I posted, can that , as a pixel map, be curved or warped or something or is it always going to appear as a flat plane? This game ThinkTanks I bought recently, lots of fun, has these toony little trees, but the leaves are pixel maps I think and they are gently curving palm type leaves. If I can do something similar, it will make things look a lot more organic.