Jump to content

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


Recommended Posts

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)

Link to post
Share on other sites

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.

Link to post
Share on other sites

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").

Link to post
Share on other sites

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.

Link to post
Share on other sites
  • 3 weeks later...

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?

Link to post
Share on other sites

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 )":

 


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

Link to post
Share on other sites

you'll be looking for the recent alts in https://github.com/GarageGames/Torque3D/tree/development/Templates/Full/game/core/scripts/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.

Link to post
Share on other sites

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.

Link to post
Share on other sites
  • 2 weeks later...

Forgive my ignorance, but is calef's fix still applicable then? I'm trying to compile what's in the development branch right now with dx11 and running into the same issue when attempting to load an existing project.

Link to post
Share on other sites

For clarity, this is with an empty template derivation? if so:


https://github.com/GarageGames/Torque3D/pull/1519/commits/5b5c6b9907d4b83ddc45335cac03da48a3738a36#diff-bb58f974dd4ad00dfc63e5c6bec33392R4 is the bit where deferredClearGBufferP was added. (further down is the file. though again, you'll want the dx11 templated version from full at time of writing, and again they'll be in a different spot soon.)

Link to post
Share on other sites

Ah, yes, got it. I went ahead and just stripped all the art and a good deal of script files from full and put my own stuff in, good to go.


Though with DX11 enabled in the project @ CMAKE there are a few strange artifacts.


http://imageshack.com/a/img922/4065/52naUn.png

(this is a guiobjectview with a model of an earth like planet with normals and specular. Or it would be, anyway, heh)


Went into options, there's a handy dropdown to switch the GPU over to D3D11, but restarting yields


failed to compile shader: C:\Users\cocka\Desktop\Torque3D-development\My Projects\Void\Null\game\shaders\procedural\5004b9ce_P.hlsl(52,23): error X3086: the 'sampler2D' keyword is deprecated in strict mode; use 'SamplerState' instead

C:\Users\cocka\Desktop\Torque3D-development\Engine\source\gfx\D3D11\gfxD3D11Shader.cpp(924,0): {Fatal-ISV} - Unable to compile shader!


I am lost haha, should I create a thread for this?

Link to post
Share on other sites
GuiObjectView is a horrible, horrible thing - it needs a ton of work to bring it in line with the other 3D view elements.

 

I use GuiObjectView rather extensively in my current project. Recently I've extended the GuiObjectView class with 4 new features that make it much more usable:

  • Added sub mesh support : To show and hide sub-meshes within a parent mesh( source code and console commands ).
  • Added sub mesh skinning : To change skins individually per sub-mesh within a parent mesh( source code and console commands ).
  • Added node support : To toggle on/off use of nodes on the mesh. If in use, camera can be set to node locations( source code and console commands ).
  • Added blend support : To use blend animations with the displayed mesh. Supports blending animations with root animation pose( source and console commands ).

 

Are there other features that you'd like to see @rlranft ? When I get time to clean up my code and revisit this I plan on sharing this improved GuiObjectView class with our community, so please do let me know if there are improvements that might be able to be made. :D

Link to post
Share on other sites

You'll probably want to talk to @Azaezel about the real issues (I believe he's addressing several render-related issues now or shortly) - mainly it doesn't have all of the rendering features that the GameTSCtrl, nor does it play nice when rendered as a child of GameTSCtrl. The reason that I say "it's horrible" is because it leads you to believe that it's going to behave like a "show room" version of GameTSCtrl, but that's not true and there are plenty of gotchas.


As far as functionality, it has what I need - it just causes endless questions from newcomers....

Link to post
Share on other sites

Yea I can see where some improvements could go a long way in some areas.


Thanks for the information about a potential WIP around the GuiObjectView's rendering code. I'd be interested to see what changes @Azaezel makes to the class! Hopefully he'll chime in and let me know =)

Link to post
Share on other sites

Lesee.. Da List...


Fars it goes, thusfar, there's of course the https://github.com/GarageGames/Torque3D/pull/846/files#diff-209aa67c63b26f65671739499ff8bf4cL525 addition that'll let it take postfx (I say 'let it', but that's really a deferred requirement that just happens to allow stuff like HDR to apply. Be nice to specify which ones long term so you could apply specialty effects to a cutout, but not particularly targeting that atm.)


Do still need to sort out why OpenGL is pitching a fit with non forward lit materials:

http://i.imgur.com/ZeazIPx.jpg


Could be related to this glitch: http://imgur.com/a/U8qvC *


For folks planning on using em in-game need to sort out the blend methodology so that it throws out that background quad (that brightening crap you can see http://i.imgur.com/wDLW46I.jpg **). Prolly somethin up with the stateblock...


Should also note at time of writing I've thusfar failed to inject the levelinfo cubemap global reference into the guiobjectview, material, or object editor scene variants. (Important for metals later. No envoronment/ibl/ect map/some kind of dropdown-selected cubemap, then it ends up showing that as black.)


*should note that in order to support guiobjectviews prior to a level load, need to shift https://github.com/GarageGames/Torque3D/blob/7bba3ee2de610c2757bc70eba10db869bab72a85/Templates/Full/game/scripts/client/init.cs#L106-L115 on up to about https://github.com/GarageGames/Torque3D/blob/7bba3ee2de610c2757bc70eba10db869bab72a85/Templates/Full/game/scripts/client/init.cs#L73


** one thing I did add so far in tinkering around would be the missing entries for fog filtering from the other two variants on that theme:

https://github.com/GarageGames/Torque3D/blob/7bba3ee2de610c2757bc70eba10db869bab72a85/Engine/source/T3D/guiMaterialPreview.cpp#L371

+

https://github.com/GarageGames/Torque3D/blob/7bba3ee2de610c2757bc70eba10db869bab72a85/Engine/source/T3D/guiMaterialPreview.cpp#L418

which nets us


void GuiObjectView::renderWorld( const RectI& updateRect )
{
  if( !mModel )
     return;

  GFXTransformSaver _saveTransforms;

  // Determine the camera position, and store off render state.

  MatrixF modelview;
  MatrixF mv;
  Point3F cp;

  modelview = GFX->getWorldMatrix();

  mv = modelview;
  mv.inverse();
  mv.getColumn( 3, &cp );

  RenderPassManager* renderPass = gClientSceneGraph->getDefaultRenderPass();

  S32 time = Platform::getVirtualMilliseconds();
  S32 dt = time - mLastRenderTime;
  mLastRenderTime = time;

  LIGHTMGR->unregisterAllLights();
  LIGHTMGR->setSpecialLight( LightManager::slSunLightType, mLight );

  GFX->setStateBlockByDesc(mRenderDesc);

  F32 left, right, top, bottom, nearPlane, farPlane;
  bool isOrtho;
  GFX->getFrustum( &left, &right, &bottom, &top, &nearPlane, &farPlane, &isOrtho );

  Frustum frust( false, left, right, top, bottom, nearPlane, farPlane, MatrixF::Identity );

  FogData savedFogData = gClientSceneGraph->getFogData();
  gClientSceneGraph->setFogData(FogData());  // no fog in preview window

  SceneRenderState state
  (
     gClientSceneGraph,
     SPT_Diffuse,
     SceneCameraState( GFX->getViewport(), frust, MatrixF::Identity, GFX->getProjectionMatrix() ),
     renderPass,
     true
  );

  // Set up our TS render state here.   
  TSRenderState rdata;
  rdata.setSceneState( &state );

  // We might have some forward lit materials
  // so pass down a query to gather lights.
  LightQuery query;
  query.init( SphereF( Point3F::Zero, 1.0f ) );
  rdata.setLightQuery( &query );

  // Render primary model.

  if( mModel )
  {
     if( mRunThread )
     {
        mModel->advanceTime( dt / 1000.f, mRunThread );
        mModel->animate();
     }

     mModel->render( rdata );
  }

  // Render mounted model.

  if( mMountedModel && mMountNode != -1 )
  {
     GFX->pushWorldMatrix();
     GFX->multWorld( mModel->mNodeTransforms[ mMountNode ] );
     GFX->multWorld( mMountTransform );

     mMountedModel->render( rdata );

     GFX->popWorldMatrix();
  }

  renderPass->renderPass(&state);

  gClientSceneGraph->setFogData(savedFogData);         // restore fog setting

  // Make sure to remove our fake sun.
  LIGHTMGR->unregisterAllLights();
}

Link to post
Share on other sites

I've got a case where I'm using it for a character preview in 3.5.1 and it functions for that just fine, especially because I'm not doing anything but displaying a player model - no "part changing" or skin swapping or anything, just show available player models. But as we all know, this is tool cool of an idea to not want to see it "done right." Thanks @Azaezel and @TorqueFan for your efforts.

Link to post
Share on other sites

@Azaezel Okay you have given me a LOT to take in in the span of a single posting. I was wondering what had changed that was making me have to set the 'usePostFx' to true during renderWorld() calls using the D3D11 build( or have the model not display at all ).


The problem is, though, when using the postfx( which is a must-have now ) the GuiObjectView's background is not transparent. Is this the "background quad brightening crap" of which you speak Az?


@rlranft The things that Az are looking into will seal the deal I believe moving forward for 3.9 and beyond. I'd like to ensure that we can solve this 'background quad' issue ( or whatever's causing the background of the view to not be transparent ) before posting up the GuiObjectView resource.


Those features I've described I have working in 3.8 and the latest 3.9 development branch( other than the background not being transparent for D3D11, but that's not as a consequence to any changes I've made ).

Link to post
Share on other sites
  • 3 months later...

@Azaezel Any chance you've had any look at 'da list' lately Az? Particularly the "background quad brightening crap"?


With the forward momentum around T3D 3.9 ->4.0, I've taken an interest in updating all of my resources into module form. Still a fly in the ointment, though, as I hadn't figured out what is going on with the postfx/stateblock on the GuiObjectView class.


If you get a chance to take a look or make any suggestions I'd sure be appreciative. It's been a thorn in the side for some time now, and I'd love to complete this work on the class so it can be shared with the community!

Link to post
Share on other sites

Well, i know Jeffs looking into unintialized variables via a one of his tools, and Hutch and Timmys mac work turned up some oddities with stateblocks for what that's worth that might bear fruit, though presumably that's only on the opengl side of things... On the GuiObjectView + playgui blend... haven't gotten too much farther in the research there. (darned gamedev getting in the way of ... gamedev), but I suspect it's at least partly fog related for what that's worth.

Link to post
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.

×
×
  • Create New...