Jump to content
The Dark Mod Forums


Active Developer
  • Content Count

  • Joined

  • Last visited

  • Days Won


stgatilov last won the day on September 1

stgatilov had the most liked content!

Community Reputation

992 Legendary

About stgatilov

  • Rank
    Lead Programmer
  • Birthday 08/26/1989

Contact Methods

  • Website URL
  • Jabber

Profile Information

  • Gender
  • Location
    Novosibirsk, Russia

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I also think that open-sourcing engines should be much easier with Microsoft than with Bethesda. Both because Microsoft is very open-source-friendly now while for game publisher it is just stupid to give out anything for free. And because for a huge company like Microsoft open-sourcing one game can be a joke (like Nokia open-sourced Qt because it did not care about it much). However, modern engines are increasingly more complex, so it is questionable how useful it would be if open-sourced. As a consequence of being complex, modern idTech engines are likely to include a lot of code from the previous versions, since rewriting everything is more and more costly. Which means that open-sourcing idTech5 can efficiently open-source a lot of active code which still gives competitive advantage. And also Carmack is not in ID, and I wonder if current ID employees care about open-source and the old tradition of ID. And yes, I hate the idea that gamedev becomes owned by a few huge corporations. Perhaps because this business is too risky? No matter what you do, you will have financial problems one day, and someone large than you will buy you, of you just go bankrupt and lose your team.
  2. Yes, this is how it works. It is a bit scary to have continuous synchronization in both directions. If there is demand from mappers, it can be added in future. I see the same problem in Ubuntu VM when I press Alt. Hitting it again should unblock the movements. It is really annoying since Alt+Tab is a common combination.
  3. Did you check if the changes work as expected on Linux?
  4. @OrbWeaver, are there any news about the pull request?
  5. 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.
  6. 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.
  7. 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.
  8. I have not heard of it, but can't say for sure. That's what I suggested.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  • Create New...