duzenko

Do we have a tutorial or video about managing projected lights in DR? E.g. I have no idea how to control it's parameters other than manually type into spawnargs

After some more investigation it seems that BFG projection matrix is different because it gives different transformation projection divider goes into W instead of Z falloff texture coordinate is not normalized This is produced by debug code in the end of R_DeriveLightData auto test = [light](idVec3 vert, int i) { idVec4 v4; light->baseLightProject.TransformPoint( vert, v4 ); auto& M2 = *(idMat4*) light->lightProject; idVec4 tmp( 0, 0, 0, 1 ); tmp.ToVec3() = vert; auto x = M2 * tmp; common->Printf( "%2d%30s%30s\n ", i, v4.ToString(), x.ToString() ); /*for ( int j = 0; j < 6; j++ ) { auto d = light->frustum[j].Distance( vert ); common->Printf( "%.1e ", d ); } common->Printf( "\n" );*/ }; for ( int i = 0; i < light->frustumTris->numIndexes; i++ ) { auto index = light->frustumTris->indexes[i]; auto vert = light->frustumTris->verts[index]; test( vert.xyz, i ); } ALIGNTYPE16 frustumCorners_t corners; idRenderMatrix::GetFrustumCorners( corners, light->inverseBaseLightProject, bounds_zeroOneCube ); for ( int i = 0; i < 8; i++ ) { test( idVec3( corners.x[i], corners.y[i], corners.z[i] ), i ); } Strangely here both frustumTris and frustumCorners_t map to texture space corners...

@stgatilov apparently the BFG code we switched to last year produces a different result compared to the old code It's R_SetLightProject vs R_ComputeSpotLightProjectionMatrix The old R_SetLightProject was inline with DR I'm not sure about why they changed it, maybe it makes more sense, but we need to maintain compatibility so revert that?

Can anyone please explain what the start, target, end, up, right points for lights are defining? I mean, I can understand what they're defining, but how they're supposed to map to the projection matrix? Compare, for example const float targetDistSqr = light->parms.target.LengthSqr(); const float invTargetDist = idMath::InvSqrt(targetDistSqr); const float targetDist = invTargetDist * targetDistSqr; const idVec3 normalizedRight = light->parms.right * (0.5f * targetDist / light->parms.right.LengthSqr()); localProject[0][0] = normalizedRight[0]; localProject[0][1] = normalizedRight[1]; localProject[0][2] = normalizedRight[2]; localProject[0][3] = 0.0f; and auto rLen = _lightRightTransformed.getLength(); Vector3 right = _lightRightTransformed / rLen; Vector3 normal = up.cross(right).getNormalised(); auto dist = _lightTargetTransformed.dot(normal); if ( dist < 0 ) { dist = -dist; normal = -normal; } right *= ( 0.5 * dist ) / rLen; lightProject[0] = Plane3(right, 0); This already gives different results

Next step is to compare DR's Light::updateProjection() and TDM's R_DeriveLightData

I can see that DR does it corners in local space using plane intersections While TDM relies mostly on projection matrices But already the initial setup in R_DeriveLightData is wrong when it comes to building frustum planes

It does not produce the actual corner coordinates though, does it?

Not sure if it's a bug in DR or (most likely) TDM but I've been hit with this issue where a light ends up having different frustum vertices in TDM than it was set up in DR Map attached. Look at light_1 Its "far" corners seems to have the X coordianate of -125 When the light loads in TDM, the frustum corners can be rebuilt using different methods: R_PolytopeSurface gives -147 idRenderMatrix::GetFrustumCorners gives -213 This really messes up my volumetric shader Which one is supposed to be correct? idRenderMatrix::GetFrustumCorners is much farther from DR but R_PolytopeSurface's output is not even air-tight @stgatilov? @greebo Where can I find the code that calculates frustum vertices in DR? Maybe I should just copy-paste it in TDM and relax. volumetric.map duzenko.mtr

Could be low on RAM - maybe round down textures and try a small mission? Or could be 64-bit color compatibility - try to disable that There's a way to bypass vendor check and force install intel drivers, I did that on my Atom tablet many years ago. Search for steps.

No, it was from the old volumetric branch I'm trying to revive today But we staill do have a render function that always tries to draw client arrays

Some wisdom from debug profile logs

@MirceaKitsune I just tried on Ubuntu 20 WSL and it builds Note my gcc version on the screenshot Your options: downgrade your gcc, create a bugtracker issue for this, try the C++ include below @stgatilov #include <limits> ?

Yet another reason to not mess with desktop screen resolution

Graphics driver issue?

Not sure how it fits the design pattern of parallelism. E.g. I might have precompiled headers compiling in 2 projects (out of 4 allowed in settings) That still leaves plenty of room for other 2 projects to load all cores twice. Even one non-PCH process should be able to load all remaining thread pool slots. (And looking in the build output window, it says it's sifting through the .cpp's at least most of that time) And I'm not even sure all the P*2T instances are pooling together, considering they're all running in separate processes. Are they talking to each other or something? It's scary to live in MSVC world!

Results here. What's puzzling me the most is relatively low CPU usage during the first minute. After that it goes to 100% and stays there until a few seconds before the end. I wonder what's going on during that first minute - maybe there's some potential in improving the overall time.

That's what I wonder actually is there a switch somewhere that allows/forbids to build projects in parallel? I'd benchmark that out of curiosity I think there should be one in .sln properties, but it's not easily accessible when opening the .cmake in VS2019 like I do EDIT. Found it in global IDE options

Apologies for going in circles around this, but What is the reason again to build projects in parallel? Other than ambiguity in project dependencies, there seems to also exist RAM consumption issue on modern many-core CPU's. I mean I understand that a semi-pro programmer is expected to have "enough" RAM (and I do) but it's still a real minus. On my day job I've seen a colleague to have 8GB RAM and 20+GB committed because of many garbage-collected java/dart/javascript processes running in background. Surely we don't want the compiler to start swapping pages to disk in the middle of build on a "regular" laptop? Are you trying to utilize CPU cores in this way? But e.g. the notools darkmod build is just one project and it loads all cores nicely. And please @stgatilov correct my on this assumption but isn't building multiple projects theoretically slower because of all the data the CPU has to keep pumping along the L3cache <> RAM bus?

It does not make sense to me to add a second ambient light in the same origin What you can do, is put a second 'regular' shadow-casting lights close to the 'bouncing' surface

I think I first noticed it here https://forums.thedarkmod.com/index.php?/topic/20169-the-history-of-bloom/&do=findComment&comment=446309 It looks rather cool, mostly because he's a no-nonsense person and his formatting kinda underscores that in my mind

Notools project does not update svn counter in build. It’s current svn.

You did You were right all along It's still frustrating as heck that it didn't raise any GL errors And I'm not sure what we're left with in the end - half-core profiles that do something specifically forbidden by specification? Crazy

Agree about fixing the error I just can’t imagine a game requiring a core profile and then doing client arrays. Oh, wait…

What is it supposed to fix? Core profile on pre-GCN Radeons? Why did all other drivers work if it's about the removed legacy stuff? I can test tomorrow, but I'm skeptical.