Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BsfImportTool depends on pre-built assets, crashes without them #387

Open
nemerle opened this issue Aug 8, 2019 · 2 comments
Open

BsfImportTool depends on pre-built assets, crashes without them #387

nemerle opened this issue Aug 8, 2019 · 2 comments
Labels
type: bug Something isn't working
Milestone

Comments

@nemerle
Copy link
Contributor

nemerle commented Aug 8, 2019

I've encountered this problem when working on the VertexDataDecl PR, when the VertexDataDecl was used in some places that caused the serialized structure layout to change in GpuProgramBytecode. I can force it to work by reverting a few changes around there, but I think that this problem can make any future changes to serialized shader asset layout quite painful? Below is the analysis of the issue:

The import tool cannot be started if the compiled shader assets are missing. Even if we want to create compiled shader assets 😄

This is caused by the following reduced chain of calls:

  • Running bsfImportTool on "IrradianceComputeSH.bsl" executes:
  • Application::startUp which calls
  • RenderBeast::initializeCore which calls
  • RenderBeastIBLUtility::filterCubemapForIrradiance which requires that BuiltinResources::getShader returned a proper shader for "IrradianceComputeSH.bsl"
  • and that requires the asset to already exist.

This looks very much like a bootstrap problem encountered when a compiler is written in a language it's meant to compile.

@BearishSun
Copy link
Member

Yeah I've encountered this myself last week. The proper solution would be to get the import tool to compile with null renderer and render backend. If that's not enough, then add checks in these sort of places, so they can handle the case when the builtin assets are missing (or an #if with a separate code path for the import tool).

It's something I'll get around to, but for now not a high priority unless its blocking someone.

@BearishSun BearishSun added the type: bug Something isn't working label Aug 8, 2019
@BearishSun BearishSun added this to the Longterm milestone Aug 8, 2019
@nemerle
Copy link
Contributor Author

nemerle commented Aug 8, 2019

Simply replacing it with null renderer and backend fails around here

#2  [addr] in bs::Module<bs::ct::RenderAPI>::instance () at bsfUtility/Utility/BsModule.h:30
#3  [addr] in bs::ct::GUISpriteParamBlockDef::initialize (this=0x7ffff7fc5dc0 <bs::ct::gGUISpriteParamBlockDef>) at bsfEngine/GUI/BsGUIManager.h:445
#4  [addr] in bs::ct::ParamBlockManager::ParamBlockManager (this=0x51c2a0) at bsfCore/Renderer/BsParamBlocks.cpp:18
#5  [addr] in bs::bs_new<bs::ct::ParamBlockManager> () at bsfUtility/Allocators/BsMemoryAllocator.h:354
#6  [addr] in bs::Module<bs::ct::ParamBlockManager>::startUp<>() () at bsfUtility/Utility/BsModule.h:71
#7  [addr] in bs::CoreApplication::onStartUp (this=0x4c8aa0) at bsfCore/BsCoreApplication.cpp:173
#8  [addr] in bs::Application::onStartUp (this=0x4c8aa0) at bsfEngine/BsApplication.cpp:52
#9  [addr] in bs::Module<bs::CoreApplication>::startUp<bs::Application, bs::START_UP_DESC const&> (args#0=...) at bsfUtility/Utility/BsModule.h:92
#10 [addr] in bs::Application::startUp<bs::Application> (desc=...) at bsfEngine/BsApplication.h:40
#11 [addr] in main (argc=4, argv=0x7fffffffe458) at bsfEngine/Resources/BsBuiltinResourcesImporter.cpp:60

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants