We want to send these a lot of these values to a large number of dynamic materials (in a parameter linked to a custom node) in the cleanest possible way.
Every bit economised is important here, because we have to send a lot of information.
We had considered sending this information as a texture, but the issue is that textures have width and length limitations; this requires spreading our lists across many rows, which leads to poor reconstruction.
The ideal approach would be to send a raw list of 32bits elements, thereby avoiding the need to reconstruct the data from a texture.
We know that GPU works mainly with float number.
Hey thanks for the replying !
We need to send something like 28 lists, each containing up to 524,288 uint32. Most of the time, the lists won’t be at their maximum size, so each one should involve sending around 100,000 uint32.
As for the MPC, I’m not sure if it can receive buffers? Because to send such a quantity of information, it seems quite complex to me to go through that (apart from modifying the engine so that an MPC can receive buffers)
I think we could use a render target, the only problem being accurately transferring my uInt32 data into 3-color vectors.
This shouldn’t be too much of a problem if color detection were accurate. However, when reading a render target into a material, having tested this solution beforehand, and asking Unreal to output the color value of a pixel, it often gets it wrong by one or two values (e.g., a color (255,12,5,1) becomes (255,15,10,1)).
Furthermore, alpha isn’t detected, so instead of having a color where alpha is 0.5, it detects alpha as 1 and that the color is darker. Therefore, in a 32-bit color vector, only 24 bits are usable, resulting in a considerable loss of data.
I’m mainly a materials-type person. Big believer in making-the-GPU-do-it if you can.
I don’t know if a landscape is involved, but you mention materialS, plural, so I’m thinking share-ability.
Runtime virtual-textures are great for sinking lots of visual information into, and making them widely-accessible in any material as it samples like an RT, just-a-texture. Not super-familiar with the finer-details of your solution, but it’s something that is writable, cache-able for the tiles/parts that don’t update from frame to frame, it works well with other systems, landscapes included (in particular), and is something that enables horizontal-information-exchange (is 1:many for being able to sample in assets).
Is the painted-area you referring to something like set-and-forget, like you sculpt and then leave it? Or is it like Splatoon where it’s something updating all the time owing to changes in the environment? RVTs can update ‘live’ in they can prioritize tiles that are visible for updates, but not knowing the overall cost of what goes into them you can never guarantee you get a live-level performance from the thing. RVTs are meant to be an information sink meaning you put lots of things in there so the cost can be open-ended in that regard..
Different RVT-types have different levels of compression, so check into the settings. Drift will become an issue, but you can also jack up the resolution to decent levels, so granularity might help sidestep the issue? Idunno, I am just spitballing here.
Otherwise, outside myskillset there might be some custom-shader code you could write to migrate such data, but not something I’ve ever gotten close to trying on my own either, sorry.
To answer your questions, firstly it is indeed similar to what Splatoon can do with very regular updates.
There is no real use of landscape here. If I mentioned several materials it is because all the actors of the level are concerned, and must therefore receive part of the information.
Can RVTs completely circumvent the compression problem?
To answer your questions, firstly it is indeed similar to what Splatoon can do with very regular updates.
There is no real use of landscape here. If I mentioned several materials it is because all the actors of the level are concerned, and must therefore receive part of the information.
Can RVTs completely circumvent the compression problem?
I just read the modification of your message, thank you all the same for your help, I will perhaps try to find other solutions to get around these problems.
So yea, thank you for all !
Not really, the problem with this plugin is that it links the paint data directly to the meshs. We already had that system, and I was asked to create a system linked directly to the world, in order to improve performance when there are many objects in the scene. But thank you anyway for sending me this link !
So when using the landscapes with RVTs there is in option to render the landscape as a single-quad. Since the RVT is top-down, XY projection, this results in a significant speed savings..
I’ve also used a single-quad, the same dimensions as my landscape as a big splat-target to paint to. This single mesh is not rendered in the main pass, only to the RVT, to then be sampled as required by other things.
My suggestion is that if a landscape, conceptually, might fit the bill, but b/c the landscape stuff is not sharable, maybe use that single, giant-quad as an intermediary target and work from there? It might allow you to use that networked paint plugin?
The main idea being you could have target(s) that don’t render and only act as paint-targets. These collectively render to the RVT which is widely-available in materials as just-a-texture.
If you can get any of your game-logic, etc onto the material-shader, it might result in a good performance savings as well.
But I have a question: since the VT is just a projection onto the XY plane, won’t there be issues with the walls? Even with multiple projections, isn’t there a risk of artifacts?
Yes we need all projections, that’s why I initially leaned towards an approach where I’d pass 3D coordinates to the materials on the fly, allowing them to render the paint themselves. However, I’m not sure how to send that much data to the material without data loss.