Crash in current development branch, on MatInstance::isInstanced()

Expanding and utilizing the engine via C++.
33 posts Page 1 of 4
chriscalef
Posts: 398
Joined: Mon Feb 09, 2015 7:48 pm
by chriscalef » Wed Mar 09, 2016 12:18 am
Is anyone else having this problem? I've tried twice, in two different repo copies just to make sure, and when I run a fresh empty template build, on load level I get a crash where MatInstance::isInstanced() is trying to refer to a null mProcessedMaterial. I tried adding a check there to make sure mProcessedMaterial is valid but it just crashed somewhere else. Working fine for everybody else? (Build environment: Win7, VS 2010)
Tiel
Posts: 25
Joined: Tue Mar 01, 2016 11:39 pm
by Tiel » Wed Mar 09, 2016 5:16 am
I haven't been able to successfully run an empty template in the current developmental build, just kinda gave up and rolled back.

Full works, however. Not sure how to figure it.
chriscalef
Posts: 398
Joined: Mon Feb 09, 2015 7:48 pm
by chriscalef » Wed Mar 09, 2016 6:29 am
Ah, thanks for that info, didn't know it was just the empty template.
JeffR
DEVGRU
Posts: 957
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Thu Mar 10, 2016 7:49 am
Probably worth tracking this down as a hotfix for people utilizing the empty template(crashes are bad).

Will note though that the new BaseTemplate will soon be rolled in(final testing at this point for any flaws) to replace it, so if it's not a major pressure thing you could wait on that.
rlranft
Posts: 309
Joined: Thu Feb 05, 2015 3:11 pm
 
by rlranft » Thu Mar 10, 2016 2:48 pm
Well, pretty sure MatInstance::isInstanced() shouldn't crash regardless. I mean, if the material instance isn't fully constructed, or hasn't been used yet, or whatever this is checking for, this should probably just return false (I'm guessing Full initializes this material instance where Empty somehow does not until it's "too late").
chriscalef
Posts: 398
Joined: Mon Feb 09, 2015 7:48 pm
by chriscalef » Thu Mar 10, 2016 7:04 pm
Yeah, some more safety checks in there might be in order. No time pressure for me, like I said I added one safety check and when that didn't work just backed out since I didn't have time for a new wormhole at the moment. But I can totally wait till the new template goes in and see if it fixes itself.
chriscalef
Posts: 398
Joined: Mon Feb 09, 2015 7:48 pm
by chriscalef » Tue Mar 29, 2016 1:40 am
Just for the record: I found the cause of the my second Empty Template crash, it was some missing shaders in shaders/lighting/advanced, there were five of them. Winmerge fixed me right up.

I also found that there are quite a few file differences in there. I don't really mess with the shader department myself, but does anyone know if there should be differences between empty and full in this area? Or could I just assume Full has been more recently updated and overwrite the whole folder from there?

Or, is the new template system ready to make these ones irrelevant?
chriscalef
Posts: 398
Joined: Mon Feb 09, 2015 7:48 pm
by chriscalef » Tue Mar 29, 2016 3:05 am
Whoops, correction! I did two things at once and assumed that the friendlier, happier one was the fix, but it turns out I was wrong. The crash I'm getting happens in renderPrePassManager.cpp, _initShaders(), and the "fix" (kluge) I used was simply to ditch early when the shader we're looking for isn't found. Change is the return after "if (!mClearGBufferShader )":

Code: Select all

void RenderPrePassMgr::_initShaders() { if ( mClearGBufferShader ) return; // Find ShaderData ShaderData *shaderData; mClearGBufferShader = Sim::findObject( "ClearGBufferShader", shaderData ) ? shaderData->getShader() : NULL; if ( !mClearGBufferShader ) { Con::errorf( "RenderPrePassMgr::_initShaders - could not find ClearGBufferShader" ); return;//Crash below if we don't return here. Thought it was just a missing shader, but I guess not. } // Create StateBlocks GFXStateBlockDesc desc; desc.setCullMode( GFXCullNone ); desc.setBlend( true ); ...
This probably leaves some critical shader initialization tasks undone, but the game comes up anyway. :-P
Azaezel
DEVGRU
Posts: 496
Joined: Tue Feb 03, 2015 9:50 pm
 
by Azaezel » Tue Mar 29, 2016 5:52 am
you'll be looking for the recent alts in https://github.com/GarageGames/Torque3D ... pts/client and a drop in for the shader changes made for deferred +linearization, though do note, that dx11 (coming in in less than about a week at this rate) is going to override those shaders, and the template refactor is going to reorganize things still further.
JeffR
DEVGRU
Posts: 957
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Tue Mar 29, 2016 4:15 pm
DX11 got merged last night, but otherwise Az is correct. Deferred/Linearization saw some changes to the shaders, and a few more changes for DX11, and then the soon-to-be-merged new base template will see a few more changes. The new template should be nothing especially drastic from the shaders side(more or less just removes the hardcoded "shaders/common/" pathing in place of a global var to indicate where the shaders are stored.
33 posts Page 1 of 4

Who is online

Users browsing this forum: No registered users and 6 guests