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

[chriscalef]

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]

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]

Ah, thanks for that info, didn't know it was just the empty template.

[JeffR]

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]

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]

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]

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]

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

[Azaezel]

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.

[JeffR]

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.

[Tiel]

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.

[Azaezel]

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

[Tiel]

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?

[Timmy]

If you see any problems with DX11, just pile them up in this thread and i'll fix as they come in ;) http://forums.torque3d.org/viewtopic.php?f=40&t=473

[rlranft]

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

[TorqueFan]

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

[rlranft]

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

[TorqueFan]

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 =)

[Azaezel]

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();
}

[rlranft]

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.

[TorqueFan]

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

[Azaezel]

@TorqueFan yep.

[TorqueFan]

@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!

[Azaezel]

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.

[TorqueFan]

As promised, I am appreciative of your insights Az ;)