Jump to content
The Dark Mod Forums

OrbWeaver

Active Developer
  • Posts

    8726
  • Joined

  • Last visited

  • Days Won

    81

Posts posted by OrbWeaver

  1. 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.

  2. 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.

  3. 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.

  4. @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.

  5. 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?

  6. 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).

  7. 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.

  8. Whoa! Okay, hm. Guess that settles that...? Would id put in proprietary texture compression support? :blink:

     

    Yes, they did.

     

    Has anyone tried creating a P8-compressed DDS and using this with image_useNormalCompression = 1? It might be worth seeing if this is the 256-colour compression id refers to, as this may produce better results.

  9. That's the same behaviour I experienced, using 2 for image_useNormalCompression causes the strange light falloff.

     

    I think we need to find out what the difference between 1 and 2 is, and see if we can generate textures that use this "256-colour compression". Maybe they mean P8?

  10. I'm fairly sure Doom 3 reads the texture names from the post-BSP processed map, not the original .map. This is because is needs the texture info per-triangle (in the .proc) not per-brush (in the .map).

     

    I'll check how these textures look on my rig when I get home.

  11. The monster clip is especially important, this should be used everywhere it can. Basically anywhere a monster cannot go can be sectioned off by adding a brush textured with the appropriate clip texture to remove the geometry from the AAS.

     

    This includes, for example, putting a clip "wall" over a mesh or patch fence which the AI cannot get past.

  12. I never really understood collision models, in my view you should just be able to create a model in your 3D app along with the actual mesh, and use it as the collision model - however when I made a mover I had to muck around with drawing brushes and exporting or something like that before the mover would respond properly.

  13. I can pick some simple locks, but normal "front door" types have stumped me. I can pick the lock on my desk at work, a few cabinets in the office, a couple simple locks I have at home, etc. I have some other locks I've never gotten, and I've never gotten the lock on our apartment door yet.

     

    Lever locks are exceedingly difficult to pick, which is why (at least in the UK) having a 5-lever lock is a prerequisite for home insurance.

  14. This weekend I will have the time to dig into the whole thing - do you have any directions for me?

     

    You will need to get set up with Scons (which requires Python or ActivePython on Windows) and the GCC toolchain (available as MinGW on Windows). If you are on Linux you will need to get these tools from your distro. These will allow you to build DarkRadiant.

     

    If you want to develop you will need to know C++, there is a thread in the public forum with people's suggestions for learning resources. I found http://cma.zdnet.com/book/c++/ to be quite helpful.

  15. Sorry, no experience in that area... do you consider it to be hard to learn (GTK)?

     

    GTK itself is not hard although it can be quite mucky with its C API, but using it to generate a usable (rather than merely functional) GUI can be more challenging for the inexperienced.

     

    The DarkRadiant code is available under the GPL anyway, so if you are interested in helping feel free to download and look through the code. It is available by Subversion at https://svn.sourceforge.net/svnroot/darkradiant and requires GCC and Scons to build.

×
×
  • Create New...