Jump to content
The Dark Mod Forums

stgatilov

Active Developer
  • Content Count

    3202
  • Joined

  • Last visited

  • Days Won

    57

Everything posted by stgatilov

  1. Did you check if the changes work as expected on Linux?
  2. I did not read the details, but the whole idea of setting map size by targeting some prescribed screen-space size of shadow texels is good, of course. At least for indoor lights with small light radius. I think we had similar ideas when we discussed soft shadows implementation. The current code already tries to adapt shadow map resolution, but in more naive way. Perhaps it already stores maps in single texture.
  3. I think it is what @duzenko did with texture gather. It is only enabled when soft quality is zero, and if GPU supports it. Unlike what you might expect, it does not remove the stair-like look of shadow boundary. It makes it a bit blurry, but separate texels are still visible pretty well. The same would happen if you decide to blur a low-resolution image rendered without antialiasing using <= 1 pixel blur radius: it will not get antialiased well. Yes, of course. Scissor test is used to achieve it: it allows to limit rendering to axis-aligned rectangle on screen. The rectangle for every visportal area is computed as intersection of all portal windings between the eye and the area. The objects outside the rectangle are completely dropped from rendering. Also, the engine does "depth prepass", so it does not compute color for occluded pixels. Unfortunately, visportals are only good in closed areas. They are often rather useless in open areas.
  4. TDM uses Percentage-Closer Soft Shadows when shadow maps are enabled. I think the only difference over plain PCF is that softening radius is correctly computed using distance-to-light and distance-to-blocker. Unfortunately, it is rather costly technique: one set of samples is used to determine distance-to-blocker, and one set to actually soften the shadow --- so it is 2 times more costly than PCF without distance-to-blocker estimation. When stencil shadows are enabled, soft shadows use screen-space blurring of stencil buffer. It is rather hacky technique which shows surprisingly good results. But there is no distance-to-blocker, so there is no contact hardening. Shadow maps use nearest-neighbor filtering, since billinear filtering of shadow maps is not that simple to use. I tried enabling bilinear filtering in various ways, but it made no difference. Because samples are usually far from each other in shadow texture, so if you see separate shadows, filtering cannot do anything with it.
  5. I have not heard of it, but can't say for sure. That's what I suggested.
  6. To be honest, removing the "unlock on open" feature sounds like better idea. If it is possible to create custom scripts which make doors openable with it enabled but not openable with it disabled, then it is the only way to go.
  7. Could you at least start the FM, execute setviewpos 2754 192 -433, and confirm that this location is reachable by player? It should have some "animated trees". Because I tried teleporting there, and got an impression that it is isolated from the rest of the map.
  8. Copying methods to interface made no sense to me, since they were only used once for attaching GUI. But if you intend to move it to separate module, then it is indeed necessary. However, if GUI is rewritten to spawn separate window, then the methods which are "public" now can once again be made private to the module. I guess the window will be located in the module too, and only the methods to start/close this window would be exposed from module.
  9. I'm not sure what you mean by "full angle-based smoothing". Does the script ensure that non-smoothed edges have angle greater than 11.5 degrees, and smoothed edges have angle less than 11.5 degrees? Well, it means it would be useless to support them on TDM side. Splitting vertices works in general, but TDM will merge them back, so it does not help.
  10. Well, if some other people second your opinion that .obj would useful, I can add support for it in the future. It is very old, well-known and rather minimalistic format with specification freely available. Would it be useful to add some integration of .mtl files too? Maybe it's possible to convert some simple subcases to .mtr file automatically. By the way, .obj format is textual. It is good for debugging, but bad for storage. It has binary equivalent, which has .mod extension. Are .mod files as widespread as .obj files? Do you mean models in .ase take more video memory than same models in .lwo format? I cannot think why it could be so. Yes, they take more storage (perhaps even compressed) and more time to read, but in the end they have the same number of vertices and indices in memory... or not? I think it is bad choice for static meshes. Its main goal is to store animated scenes in a way that anyone can read it (basically, each frame is stored as separate data, like in motion jpeg). Such animated scenes are damn huge of course, but for movie industry it is OK. In game industry, I think it is only useful for complicated non-skeletal animations, e.g. precomputed liquid simulation.
  11. Well, anyway COLLADA is not for the engine. It can be used as intermediate format if it becomes hard to convert to .lwo directly from popular tools. I'm have again come to conclusion that .lwo is a very good static model format for direct loading by the engine. It is 1) already supported, 2) small size, 3) fast to load, 4) supports some advanced features which we can start using if we like. So the main question is if there is some particular problem with how D3 imports LWO files.
  12. My suggestion was to write a script which would extract clean latest revision from SVN, and them push it to all the mirrors. So on the mirrors/game side, nothing will change. SVN is not intended for downloading, it is only for managing the database.
  13. Using closed proprietary format in a free open source game? The game which cannot even link steam integration libs due to its open-source license? The format managed by monopolist company which is known to sue companies for making independent interoperability tools for its formats? Not gonna happen I would say COLLADA is a better choice. But of course only a small subset of it, since it is damn huge (included B-reps, shaders, and what else). And since this format is not efficient for loading (it is made for interoperability), it should be preprocessed into something native and easy-to-load anyway. So some D3 export tool would still exist even for COLLADA. I would even say that DarkRadiant is a better location for such export tool.
  14. Let's spawn @chedap here. As far as I see, there are 3 ways to specify smoothing/unsmoothing in LWO format: Same/duplicate vertices --- that's obvious. Smoothing groups (SMGP). Max smoothing angle (ANG4). Doom 3 code glues vertices together, if they have 1) same color, 2) same texture coordinates, and 3) normals match within acos(1 - r_slopNormal), which is about 11.5 degrees. The condition 3 is disabled if renderbump is on (no idea what it is, but chedap mentions it). It efficiently means that way 1 is broken (duplicate vertices have no effect on unsmoothing), way 2 does not work (ignored by D3 code), and way 3 is sorta hardcoded, because the coefficient recorded in the file is ignored. I think it is possible to change something about it, but new rules will enable only if model contains some special text (e.g. "use-smooth-groups").
  15. I'm looking into the following warning: I think it is fairly easy to automatically break such polygons into triangles, as long as they are: planar: otherwise different triangulations produce different geometry, so better forbid such ambiguity. convex: breaking nonconvex polygon into triangles is too much hassle. Briefly looking into debugger on a few cases, I got an impression that most of the offenders are simple quads. I wanted to ask if there are other LWO-related things to improve/fix. For instance, I see that smoothing groups stored in LWO file are ignored by D3 engine. Isn't it inconvenient? LWO is a very rich format, it allows storing patches, bones, and lots of other stuff. Just look into specs (attached). D3 is using a small subset of it. By the way, how popular is this format today? How easy is it to convert into it from other programs? lwo2.html
  16. I'd like to emphasize that this is a serious matter, not a joke. Right now I need to do minor update to several FMs. And since I know that history is not saved, it is pretty scary. Imagine the following situation. I create pk4, test it and start uploading, without knowing that my network adapter is broken (or my internet provider has broken outgoing traffic). Since it is absolutely obvious that I must update all mirrors simultaneously, that's what I do: update all of them, replacing each copy with a broken file. As the result, the pk4 of the FM is gone from all official mirrors at once, and can only be salvaged from players' machines (and from author's machine if he is still active).
  17. Already done. Replaced ws4_warrens.pk4 on all three mirrors, bumped version to 2. Verified that I can update from old version to the new one in in-game downloader (unless this FM is installed --- I guess that's limitation of downloader). I have checked it both on trunk and 2.08: the cylinder looks properly, behaves properly in physical sense. Placing it on the nearby player works as you describe. As you say, it plays music. Other cylinders nearby contains other pieces of music. I'm sure it was unintended. One of the problems with rotation hack is that it was not reported (well, until recently), so it was very easy to use it without knowing/wanting it. I tested all WS mission from 1 to 5, and I did not see any problems with the others.
  18. The general problem is that rotation-hacked entities do not work properly under some circumstances. Mappers usually had to make such objects noshadows, non-solid, and probably something else, but given the number of such entities (100 FMs x 100 RH entities per mission), then often forget it. And testing is not very reliable, since players can bring any moveable/light to any position, but rarely do so. I believe the cylinder in question does not cause any problems: since it is moveable, it should loose its scale immediately after FM starts. I can do the fix for you. Regarding WS4, the fix is as simple as replacing the current rotation: "rotation" "0 1 0.0871563 -1 0 0 0 -0.0871563 1" with normalized one: "rotation" "0 0.9962234 0.0868271 -1 0 0 0 -0.0868271 0.9962234" Dmapping is not necessary. I have checked that it looks and works properly in-game. My only worry is that I'm not sure what's the purpose of this cylinder in the mission (sorry, did not play it yet). Could you please clarify what important things should happen with this cylinder, so that I could test them?
  19. To be honest, I would prefer putting the whole FM database (including the actual pk4 of FMs) into yet another SVN. After that establish automatic sync from this SVN to http mirrors, from where they can be downloaded by players. This way: It is obvious which FMs are where: every FM is on every mirror. It is not necessary to manually update every mirror (sometimes we forget to update some mirrors, causing random players playing old version). Just commit new version to SVN, and trigger sync task. It is clear who and when changed every FM. Even though exact changes are not viewable. It is possible to return back to any old state of any FM. The metainformation can be stored in the same SVN in e.g. XML format. It can be edited with any XML editor or just text editor, and diffs are easily viewable. You can blame the XML and see for each line who changed it last.
  20. The version number in database is an integer number, which must be increased every time you post something new. Otherwise players with old version won't see new version in in-game downloader. I'm not sure why this internal number is displayed to players though. It would make more sense to show whatever author has written in txt file. Perhaps that's because many authors forgot to change the version in txt file on update.
  21. The loading screen has small red digit "4". So I guess version shown by downloader is greater by one (perhaps someone had to make a small update at some moment, which you did not count as new version).
  22. Yes, I used the state of FMs from the beginning of this year, so my information can be outdated. I have downloaded version 5 of siegeshop (in-game downloader says it is version 5, pk4 size = 15172538). Unfortunately, it still does not boot. The error happens on entities of atdm:fish_animated_01 class. Their model is animated, and their rotations include scaling.
  23. Everyone has probably heard that setting non-orthogonal "rotation" (scaling or shear) on entity is bad, and such entity can misbehave under various circumstances. The dmap warnings for it were added in 2.08. The developer discussion about eradicating this hack is almost year old now. There was even one type of "solution" in 2.08 beta, quickly removed from it. The main problem with rotation hack is that it is used all over all existing FMs. The challenge is how to forbid it completely in the engine, but leave existing FMs in working condition (preferably in fixed condition) without updating all of them. I believe I have solved the problem in latest dev builds without too much hacks in the engine. Now non-orthogonal rotation is always stripped from the entity, and all of its models are wrapped into "proxies" which copy and transform them on load. While it works well for 99% of cases, it breaks on some nontrivial cases. They classify into two groups: collision models and animated models. Having a rotation-hacked entity with such model in a map causes ERROR on load, making it unplayable. I hoped that nobody would ever risk to use rotation hack in such complicated cases, but alas. Luckily, the number of such maps is fairly small, so I hope they can be fixed manually. Here is the list of FMs with the problem: 1) Collision models: ws4_warrens: @grayman (already fixed) rightful: @jysk (no response --- I guess I'll have to fix it) 2) Animated models: antr: @Fieldmedic (Fieldmedic is OK that I'll fix it) elixir_1_3: @Bikerdude, @Obsttorte (Bikerdude said he would fix it) siegeshop: @PranQster, @lowenz (PranQster says already fixed in upcoming version) I'd like to hear authors' opinions and advice about it. I think I can fix all these problems myself, although I would appreciate help from the authors. If you are author of one of these FMs, please write if you prefer fixing it yourself or prefer me to fix it. If I will fix a map, then I will post the suggested differences here and wait for approval. Speaking of collision models, there are two ways to fix the problem: Add clipmodel spawnarg with the same value as model. However, it usually results in collision model not matching the visual model. Normalize rotation, removing scaling/shear. Since such entities are usually moveable, and moveables lose their scaling/shear immediately after first move, it sounds like a better fix. Speaking of animated models, I have no idea how to fix the problem except for physically applying the transformation to .md5mesh file. I wonder if there is any existing tool which can do it easily. If not, I think can write a Python script. P.S. I can post names of entities which cause issues if needed.
  24. I think no. I recall there is an issue about it somewhere. I tried to listen more attentively to lockpicking sounds, but did not hear anything suspicious. I guess it causes to little harm to bother.
×
×
  • Create New...