OrbWeaver
-
Posts
8652 -
Joined
-
Last visited
-
Days Won
69
Posts posted by OrbWeaver
-
-
I'll see if I can take a look at it, there is an ASE importer for Blender (which I haven't tried yet, but feedback is positive).
-
OK, I think that's a problem with the mesh smoothing. This would need to be checked in a modelling app, and vertices unwelded if necessary.
-
I don't think so. I've switched all the textures to ones that I know work fine, and I still get strange lighting effects, as if parts of the gate were being hit with tons more light than others. When I zoom in I can also see some odd streaky distortion where the white meets the grey
Do you mean you have switched textures to one with low or no specular, and still see the effect? Have you tried disabling specular with r_skipSpecular?
-
OK, things to watch out for:
1) The Blender LWO import does not support UVs for some reason. There is a LWO script which imports UVs which I cannot currently find on Google, hopefully it is somewhere on my hard drive however.
2) When it comes to export, using ASE is better than LWO from Blender due to limitations on the length of material names (which have to specify the complete name of the Doom 3 material).
Provided I can dig up the LWO import script it should be relatively easy to do what you need.
EDIT: This seems to be the LWO import script: http://uaraus.altervista.org/index.php?fil...O_importer.html
-
There seems to be some confusion here between the disk space and the video ram issues. These are not the same. Supplying TGA textures will have a definite impact on disk space, but it will not impact memory because Doom 3 compresses the TGA images dynamically if the requisite cvars are set.
I don't see why we couldn't use TGA images in the master development repository, and then perhaps strip them out and go to exclusively DDS versions when the non-hires version of the mod is due for release.
-
Well, that's a diffusemap, just not a very good one. I tried switching to a different diffuse, and commented out the normalmap, and the problem still occurs. It's not the specular, since that's just a grey square. I'm confused.
It is the specular, try "r_skipSpecular 1" and watch the strange lighting revert to a simple black mesh. Essentially you are seeing a physically-invalid effect because the diffusemap says "reflects no light" but the midgrey specular map says "reflects quite a lot of light".
The textures for all static meshes go in that directory.That's very strange - it implies that the texture for an architectural mesh is a type of "prop".
-
Could you be a little more specific as to what you are attempting? Blender should be able to process both LWO and ASE but I'd need to know exactly what you are trying to do in order to give any advice.
-
I wonder if its possible to specify a DDS file directly as part of a map stage in a texture, rather than using a dummy TGA path which is replicated with a DDS in the dds/ folder.
-
I have to say I am extremely concerned about the use of DDS for original textures. While I understand the reasoning as regards the size of the download, and agree with it in principle, the fact remains that exclusively using DDS textures is just something Doom 3 was not designed to support.
I think as we go forward we may find that the amount of hackery required to get the game to work properly, when the original TGA images that Doom 3 expects simply aren't there, becomes more trouble in terms of maintenance than its size advantage justifies.
-
The reason is that it doesn't have a diffusemap.
models/darkmod/props/textures/irongate_d.tga is completely black.
As an aside, is it intended for model skin images to be in models/darkmod/props/textures, even if the model itself is in architecture? If so this is pretty confusing.
-
Looks suspiciously like the compressed normalmap problem.
-
Since we have a method of changing the additive stage based on the light, why do we need to change the model?
-
Yes, you would have something like
{ colored blend add map path/to/additive_texture.tga }This means that the additive texture will be multiplied by the entity colour (i.e. the colour of the light specified by "_color") before being added.
-
Edit: I'm changing the combined light level, and the only effect I see is normal light hitting the object making it brighter or not. So I'm guessing you guys are talking about something a tad more complex.
You would certainly see no effect without the "colored" stage, otherwise the material will not know how to respond to the light colour changes.
-
As a first order guess I would say that combine means "take the first object selected, add all of the keys from the second object (keeping the classname of the first), and delete the second object".
It would be interesting to view the result when combining a light with a func_static made from a patch, rather than a model, although in this case it would appear that the desired effect could be achieved merely by adding the aformentioned "colored" stage to the texture of the light's model.
-
Indeed, very nice. Now there's just the small task of modelling the thing.
-
I looked on D3W and it seems that you do this simply by selecting the light and a func_static with the texture, and Combine them together in the editor. I could not find any detail on what texture stage code was required to make this work, I suspect it involves multiplying the Add stage by a certain shaderparm. Hopefully it should be possible to find out by looking at the D3 materials.
I would also like to know what "Combine" means at the map level because presently DarkRadiant has no option for this.
-
There is a way you can bind a light and a textured entity together such that the brightness of the light affects the brightness of the texture. This is used in Doom 3 for the "trim" lights that are made from textures but need to switch on and off along with the light source.
I have never done this myself but there should be some info on Doom3World.
-
Ok, I have downloaded and compiled Darkradiant (from "trunk") and I had a quick overview over the source files. I played around a bit with the editor (even managed to crash it once, when I tried to stretch a texture to zero value, I think) and clicked through most of the menus. Where would it best to go from here? What are you currently working on and where could I possibly help?
Did you compile on Windows or Linux? I'm very pleased if it's Windows because it took a long time to get the build script working and it hasn't been tested on any other machine except mine.
Do you prefer working on front-end GUI or back-end systems coding? I can certainly give you some ideas of things I want to do but I haven't really looked into many of them yet so there would be a lot of investigation needed on your part.
I'm over halfway through the C++ Tutorial you linked, much of it seemed quite familiar to me (as I read a Turbo C book over ten years ago), but some parts were of course new to me (mostly the class inheritance part). Could use a bit more practice though
. I've quite some experience with classes from PHP, but those are much less sophisticated in comparison to the ones from C++ it seems. But it should not be too hard to get used to, I believe.C++ is not difficult, but it is very unforgiving at times. You really need to understand the differences between (say) pointers, references and objects, the difference between virtual and non-virtual functions, local objects versus heap-allocated objects and so on. Still, the basic ideas should be familiar so for a reasonably experienced programmer it is just a question of learning the details.
-
@Orbweaver: When you look at textures/darkmod/wood/wall/boards_new_001, does it load the normalmap? If so, can you also look at vanilla D3 textures? And if so, what do you have image_useNormalCompression set to?
With useNormalCompression = 2 it works fine. With useNormalCompression = 1 I get the incorrect lighting. I am beginning to suspect that my random guess was correct, in that Doom 3 needs the original TGA if the normal compression method set in the engine is different from the provided DDS.
-
Actually, the problem seems to be that when image_useNormalCompression's set to 2, he can read RxGB normalmaps, but NOT other DDS normalmaps. When it's set to 1, he can read other DDS normalmaps but not RxGB. I have that set to 2, and I can read both RxGB and other DDS normalmaps. (if I set it to 1, I can only read other DDS normalmaps, same as him) ...so why is it that his installation can read RxGB and other DDS files, but not at the same time?
To be honest that behaviour is what I would expect, if a particular compression method is set then only that format would work. The mystery is why it seems to work on your machine. Are you absolutely sure that it is working as you describe, and you haven't overlooked some detail?
Random guess time: if Doom 3 is set to use RxGB and it finds a non-RxGB DDS normal map but NO tga, it will probably break, since it is unlikely to recompress an existing DDS in a different format. Maybe you have the original TGAs which Doom 3 can use in this situation, but Dave doesn't?
-
I don't think it's card related as I have seen the effect before (on my own custom textures), although I can't reproduce it right now.
Might be a driver issue I suppose.
-
Do you mean stop loading them completely, or display them with the incorrect lighting?
If I was forced to guess at the incorrect lighting, without knowing much about what is going on I might conclude that it had something to do with the RxGB format not being correctly decoded, perhaps with the result that a certain component of the normal vector was set to 0. I don't understand how this would vary between machines if the DDS files are the same, and it certainly shouldn't happen on vanilla textures.
I just tried both torchtest.map and warehouse.map with it set to 2 and textures displayed fine (all vanilla D3 as far as I can tell).
-
My card is an nVidia card, but it supports RxGB just fine.
Oh, we were talking about the card. I though SneaksieDave was referring to lack of support in the nVidia tools.
The card does not directly support the format, it is unswizzled by the Doom 3 shader. I think this is the case whether an ATI or nVidia card is used.
Problems With Iron Gate And Fence
in Art Assets
Posted
Look at the spiral - there's some quite obvious incorrect Gouraud-shading going on there.