HD Render pipeline on mobile?

Hello,

I saw that the first post in this thread says that the HD render pipeline supports Android & iOS under certain circumstances:
https://forum.unity.com/threads/feedback-wanted-high-definition-render-pipeline.560653/

I just wanted to test that and ran an iOS build for a project using the HD render pipeline. However, I get the following error:

BuildFailedException: The platform iOS is not supported with Hight Definition Render Pipeline

(also see the typo in that error )

Is that mobile support not yet available? and if that's the case, when do you think it will be ready?
As far as I understand, you can't really switch back from the HD render pipeline to the standard one or the Lightweight one due to the compute shaders, is that correct?

I am using Unity 2018.2.8f1 with HD Render pipeline preview version 3.0.0.

 

Based on the following GitHub page, support for iOS with Metal is planned. No ETA, however.
https://github.com/Unity-Technologi...wiki/High-Definition-Render-Pipeline-overview

(Maybe @SebLagarde can chime in and tell us more )

Afaik all three RPs (High Definition, Lightweight and Built-in) uses different Lighting, Shaders, etc. That's why you can't switch from HDRP to Lightweight or Built-in.

 

Technically you CAN swap the RPs runtime (I have proof of concept demo for this) but it really means you need to swap all materials to use different shaders, adjust lighting, sky etc separately per SRP. Unity doesn't officially support this for obvious reasons.

 

I know, but that's why I didn't mentioned it You're right: It's possible, but... just don't do it. It's too much hassle.

 

General thoughts:

It's usually going to lead to a worse quality product supporting two separate renderers within the same game. It would be difficult for AAA, it would be pointless for indie. It's very amateur to even want to do so, it demonstrates a clear lack of experience because:

• if you are indie you only have time for one set of media
• if your game so simple that the same set of media can be used then use built-in or LWRP and modify those
• if you build for HDRP and downgrade to LWRP your game will look worse
• if you build for LWRP and upgrade to HDRP your game will look worse
• if you build for LWRP and stay with LWRP but upgrade post on high end platform your game will look better

So it's basically a time cost. It will cost you much more in time than you think, or look worse than you think if you want to support both. In fact the last bullet point is basically what everyone still did with builtin renderer anyway when supporting mobile + desktop. If they wanted quality they picked the lowest hardware platform and designed for that, then slapped a load of post fx on the way up. This is the safest, most nondestructive way to support wildly different hardware.

And it won't be long before HDRP is just the default - probably a couple of years - because hardware moves that fast in the mobile space. So it's really about how much you really know about the game you are making.

 

Thanks, very good reply. But does that mean there’s no practical way of using the visual graph and gpu particles and making a game for both desktop and mobile?

We’re making a game which we will launch on desktop first, but it’s pretty well suited for phones/tablets too, and it would be nice to be able to use the new visual techniques.

 

The latest thousand dollar top-end iPhone will struggle to run all this, yes. You will want to come back down to reality. Will it run ? yes. Will it look worse than authoring using shuriken and careful shaders? yes. Because you will cut so much to get performance. HDRP+VFX and so on really is designed for new consoles and current desktop hardware.

You can do it but I don't think it's smart to do so if you want to get maximum benefits from current mobiles. I'll bet you any money a hand crafted LWRP scene will look a lot better than HDRP+VFX if you aim at a specific minimum framerate.

Why not try it all out? It could be I don't know your game's limitations.

 

Based on past experience with compute shaders on ios devices, I am inclined to disagree with that, and I think it will make quite a bit of sense for some projects to go down this route in future. But I'd rather just wait until I can properly test for myself. And now is not that time for that sort of thing because I'm not going to bash my head against a brick wall trying to get HDRP etc working on iOS until Unity have had more time to direct their efforts more towards fully supporting that platform with HDRP etc. I think its already clear that Unity will be having fun in future showing off rather busy and impressive scenes, built using modern things like HDRP and ECS, on mobile platforms. And I dont expect the Visual Effects Graph stuff to be an exception to this.

 

Quite sure that if your goal is to make money, then this is a bad idea unless your game has AAA art to show it off on the tiny screen for the present market, which has a real mix of different device capability. I don't know what the OP wants to target. Likely android could be involved.

In a couple of years I think it'll all be HDRP wall to wall

 

I guess I’ll keep using the standard renderer and have as many post processing and light/shadow features as possible where needed, and then just scale that down for mobile devices.

The most important for me would be to have one codebase rather than two versions of the game in hdrp and lwrp.

I’m just intrigued by the gpu particles to make a lot of dirt, explosions and stuff

 

I agree, I think it's senseless having more than one renderer and more than one set of assets. But I wouldn't write LWRP off at all. In 2019 we're going to see some sweet quality bumps and features. Pretty sure it'll pretty much beat out builtin's feature set in the end (give or take a few tweaks).

 

Apple showcased a new live presentation to show off their new iPad Pro and Mac lines. The company even took it a step further by stating it's as powerful as an Xbox One S.

It's closed the gap between consoles and mobile ( not yet for memory a the iPad has way less memory )

 

[SOLVED]
So whats the alternative for decals,I was compelled to upgrade to HDRP from standard,and now am stucked either i lose decals or i lose android build...what should i do??

 

How close are you to shipping? Can you wait?
If not, there are a million ways to do decals on any pipeline. The problem is that no one solution is ideal for all decals. No matter what you use you might need more than one system.
Can you afford to do a Z pre-pass? Projecting on that should give you good enough results for mobile.
Alternatively, skip them. Most people on mobile won't care as long as your game is fun.

 

So happy someone replied!!!, really appreciate your efforts mate,but i found one alternate solution using quad object in standard shader,and to avoid the z-fighting i still need to figure that out

http://wiki.unity3d.com/index.php?title= blended decals

i need this shader but there is only a script. and i dont know how to convert script into shaders

 

Unfortunately, the link does not work.
What sort of decals are you drawing? Bullet holes?
Are you use LWRP on mobile?
Do you use a Z Prepass already? (i.e. if you use Cascaded shadow maps the z prepass is already required)
I hope that I can help...

 

sorry for that...
heres the actual link :- http://wiki.unity3d.com/index.php?title=BlendedDecal&oldid=13826
how to convert script into shaders?
i saw one video and got this link from there

 

This is the easiest kind of decal you can do. It is up to you to position it, it doesn't do projection or clipping, it just applies a z bias to keep the decal in front of the surface it is on.
I am not about the shader in the article, but the easiest way to do this on mobile is to move all vertices of the decal towards the damage.
Most GLES implementations use fixed point z buffers (actually z/w which in practice is about 1/z) which makes it difficult to determine how far to shift as the epsilon grows as the decal gets farther from the camera.
Fortunately, there is a simple function that will scale your offset to match the epsilon: k*z.
You can simply replace your projection from object space to clip space with something like:
float3 viewPos = UnityObjectToViewPos( v.vertex) * (1.0-1.0/1024.0);
o.pos = UnityViewToClipPos(viewPos );
This is a very big epsilon. It is a good starting point but you may want to bring the 1-1/1024 closer to 1 in practice. If it is too close to 1 you get z fighting, if it is too far from 1, the decal may appear in front of things that it should be behind.

Hope that helps!