[Official] Dropping VertexLit rendering path for Unity 5.0?

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.

 

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

 

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

 

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

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.

 

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!

 

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

 

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

 

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.

 

Vertex lit path is useful for cameras used in reflections (especially on mobile) or other RTT effects that don't necessarily need all the detail of Forward or Deferred paths.

If there is an easy way to bump LOD down per camera, then yeah. Kill it. If not, it may be useful to keep around for a while until there is a solution.

 

Yeah, it's sort-of doable, but it's not likely to be a very elegant solution, especially if you've got lots of meshes and need quite a few lights, and you want to preview lights in edit mode, etc.

Unity already has fast/native code to determine which lights affect which meshes and set up per-mesh shader parameters for vertex lighting - it just seems to turn this off if a mesh is lightmapped, and it'd be nice if we could turn it back on.

 

Yeah, that's what I'm mean by "using Unity buildin data". You don't need to create your own light scripts, you get that data directly on your shaders (natively feed by Unity). Or you can feed your shaders with your own data (which is kinda unnecessary unless you are bypasing the whole system).

 

The vertex light data from Unity isn't there when lightmapped objects are being rendered. Or at that's how it appeared last time I tried to make this work. It looks like Unity assumes that lightmapped objects will never need to be vertex lit? (IIRC I was trying to use Shade4PointLights() from UnityCG.inc in a custom shader)

 

• Should have been dropped in 4.0

But seriously, I would drop it for 5.0. It's not worth the effort anymore. Even if it enables you to reach lower end devices, the result is probably so different from the intended result you probably just want to show a "doesn't work" dialog anyway.

I'm guessing that removing vertexlit will clean up the codebase to quite a large extend. As a sidestep, the forum is full with questions on why the shadow of an object doesn't move along if the vertices are moved in the vertex shader. I'm guessing that this question will also become easier to answer once the shadow passes are moved from vertexlit to surface shaders.

 

That's just the way build-in vertex lit shaders are done in Unity, you can still modify them or even better you can mix all that stuff with your custom shader eg: Vertex lit + lightmap, or even vertexlit + shadows, etc. No limits, up to you.
Anyway, Aras is right, we are getting a bit offtopic. Don't worry, you can re-create any vertex-lit shader the way you want even if vertex-lit path is removed. ^^

 

The benefits of vertexlit can be gained from using the appropriate shaders in the forward renderer right? And you probably have some numbers about the market share of devices that work on nothing but the vertex lit path.

 

I'm a complete idiot and did the same thing.

 

Me too... I selected the 'No, I don't need it' option, then realised it actually said 'No, I do need it'... d'oh!

 

I guess, now that I think about it, if I am advising artists on art direction, and we're working on hardware that's low-power enough that I'd need to use vertex lit stuff for lighting, I would normally advise "just don't use lighting. Do something stylized/unshaded/custom shaded. You will dodge an ugly-bullet".

You're better off going for a highly stylizes flat/vert color aesthetic than using a lighting model that is serving only a very approximate aesthetic goal... it's just legacy from a time when "that's the best we can do". But we can do better now. I just hope there's a lot of on board instruction for different lighting styles/techniques/approaches so that it doesn't feel too much like the rug has been pulled out from under some mobile dev's feet.

It is definitely a contributor to that "this looks like it was made in unity with all the defaults" aesthetic. So. A prettier alternative default which has decent support for beginners would be excellent.

Ideally, something doesn't require excessive copy-paste throughout all shaders. I think that'd be my main concern - how much maintenance would someone have to do on a project that did use vertex lighting? Is there a way to chuck in the equivalent extra lines of code into their #pragma vert, when upgrading? Is it more overhead if that's been the only option for a developer?

 

And one more here. (Feature request to change your vote on the forum?)

 

Drop it, and there's 11 votes to not drop it and 4-5 of them were misclicks.

 

Not sure why this is a poll at all, @Aras if setting lod will do a similar thing and Forward can do this if you write your own shaders

 

So why is it that VertexLit looks so much better than Standard in Forward?
I am no expert like you all but man, it is so much better on my set up.

 

This is an old thread.

I keep using it because i feel secure with it until i learn more about this to take variables out of the equation
of mobile optimizations.

 

Not sure if VertexLit is still being considered for deprecation but I think it should stay as long as it performs faster than forward. Could it be a cheaper alternative when rendering with replacement shaders instead of using normal forward rendering path?

 

No, you pay the same cost. You just need a vertex lit shader. Vertex lit is forward path... It should not perform any differently to vertex lit if you use vertex lit shaders or just change lod:

 

So, will it remain or not?

 

I imagine it doesn't actually matter. Because SRP replaces everything, if you want it to... Still @Aras cannot escape his graphics heritage! He has tried to leave the building of graphics and yet we draw him back!

 

Is this still something that is happening? I agree with dropping it. Even on mobile games I use forward rendering. Most mobiles GPUs are fast enough now unless you have an ancient device.

 

I don't know if this thread discussion is still relevant, and I'm probably bumping it (even though I still don't know what that means), but I have to put it out there: don't ask for things to be removed just because you personally haven't found a use for it. You're not the only Unity game dev in the world, and not everyone owns your beast PC.

When making very low end games, it's highly useful. 30% of all votes isn't a small amount at all, especially for something like this; you'd think if it was soo useless nobody would want it, right? And if it's soo similar to forward in terms of technicality or practicality, you'd think it wouldn't warrant a change at all.

Also, here's a hypothetical: say I want to render a crapton of models at once, but on Forward it lags a lot. If I put it on VertexLit, and it runs perfectly, would this decrease or increase the quality of the project, providing the end objective was to render as many objects as possible, while still giving the instant, quick and easy option for the player to choose fancier shading with Forward and Deferred? Food for thought.

 

The best possible performance you can get (going back as far as Unity 3 when I first did it) is to just write simple vertex/fragment shaders that have vertex lighting. Slightly faster than the vertex lit mode in Unity, for devices like the 3GS and up, because the vertexlit mode in Unity was really just forward with different lighting.

Since this has already occurred, and there is no vertex lit in Unity, I will lock the thread.