Is it possible to switch between pipelines ?

Hello ,
We are working on VR and PC game. We plan to use HDRP. But in feature if we want to support oculus quest is it possible to disable it or switch to LWRP. Also for low-end pc devices is it possible to disable HDRP ?

In HDRP site i see high end pc term. I am not sure which cpu/gpu is in the high end category ?

 

It is not possible to realistically switch between pipelines and HDRP hasn't even got stable VR yet (it's a WIP).

 

HD doesn't automatically mean it's heavy, I'd test both first on some similar complexity scene that you target and draw own conclusions. There is initial VR support on 4.0.0+ HDRP so you could test it with 2018.3 betas.

As for swapping the pipelines at runtime, it's possible but it's not supported by Unity. I did a demo about this at https://forum.unity.com/threads/lightweight-and-hd-in-same-build-proof-of-concept.529839/. While it's technically possible, it would require for both LW and HD to have custom material setups as shaders are not compatible, separately tweaked lighting, different sky, fog etc setup as HD does this differently, different PP setup etc.

But considering that HDRP is finally getting VR support and it does work in optional forward-only mode with MSAA, that would be easiest route (once that's matured enough).

 

Thanks for reply. Is it complex to switch between them at editor. I mean we could make diffrent builds. Is hdrp production ready ? How can i learn is oculus quest support DX11 ?

I have some assets from asset store should i change all materials to make it work with HDRP ?

 

Hey, this is a great idea to think about.
As the scriptable pipelines was made open source this will definitely be possible sometime in the near future.
As you work on 2 or more feature and start seeing a pattern between them, you can make a base that those features use. That is refactoring.
Now, for the LW and HD pipelines, we need to see what is the base and what differs between them.
The first thing that come to mind is the data. What data does a render pipeline use? Geometry, animations, textures and shaders comes to mind.
Geometry: We can use LODs, where a range (ex. from LOD 2 to LOD 4) is shared between the 2 pipelines, and where all the LOD set is only used by the HD.
Animations: I haven't heard of level of details for animations, but it could be done.
Textures: We have level of details for textures through mipmaps. We could also have different texture settings for the 2 pipelines.
Shaders: We already have the concept of sub shaders and fallback.
The last discussion will be about the build size and how you can improve this. One way would be by minimising the data that is required by the LW pipeline and never by the HD one, by sharing and much as possible. The other option is by using asset bundles were the client download only the need data once the client knows what pipeline supports.

Regards.

 

Strongly suggest not trying to use both or even finding common ground.

• need to redo lights
• need to redo reflection probes
• need to remove a lot of functionality from hdrp
• have to re-author and repack all the textures as the channels are all used differently
• and so on (I only scratched the surface)

This sharing lark is not going to work well... unless it's just your own niche project where you totally control a very limited set of textures and lighting. Doing that would probably just be better looking overall sticking with LWRP. It would look better than being able to switch between LWRP and HDRP, due to how many artificial limitations you will need to impose on HDRP to get such a concept to work.

HDRP has a lot of options to turn stuff off for speed. It's got a lot of room. LWRP is being improved by Unity next year to have more features.

Pick one and stick with it or build up your own SRP based off LWRP or use Builtin (nothing wrong with it!)

 

hippocoder, off, it was just a reasoning exercise. This is the approach you will use to do code refactoring in any situation. I know that at this moment there are some limitations and it is better off using one pipeline and going with it. But, if we put concepts in immutable boxes, than where will innovation come from? My experience tells me that innovation comes from pushing yourself in doing the "impossible".
Best regards.

P.S. If someone wants to do this, help him however you can. Who knows, maybe he will create the base for the technology that will be mainstream in 10, 20 years from now and you will be part of it.

 

I agree, I tried many times as well and came to the conclusion that Unity's just plain right in this respect. One of the reasons I feel Unity is right is because I've battle tested exactly this problem in the past.

When you develop a cross platform game, say mobile and desktop, you have to pick a master to build from, even if all the media turns out the same.

For example if I pick mobile as the master platform, I can really push that to the limits, then for desktop I just slap more post effects on and... done! That ends up with an overall better image than if I chose desktop but then had to butcher the hell out of it for mobile. Because picking desktop first would require subtracting too much that can't be controlled.

When you go down to up, you get to add a whole bunch of stuff in post. But when you go up to down, you have to remove the post AND butcher the media to a point where it'd never have looked as good as starting from a mobile base.

However in HDRP's case - the team is really smart. They decided that HDRP can scale backward - you can turn a hell of a lot off. You can even go forward! You can save bags of memory, so the gap in my mobile vs desktop example above, it's much smaller with HDRP because HDRP is designed to scale a lot.

The real decision is: will you be on compute shader hardware only... or not? If you make a product that runs on compute and not compute, you make a product that isn't as strong as picking the low target and maximising it.