[1.12.3] need access to shader compile errors and loadHighLevel()

[loath]

my project uses custom shaders for everything under directx 9. i compile shaders on background threads to avoid frame hiccups. to support this i make a single change to vanilla ogre:

HighLevelGpuProgram::loadHighLevel() must be public instead of private so i can call this function manually on a worker thread. (directx 9 is not thread safe except for the shader compiler function, fortunately for me)

awhile back paroj suggested I implement this in terms of custom shader parameters for submission to mainline ogre:

(from github)

this method is not really meant for public use as it is not properly locked.
Would a simple load() work as well or is createLowLevelImpl problematic?

alternatively use createParameters to trigger loadHighLevel only.

this solution works great with one problem: i would also like to catch the ogre exception thrown when compilation fails in order to display in my toolset UI. for now i'm considering making a second modification to vanilla ogre to change GpuProgramType::loadFromSource() from protected to public. this function throws the compilation exception which i could use in my toolset. normally this exception is caught higher up in loadHighLevel() so without making loadFromSource() public the only thing i know is that GpuProgram::mCompileError == true when compilation failed.

before i investigate implementing the custom shader parameter approach i want to get feedback on the best way to expose or access the error info above. any ideas?

thanks!

[loath]

attaching a LogListener during the compilation call works. it isn't pretty but it's good enough.

i just need to figure out the best way to implement accessing loadHighLevel().

[paroj]

I am afraid that this will require some deeper refactoring inside Ogre. Currently there are the following issues:
- GpuPrograms do not properly follow the prepare > load cycle, but instead do everything in load. With proper separation, you could just call prepare on the background thread. In fact for D3D9 loadHighLevelImpl is the prepare step. https://github.com/OGRECave/ogre/issues/1361
- there is no mechanism to properly signal a compilation error like Material::getUnsupportedTechniquesExplanation

[loath]

ok, i'll just keep making LoadHighLevel() public for now. prepare makes non-thread-safe dx9 calls (i think to assemble the compilation results) or i would use that.

thanks!

[paroj]

when https://github.com/OGRECave/ogre/pull/1366 lands, HLSL shaders will be compiled in prepare() (throwing).
This means that you can just do background preparation and will get any errors in BackgroundProcessResult::message

[loath]

i finally got around to upgrading to 1.12.5. (i didn't see a release announcement for 1.12.5... i assume this is an official build?)

the 1.12.4 prepare() change works great! i'm finally using vanilla ogre again so thanks. (PS. the node-based camera and light changes were easier to port than i thought thanks to the guide.)

RE: https://ogrecave.github.io/ogre/api/lat ... ource.html

if you need to background load skeletons, like i do, you can:
1. create and register a Ogre::MeshSerializerListener derived class. in the processSkeletonName() callback i zero out the mesh name to prevent the skeleton from being loaded on the main thread.
2. i then create a skeleton resource via the Ogre::SkeletonManager and call it's load function on a worker thread. Skeleton::load just deserializes the mesh data into memory so it works fine on background threads.

perhaps in the future, this deserialization could be moved into the prepare() method like the other resources making Skeletons "officially" supported for background streaming.

[paroj]

i finally got around to upgrading to 1.12.5. (i didn't see a release announcement for 1.12.5... i assume this is an official build?)

I usually dont write announcements for point releases - the last releases just coincided with notable new features.
All releases and change-logs are at:
https://github.com/OGRECave/ogre/releases

which you can also subscribe to via RSS.

perhaps in the future, this deserialization could be moved into the prepare() method like the other resources making Skeletons "officially" supported for background streaming.

I think there was something preventing file reading to be done at prepare, however I will check again.

[paroj]

1. create and register a Ogre::MeshSerializerListener derived class. in the processSkeletonName() callback i zero out the mesh name to prevent the skeleton from being loaded on the main thread.

I think this was the reason, as skeletons are only requested at Mesh::load by the serializer i.e. on the main thread. Ideally this would be done at Mesh::prepare. However, the mesh serializer creates hardware buffers, so we cannot use it there.

Anyway I moved the Skeleton loading to prepare. While this does not solve the above issue, it makes your workaround slightly easier:
https://github.com/OGRECave/ogre/pull/1 ... 814a3a1475

[loath]

fantastic. thanks so much!