duzenko

It seems as if the problem is with VBO but I can't see it For now I added a fallback code for compatibility profiles Completed: At revision: 9653

Can you double check spotlight_normal2? It seems to have invalid start/end resulting in NaN in its matrices and debug asserts failing { "classname" "light" "name" "spotlight_normal2" "_color" "1 1 1" "light_end" "200 0 -20" "light_right" "50 0 0" "light_start" "0 0 -20" "light_target" "0 0 -100" "light_up" "0 30 0" "nodiffuse" "0" "noshadows" "1" "nospecular" "0" "origin" "-4 -300 40" "parallel" "0" "texture" "lights/ambient_roundedsquare" }

Let me look into that

r_showLights was based on fixed-function GL and needs some love to make work on core profiles It seems that volumetric is the easiest option right now

You could use the debug code in the volumetric render function that compares corner vertices. That and maybe compare with dr corners. Maybe also use volumetric light to visualize the frustum and put 8 candles on frustum corners in dr

Are we ready for bug reports in materials? E.g. a door in Cole Hurst 1 has depth fighting at 6250 555 -20

Let's do something with it already

The d3 frustum is not air tight Bfg code has some nice optimizations It will be a pity to see it go and endless source of suggestions to redo it

I think it's too late to fix it then If even gl 3.1 was too much stress for that pc

Does 2.08 work?

Don't you get a click to start gui before you get to 3d world?

I'm rather clueless on how to accomplish that due to my inadequate skills in linear algebra Can you do that while keeping the idRenderMatrix stuff in working condition? Will it be 100% what D3 projection was, or something in-between that and BFG? At any rate any decision is better than no decision as the beta season starts soon

1. Update graphics driver 2. Upgrade the hardware 3. Downgrade TDM

Select a dev build in the installer

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

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

All well that ends well

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?

Not wishing to do anything is not exactly a great start for support request Sorry for being the Negative Ned

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)

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

@OrbWeaverLinear Z, huh? I was wrong then

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

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.

Before you get too excited, think about the fact that people don't use projected lights like that