This is an implementation of UTexture2D that is always a streaming virtual texture with specific tile settings from the renderer project settings.
It allocates a virtual texture on creation (instead of relying on a he material do the allocation), and tracks the allocated virtual textures.
It can provide a 2 dword descriptor giving the location of the virtual texture in the shared virtual texture pool.
It can provide a description of the shared virtual texture pool for binding to the view uniform buffer.
[CL 34578717 by jeremy moore in ue5-main branch]
Add project renderer settings to disable specific RVT material types.
This allows us to remove shader permutations for types that we know that we don't need.
Specification can be overridden per platform if necessary.
When removed, material types no longer show up in selction option for RVT asset.
If an RVT has a removed material type then the RVT volume is not instantiated.
#rb jonathan.bard
[CL 33922564 by jeremy moore in ue5-main branch]
Remove "apply filter" button, and apply filter whenever we change the filter value in the dropdown.
Select initial filter value as min or max size according to whether we are converting to VT or from VT.
Default initial filter value is fully inclusive so that we don't get strange UX of selecting to convert a set of textures but none of them pass the initial filter.
#test In editor select to convert one or more VT textures to regular (or the other direction) and validate that all selected textures appear in inital filtered view.
[CL 33424132 by jeremy moore in ue5-main branch]
This only applies when the streaming low mips are already enabled and showing. It forces the use of only the streaming virtual texture with no runtime pages. This is intended for workflows that use RVT only as a means to generate some baked world texture for sampling.
Also changed "Show in Editor" to be a persistent setting, since that is what would be required for such a baked only workflow.
To help with debug only workflow to show SVT in editor, added r.VT.RVT.StreamingMips.UseInEditor which when set to 0 will force SVT off in editor, 2 will force on in editor, and 1 will obey the RVT volume setting.
#rb jonathan.bard
[CL 33273653 by jeremy moore in ue5-main branch]
* Prevent mobile-specific SVT textures to be displayed if Virtual Textures on mobile is disabled in the project settings
* Various UX adjustments to make it clear to the user what to expect when using mobile-specific SVT
#rb chris.tchou, jeremy.moore
#tests editor
[CL 32792706 by jonathan bard in ue5-main branch]
* Ensure the set bounds are valid in the case of a flat mesh
* Take into account the unloaded components bounds when the bounds align actor is a landscape
#rb don.boogert
[CL 32768930 by jonathan bard in ue5-main branch]
- FRHITexture2D
- FRHITexture2DArray
- FRHITexture3D
- FRHITextureCube
- FTexture2DRHIRef
- FTexture2DArrayRHIRef
- FTexture3DRHIRef
- FTextureCubeRHIRef
Replaced with FRHITexture and FTextureRHIRef
These types were unified in UE 5.1 and have been defined via "using" statements to the same underlying texture type for several engine releases.
#rb christopher.waters
[CL 31724002 by luke thatcher in ue5-main branch]
Added support for writing fixed color when baking SVT. This replaces the fixed "debug" function and allows us to use the feature outside of debug usage.
Fixed path that creates an SVT for displacement map. Here the fixed color can be used to effectively set a zero displacement for the low resolution mips.
Added r.VT.RVT.MipColors cvar which uses the fixed color support to generate RVT using debug mip colors. This is useful for debugging issues with materials sampling higher resolution mips than expected, putting pressure on the physical pools.
Removed r.VT.RVT.EnableVolumes cvar which is no longer required now that volumes can be enabled/disabled per platform without triggering page table or physical texture allocations.
Added support for custom expanding of bounds for RVT volume.
Tidied naming of categories and sections for the RVT components.
[CL 30550025 by jeremy moore in ue5-main branch]
When calculating RVT bounds, if the bounds align actor is a landscape, then include all of its landscape components.
[CL 30091367 by jeremy moore in ue5-main branch]
Texture IsPowerOfTwo check was confusingly only checking first block
most call sites want to check AreAllBlocksPowerOfTwo
deprecate the old problematic function name
#rb dan.thompson
#rnx
[CL 29820923 by charles bloom in ue5-main branch]
shrinks sources above threshold size to make uassets smaller
tries to change LODBias to keep output size the same, but that is in no way guaranteed
#rb dan.thompson
#rnx
[CL 29527423 by charles bloom in ue5-main branch]
Render Command Pipes dedicated asynchronous task pipes for render commands. Users can easily define new pipes and enqueue commands into them. Pipes can be synchronized using a scope to run serial render commands on the render thread, but initially pipes cannot be synchronized individually with each other. Render command overhead is reduced by recording command lambdas into MPSC queues which are serviced by the task graph; both for pipes and for the render thread. This reduces the task overhead as commands are no longer 1-to-1 with tasks.
Pipe behavior is controlled with new CVars. `r.RenderCommandPipeMode` controls overall behavior:
0 - Legacy render thread tasks,
1 - Render thread MPSC queue,
2 - Render thread and async pipe MPSC queues.
To define a Render Command Pipe, use DEFINE_RENDER_COMMAND_PIPE(MyPipe), or DECLARE_RENDER_COMMAND_PIPE(MyPipe, MODULE_API) to declare an extern reference.
Enqueue a command into the pipe like so:
ENQUEUE_RENDER_COMMAND(MyCommand)(UE::RenderCommandPipe::MyPipe, [] (FRHICommandList&) {}).
Omitting a pipe will fallback to the 'general' pipe which is the render thread.
Eventually pipes need to be synced back to the general pipe for scene renders and other GPU work. On the game thread timeline, use UE::RenderCommandPipe::FSyncScope to synchronize the pipes. This waits for pipes and disables recording of new pipe commands until the scope completes, at which point pipe recording is restarted. This creates a 'sync point', so render commands issued prior to a sync scope will be waited on at the start of the scope, and render commands issued after the scope ends will not be able to start until the render thread finishes processing prior commands.
#rb christopher.waters, luke.thatcher
[CL 27074956 by zach bethel in ue5-main branch]
[FYI] zach.bethel
First Original CL Desc
-----------------------------------------------------------------
Moved volumetric volume to RHICmdList.
[CL 27054300 by bob tellez in ue5-main branch]
[FYI] zach.bethel
Original CL Desc
-----------------------------------------------------------------
Render Command Pipe Implementation and API
Render Command Pipes dedicated asynchronous task pipes for render commands. Users can easily define new pipes and enqueue commands into them. Pipes can be synchronized using a scope to run serial render commands on the render thread, but initially pipes cannot be synchronized individually with each other. Render command overhead is reduced by recording command lambdas into MPSC queues which are serviced by the task graph; both for pipes and for the render thread. This reduces the task overhead as commands are no longer 1-to-1 with tasks.
Pipe behavior is controlled with new CVars. `r.RenderCommandPipeMode` controls overall behavior:
0 - Legacy render thread tasks,
1 - Render thread MPSC queue,
2 - Render thread and async pipe MPSC queues.
To define a Render Command Pipe, use DEFINE_RENDER_COMMAND_PIPE(MyPipe), or DECLARE_RENDER_COMMAND_PIPE(MyPipe, MODULE_API) to declare an extern reference.
Enqueue a command into the pipe like so:
ENQUEUE_RENDER_COMMAND(MyCommand)(UE::RenderCommandPipe::MyPipe, [] (FRHICommandList&) {}).
Omitting a pipe will fallback to the 'general' pipe which is the render thread.
Eventually pipes need to be synced back to the general pipe for scene renders and other GPU work. On the game thread timeline, use UE::RenderCommandPipe::FSyncScope to synchronize the pipes. This waits for pipes and disables recording of new pipe commands until the scope completes, at which point pipe recording is restarted. This creates a 'sync point', so render commands issued prior to a sync scope will be waited on at the start of the scope, and render commands issued after the scope ends will not be able to start until the render thread finishes processing prior commands.
#rb christopher.waters, luke.thatcher
[CL 27054009 by bob tellez in ue5-main branch]
Render Command Pipes dedicated asynchronous task pipes for render commands. Users can easily define new pipes and enqueue commands into them. Pipes can be synchronized using a scope to run serial render commands on the render thread, but initially pipes cannot be synchronized individually with each other. Render command overhead is reduced by recording command lambdas into MPSC queues which are serviced by the task graph; both for pipes and for the render thread. This reduces the task overhead as commands are no longer 1-to-1 with tasks.
Pipe behavior is controlled with new CVars. `r.RenderCommandPipeMode` controls overall behavior:
0 - Legacy render thread tasks,
1 - Render thread MPSC queue,
2 - Render thread and async pipe MPSC queues.
To define a Render Command Pipe, use DEFINE_RENDER_COMMAND_PIPE(MyPipe), or DECLARE_RENDER_COMMAND_PIPE(MyPipe, MODULE_API) to declare an extern reference.
Enqueue a command into the pipe like so:
ENQUEUE_RENDER_COMMAND(MyCommand)(UE::RenderCommandPipe::MyPipe, [] (FRHICommandList&) {}).
Omitting a pipe will fallback to the 'general' pipe which is the render thread.
Eventually pipes need to be synced back to the general pipe for scene renders and other GPU work. On the game thread timeline, use UE::RenderCommandPipe::FSyncScope to synchronize the pipes. This waits for pipes and disables recording of new pipe commands until the scope completes, at which point pipe recording is restarted. This creates a 'sync point', so render commands issued prior to a sync scope will be waited on at the start of the scope, and render commands issued after the scope ends will not be able to start until the render thread finishes processing prior commands.
#rb christopher.waters, luke.thatcher
[CL 27042459 by zach bethel in ue5-main branch]
