OK, great, since C4 currently doesn't expose RTT to applications.

I've checked in the meantime, and yes, C4 maintains the state of relevant variables on the CPU side. There are methods for setting state variables (though currently no ones for getting the values), however, the engine doesn't expect other apps to modify that (it always checks if newState != oldState before issuing calls to the GPU).

I was wondering if the NooesisGUI API could add virtual methods for setting the state that could be overridden by integration code. So the default implementation would just call whatever you do now (like glEnable(XY)), but an engine integration could replace that with its won call (GraphicsMgr::SetBlendState(XY) or whatever). Such an API structure would make integrations easier, I think.

I've checked in the meantime, and yes, C4 maintains the state of relevant variables on the CPU side. There are methods for setting state variables (though currently no ones for getting the values), however, the engine doesn't expect other apps to modify that (it always checks if newState != oldState before issuing calls to the GPU).

Then for now, the best way is using the same code as LeadWerks wrapper.

I was wondering if the NooesisGUI API could add virtual methods for setting the state that could be overridden by integration code. So the default implementation would just call whatever you do now (like glEnable(XY)), but an engine integration could replace that with its won call (GraphicsMgr::SetBlendState(XY) or whatever). Such an API structure would make integrations easier, I think.

Problem with that approach is that inserting a virtual call on each microstate change can penalize the performance. The ideal solution would be implementing a new rendering (implementing a new IRenderSystem) using the API exposed by C4. That is the solution is going to be taken in Unreal integration.

But for now, I would implement the approach you are following. Once it is working we can look for better solutions.