Jump to content
The Dark Mod Forums


Active Developer
  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by duzenko

  1. Then what are we left with? It would be great to keep the render matrix stuff but you say it requires the BFG-constructed projection matrix? I suppose we should then change DR to use that method as well? Probably the only change should be the end pos being relative to origin rather than start to improve compatibility with the existing maps? Sorry, what do you mean by that? Being a frustum means that near/far planes are parallel to XY or ???
  2. I was thinking the frustum is generated from the matrix. The both style matrices define the same frustum since one is computed from the other. Currently the D3-style matrix is computed from the BFG one. I was suggesting to reverse this so that the BFG matrix is computed from the D3 one. This way, we will end up with the D3 frustum, and both matrices would be compatible with it
  3. Oh dear I thougt that local var localProject is not used beyond creating the light->lightProject But I can now see it's used for light->baseLightProject Let's start again The conversion between the two styles is rather straightforward. Can't we use R_SetLightProject for D3 style matrix and then compute BFG style by swapping columns and normalizing Z?
  4. Not wishing to do anything is not exactly a great start for support request Sorry for being the Negative Ned
  5. Do you have opinion on how those changes practically change mapping and gameplay? Is there any upside/downside? (even if theoretical) Right now I'm leaning towards reverting to D3 matrix, because this thing has dragged long enough, generated lots of noise and so far has lead to nothing other than examples of incompatibility I'm talking about the BFG projection matrix build function only, not the render matrix stuff (which looks quite useful)
  6. It was me trying to fix I can't remember what now. I changed to 1 / (n+f) locally but did not commit yet Can you please look where the "end" pos projects to with the both matrices? Does it mean that the "end" changed its meaning in BFG? What should we do about it? We don't discuss changing anything in this regard (like swapping W and Z) Please don't worry about it The two matrix styles co-exist in TDM, they don't replace each other anywhere
  7. We still use the D3-style matrix in shaders, nothing has changed in that regard It does not matter really which matrix style the BFG shaders use, they are equivalent, because one is built from the other The question is about the first "original" matrix in R_DeriveLightData and which building function we want to stick with
  8. There's a good reason that falloff does not make sense with perspective projection The z component is crammed to have most of its range near the front plane. You won't be able to apply texture to it in a meaningful way.
  9. Before you get too excited, think about the fact that people don't use projected lights like that
  10. Well, I kinda like some of the functionality the render matrix offers, like easy transformation of Vec3 to Vec4
  11. Thanks I don't think we should not try to modify either of the two projection matrices, just pick one of them and use in both TDM and DR. Do you have any idea what they tried to achieve with this change and why?
  12. Once again, we need to decide if we want to switch back to the D3 matrix in TDM or switch to BFG matrix in DR I don't think I'm qualified to make that choice despite all the time I spent on this
  13. tr_lightRun.cpp in TDM R_DeriveLightData/R_ComputeSpotLightProjectionMatrix/R_SetLightProject Light.cpp in DR Light::updateProjection The math in D3 was okay, I suppose. The problem is that something changed in BFG and it's not consistent any more. The end point no longer projects to the far plane. I want to understand if it was a bug in BFG, or something changed in the logic behind the anchor points. And if it did change, then it should have been reflected in whatever editor they used for BFG maps?
  14. That's what I've been asking for a while but no one seems to care\know It seems asymmetric frustums have been the "norm" in D3/DR/TDM - of course projected lights in general were taken for granted and people just used them as is without any second thoughts If you create a projected light in DR and start dragging the anchor points around you're bound to lose symmetry soon enough Technically it would be easier to handle if left=right and up=down but there's an issue of compatibility. Expect some angry mappers when they find out their asymmetric lights have stopped working. It can also be used for optimization if the symmetric frustum spans too much.
  15. OTOH if we want to support "asymmetric" (off center) projections then would require exactly that - non-orthogonal basis? Like glm::frustum (btw maybe just use that?)
  16. In this case logically the resulting frustum center point is not what DR shows I would suggest to fix this in DR then
  17. Could you maybe shed some light why target, right, up aren't orthogonal? One difference between d3 and bfg is that BFG uses the target vector from spawnargs for Z basis vector and D3 computes a normal between up and right instead.
  18. Forget about shaders, this is not about that No, the game, same as DR, uses the falloff texture. The texture decides where the light is brighter or dimmer. There's no shader math for that. The texture does not have to be symmetric, if a particular texture is symmetric, that still does not mean anything. There's no really need or sense to change anything in that regard.
  19. Added the test code for that (placed in the end of R_DeriveLightData) Results Unless I'm not mistaking it means that the BFG matrix does not map the end pos from the spawn args to light frustum "far" plane, unlike the D3 code At this point we should decide if it was a bug or a feature and what their intention was when they changed the matrix.
  20. @stgatilovThanks for looking into this I think I got sidetracked and distracted you from the real problem Yes, the thing I wrote about in the last post is a non-issue. Since the baseLightProject is always based on the lightProject, they'll both produce the same result My problem is the code that builds lightProject. R_SetLightProject vs R_ComputeSpotLightProjectionMatrix will give different matrix sets and different frustums I'm going to try another thing now. Transform local start/end coordinates (in the spawn args) to global space and see where their "projections" are EDIT. Also note, that locally I reverted to return 1.0f / ( zNear + zFar ); in the end of R_ComputeSpotLightProjectionMatrix but did not commit to svn as I'm still investigation this
  21. Is the outline supposed to work for both old and new backend? I think it should though I vaguely remember something only working in new backend
  • Create New...