Related to the AnswerHub question here, is there a way for us to supply our own textures and have the engine use them directly without going through the process of copying the data to memory then copying it to unreal’s memory where it then gets copied to a driver temp space before finally getting loaded as a texture. I have some streaming data that is going directly to a texture in a hardware accelerated way and I would really like to use it directly.
Is there any existing class to support This use-case or a simple way to subclass an existing one like Texture2D to support this?
I would also like to know the answer to this question as this seems necessary for hardware accelerated video decoding.
It could also prove useful for libVLC support, doing the rendering and color space conversion directly in UE4 rather than reading the GPU rendered VLC frames back to memory and then to the GPU again using UE4.
I found and just tried out ‘UpdateTextureRegions’ which according to my timings is plenty fast for me!
I used QueryPerformanceCounter for my timings and am getting some very low numbers if I’m doing it right, which I think I am. You guys should try it if you haven’t already.
Oh I see I just tried to do File->Package project with my simple test setup and indeed I just get a black screen. It worked in Play->Standalone.
Would any engine dev’s be able to chip in and and tell us a bit more please?
Is there a way to get this working somehow ourselves? Can this be made to work in the near future? It seems like a bunch of people are wanting to have this functionality!
(is there a list of things that work in the editor but will not work in a full build? It should probably be removed from the wiki if it is not working.)
I’m currently using that. You need to copy and paste the code from the wiki because you’re right, it isn’t available in a cooked build. The problem is this kills memory bandwidth depending on how large your streaming textures are. If you already have a texture on the GPU that you just need to use you’ll end up:
copy from GPU to CPU, for your use
copy from CPU to CPU, Unreal Engine memory for update region to work
copy from CPU to CPU, copy from Unreal Engine’s memory location to the Direct3D driver memory buffer location to upload to GPU
copy from CPU to GPU, Direct3D to GPU texture upload
I’m guessing that this is the order, but even if you can magically skip the two center steps you’re still doing a copy from GPU to CPU then back to GPU for something that is already on the GPU and ready to use. I’m trying something painful right now subclassing UTexture2D, FTexture2D and one more class and seeing if there is any way to force my texture in there directly. So far it isn’t working but there is a chance.
PS: feel free to upvote the question on the answerhub in case a highly voted question with 0 answers will end up getting a response
so are you saying that when you copy and paste that wiki function into your own class it should work cooked? Just because that is what I did and it gives me the black screen after the File->Package.
It went through the package build ok so should I assume no major build/link errors do you think?
In my case I will start off with my texture data on cpu so maybe I’ll be fine. (If it is as fast as in the editor-play then i’m ok) Though when you are saying ‘memory bandwidth’ I’m not 100% what you mean.
I can’t say why it shows a black screen after packaging. To be honest I haven’t needed to package yet since 4.4 so I don’t know if there has been a regression. It certainly worked for me before with no issues.
In terms of memory bandwidth, I meant that there is a noticeable slowdown for my application when I start uploading textures versus when I don’t. The CPU is barely being used so my guess is I’m saturating the system and GPU memory buses. There are no performance issues with smaller textures, but doing many large ones at the same time has a large cost. If I could use them directly then that portion goes away.
I also tested with my own mini-engine and getting rid of the copies and using just the original textures give smooth performance, introducing the copies starts causing big slowdowns and much stuttering.
Therefore, being able to create textures directly in the Engine with our own parameters/flags not purely the default ones or sharing our native textures with the engine seems to be a performance requirement for my needs. Support for D3D and OpenGL would be essential for cross-platform use.
I’ve made changes to the engine to support passing in a D3D texture and can be trivially made to extend this to OpenGL.
How can I try to contribute this change back to the engine so others can use it as well? I would really like to share this with everyone who needs it as well as reduce the need to maintain this separately. My changes are on a local 4.6 branch that is fully up-to-date. There are some small things that others can help with once I know who to contact both for getting in the engine as well as defining whatever coding standards are required.
I’ve created a pull request from my branch and welcome comments or improvements (eg: OpenGL support or fixing compiling on non-OpenGL/Direct3D platforms):
Pull request was rejected without comment. Does anyone here have suggestions or tweaks? Does commenting in support of a request help? Should I try on a later branch than 4.6 for the request? First time I’ve requested anything, works great on my end and is exactly what I need.
I’m also struggling with this performance issue. It’s exactly as hesham described: two large textures at once causing hiccups. Using only one texture, it runs at 90 fps. When I activate the second one, it drops to 45!! Sometimes even 35.
Both textures are Full HD (1920x1080).
I see I just tried to do File->Package project with my simple test setup and indeed I just get a black screen. It worked in Play->Standalone.