x

Search in
Sort by:

Question Status:

Search help

  • Simple searches use one or more words. Separate the words with spaces (cat dog) to search cat,dog or both. Separate the words with plus signs (cat +dog) to search for items that may contain cat but must contain dog.
  • You can further refine your search on the search results page, where you can search by keywords, author, topic. These can be combined with each other. Examples
    • cat dog --matches anything with cat,dog or both
    • cat +dog --searches for cat +dog where dog is a mandatory term
    • cat -dog -- searches for cat excluding any result containing dog
    • [cats] —will restrict your search to results with topic named "cats"
    • [cats] [dogs] —will restrict your search to results with both topics, "cats", and "dogs"

[Closed] UpdateResourceImmediate(bool bClearRenderTarget=true) does not respect the bClearRenderTarget

So I am trying to use a UCanvasRenderTarget2D to draw some images into a texture. Unfortunately, every time I draw something into it via the FOnCanvasRenderTargetUpdate, the stuff I've previously drawn gets cleared. A bit of poking through the source code showed that the UpdateResource() override inside of UCanvasRenderTarget2D calls UpdateResourceImmediate() which at some point got a bClearRenderTarget parameter that defaults to true.

Alright, no big deal then, I just added a bClearOnUpdate bool to UCanvasRenderTarget2D, fed it into UpdateResourceImmediate() and compiled it only to find that my data still gets cleared. I traced the execution chain all the way to FTextureRenderTarget2DResource::UpdateDeferredResource where the bClearRenderTarget is correctly set to false, and it skips the "clear the render target surface to green" execution block. But somewhere past the CopyToResolveTarget call, the data still gets cleared.

Product Version: Not Selected
Tags:
more ▼

asked Jul 25 '16 at 03:56 PM in C++ Programming

avatar image

Answers.Archive STAFF
1.8k 189 298 660

(comments are locked)
10|2000 characters needed characters left

The question has been closed Jul 25 '16 at 03:57 PM by AndrewHurley for the following reason:

The question is answered, right answer was accepted


1 answer: sort voted first

Hi Damir, Sorry for the delay. CopyToResolveTarget doesn't really have the capability to clear anything. It could overwrite the target texture if the source and target were different, but from the looks of FTextureRenderTarget2DResource::InitDynamicRHI they should be the same.

Can you confirm that in the CopyToResolveTarget call in question the source/dest are the same? If they are then the problem is elsewhere. Some other rogue clear or draw coming in before or later.

Are you specifically seeing it cleared to green? A breakpoint in RHIClear or SetRenderTargetsAndClear around the problem area should help narrow it down.

more ▼

answered Jul 25 '16 at 03:56 PM

avatar image

Answers.Archive STAFF
1.8k 189 298 660

avatar image Answers.Archive STAFF Jul 25 '16 at 03:56 PM

Hey Marcus,

The behavior is a bit weird. I've set it up in such a way that I assign an event to the OnResourceUpdate delegate (or whatever it is called, I am not in the office right now) and update the resource every 1 second. Via the passed-in canvas, I do a DrawTexture using a small square at a random point on the render target. The result should be those small textures accumulating, but I only ever see the last one drawn, the previous one gets cleared. It only gets cleared to green if I set the blend mode to additive, grey otherwise.

However, if I put a breakpoint at any point of the drawing process, and just keep stepping through, I DO see the textures accumulate, and when I remove the breakpoint and resume at normal speed, it gets cleared the next call.

Hope that helps.

Best regards, Damir H.

avatar image Answers.Archive STAFF Jul 25 '16 at 03:56 PM

Wow that is really odd. Can you try console command 'r.rhicmduseparallelalgorithms 0' and 'r.rhicmdusebypass 1' and see if that changes the behavior?

avatar image Answers.Archive STAFF Jul 25 '16 at 03:56 PM +

I think the problem you were running into is that UTexture::UpdateResource() automatically "renames" the underlying resource for you.

Since the CPU and GPU are on different timelines you can think of "renaming" as a new surface is allocated for you on each UpdateResource() since the previous updates may still be in flight on the GPU.

So in this case "bClearOnUpdate" really means, "will you write all the pixels? in that case you can skip the initial clear." On update the whole surface is expected to be refreshed.

If you can describe your end goals we can discuss some alternative approaches.

avatar image Answers.Archive STAFF Jul 25 '16 at 03:56 PM

Hey,

Terribly sorry for the late reply, I've been busy left and right with the Reboot Develop conference, hadn't had time to get back to this.

I understand the explanation and that is most likely what is happening. What I am trying to achieve is to incrementally write stuff to a render target, i.e. draw something, then 5 seconds later, draw something to the same render target, retaining the results of the previous draw. I have found a workaround for the situation I opened the post for, but it would still be a good thing to know about.

Best regards, Damir H.

avatar image Answers.Archive STAFF Jul 25 '16 at 03:56 PM

Hi Damir,

Glad you found a workaround. Our plan for the future is to phase out the Canvas system. We are intending to write a more generic system to allow you to drive rendertarget rendering more generically, and more integrated into blueprint and the material graph.

We're hoping to have a prototype in the next month or two. I can keep you up to date on it on progress on it. :)

avatar image Answers.Archive STAFF Jul 25 '16 at 03:56 PM

That would be awesome, thanks a lot. Looking forward to the new system.

What I do now is spawn particles at set locations high up above my game and have a scene capture set to only capture particles grab those and put them in a render target. I am running into a few issues those, mostly the fact that scene captures are very slow even with only particles (and translucency) turned on and having a very small max render distance. Curiously enough the performance is much better in the editor than a packaged build...

Will the new system allow for things like that? I use the system above to e.g. spawn wave particles that slowly grow and fade out in order to spawn small waves in bodies of water as the player walks through them.

avatar image Answers.Archive STAFF Jul 25 '16 at 03:56 PM

Is there any news on this prototype?

avatar image Answers.Archive STAFF Jul 25 '16 at 03:56 PM

The replacement system can be driven via BP as well as c++, so for an overview see the BP node, DrawMaterialToRenderTarget. This is live in Dev-Rendering and will be released in 4.13.

avatar image Answers.Archive STAFF Jul 25 '16 at 03:56 PM

Can you explain your workaround? Do you copy the results in another surface? Thanks.

(comments are locked)
10|2000 characters needed characters left

Follow this question

Once you sign in you will be able to subscribe for any updates here

Answers to this question