How muсh cost WRITE in RVT?

In material stats part that use for write in rvt dont calculated in result cost and some youtubers say that its cost ZERO.

so question:
How much cost write in RVT and how profiling if use rvt?

You don’t write anything to the virtual texture so much as use it as a lookup.

The virtual texture is like a precomputed stack of math that the engine can figure out before runtime, so when the render call is actually executed, some of the math you might have to figure out along the way in a normal material (w/o a VT), is already done for you or at least in a form where the math can be run fast, a quick-path.

When you build the virtual texture volumes (SVT’s), you are building out those (effectively) look-up tables, you are not actually rendering anything into the texture per-se. What you see in the content-browser as a little-mini-texture is more the math-being-evaluted in the browser and of course, it looks like what you pointed it at… THIS is the costly step, what you likely think about in terms of a ‘write’. Otherwise, at runtime, it’s not really a render so much as a reference.

SO! In that sense, at runtime, you can consider VT lookups ‘cheaper’ than a regular texture-lookup. Writing to the texture more means updating the lookup’s, but then you still have to evaluate those and get the actual thing you want to render, etc. ‘Writing’ isn’t so much rendering a texture like a render-target so much as updating an index.

VT’s are tiled, so they can be such that you only read/write a specific set of the VT, really only what you need to, that’s the point (vs always rendering the entire thing).

As for the no-draw call, anything rendered-into the virtual texture is not an actual mesh, it’s a top-down projection into to VT. So when he is painting grass he’s not really painting meshes but just the lookup information to the textures the grass uses on itself. In this case the VT is more like a big mixing bucket one can render stuff into and the VT holds the aggregate-result.

This has some debugging information if it’s helpful: Runtime Virtual Texturing | Unreal Engine Documentation

what better complex landscape material with 100500 layers?
or write material that already on screen in rvt?

i need more that understanding, i need COST(10? 100? 1000?..)

road write in rvt BUT how i can get more info about cost?
what is chiper decals or rvt?
i need more exact info
BUT thks for answer

Look at it this way: To render a stack of math to get a pixel-color costs you X.

Part of that X can be precomputed and offloaded to the virtual texture, you can assume you save some cost up front from pre-computation.

There are no draw-calls associated with the stuff rendered into the texture if you do not show the mesh, but you still have to render it, if it’s lit, etc, the cost of the materials, etc. All that ought to be the same as a standalone mesh to get it INTO the VT, but there are no draw-calls like a static mesh.

I can’t qualify/quantify the exchange between draw-calls and instruction-count, it’s like trying to convert weight to time; not really straight forward.

SO! What I can say is you save draw-calls (which can generally be more expensive) and lookup overhead, but you still have (generally) the same rendering cost as the things you are capturing to the VT. So, generally, if you can make it work with a VT, it’s going to come out in your favor.

Does that help?

its again story about rvt work.
my question about profiling this work or about cost range(min-max)
difference in ms its not good becouse i have very old hardware and get not correct result…i need only analitic answer or explaining how profiling per-mesh write performance

etc: read from rvt cost near 200 instruction but its only read texture so i think write in rvt can cost much MORE than drawcall
SO i need more exact info

My point is the write is largely done up front, that’s the step to build the SVT. When your computer grinds out that long progress bar.

You can read and write to VT’s in the same material and it doesn’t add 400 instruction, just the ~100-200 it normally does. The cost is the cost of whatever it is the thing that needs to render to the virtual texture costs to normally render, then the overhead to interface with the VT, which can vary based on what channels you send and how the compiler can save math based on this. This can vary and cannot be predicted (at least by me).

The VT’s don’t cache pixel information, they cache texel information. What you do at each texel can vary, depending on the core math to what you capture to the VT on each thing you render to it. There isn’t a formula (that I know of) that will allow you to plug stuff into variables to say ‘hey this object will cost Y extra cost to render to the VT’.

The VT’s are essentially holding a fast-path through the material maths for those things that render to it, but what you choose to pump through it can vary, hence the lack of inexactness. In the larger, general capacity, it always ought to be more performant, subject to the limitations of static meshes, dynamic math in materials, etc.

So far as I know there is no debug output the editor has that can give you the specific kind of information you are looking for. What you really want to do is render things normally on a mesh, count the instruction cost and the frame-rate, and then render everything you want to the VT. Add up the differences across all your items and that’s the cost.

Unsure if decals cost you draw calls, but if they do, rendering to the VT ought to be more performant.

1 Like

When you say “upfront” it may be unclear.

The work is done by the engine, so that when you compile the executable the executable can run faster by using what the engine has computed.

Similar to precomputed lighting.

How much performance you gain depends almost entirely based on what you are doing.

A billion meshes into an rtv are possible.
A billion meshes on screen on a 1060 or less are not even possible.

Of course, if you work on an older machine, you won’t be able to compute the billion meshes in engine either… or at the very best you can expect long wait times…

we have landscape with 6 layers and have material near 300-400 instructions
but in any situation i will see only 2-3 layers so i have overhead material.
using rvt i can create simple material and IF i want add other layers using rvt BUT i want know:
when i START get profit from rvt?
200 instr base material +1 one rvt=6 layer complex material or =8layer material or 50 layer material…
i can check how many rvt i use at once, i know how they sorted and calculated latency
BUT i need info about analitic write cost for best choise not in ms becouse its only one hardware test
i want think about best way fo different situations using analitic date

for example rvt using cost problem:

i can create opaque water with good reflection, shadow, draw coast line… in price chipper than translucent
BUT i dont know how much cost write rvt height ? and its problem what better dancing with opaque or just use translucent?
i think rvt is very good but i afraid that i mistake about it price? becouse dont know write price

There’s another major consideration for you.
RTV still doesn’t support world composition or multiple maps.

If it did, I would have an answer for you in terms of when you start seeing improvements from it.

As it is, it’s completely useless in 99% of my projects…

i dont need that in this project
its strategy so i dont need world exploration fucntionality(“fog walls” work fine for hiding some map parts)

In this case, you are probably better off setting up to use it.
It’s going to allow for a faster final publish eventually.

Of note, foliage doesn’t draw into the RTV unless they fixed it. My last attempt on that was in .25 I think.

no payment==no deadlines.
we are indie…and dont have 2-3-4 chance make our game good, only one…

Faster as in better performance - not time of development.

better performance==saving time for content optimisation or more content on screen.

lets back totopic question:
how much cost write in rvt?

You’re asking a question that doesn’t have a definite answer; ‘cost’ isn’t going to break down to a specific number somewhere. Generally, when you use an RVT you would realize (decent) performance gains where-ever it can be applied.

Instruction-count-wise, what you see in the material editor is the only exact answer the engine is going to give you. I get you (and anyone else) want to save as many instructions as you can (I DO TOO!!) but the only feedback you can get in this area, with a specific number, is the difference you see in the material editor between what it costs material X to render, then after you hook it into the RVT.

Otherwise, because the RVT can be touched by so many things, it’s very hard to qualify how it improves X, Y, or Z. As lame and basic as it sounds, the best way to gauge your performance is by using the stats commands, FPS mostly.

FWIW the use of an RVT should never COST you more, it can only improve things.

EDIT: with regards to that green/red graph in the first post, that only hinges off the raw instruction count. It doesn’t reflect texture samplers/samples, and b/c they are not accurately represented, that diag is useful but inexact. This lack of visibility into some things in the engine is why I can’t really point you to an exact answer, but only point you to things you can look at with the idea that if all those things get better/more-performant, that’s the ideal. How MUCH better, again, largely depends on what you, the particular developer, choose to do with it.

1 Like

again talk about rvt…
i need price or info about rvt profiling.
i understand that its not easy question but i need answer exactly for this questions.
all talking about “good”, “must be”…its opinion i want something MORE analitic (explain how to profiling rvt cost will be best)

And I am telling you to the best of my knowledge, there isn’t any.

i heard you
and will waiting more good answer(i need more exact info)
info about price or profiling! all other answer dont metter

OK, have fun waiting :smiley:

1 Like

Hey guys, make sure we’re being civil. We’re all here to help :+1: