[Official] Dropping VertexLit rendering path for Unity 5.0?

So Unity has the VertexLit rendering path. It is a strict subset of Forward rendering path (Forward can do everything that VertexLit can, and more).
We looked at some numbers we have, and looks like almost no one uses the VertexLit path. So how about dropping it for Unity 5.0?

Exactly the same thing can be achieved using Forward rendering path, and lowering global shader LOD or just using VertexLit/Unlit-type of shaders.

If you use VertexLit rendering path and need it, we’d love to hear why.

1 Like

Definitely unused here.

Unexplained “need it” votes aren’t very useful…

If I am not mistaken, using VertexLit path will cause all objects rendered on that camera to use a low cost, single draw-call shader. This is incredibly useful, and I use it for a form of water reflection in the free version of Unity. Switching the materials at runtime would be quite a messy thing to do. Am I mistaken about these savings?

I also use it to render distant, but high quantity objects, using a separate camera.

That said, I’ve recently spent considerable time re-writing the default unity shaders to use a single draw call, incorporating one light and ambient lighting in one pass.- perhaps now I’ve done this my personal performance savings will be less significant, but I’d feel a little uneasy knowing these tricks were no longer so easily implemented.

1 Like

To clarify, what needs to be done to make Forward behave the same way as VertexLit? Is it just setting Pixel Light Count to 0?

I think you’re mistaken. AFAIK VertexLit just does what it sounds like: calculates lighting on a per-vertex basis. You still have to use a separate draw call for each material, because the GPU needs to stop and e.g. change texture.

Kill it (Although i clicked “I need it” in the Poll for some reason unbeknownst to me

No, you’d have to use shaders that have LightMode=Vertex and similar tags.

In forward with PixelLightCount=0, the ForwardBase passes are still rendered (so objects get SH, directional lightmaps etc.).

But you could do the same using a Forward camera, and making sure it uses LightMode=Vertex or LightMode=Always pass types, right? (e.g. dropping global shader LOD to achieve that before rendering said camera)

Yes, one draw call per material, but at present, one object requires two draw calls. Dropping to Vertex Lit means each object renders in one draw call. This is something I’m pretty sure I’ve tested, but I’m questioning my accuracy on the matter :slight_smile:

My opinion on this:
The less legacy features in the engine, the lightweight the codebase will be :slight_smile:

So drop all that old stuff while it’s still time!

In a previous project we made, I was happy that we were not forced to switch to Mecanim and that we were able to continue the development with the Legacy system. The 2 systems were drastically different while here it’s easier to re-obtain the same results with Forward by making few changes.

2 Likes

Ah, I see how that would give the same result. Might need to fix some older shaders I guess. Clever. IN which case, I don’t need the vertex lit rendering path itself. Cheers!

Under standard forward rendering, if you have at most one Directional light, and all other lights are forced to SH via the ‘pixel light count’ QualitySetting, then it should be coming out at 1 draw call per object-material. Sounds to me like you’ve got other lights going on.

1 Like

I also think the Vertexlit stuff really causes a mess in the Unity shader pipeline, I mean I use forward rendering and roll my own vertex lights.

So yeah, dump all the crap and make Unity the modern beast it wants to be. It’s clear people complaining they want the past but they don’t know why. For example shadows, they just flat out won’t work on vertexlit path will they? you need forward for that, and with the improvements to shadows in 5 it’s time to drop VertexLit since you can have vertex lighting in forward anyway.

IMHO just do it, people will soon figure out Forward is the same speed with a few tweaks and we can help them with that. No downsides :slight_smile:

1 Like

I’m getting two draw calls on an empty scene with one cube, one directional light and one material. I thought it worked such that it was one draw call for base, one for each light- ie the lighting was an additive pass after the fact.

(Just tested my sanity in Unity: One cube, one directional light, one material: two draw calls. Dropping to Vertex Lit gives me 1, so does dropping pixel lights to zero- so I’m sorted and no longer require the Vertex Lit path.)

[edit]

Interesting, I’m getting odd results on this. This isn’t the thread for it though, i’m going to go away and see if I can track it down. I’m ashamed to say it looks like my knowledge on this may be wrong, or you are right and I do have a rogue light in the other project.

Feel free to make another thread on it and we will help. For example on forward I currently have 9 total (custom) lights affecting a complex scene with one draw call in Forward, so I do know it’s possible :slight_smile:

Figuring out exactly how every object is being rendered in Unity (which lights are done in which passes) is a nightmare, and unfortunately removing the Vertex Lit path won’t solve that. We really do need proper documentation of how the forward renderer works, and ideally the editor would provide a straightforward way of seeing what draw calls were being made for a given object, and what lights, etc. were causing them.

1 Like

Agreed, and I’d like better control over the shadow system, and less defineception in the cginc files. Currently it’s a total mess of hacks that you need a map to navigate.

I don’t think I’ve got a need for the separate vertex-lit path, but vertex lighting seems likely to be useful on mobile for a while yet.

So could we get vertex lighting which works with lightmapped meshes, please! (in a single pass, on mobile)

It seems that lightmapping completely disables per-vertex lights at the moment, and I’ve not found a workaround via custom shaders (it looks like the vertex lighting shader parameters aren’t getting set for lightmapped objects?). I suppose I could implement my own lighting and light management, but that could get a bit ugly.

Lightmaps and probes are great, but it’d be nice to have an easy/inexpensive way to add a little bit more dynamic lighting on mid-spec mobile devices - where multi-pass/per-pixel lighting is still prohibitively expensive.

Yes, please.

You have Spherical Harmonics in Surface shaders but by default they don’t have any sort of attenuation (which is a shame) they pops in and out. You can however create your own custom vertex lighting with attenuation using Unity buildin data (eg light positions, attenuation, color, etc) or your own data.