Navigation
API > API/Runtime > API/Runtime/Engine > API/Runtime/Engine/FExpressionVirtualTextureUnpack
- FExpression::PrepareValue()
- FExpressionVirtualTextureUnpack::PrepareValue()
References
| Module | Engine |
| Header | /Engine/Source/Runtime/Engine/Public/MaterialHLSLTree.h |
| Include | #include "MaterialHLSLTree.h" |
| Source | /Engine/Source/Runtime/Engine/Private/Materials/MaterialHLSLTree.cpp |
virtual bool PrepareValue
(
FEmitContext & Context,
FEmitScope & Scope,
const FRequestedType & RequestedType,
FPrepareValueResult & OutResult
) const
Remarks
Computes a FPreparedType for this expression, given a FRequestedType. Will be called multiple times, with potentially different requested types, if the FExpression is used multiple times. In this case, all the prepared types will be merged together if possible (or generate an error otherwise). PrepareValue will be called in two phases, first with Context.bMarkLiveValues=false, then with bMarkLiveValues=true. If Context.bMarkLiveValues is true, the expression should record any state to signal to the client that it's active. For example, a material expression parameter might add the parameter name or texture value to the material data. This is typically done through the Context.FindData() interface. If Context.bMarkLiveValues is true, the expression should also take care not to call Context.PrepareExpression for any nested expressions that are not relevant to the final result. For example, in a multiply expression where one input is 0, the other input is not relevant, and can be skipped. The EExpressionEvaluation set by this is important for determining which EmitValue*** methods may be called A given FExpression implementation must support at least one of EmitValueShader/EmitValuePreshader, but doesn't need to support both TODO? - It feels messy to have PrepareValue() used for both of these phases, possibly better to have a separate MarkLive() virtual method...in practice that would often lead to duplicate code however