Jump to content
The Dark Mod Forums

TDM Engine Development Page


zergrush

Recommended Posts

Not sure it can be fixed on renderer level, but we could try with nbohr1mores suggestion.

Maybe its the same bug i have in crucible of omens, in that one it is just a far away solid object that acts like a portal untill you get closer.

Unfortunatly it is hard to see in screenshots in that particular map, but what happens is that a solid object "a wall in this case" lets the skybox shine through at a far away distance.

 

Hmm this could indeed be caused by a bug with transparency after further thought, ill have a look at the commit in question.

The problem is line 956 Interaction.cpp

You can see it with this additional check

		if ( shader->ReceivesLighting() || r_shadows.GetInteger() == 2 && (shader->SurfaceCastsShadow() || r_ignore.GetBool())) {

Then do r_skipparticles 1, r_ignore 1 and reload.

Nothing to do with far Z plane, depth transparency, or vis portals.

And you can't just remove shader->SurfaceCastsShadow() check otherwise all surfaces start casting shadows, including street wall decals in Lockdown

  • Like 1
Link to comment
Share on other sites

I checked against how fhDoom does it and seems he ran into some problems in certain areas as well,

so he created an enumerator to determine or set shadow modes based on game data (material flags etc), namely stencil / shadow map, or noshadow.

 

In the problematic areas it auto switches to shadow volumes based on the above if the map has problems with shadow maps.

The downfall is that we would need to add alot of code possibly rewriting large parts of especially the GLSL renderer and the light editor, as well as the dmap optimizer.

If it gets things to work im all for it, but before i start anything i wanted to hear your opinion.

 

also

		// generate a lighted surface and add it
		if ( shader->ReceivesLighting() || r_shadows.GetInteger() == 2 && shader->SurfaceCastsShadow() )

Is rather different from his way

		// generate a lighted surface and add it
		if ( shader->ReceivesLighting() ) {

instead he moved those checks into the function below which is stencil only like this

		// if the interaction has shadows and this surface casts a shadow
		if ( lightDef->ShadowMode() == shadowMode_t::StencilShadow && HasShadows() && shader->SurfaceCastsShadow() && tri->silEdges != NULL )

I tried with a minimal approach of the way he does it to see if it fixes anything, but it causes massive Z-fighting in the shadowmaps on some objects (sawtooth syndrome),

and do not seem to fix the problem properly though the skybox bug got a little better.

 

Granted i only used a minimal part of the code, and it seems it relies on more than just the tinkering in interaction.cpp

Link to comment
Share on other sites

It's been dragging for long enough, so I just went ahead and fixed it in svn 7703.

 

I have a task that might be more in your style.

 

There is a certain r_fboResolution cvar. It's a backend-only thing, that should never be used anywhere else.

Now the problem is that at some point I made a mistake and used it in front renderer (idRenderSystemLocal::BeginFrame).

 

Can you please see if you can refactor that code so that the frontend operates in window coordinates, and the conversion to FBO coordinates is done on the backend side, ideally in FrameBuffer.cpp.

 

I have more exciting tasks for you coming! :)

  • Like 1
Link to comment
Share on other sites

So it was a combination of the same optimization bug that turned up after switching to msvc 2013 and globalinteractions having an invalid value, heh that one was rather irritating back then i remember.

Been a busy week so it took me longer than i might have liked to get to the bottom of it, not sure i would have guessed that the optimization bug was also affecting SM's, good job.

 

Sure ill be looking it over :) just remember i been out of the loop for a while so i might take longer than you might like to wait,

last time i did some serious coding was in 2012 where i had to call it because i simply couldnt take the pain anymore.

 

Even forgot stupid things like the OpenGL string length bug for a time, that one bugged the hell out of me when i tried to get up to speed by doing some work on an old quake project, untill i got reminded about it :laugh:

So its slow going atm.

Link to comment
Share on other sites

Re your recent post.
I agree that dozens of "if (r_shadows.getInteger() == N)" conditions are annoying.
Do you think you could add a flag to renderlights (none, stencil, depth ) to be used in the backend instead?
Not sure if it's better in the lightDef because of added code (vLight->lightDef->shadows is more typing than simply vLight->shadows).

E.g.

	bool doShadows = !vLight->lightDef->parms.noShadows && vLight->lightShader->LightCastsShadows(); 
	if ( doShadows && r_shadows.GetInteger() == 2 ) // FIXME shadowmap only valid when globalInteractions not empty, otherwise garbage
		doShadows = vLight->globalInteractions != NULL;
	if ( doShadows ) {
		if(r_shadows.GetInteger() == 2 && vLight->tooBigForShadowMaps )
			qglUniform1f( shadows, 1 );
		else
			qglUniform1f( shadows, r_shadows.GetInteger() );
		//qglUniform1i( shadowMipMap, ShadowMipMap[0] ); // don't delete - disabled temporarily
		qglUniform1i( shadowMipMap, 0 );
	} else
		qglUniform1f( shadows, 0 );

would end up like

	bool doShadows = vLight->shadows != LIGHT_SHADOWS_NONE;
	if ( doShadows ) {
		if(vLight->shadows == LIGHT_SHADOWS_STENCIL )
			qglUniform1f( shadows, 1 );
		else
			qglUniform1f( shadows, 2 );
		qglUniform1i( shadowMipMap, 0 );
	} else
		qglUniform1f( shadows, 0 );

Or even

qglUniform1f( shadows, (int)vLight->shadows );
qglUniform1i( shadowMipMap, 0 );

I imagine you would have to set the shadows flag where the tooBigForShadpowMaps is set now. It should include lightDef->parms.noShadows, lightShader->LightCastsShadows(), r_maxShadowMapLight, r_shadows. (probably globalInteractions check as well)

Link to comment
Share on other sites

Ok moved virtual resolution to frameBuffer.Cpp and refactored it, still needs a little refinement but it allready works quite fine.

 

It now also updates resolution on mode changes.

Does not work at all.

	width = &renderWidth;
	height =&renderHeight;

in FB_Resize() does not even generate any machine code in release.

 

If you want to discuss the depth check revert please PM.

  • Like 1
Link to comment
Share on other sites

Thats strange :huh: so i did a small check to see if it was actually modifying the width and height and it does here.

 

r_fboresolution 2

 

https://ibb.co/hhfoe9

 

r_fboresolution 4

 

https://ibb.co/bFNUmp

 

granted i refined it a bit in the meantime, but the underlying code is still the same, so im a bit baffled by it.

Try r_fboresolution 0.1 and see if the picture on the screen becomes pixelated.

  • Like 1
Link to comment
Share on other sites

@all

What is the referenceBounds on entity and how different is it e.g. to the bounds of the entity's md5 model snapshot?

 

This is related to the bug that @nbohr1more noticed with dynamic models sometimes being scissored on the edges because the model does not fit its referenceBounds on some of its animation frames.

  • Like 1
Link to comment
Share on other sites

No pixelation with my current code :) just uploaded. Or did you want it to pixelate ?.

 

Hmm preferably there should be no difference between the bounds, but somewhere along the line this might go out of whack if something modifies the md5 bounds behind our backs.

So i guess we have to figure out where that would happen.

 

Hmm i seem to remember a recent snapshot of dhewm tried to get around this, let me have a look.

  • Like 1
Link to comment
Share on other sites

Done refactoring the code to the best of my abilities, took me more work than anticipated but in the end it came out quite ok.

 

Now i reeeealy need some sleep -_- been burning the midnight oil on this one.

 

r_fboresolution can now scale above and below 1 but dont get cocky and set values like 100 unless you want to burn out your gfx cards :P it will become rather heavy on values above 4 on a decent card.

 

Theres a small bug with shadow maps on which i been unable to fix, the shadows themselves look fine but some surfaces (like stolen paintings) will show a fishbone pattern where the painting was.

This does not happen often so it is hard to track down what might cause it ( alpha blended surfaces ? ).

  • Like 1
Link to comment
Share on other sites

Added some curlies and typecasts to avoid some warnings, not sure i would call that formatting only changes.

Its just my style with curlies, old habits are hard to get rid off :/ but ill make a note of it.

How do you get a warning about that? I'm using vs 2017 and there's nothing like it.
Link to comment
Share on other sites

Sorry to pile on but...

 

As of last nights build:

 

1) Enabling Soft Shadows disables or kicks you out of FBO mode

2) It seems that MSAA is completely broken

 

Given that item 2 is the main marquee item for 2.07 (Soft Shadows with MSAA) this is a rather concerning regression...

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

Also using vs 2017 the warning was a cast from size_t to int. Not sure if warning level is set lower on your builds ?.

Msaa is broken now :blink: is that whats causing these fishbone patterns to appear ?,

i was unsure as to what caused it but maybe if i revert the two files modified to the previos versions from svn i can see if there is any difference.

If by some chance croppedWidth or croppedHeight leaks wrong resolutions to msaa i might need to use a seperate set of msaaWidth and msaaHeight to isolate it.

 

Else i took great care in asuring that FB_Resize only used scale when told to, so that it emulated the orginal code, but something is definatly fubar if it kicks us out

of the framebuffer when softshadows are on.

 

Ill se what i can do about it.

Link to comment
Share on other sites

Curlies dont throw warnings ofc, the cast warnings where here

int thisCount = idMath::Imin( static_cast<int>( lightOrigins.size() - i ), MAX_LIGHTS );

and here

backEnd.pc.c_interactionMaxLights = idMath::Imax( static_cast<int>( backEnd.pc.c_interactionMaxLights ), static_cast<int>( lightOrigins.size() ) );

whitespace change as you correctly assumed was from removing

#if defined(_MSC_VER) && _MSC_VER >= 1800 && !defined(DEBUG)
//#pragma optimize("t", off) // duzenko: used in release to enforce breakpoints in inlineable code. Please do not remove
#endif

So i guess that even after moving it to FramBuffer.Cpp you wanted to keep it handy in case it was not enough.

 

 

Shadow Maps completely fail to render. Only Stencil Shadows work. :(

 

 

Woot they work here :blink:

 

gatehouse1_3_2018-09-24_08.01.36.jpg shadowmaps with no softshadows or 0

 

gatehouse1_3_2018-09-24_08.01.47.jpg same with softshadow quality 96

 

r_fboresolution now seems to scale correctly without pixelaltion, but it blurs the view somewhat at lower settings.

Link to comment
Share on other sites

To 7707 and only for FrameBuffer.cpp, but i keept a copy of the newer revision of it so that i could write back the stuff that worked in that one.

 

RenderSystem.Cpp i just copied back the code i removed from a local copy of the 7707 revision.

 

If changing from SS to SM, shadows do not allways come back immediatly, i noticied. Guess the framebuffer needs some time to update.

Link to comment
Share on other sites

idRenderSystemLocal::BeginFrame was using r_fboResolution in 7704 last time.

Are you saying that 7707 also had r_fboResolution in idRenderSystemLocal::BeginFrame??

Do you know how to use svn log?

What is the accumulate effect of your commits 7705 and 7712? Did you complete the r_fboResolution refactoring task? Or are we on the reformat/revert/re-revert loop again?

Do you understand why you should have done the r_fboResolution changes in svn commits separate to the unrelated stuff you did, like the depth color, type casts, or reformatting?

Link to comment
Share on other sites

sorry one earlier version before i removed it originally so yeah 7704.

 

Yes i know svnlog, was just a bit tired at the time, took me all night with those changes.

 

Havent completed the r_fboResolution refactoring yet cause i ran into a snag with renderCrops, this caused some viewport issues which i am still investigating the cause of.

 

the PCF change was from a working example, i noticed when softshadows where not on that some objects had some rather nasty jaggies when using SM (lego block size), so i tried with the working PCF codepiece and it did soften them up some.

 

The depth color change was from looking at how the original did it (alpha tested vs not) since the original used immediate mode i was not sure if still correct so i left a comment to remove it if not.

 

original code below

			// skip the entire stage if alpha would be black
			if ( color[3] <= 0 ) {
				continue;
			}
			glColor4fv( color ); // alpha tested

			glAlphaFunc( GL_GREATER, regs[ pStage->alphaTestRegister ] );

			// bind the texture
			pStage->texture.image->Bind();

			// set texture matrix and texGens
			RB_PrepareStageTexturing( pStage, surf, ac );

			// draw it
			RB_DrawElementsWithCounters( tri );

			RB_FinishStageTexturing( pStage, surf, ac );
		}
		glDisable( GL_ALPHA_TEST );

		if ( !didDraw ) {
			drawSolid = true;
		}
	}

	// draw the entire surface solid
	if ( drawSolid ) {
		glColor4fv( color ); // not alpha tested
		globalImages->whiteImage->Bind();

		// draw it
		RB_DrawElementsWithCounters( tri );
	}

And yes i should have kept it seperate for readability, at some point while working on it i just entered auto mode :wacko: and before i knew i had done multiple unrelated changes.

Note to self dont code when tired.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 1 reply
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
    • nbohr1more

      Please vote in the 15th Anniversary Contest Theme Poll
       
      · 0 replies
×
×
  • Create New...