Alpha in Render Texture MUST be Alpha

I've been debating how to raise the alarm on this, since I know there is some general awareness of the issue on Unity's side... but unfortunately the response seem to be As Designed, when it should not!

Right now you cannot write Alpha to a Render Texture. I've seen many forum posts and issues submitted. One issue was marked as As Designed (or Won't Fix, I forget) with a dismissive note that the alpha channel was being reserved for future use.

I cannot stress enough that this is wrong. Alpha already has a past, present and future use: ALPHA.

As just one example: We render our HUD to an off screen texture so that we can post-process it independently of the main scene. Then we render that texture as an image over the main camera. This REQUIRES that Alpha be used as Alpha. There is absolutely no other way to do this.

How do we get this issue raised to the right people so that we can get this corrected?

 

@Remy_Unity

Okay, I guess that's a step forward... but seems still broken and I'll considered. Why would post processing break it? In my use-case (and many) the whole point of a render texture is because I NEED to do post processing in isolation form the main scene. This has to still work.

I definitely don't want my color buffer format decided for me either.... that doesn't make any sense.

What are you guys doing that make such a simple thing so complicated? Just write ALPHA to the RTT. It's as simple as that.

These constraints leave it still broken.

 

@SebLagarde

> The code is available, you are free to patch it locally.

Really... (sigh)

What you are describing either doesn't sound quite so reasonable or maybe I'm misinterpreting? You describe custom passes along with custom post processing. I don't understand why custom anything should be needed for such a common use-case in game development. You already have a full setup for this that works today.... you render with a camera to a render target. And you post process using the post processing stack on that camera (by volume). It works, as this is what we do now in the standard rendering pipeline. It requires no custom anything.

I certainly don't want to reinvent what's already there, such as post processing frameworks and existing filters, just to apply them to the HUD. I want to use standard post processing and standard techniques. This isn't some way-out-there concept that should require figuring out custom anything, in my view.

Truthfully I, also, am trying to be helpful here. I have a unique perspective: I've done what you do... I brought a commercial 3D game engine to market for years (HeroEngine), and I know what it's like having all these conflicting requirements and demands. But primarily I'm a game developer, and as such, it really looks like something has gotten a bit off the rails here.

I get that you have made some specific decisions elsewhere in the pipeline that is making the render target thing suddenly harder than it might have been. Maybe you didn't realize it at the time or maybe you did but just gave it low priority. But off screen render targets (with alpha) are not some obscure use-case in game development, it's pretty dang mainline. To sacrifice being able to do this properly and cleanly doesn't add up from where I sit. Because there is no other way to achieve these common things... short of hand waving things like taking over the pipeline and re-implementing or changing what you've done. That's not in my budget.

The Standard Rendering Pipeline is going away and the future is in either the Universal or HD one. But the decisions being made are precluding us from even testing the waters much less looking to move our code forward. It's gotten so discouraging that after being an early adopter of Unity and promoting it since it's infancy, and shipping many titles with it, we're forced to look at other solutions like Unreal. The costs of switching to an engine we're not familiar with would normally seem too high to even consider.... but staying with the rapidly evolving and changing Unity (along with it's questionable directions like this) have made that direction nearly as costly for us.

I just want us to get back to things working as we expect them too. To have HDRP to focus on what real down-in-the-trenches game development needs and not just what it takes to make admittedly impressive demos.

 

Personally I want them to focus on performance first, with certain target platforms in mind, and then build on that over time. Performance/quality is a real need for me as a developer, I want it to be king of the modern pipelines, priority number one, via modern methods and a different set of compromises and complexities compared to how these things were done in the past.

As such, it is still too early for me to judge how well Unity are doing, other than me being broadly happy with their priorities and what they have managed so far. I would always expect mistakes from any new pipeline, with resulting refactoring and changes of approach along the way. And I also expected some years of pain where weaknesses, omissions and limitations people werent used to when they used the legacy systems would cause frustration, bad timing for peoples own project development cycles, etc, when using the new pipelines. Some of those will be fixed by Unity given time, some will be dealt with in other ways. And once the pipelines settle down and do not evolve at such a fast rate, I expect more custom work to be done and shared/sold to the community by other developers. Lots of people dont have the technical budget to customise the pipelines themselves, but if Unity leave some glaring omissions in their pipelines for ages I'm pretty sure we will be able to rely on 3rd party developers providing their own solutions.

I know nothing I've said really helps with any pain at this stage, but I dont think there is anything anyone can do about that really. Everyone has their own areas they want to see improved with top priority, but resources are finite and we are just going to have to hang on tight for the rest of the ride, including game developers letting Unity know when a particular choice or compromise is stopping them from using the pipeline for a particular project.

 

Although additional care about this decision should be taken if people are intending to use other modern, rapidly evolving systems during this period. Just one example, if intending to use ECS hybrid renderer, be aware that they dont intend to proactively test this with builtin renderer after 19.3 ( as mentioned in this post #84 ), URP and HDRP are their focus with that going forwards.

 

I agree, I was just giving one specific and slightly less obvious example of a scenario which might make modern pipelines a better choice for certain projects, depending on developers choices made in regards other parts of modern Unity technology stack.

 

I don't really consider the built in rendering pipeline sufficient at all. It's not competitive with other engine rendering capability, which of course is why Unity is pouring resources into HDRP in the first place. It is, however, feature complete enough to prototype and get us ready to move to HDRP when it is ripe.

It doesn't matter how performant you make HDRP if it is just outright missing the types of things you need to do in building a production game title. You can be performant AND support offs creen rendering to textures with alpha and post processing those and compositing those back to the frame buffer. This is a situation where you can have your cake and eat it too. I say this because this is a fundamental capability of any quality commercial game engine I've ever worked with in the modern era (or even in the last decade). Unity included.

I might be able to carry forward with the standard rendering pipeline except for the fact you've said you are not doing anything more with it and because it doesn't benefit from modern advancements, such as shader variant batching (which we believe would make a big difference for us).

If the standard pipeline kept moving forward in some way, I'd probably be okay with it.... depending on the exact details. But as it is, I have to go with one of the two new ones and neither are capable enough to do enough to be considered a fully realized rendering pipeline. Universal is far too lacking in features (no deferred rendering, etc.) while HDRP certainly looks feature rich in rendering, is lacking some basic capabilities that are just needed in typical game development. Which I wouldn't mind either if someone would just say "Yup, we recognize this and we are going to fix it!"

Those of us working on large-scale projects need a certain level of assurance things are going in the right direction during these times when Unity is going through such tech upheavals. I apologize if I'm being overly zealous about this, but I've got a big team and an eight-figure budget project here, and it's a pretty [censored] big deal for us (and those like us) that Unity is on the right track.

 

(sigh)

This is so discouraging and disappointing. Epic has a guy coming out to sell us on switching to Unreal Engine. Something I would never have even considered, but it certainly shows a fundamental attitude difference.

I've been the biggest champion of Unity in our organization of over 600 developers across 12 studios (and rapidly expanding).... and this has made me feel, to be honest, like I need to re-evaluate what I've been promoting. Great job.

 

I dont see how that shows a different attitude at all, its a completely different thing. Trying to sell you on their engine is hardly the same thing as agreeing to implement the exact technical changes you want.

And Unity acknowledged the shortcomings with the current system, and the need to improve.

If Unity changed their technical approach every time someone demanded something be done in a specific manner that they are more comfortable with, I would be forced to ditch Unity due to lack of vision and hopeless mess of compromises.

 

Im currently Stuck on 2018.3 because any newer version does not have the Alpha channel support.
And saying "You may use the beta /alpha version and postprcessing will probably not work" is not a option.
The ever changing HDRP API and structure does make it nearly impossible to have any plans regarding projects with it.

 

I do feel the pain in regards planning - lack of useful, detailed HDRP roadmap is starting to hurt me, especially as some HDRP things mentioned in previous roadmap talks did not happen as planned, and I got no update about what the new plan is (eg area light volumetric support).

 

Actually, not really. It's confusing because they spoke about one minor aspect (the color buffer format) as something they want to improve while being much more dismissive about the larger issue here. It comes down to "do it yourself, we got other priorities" so far and some mixed-messaging that gives little comfort things are being taken seriously.

And, yes, the attitude between the engine providers is different these days. You might not see it if you don't have the history or are exposed to the machinations going on. At one time I'd even hang with David Helgason in Unity's SFO office to kick around ideas and share numbers. There was a laser focus on making the engine do what people needed to make game titles. As a direct result, the product rose dramatically in capability and managed to be the foundation for a lot of successful developers.

For example, a crazy large portion of the entire worlds population played Temple Run on mobile... a title I had the good fortune to be allowed to port from it's native Objective-C (thus iOS only) to Unity so it could run on about everything. It happened because I demonstrated how powerful Unity could be to my friends at Imangi for this, and Unity's support in making sure the engine's rough edges were addressed.

Epic is out actively doing what it takes to court developers and understand their needs. Something Unity was also great at. And is still pretty good at in moments. I've advised them on many things that ultimately came to pass over the years. They were good at listening.

But more recently, there's been something of a shift away from this. Unity has fractured into a blizzard of little projects all trying to move forward, in fits and starts, simultaneously. Including a lot of dubious things that have nothing to do with game development as it strives to be a solution to vastly more problems than originally intended (car manufacturing sector, anyone!). It's created a mess for any large-scale game development because anything one decides on can be suddenly deprecated in service of the NEW, while the NEW is in such a half-baked state that you can't figure out if it even makes sense to move forward or not. There are too many different directions and inter-dependencies (both acknowledged and hidden) that you can't do an reasonable risk or cost-benefit analysis.

On the one hand this has sorta allowed Unity to progress in parallel on many fronts, but it has also made it so there is no clear vision. They change their mind so rapidly that unless you live and breath in the forums, and on some of the other less well-known communication channels, you can't keep up. For an indie, probably not a big deal.... maybe even cool. But when working on budgets with 8 figures on lengthy development horizons, it's a problem.

And that'd be fine if Unity recognized this in a way that gave reasonable assurance there was a focus on developer needs. If they demonstrated a more consistent attention to unsexy stuff that's needed and not just the glitzy stuff that makes for great blog posts and PR opportunities. I know they can do this, and often do do this, but in this instance ..... I'm not feeling the love. At all.

What Epic is doing is quite different. Since this isn't an Epic forum, I won't expound on that. You can look into that for yourself if you are interested.

 

Some differences, but plenty of similarities. The non-game-industry stuff (film, cars, etc) has been a focus of both in recent years. And I saw plenty of examples over the years that are really the Epic equivalent of the thing you mentioned "do it yourself, we got other priorities" - in their case 'you have the full engine source code, you can modify it for your needs'.

Two big differences would be that Epic have to really eat their own dog food all the time, and that makes a difference. And yes, Unity has embarked on a mission that will effectively see most of the engine rebuilt over a period of quite a number of years, and they've gone for a modular approach. I think the ultimate destination for that is very promising, but there is so much pain along the way. Perhaps it would have been better if they had made a cleaner break between the legacy ways and the brave new modular world, and offered devs a different way of thinking about these 2 different Unitys during this long period. This is probably the wrong place to go into greater depth about what I mean, and sometimes I think its the entire modular approach that is actually doing some peoples heads in - they dont want to deal with all the choices and tracking down knowledge in obscure places and seeing different pieces evolving at different speeds. Some of what made Unity attractive to people originally is maybe getting lost. I dont feel that way myself, but I think I have observed this stuff lurking behind some of the forum sentiments of recent years.

edit - the two things that have slightly spoiled the modular approach for me are the number of things that still end up tying particular versions of modules to specific Unity versions, losing some of the modularity advantage, and the lack of high quality, timely roadmaps for every module.

 

@elbows

Very well stated. That's about the state of things in a nutshell.

And lack of eating their own dog food is, and always has been, a major weakness of Unity. But the implications of that have become way more dramatic with the giant upheavals in direction, deprecations of what is in favor of what will come (someday). It's hard to figure out how to even stick with Unity when A) you can't tell where it's going and B) their expressed attitudes are classic "we don't make games ourselves, but....."

On the plus, they do have groups who prototype games (like the FPS example). These do help inform them of where their tooling comes up short quite a bit. But it's still a half measure, because they are not responsible for taking a product through to completion, deployment, going to market, continuously updating, etc. They are missing experiencing a lot of pain points yet.

Which is why getting something like this Alpha compositing from offscreen textures wrong is so disconcerting. It represents a fundamental thing that they've shrugged as not important, when in fact it very much is in real world game development. And it's just one such example from a list of things. If they can't even give this one the appropriate priority, I can't even begin to move down the list.

 

Well almost everyone thinks the issues that affect them should be top priority. Doesnt mean they should be top priority.

Likewise, I can tell that you think their approach to offscreen textures is wrong, but they have acknowledged your broader point, and have shown a desire to improve situation in future, just not in the way you want. I will sit on the fence on this one, because if I start to second guess all their pipeline design decisions then I will jsut go crazy, I have to respect some of their decisions even when they arent perfect for my own needs.

Also, I generally want the unvarnished, plain spoken technical reality when I talk to engineers, lead programmers, unity team/module/studio/office heads etc. I dont expect all the extra careful customer relationship stuff from busy programmers on forums, especially when english may not be their first language, there are other Unity departments for that stuff. And in this case they took extra time to try to reassure you that they were listening and they do understand the importance of alpha stuff, but you seem to want to ignore that completely.

 

You think they are acknowledging the issue and planning to address it? I did not get that impression.

It's confusing because of contradictory things that were said ranging from saying some sub-point (but not blocking) was worth fixing all the way to fix it yourself.

In the end... if it's possible to do this at all... it's unclear, not documented and involves re-inventing what is already invented. Not DRY and not reasonable for a commercial game engine trying to be competitive, in my opinion.

 

This can really cause some confusion, so I'm going to jump in and add my experience ... I've already been told by Unity that the devs on the forums are not required to answer anything, nor is Unity held to anything they say. So, while it _is_ nice when a Dev acknowledges something, that isn't actually enough to act on, in any way what-so-ever. We need to distinguish between questions like: "Hey guys, it would be cool if X, what do you think?", and "Hey guys, this is going to actually break our product, will this be fixed?".

Take the case of videoplayer breaking on Android. A dev responded that they already had a fix in the works ... And then dissappeared for a very substantial amount of time (enough to take out the videoplayer, replace it with another solution, finish the project, then check and still nothing ... my memory is that it was 6+ months, but I could be off) with no one fixing it or even responding to multiple threads of people mentioning they couldnt launch their products with that bug. This was when Unity was pushing the new video player as being production ready and the new big thing. The only real response I ever got from a rep at Unity who handles people looking for tech support was A) ask on the forums because the devs are great there, B) the devs have no accountability there, and C) we couldnt pay for tech support to ask questions about the status of Unitys own bugs unless we paid ten thousand dollars per year for 10 seats of support. Note the response to my asking what to when a forum Dev had already acknowledged a known bug was being fixed and then disappeared, was ... To either ask on the forums (which he told me Dev's have no requirement to respond to) or file another bug report (which he also told me had no guarantee of ever being answered, let alone solved), or to pay 10 thousand dollars per year. I asked if he realized what he was telling me, that I mentioned the forums _were_ the problem (multiple threads of many users each all with projects blocked by this bug, just asking for _any_ dev to follow up and let us know if it was actually being fixed, or what was going on) and bugs had already been filed for this, and all I needed to know was an official stance on the bug ... but he basically read from a script at that point telling me the forums are working great, yada yada ... and to pay up. I was straight out told that there was no way of even inquiring into the status of something a Dev mentioned was already being fixed (for something rendering the product unreleaseable) short of paying a huge amount of money.

Soo ... No. Dont assume a lone dev here saying anything is being looked at means anything. He might really mean well, but his boss might also say its not a priority and then no one will ever care to address the issue or even mention that its not going to get fixed after all.

Sorry. I love unity ... But the support and customer service is pretty horrendous at times. Ive never experienced anything as blatantly rude as that entire experience, even when I mentioned I was a paying customer for years already (including before subscriptions) along with spending thousands upon thousands in the asset store.

Take my rant for what you want. But my advice is to love Unity for what it is, but not to expect much to come out of telling them something they built is breaking products in normal use cases, unless you have a ton of pull, or they decide its worth fixing.

The fact that a dev mentioned theyre thinking about it is meaningless without more backing it up.

 

When WebGL came out there was a bug that crashed our product. The recommended fix I got from a dev was wrong because he used out dated docs. That tech was also changing fast at the time. That was one of my questions to whoever marketing tossed me to ... What do I do when Unitys docs are out dated and wrong, theres a crash bug, the responses from devs on forums are also wrong, and the bug filed is still over a week of back and forth with no answer, and our project has to move forward. The response was to pay 10k (that's the minimum, even though we didn't need 10 seats, and only needed to ask a question now and then about the status of bugs in new tech) to even find out if Unity is planning on fixing a major bug on a platform. (That may have been an issue with the sales person for all I know, but I did write a letter complaining about being a paid customer and being told that, and never got a response).

Again, not trying to be snarky. I love Unity, the devs do some really awesome work and are in general nice people. But the system in place for getting past new tech that is constantly changing and keeps breaking isn't the greatest ... unless something has changed in a couple of years.

Just my warning, as sad as I am to say it. Luckily I almost never have those types of issues, but when I did, I found I had no real way of getting any answers.

PS: I had the same issue for creating prerenders of characters for a 2d adventure game. I ended up taking two screenshots, a black background and a white background, and comparing each pixel to do a good enough final render with transparency. While this isnt a mainstream use, it still felt pretty silly needing to do that.

 

Sure, plans change, priorities change, technical hurdles crop up, etc. But I have a good experience with Unity staff and the forums, and I very much take into account the actual role at Unity that a particular person has.

In this case, to quote the twitter account description for Seb Lagarde, he is "Unity Paris studio head and lead graphic programmer (HDRP)." And I am familiar with his history of posting on the forum about HDRP technical details, plans etc, and I take his word as authoritative.

 

If that's the case, then that's wonderful that he's on here. I'm not knocking their work, and certainly not knocking any Dev's, nor saying not to believe them when they say something. I think everyone's work here is great, and very grateful Unity is around. My only gripe has been not having any real way of following up on things Dev's say here, even when the information was critical for us, and that was only because of getting burnt a couple of times with newer tech.

My own experience when dealing with new tech that may or may not have something done or fixed though ... has been to assume it won't happen until it does, regardless of what a Dev says on here, and that I might have to figure it out myself or even back out of the tech with zero official input. I don't mean in terms of discussions, or hoping it really happens, but in terms of planning a project around it. Otherwise, if you do hit a snag, there is no guarantee you will get past it.

So ... if this is going to be a _real_ problem for anyone, the advice of using the Standard renderer is definitely the safest bet. If that _can't_ be done, then making a business decision around hoping something gets done because of something said on here is still pretty risky.

My real point was not to take Seb's answer as a "We're planning on fixing this!", and when talking about issues that are real problems for a project, that's all that really matters in the end.

"And I provide you a workaround that work with 7.1.1 and is more efficient, but indeed require a little of coding (which if you have a big team should be fairly ok). Agree that this is fairly new however (1 week ago).

We do consider your request and appreciate your feedback. And appreciate that you are well aware that as en engine developer, we get a lot of critical requests to be able to ship projects."

The last line is really what I'm stressing with my own experience. Unity is a _huge_ company. They get a lot of critical requests, to the point where they didn't even have the man power to answer a single question about the status of a known critical bug for less than 10k, even when we offered to pay. Clearly, they have a lot to do. I'm not bashing anyone, just saying ... its a feature request, and they basically said "noted", and now we just have to see how it plays out vs. the other critical requests that may be aligned against it.

The stance seems to be that they'll go the direction that makes sense for the most people (or whatever their target use case really is, clearly console performance is key right now, but I was told I couldnt be helped because there were too many people using Unity to offer any individual assistance, even if paid, unless its 10k or over), and if anyone needs something different, its up to them to implement it, or maybe even try to find a fix. Like nsxdavid said, I didn't get the vibe that they are planning on addressing it ... only that its noted, and something may or may not be done, depending on how things play out. Which isn't very developer friendly right now ... but to be fair, I think Seb also acknowledged that by pointing to the Standard renderer.

 

Certainly, I think that 'only make solid plans using stuff that already exists' is a golden rule. And my favourite Unity people who post on the forums tend to bake that approach into their suggestions.

I still have to do a second tier of planning, that is not set in stone and carries greater uncertainty and risk. And thats where roadmaps that get updated in a timely manner come in handy, even though the details are always subject to change or delay. Its possible to make reasonable assumptions in these areas a lot of the time, and Unity developers on forums really help with this area, I still want to know about uncertain things, and I still prefer information that may become invalid to no information at all.

 

A lot of discussion happening here is mind boggling to me.

• You are complaining about lack of features in preview module. If it does not supports your needs just don't use it. If you are planning your big scale development project to relay on no-production ready technology than its a problem with your planning decisions, not with the technology itself. If you are not comfortable with fast iteration and changes with hdrp, just use standard. A lot of great games has been done using quite outdated technology. It's not the tool that makes the product but ultimately the craftsman.
• Entire world moved to component-based development approach. I'm not talking about game development which is not that big to be honest. Web development, enterprise and corporate scale solutions, everything pretty much already completed modularisation transformation or are well underway. If you consider this approach to be bad, it's a problem with your understanding of pros and cons which was been worked out for decades in development discipline. You need to adapt or you will stay behind.
• Complaining about developers interactions on the forums? Again, misunderstanding of what those forums actually are. This is the place for community to interact with each other, help and build up, and if developers chime in that's great, but you don't hold them accountable for that they communicate here. If you expect enterprise level support - that you can hold some accountable for, just get the enterprise level support. This stuff was newer free and I don't know any company that uses community forums to communicate timelines or plans. If you expect such level of service, you wont find it here certainly.
• HDRP is planned to go out of preview with 2019.3, which I don't have much confidence in actually. I would not treat it as production ready then, in similar fashion you never should bet on first version of any product to be honest.

 

Just to be clear, Im not complaining about developers or interacting with them. Any complaints on my part are solely that there isnt a lower tiered support for people/smaller companies who dont need enough support to warrant spending that much money. The rest was my just trying to say ... If its not built already, it may never exist, regardless what anyone here may or may not say. Also ... that using new tech is extremely risky, even after its out of preview.

Sorry to anyone if I came off as complaining about interactions with developers.

 

The point of the preview versions is to gather feedback from the community. And this is a good time to change some decisions. It will be too late, for example, to complain about missing transparency from render textures in the stable version of HDRP, because it will be hard to change it then. And you can not give such feedback without using it in the at least preproduction. Everything always works in the demo versions and small projects . But you will get the real edge cases and some specific scenarios only in real projects.

 

But not in manner like in this thread, with an overabundance of arrogance and aggression.

 

People keep confusing a more direct matter-of-fact way of speaking as arrogance and aggression....

 

So seems that what they are saying at Unite going on right now is that HDRP will be put of preview status with 2019.3.

I would argue that making a stink about this now was not only not premature, but perhaps on the late side.

The implication that one should not commit to big projects around things still in preview is naive. With anything based on an engine, it’s competitive features become your competitive features (such as rendering features). And titles that a year or years out to market need a path forward. The standard pipeline is a dead end because they said it is. So I am forced to contend with their new under-baked pipelines to stay with Unity.

And so I’m definitely going to show them when their thinking doesn’t match what is needed in the field. Thats how it works.

 

IMO you are putting too much epiphysis on engines competitive features. There are numerous examples of very successful games using old technology while still retaining visual fidelity.

One of the most recent examples is Lost Ark, one of the best looking aRPG released this year, highly successful in Asian market and it still uses UE3, and engine that is almost 8 years old.

 

Thanks, but been doing this professionally for 32 years. Quite familiar what what's needed and not for our project.

 

I'm using 2019.3.0b4 and still not working!

 

I have not tried it yet... trying to get to it. Did you set the color buffer format as they indicated?

 

I think I see recent signs of alpha-related stuff being worked on, on github:

https://github.com/Unity-Technologi...mmit/dcbcd6ff4b78b2422c4e30fe1f8b6af2c0a6ae57

 

That's very encouraging! That was 3 hours ago, though, so I guess that didn't make b4. But still.... very encouraging! Thanks to Chman for the work on this!

 

Well these packages are separate from unity editor changes (except that certain package versions are set to need certain versions of editor, but the code is still separate). It will be a particular HDRP package version that you'll be looking to see these changes in. At this stage new stuff is tending to be merged into 8.x of HDRP, which is for Unity 2020.1. But at the moment a lot of it still gets backported to a 7.x version of HDRP, which is for 2019.3.

Its not clear to me whether this one in particular will be backported, the github pull request for it by Chman has a note 'do we want to backport this?'

https://github.com/Unity-Technologies/ScriptableRenderPipeline/pull/4749

edit - oh and beta 5 of 2019.3 came out yesterday, but it doesnt make any difference to which versions of HDRP you can try with it compared to beta 4.

 

Hmmm. Well, regardless, it shows some promise that this is maybe getting addressed in some reasonable future time. Details are sparse, but at least it's moving.

 

Looks like that bit has made it into 7.1.3. Just be aware that 7.1.3 isnt finished and released yet, but people can still try it in its current state via github if they want to.

https://github.com/Unity-Technologi...render-pipelines.high-definition/CHANGELOG.md

• Added basic alpha compositing support - Alpha is available afterpostprocess when using FP16 buffer format.

 

What unity version is this compatible with?

 

2019.3, beta 4 or newer.

There is always a chance they will change this to a later beta version if some important editor change/fix is made later that HDRP requires. But 7.x versions will always be for 2019.3.

 

Okay, and what is now the officially proposed workaround for alpha support in RenderTextures with HDRP 7.1.6 and Unity 2019.3.0f3?

 

Yeah, would definitely like to know.

 

Our app is develop by Unity 2019.2.3f1 with LWRP, how can i modify the code for RenderTexture ,and alpha is work!

 

Any updates on this?

My render textures used to write an alpha channel, and now they don't (just a solid color)

 

Same. When it will be fixed?

Edit: Nevermind, I forgot to set HDRP asset "Color Buffer Format" to use "R16G16B16A16" Everything works now.

 

Are there any other downsides to changing the color buffer format except for slightly increased VRAM use? Is there any way to change the color buffer format for individual cameras, perhaps? Setting a camera's target buffers to a render texture color + depth buffer doesn't seem to render anything in my case.

 

Having to change the Color Buffer format just to get alpha render textures seems costly to get this functionality.