Class: NTCNodeMaterial
A MeshPhysicalNodeMaterial driven by one trained NTCTrainer
model: channels the source material actually varied spatially ( activeChannels) read a decoded slice of one shared grid + MLP forward
pass - all from the same pass, matching the NVIDIA neural texture
compression "one decoder, many correlated channels" design - while
channels that were just a flat constant on the source material
(constantValues) are applied directly as ordinary material properties,
bypassing the network entirely (see NTCSource.
classifyMaterialChannels for why: no sense spending network capacity, or
training-sample budget, reproducing a value that never varies).
Applying a trained slice or a resolved constant onto this material is
itself channel-defined, not hardcoded here - see each channel descriptor's
applyActive/applyConstant in NTCFormat.js. This constructor
is a fully generic loop over whatever channels array the classification
was built from (options.channels, defaulting to the built-in CHANNELS
vocabulary), so a caller-supplied custom channel array works exactly the
same way the built-in one does.
Example
import { NTCNodeMaterial } from 'three-ntc';
Extends
"three/webgpu"
Indexable
[
key:string]:any
Constructors
Constructor
new NTCNodeMaterial(
cpuModel,channelClassification,options?):NTCNodeMaterial
channelClassification is whatever NTCSource. classifyMaterialChannels returned - { activeChannels, constantValues, totalChannels, packCount } - passed through as-is rather than
destructured by the caller, since the two fields this constructor
needs are always produced together and never meaningfully used apart.
options.channels is the full channel array (active + constant alike)
channelClassification was produced from - defaults to the built-in
CHANNELS vocabulary, matching classifyMaterialChannels's own
default, since setDebugView needs every channel descriptor (not just
the active ones) to resolve a debug view by key.
options.renderer is accepted for callers that already pass one through
from examples, but the stock path uses fp32 decoder uniforms.
Parameters
cpuModel
channelClassification
options?
Returns
NTCNodeMaterial
Overrides
MeshPhysicalNodeMaterial.constructor
Properties
activeChannels
activeChannels:
NTCLayoutChannel[]
channels
channels:
NTCChannel[]
cpuModel
cpuModel:
NTCCpuModel
levelTextures
levelTextures:
any[] |null
mipChainTexture
mipChainTexture:
any
uvTransform
uvTransform:
NTCMatrix3Like
Accessors
samplingMode
Get Signature
get samplingMode():
"nearest"|"stochastic"|"trilinear"
Returns
"nearest" | "stochastic" | "trilinear"
Set Signature
set samplingMode(
mode):void
Parameters
mode
"nearest" | "stochastic" | "trilinear"
Returns
void
Methods
dispose()
dispose():
void
Returns
void
setDebugView()
setDebugView(
view):void
Swaps the visible output between the full physically-shaded material
and an unlit preview of one channel in isolation - trained or
constant alike - matching NTCSource. buildChannelPreviewMaterials on the teacher side, so both are
comparable directly.
Parameters
view
string
Returns
void
setLodBias()
setLodBias(
bias):void
Retunes the auto-LOD bias (see computeAutoLodNode's doc comment) after
construction - just writes .value on the uniform() node the
constructor already built lodNode from, so (unlike lodBias's
one-time-baked plain-number form) this takes effect on the very next
frame with no material/node-graph rebuild. A no-op when this material
was built with an explicit options.lodNode override, since there's no
bias uniform feeding into a caller-supplied LOD node.
Parameters
bias
number
Returns
void
setSamplingMode()
setSamplingMode(
mode):void
Rebuilds the TSL graph for this mode; the renderer compiles it on next use.
Parameters
mode
"nearest" | "stochastic" | "trilinear"
Returns
void
updateFromModel()
updateFromModel(
cpuModel?):void
Upload new values without changing textures, uniforms, or shader graphs.
Parameters
cpuModel?
NTCCpuModel = ...
Returns
void