#URP vs Built-in for Quest

1 messages · Page 1 of 1 (latest)

normal zinc
#

You'd be shooting yourself in the foot by picking built-in for a new Quest project. You can expect more Quest features than just AppSW to be URP exclusive in the future.

#

My understanding is that URP has had very inconsistent performance on Quest for a while, but it has stabilized recently.

#

Assuming you're on a recent Unity and URP version.

split night
normal zinc
#

I've been reading bug reports about this for at least 2020 and 2021. 2021 LTS may have received fixes for it alongside 2022 and 2023.

split night
normal zinc
#

Don't use AppSW unless you have to.

split night
#

Another question, is the lightning system or post processing system any different in URP in terms of performance. Will they work like I described here: "Ideally, I want to run at least one realtime spotlight with no shadows, use scopes (so just a second camera, I don't know if the SRP batcher can deal with this any better), and have night vision (so some kind of simple color/exposure post-processing) all at once."?

Edit:
I could make night vision and scopes not work together if it's too demanding, but either nvgs or scopes have to run at the same time as at least one spotlight.

normal zinc
#

The real-time lighting system is significantly different in URP, for the better. In built-in, any real-time light hitting a mesh will cause that mesh to be redrawn with a transparent overlay on top of the base pass to add the light on top. This means if you have a large building mesh and a light hits a small part of it, the whole building gets rendered twice.

#

URP has two options for real-time lights, Forward and Forward+. Forward works by finding the N number of lights that hit an object and passing that light information into the object's shader to apply the lighting. This way it can do lighting in one pass. You have to set a maximum number of lights that can affect per object.

Forward+ takes all the lights and puts them in an optimized 3D grid within the camera's frustum and makes this accessible to shaders for them to find all the lights near them. This means you avoid the per object light limit and can support things like per-particle lighting with VFX Graph.

normal zinc
# split night Why?

Let me rephrase: don't use it at the start of your project.
It will hide performance issues that may be trivial to fix, if you spent the time to figure it out.

#

There are other reasons to not want to use it, such as artifacts on transparent elements like particle effects.

split night
normal zinc
#

The size of the light ranges also matters. One light with a huge range can be much more expensive than 16 lights spread apart with small ranges.

split night
normal zinc
#

Which shader were you using for your environment? How big was the light range. How big were the meshes that the light was overlapping?

#

Neither RP will give you good performance by default. You will always have to optimize your scenes by choosing shaders, mesh complexity, light setup, etc.

split night
# normal zinc Neither RP will give you good performance by default. You will always have to op...

About that, my plan is to use a non-PBR workflow for everything except firearms and potentially the player’s IK.

Is the Simple Lit shader good enough for that, or should I use a more optimized shader that only supports a base map?

Also, the Simple Lit shader only supports specular highlights with realtime lights, which I don't want to use for the main light, only for flashlights. I tried using specular probes (https://github.com/zulubo/SpecularProbes), but Simple Lit doesn’t support environment reflections. So for metallic objects that aren’t firearms, should I use the default Lit shader, matcaps, or something else?

normal zinc
split night
#

In fact, I might as well use matcaps for firearms too and try to implement some sort of occlusion probe that changes the matcap brightness based on if the player is interior or exterior.

split night
normal zinc
split night
normal zinc
normal zinc
split night
split night