Is in the RealTimeImportBPLibrary. It’s even in the changelog.
1 Like
That would be really great.
Texture variables.
Thank you! )
If the virtual textures work with “Texture 2D Object Reference” this should be compatible with my plugin. It would be important to test it in a build as the editor can behave differently in this case. You can create a variable with this type and test it.
As far as texture compression is concerned, it looks bad. I found a note of mine from December 2023. It says: “Probably not possible in unreal. According to the forum even not legal because of license stuff.”
Do you need Mip Maps? Without them, the memory requirement is significantly reduced.
These are different classes. ( Their common class is texture.
In the project settings, you need to enable virtual textures. Then download the textures from the link, select all of them, and drag thems into the content browser. You need to achieve this result in real time so that afterward you can take the three imported textures, add them to the prepared material, and apply it to the mesh.
1001, 1002, 1003 - these are the mesh’s UDIM numbers.
Thanks for the files. I had a quick look at the topic. There seems to be a “Virtual Texture 2D Object reference”. I would have to take a closer look. Basically, just like with normal textures, you just create a material and insert them there or not? I don’t know when I’ll have time to test that.
Your example textures are also only a few kilobytes in size. I don’t see a problem there. Rather with the way they are assigned to the meshes.
These textures were created specifically for this example and simply have different colors.
I think the most important thing is to load them correctly in real time, and after that, I don’t expect there to be any problems.
Yes, it has to be set up in the material exactly as shown in the screenshot so that they work on the mesh.
If you need a model for testing, I can make one. It’s a very important feature. )
Thank you in advance! )
I can play around with the virtual textures at the weekend. But this is only about VRAM not RAM. I don’t think it’s possible to stream the textures from SSD.
Is there any information?
Maybe we should build a simple model for testing?
I use the standard static mesh cube. I think that’s enough, don’t it? Anyway, I have looked for functions in the engine that create virtual textures. I also found some. I also found the variable VTData in the texture. It probably has to be filled. Unfortunately, I haven’t managed to do that yet. The engine has the “if editor” macro in many places. Code within only works in the editor. I am still looking for solutions. But it doesn’t seem to be that easy.
No, that’s not enough. The model itself needs to contain information about UDIMs so that the required textures—1001, 1002, and so on—are applied to the correct faces on the model. A standard cube doesn’t have this information.
The information is needed for what? I tried a ~400MB png file as a virtual texture and checked it with stat rhi. Seems to have worked as no VRAM utilization was seen. When I imporitere the same file via my plugin I see ~800MB additional.
Edit
I tried another project without virtual textures. stat rhi shows no difference here either. I must be going the wrong way somewhere.
I created a model made up of 10 boxes, each with its own UDIM number. For testing, if you import this model into the UE editor and create a material from the textures I shared earlier (as shown in the screenshot above), then apply this material to the model, each box should get its own color that matches its UDIM number.
https://www.sendspace.com/file/nq4vlr
In the end, it should look like this.
UDIM tiles
I don’t think I understand what the goal is anymore or what virtual textures are. It’s about the vram utilization or not? How do these few byte textures help?
No, these textures have nothing to do with video memory.
We need to make the plugin recognize these textures the same way the UE editor does.
Okay, then we’ve been talking at cross purposes. Can’t you do that with blueprints? The names of the meshes and textures should be returned by the plugin. Can you use this to implement this or not? If not, what’s missing?
When importing these textures into the UE editor, it recognizes that T_AGR_Test_Diffuse_1 actually consists of 10 textures (from 1001 to 1010), and instead of creating 10 separate textures, it creates a single virtual texture. The same happens with T_AGR_Test_ERM_1 and T_AGR_Test_Normal_1. As a result, instead of having 30 textures total, we end up with just three virtual textures, which are then connected to the material. Consequently, the model ends up being colored in different colors.
You can add a new function to the plugin that, following the UE editor’s approach, recognizes and imports these UDIM textures.
Yes, I would have to combine the images. I’m not sure if that’s going too far. Sounds like a painting program. Can’t you combine the textures in one material? I just tried it but my frontend skills are limited. 
Yes, you can start with that. )
Could you make it so that during import, the plugin recognizes textures starting from .1001 (for example, up to .1010) and combines them in order into one large texture? Then we could load the resulting Texture 2D Object Reference into the material, and I’d check to see if that works. That might be enough. You could add an optional flag in the function that enables this feature, or maybe it would be simpler to create a new function for it. Thanks! )
