Jump to content
The Dark Mod Forums

OrbWeaver

Active Developer
  • Posts

    8659
  • Joined

  • Last visited

  • Days Won

    71

Posts posted by OrbWeaver

  1. Just out of curiousity, do you have any idea why ID chose RXGB? It seems like a strange way of swizzling things. Is it to give more bits to the red and green channels, since they're more important to normalmaps than the blue channel?

     

    I never really understood it. There seems to be very little information available on the format, as far as I can make out it just stores the R component in the alpha bitfields, which I guess gives more precision to the R component but doesn't affect anything else. Perhaps they considered improving the precision of a single colour channel to be better than nothing.

     

    Here is some interesting information, from http://www.techspot.com/tweaks/doom3/doom-7.shtml

     

    One thing of note on the normal map compression is that generally speaking if you DXT a normal map you get really crappy results. NVIDIA hardware supports palletized compression which yields good compression and normal maps retain hard and round edges really well. Unfortunately this compression does a poor job in other cases and you end up getting splotchy areas. ATI does not support the palletized compression so we needed a better solution. ATI had done some research on various methods of normal map compression and we ended swapping the red and alpha (which is zero in the case of a normal map) channels. This effectively allows the compression to do a much better job and is just 1 extra instruction in the fragment program to move the alpha channel into the red channel. The bottom line on what happens on each card is as follows.

     

    All modern NVIDIA and all ATI hardware use the compressed normal maps in Medium and Low qualities with the sizzled components. NV10/20 hardware (GF4MX and GF3) uses palletized normal maps in Medium and Low qualities.

     

    That is the answer to why Dave can only use one form of normal compression, and the rest of us can only use the other. They are not selectable options, they are graphics-card-specific requirements.

  2. Is the purpose of separating the TGAs from the DDSs to reduce the checkout times for developers, or to reduce the size of the final download when the mod is released?

     

    If it is the latter, it would seem to me to be preferable to put all of the images in the darkmod tree as normal, but when the final PK4s are generated, zip up the textures/ and dds/ folders separately and give the downloader the option of skipping the textures.pk4 if they want a smaller DDS-only download.

     

    SneaksieDave - I think I've figured out why you can't load the compressed normalmaps in D3. The unswizzling of RxGB compression takes place in the interaction.vfp fragment shader, which will not run on a Geforce 4.

  3. @Orbweaver: I wish I had thought of that or somebody had mentioned it earlier... at this point I don't think it warrants another texture reorg, especially since there's documentation about what each category means.

     

    There was some discussion, but unfortunately whatever you choose there will be some confusion. If you label by tiling strategy mappers will say they don't understand or care about it, if you label by usage you get confusion over what defines a wall or floor texture, and if you label by theme you limit people's choice of textures unnecessarily.

     

    In DarkRadiant there is currently no texture browser yet, so this isn't so much of an issue. I would like to find some way to allow browsing of textures but in a more image-based rather than name-based fashion - perhaps the directory tree could display all contained textures in a preview window when a given folder was clicked on.

  4. The majority of the programmers who could actually code the fades were initially pretty against it and would've liked to see the idea die a certain death.

     

    Nobody was "against" it as far as I can recall. There were some concerns that implementation would be difficult, but this turned out not to be the case and the feature was therefore swiftly implemented.

  5. I don't understand why people make such a big deal about "gender" anyway, it's just some relatively minor anatomical differences and a different chromosome (X over Y). Nobody complains if you play a character who isn't like you in other ways, like the same race or nationality, so why does their notional sex matter?

  6. I would just say something like "I appreciate your concern, but I am not having any sexual identity issues and if I ever do I will be sure to seek the help of a qualified therapist".

     

    At the end of the day it's none of their business, and unless they are themselves qualified psychologists (which it doesn't sound like they are) it's not for them to be trying to "treat" a "problem" which doesn't even exist in the first place.

  7. That was how Brian @ Id suggested doing the CMs, so he at least thinks it works. Haven't tried it personally, but I'm pretty sure BT has tried it and said it worked. I'd say see how accurate you can get with a brush, and if it's not a tight enough fit around the model, go for the modeling method.

     

    I would much rather do it with a model than a brush, if it works. Do we have documentation on how to do it this way? I can't quite see how the stuff about converting to func_clipmodel and exporting as CM would work if the clipmodel is part of the mesh.

  8. Never get LCD's if you want to see true black, so basically never get LCD's if you want to game or watch movies on your computer.

     

    Arguments over "true black" are specious. You won't see true black until you are standing at the bottom of a mineshaft with no light sources.

     

    It may be true that a CRT gives a better contrast ratio than an LCD, but what the eye perceives as "black" is entirely relative to whatever else it can see at the same time. My LCD gives perfectly acceptable blacks during gaming or movies, and it is not even a particularly decent or expensive one.

  9. meaning your LCD monitor will have to perform scaling calculations to support different resolutions, which reduces performance).

     

    By "performance", are you referrring to the blurring/response time? I don't see any way in which a hardware operation in the monitor could affect the actual game's performance.

  10. You can get better results using a pre-rendered cubemap. You need to stand in the position where the cubemap should be taken from, and type "envshot" in the console. This should write out six cubemap images which you can then apply to your material using the "cubemap" stage keyword.

     

    I have never tried doing this myself, but it was used in a lot of the original Doom 3 and Quake 4 levels where you see a reflection on a possibly non-flat object.

  11. It started "reflecting" stuff from other rooms (with brushes it between) and there was severe pixelation occasionaly. And that's only what I experienced first hand.

     

    I think the way it works is by positioning a second camera the other side of the mirrored surface, and taking a render back towards the player. This becomes the texture which is put onto the surface.

     

    I believe the upshot of this is that there must be no geometry in the mirrors "reflected space" that could get in the way of this rendering step.

  12. What's broken about it? It worked fine for me.

     

    You do have to add a couple of standard lines to scale and translate the mirrorRenderMap stage, there should be tutorials on Doom3World.

     

    Oh, and don't ever add a mirror texture to two sides of the same brush, you will get a weird colour wheel or possible the Doom 3 burning planet image.

  13. The problem with the ambient lights not working in render mode. Is that something we will be able to fix, or is it more up Spog's alley? It might be a further deterent to beta mappers if they can't see the ambient lights properly rendered.

     

    I will have a look into this. Initially I thought that the light texture was ignored, which would mean the functionality was missing from the renderer, but further tests reveal that some textures do work (lights/biground1 for instance). This is encouraging since it suggests that the code is already in place to handle this; hopefully it should be possible to recognise the ambientlight keyword as well.

  14. One suggestion. Would it be possible to move all the lights out of the entities menu and drop them into their own menu under Add Light? It sent me for a loop initially that I could only add a normal light and then have to go into entities to select the type of light I actually wanted.

     

    The way it works is that Add Entity gives you the complete list, while Add Light and Add Model just give you a quick path to two very common specific types of entity ("light" and "func_static"). I could theoretically add more hardcoded shortcuts like this (perhaps "Add moving light" or something), but I wouldn't want to go down the route of special-case subsearches.

     

    Also, can the textures menu be tidied up a bit too? In DarkRadiant, I can only load all of the darkmod textures, I can't select specific groups for faster viewing.

     

    A Doom 3-style media browser is on the to-do list.

     

    Sorry, one last idea. Could the light, entity and prefab menus have a search field or perhaps just the ability to press a letter to take you further down the list?

     

    Not sure what you mean - are you referring to a shortcut key with ALT?

     

    I'm really liking where you're taking DarkRadiant orb. It's looking great.

     

    Glad you share the vision. Hopefully I can prove wrong my own previous assertion that there is not a game level editor in existence that isn't unfriendly and bug-ridden.

  15. Is it the collision mesh that determines how it rests on the ground? If so a simple box probably won't work for a rock.

     

    Yes. Yes.

     

    If you zoom in small you should be able to fit the brush to the size of the model fairly well. You can also shave off parts of the brush with the clipper tool before exporting, as long as it remains a single convex brush.

  16. DarkRadiant 0.5.1 is available from SourceForge:

     

    http://sourceforge.net/project/showfiles.p...lease_id=434137

     

    Fixes:

     

    - Changing an entity keyvalue now sets the map status to changed so it can be saved

    - Dragging a model now updates in realtime, rather than waiting for the drag to finish

    - Textures should now display correctly on ASE models

    - Application should not crash on Window 2000 due to the presence of global.xlink (which has been removed anyway).

     

    Enhancements:

     

    The huge right-click entity menu is GONE. Instead there is a context menu with options to add a light, model, entity and (eventually) a prefab at the current location. The selection of an entity uses a separate dialog with an alphabetical list of all entity classes (with typeahead search).

×
×
  • Create New...