Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Lightmap + Directional Light : Drawcalls went up [SOLVED]

Discussion in 'Developer Preview Archive' started by n0mad, Feb 16, 2012.

  1. n0mad

    n0mad

    Joined:
    Jan 27, 2009
    Posts:
    3,732
    edit : a [SOLVED] tag was put, but in my opinion it's not. See later posts for details.

    Hello,

    just noticed that prior to 3.5, I was having less drawcalls with my lightmapped scenes containing a directional light (which was lighting the LM objects aswell).

    In fact, before 3.5, every lightmapped object that was dynamically lighted at runtime spent 1 drawcall.
    Now they spend 2, systematically.

    What happened ? I understand that to illuminate a lightmapped object you have to use a Pixel Light instead of Vertex Light, but how did it displayed less drawcalls before 3.5 ? Was it a bug ?

    edit : and of course the number of tris is doubled too.
     
    Last edited: Mar 22, 2012
  2. n0mad

    n0mad

    Joined:
    Jan 27, 2009
    Posts:
    3,732
    It is as if before 3.5, Vertex Lights were working on Lightmapped objects (which could explain the lack of a second pass, therefore a single drawcall).

    Whatever, even if I'm wrong on this assumption, wouldn't it be possible for dynamic Vertex Lights to affect Lightmaps ? Without needing to be a Pixel Light ? If Lightmaps are based on vertex, maybe add the Vertex Light's color ? That would save a truck of power ...
     
  3. n0mad

    n0mad

    Joined:
    Jan 27, 2009
    Posts:
    3,732
    bump, am I the only one to experience such a difference ?
     
  4. Tiles

    Tiles

    Joined:
    Feb 5, 2010
    Posts:
    2,481
    Nope, you are not, unfortunately. But i guess that most folks doesn`t realize the difference because they install 3.5 above 3.41, and have no chance to check it then anymore.

    I confirm this behaviour, and think about going back to 3.41. My game runs much slower now, and uses ways more drawcalls with 3.5, with same scene. That`s not what i expect from an IMPROVED version. Why was there nothing to read about this behaviour when Unity 3.5 was public beta? :(
     
    Last edited by a moderator: Feb 18, 2012
  5. kenshin

    kenshin

    Joined:
    Apr 21, 2010
    Posts:
    940
    Guys, if you haven't already done I think is a good idea to fill a bug report :)
     
  6. n0mad

    n0mad

    Joined:
    Jan 27, 2009
    Posts:
    3,732
    Thank you Tiles ! I'm reassured, that means it can only be better in the future :)
    (absolutely kenshin, already filed one)
     
  7. Joachim_Ante

    Joachim_Ante

    Unity Technologies

    Joined:
    Mar 16, 2005
    Posts:
    5,203
    Do you have a case number?
     
  8. n0mad

    n0mad

    Joined:
    Jan 27, 2009
    Posts:
    3,732
    case 443882 :)

    But it's just this topic rewritten, and there is no example attached, as it was happening systematically with all my 8 levels, and was concerning absolutely anything that would be lightmapped. Plus I don't have my 3.4.2 levels anymore so there's no concrete comparison point :/
    (sorry, didn't expect the problem at all from RC)

    It seems like Tiles still have a 3.4.2 scene, maybe he could use his old level ?

    Thanks for your interest Joachim, didn't you have anything close to this difference internally ?
     
  9. n0mad

    n0mad

    Joined:
    Jan 27, 2009
    Posts:
    3,732
    addendum : I tried a lot of "simplifications" to see if it comes from my side, like reverting all shaders back to basic diffuse, checking every object to "static batching", etc. Didn't change anything.

    The only way to lower the drawcalls is to put unbaken lights to ForceVertex, but then they don't illuminate lightmapped objects anymore (unlike in 3.4.2).
     
  10. Tiles

    Tiles

    Joined:
    Feb 5, 2010
    Posts:
    2,481
    Still at preparing everything and at some tests like building an exe. But will have a look to submit it today :)

    EDIT, tests are finished, all is prepared for upload. But i found another funny behaviour while testing. Not sure if this is another bug though or if it is connected with this behaviour. I made an exe with 3.42, and one exe with 3.5. Then i removed the lightmaps via clear in the lightmapping tool, and made two more exes without lightmaps.

    The result is as follow for the very same data set:

    Exe with Version 3.42 before removing lightmaps: 125 fps
    Exe with Version 3.42 after removing lightmaps: 115 fps

    Exe with Version 3.5 before removing lightmaps: 100 fps
    Exe with Version 3.5 after removing lightmaps: 80 fps

    Conclusion 1: Seems that removing lightmaps decreases performance in the exe. Curious behaviour that removing something slows the performance down. I would`ve expected that ít increases the performance.
    Conclusion 2: 3.5 is visibly less performant than 3.42.

    Will file all examples with the bugreport now. And yes, it also contains a from Unity 3.5 untouched project. I always keep backups ;)
     
    Last edited by a moderator: Feb 18, 2012
  11. Joachim_Ante

    Joachim_Ante

    Unity Technologies

    Joined:
    Mar 16, 2005
    Posts:
    5,203
  12. n0mad

    n0mad

    Joined:
    Jan 27, 2009
    Posts:
    3,732
    Ok, thanks for the tip. I put my single directional light on auto in the most drawcalls intensive level, and it didn't change anything. DCs are still up until I ForceVertex the light.
    Also, I deleted all the baked lights from the scene, as they don't need to exist anymore.
    So technically, there is only 1.
     
    Last edited: Feb 19, 2012
  13. n0mad

    n0mad

    Joined:
    Jan 27, 2009
    Posts:
    3,732
    Lightmaps are baked lights, so that they don't need to be calculated at runtime :)
    That's why when you delete lightmaps, the scene falls back to a state where it has to calculate those ex-baked lights again on every frame.
    Hence the fps down ;-)
     
  14. Joachim_Ante

    Joachim_Ante

    Unity Technologies

    Joined:
    Mar 16, 2005
    Posts:
    5,203
    When you change your directional lights to auto. Did you rebake the scene?

    The way Unity works is that after the bake has completed, it will tag the light as should affect only non-static geometry.
    Thus after the bake has completed your draw calls will go down. Not before.
     
  15. n0mad

    n0mad

    Joined:
    Jan 27, 2009
    Posts:
    3,732
    Yes, baked lights won't affect static geometry, that's why I didn't integrate the supposed dynamic single dir light in the baking process. I wanted it to affect any object, baked or not.

    Ok I've rebaked the scene including the runtime light as you asked (and setting it to auto), and drawcalls are effectively down to normal. But once again, the dynamic dir light doesn't affect baked objects when changing its intensity at runtime, as opposed to 3.4.2.
     
    Last edited: Feb 19, 2012
  16. n0mad

    n0mad

    Joined:
    Jan 27, 2009
    Posts:
    3,732
    I don't know if it can help, but I found another (minor) different behaviour with 3.5 :

    In Editor mode, no playing, when I deactivate/reactivate my single light, the drawcalls go down again. Only when I hit play, drawcalls double.

    Here is a comparison (upper = before deactivate/reactivate, lower = after) :

    edit : actually, the picture DC number difference is exactly the one I'm talking about initially.

    $test.png
     
    Last edited: Feb 18, 2012
  17. n0mad

    n0mad

    Joined:
    Jan 27, 2009
    Posts:
    3,732
    Topic was put on [SOLVED] ? oO
     
  18. Tiles

    Tiles

    Joined:
    Feb 5, 2010
    Posts:
    2,481
    o_O

    Funny one. I don`t have a active Baked Only light in the scene. And have nevertheless triple drawcalls. Even when i turn off all lights i have still a big drawcall overhead.

    Hmm. I`m still in trouble to understand it. Is lightmapped geometry completely excluded from any lighting? That would explain why normalmaps doesn`t work at lightmapped geometry. Which is a pity.
     
    Last edited by a moderator: Feb 18, 2012
  19. n0mad

    n0mad

    Joined:
    Jan 27, 2009
    Posts:
    3,732
    I don't feel the underlined part to be normal. Absolutely no light at all should never keep the same number of drawcalls as if they're all active, unless they're all baked.

    Lightmapped geometry is supposed to be completely excluded at runtime from any baked light (except RealtimeOnly for Dual Lightmaps, as hinted here). I understand how not being able to normal map a lightmapped object is a severe letdown, especially in 2012 where normal mapping is a base feature of any console game.

    ____

    So, this topic is marked as "solved". Ok fine, but isn't there really a possible solution to have Dynamic Lights affect Lightmapped objects then ?

    Like allowing Vertex Lights color to be additive blended to lightmapped objects vertices ? This wouldn't be as pretty as pixel lights, but at least it would still save the drawcalls ? I don't really know how Beast lightmapping works internally, so forgive me if I'm wrong on the vision.
     
  20. Joachim_Ante

    Joachim_Ante

    Unity Technologies

    Joined:
    Mar 16, 2005
    Posts:
    5,203
    You can use Directional Lightmaps to make normal maps be affected by lightmapped lights.
     
  21. Tiles

    Tiles

    Joined:
    Feb 5, 2010
    Posts:
    2,481
    Thanks Joachim. That`s a 3.5 feature though, and i have to wait for the higher drawcall fix before i can use that one :)
     
  22. n0mad

    n0mad

    Joined:
    Jan 27, 2009
    Posts:
    3,732
    I'm adding yet another drawcall unexplainable rising case :

    This time with a simple HUD, so Lightmapping, projectors, and shaders complexity don't count here... Using 2DToolkit, so this should always be 3 drawcall as I'm using only 1 atlas + 2 fonts.
    But the Editor jumps from 14 to 23 drawcalls whenever I'm activating it. The shader used is ultra simple, no normals, no bump, no projector, no lightmap indeed, and the HUD is only made of quads.

    And yes, I checked absolutely everything, there's no light hitting that HUD.

    HUD activated :

    $test1.png

    HUD deactivated :

    $test2.png

    I tried to see if it was coming from the large distance between elements (due to coordinates being 1 float unit = 1 screen pixel), all packing them to a Zero position, but it didn't change anything.
    Tried a built-in Mobile shader, still 7 drawcalls instead of 3.

    The much odder thing is that this drawcall rising is different from level to level. For Shibuya, it is 7, but for another it can go up to 9. Reminder : the HUD is always the same.

    This is not [SOLVED] to me. Not at all.

    edit : another funny (?) fact : pausing at a random moment, taking results :
    - when I disable static/dynamic batching, it displays 42 drawcalls.
    - when I enable both, it displays 17 drawcalls, 31 batched.

    Wait ... So 42 - 17 = 31 ? oO
     
    Last edited: Mar 20, 2012
  23. n0mad

    n0mad

    Joined:
    Jan 27, 2009
    Posts:
    3,732
    Update : I found something that triggers 100% of the time a drawcall rising.

    0) create a Perspective camera

    1) create two sprites using the same texture atlas in you 3D tool, using quads. Let's call these two sprites : SpriteA1 Sprite A2. Those will be exported under the same FBX (FBX_A).

    2) Then create another third sprite using a second, different texture, in a different 3D file. We call this : SpriteB. (Exported in FBX_B).

    3) import FBX_A FBX_B in Unity. Create 3 prefabs from the 3 different sprites, all using the same shader (ex : Mobile/Particles/AlphaBlend). So we have following prefabs : SpriteA1, SpriteA2, and SpriteB.

    4) create 2 instances of SpriteA1 (SpriteA1_1 SpriteA1_2), same for SpriteA2 (SpriteA2_1 SpriteA2_2) and SpriteB (SpriteB_1 SpriteB_2).

    5) place SpriteA1_1, SpriteA2_1 SpriteB_1 on the left part of the screen (let's, say, at X = -4f).
    6) same for SpriteA1_2, SpriteA2_2 SpriteB_2, but on the right (x = 4f)

    7) put all of them on the same Z level (ex : 0f)

    -> on my screen, it displays from 3 to 5 drawcalls, all depending of the all 6 sprites position in screen. As you can see below, sprites are always in camera frustum and never spreads outside, but only changing their position by even a small 0.1f can create an additional drawcall (screenshot 1 vs screenshot 3, right-click > open picture in new tab if numbers are too tiny). It's completely random.

    $test1.png

    $test2.png

    $test3.png

    Now another scenario, which provides yet another result :

    8) put spriteA1_1 spriteA1_2 on Z = 0,
    8) put spriteA2_1 spriteA2_2 on Z = -1,
    8) put spriteB_1 spriteB_2 on Z = -2

    now play with the camera position again, it's either 2 or 4 drawcalls. Never 5.
    Yes, 2 drawcalls, the expected number as we are only using 2 materials (plus static dynamic batching).

    $testB2.png $testB1.png

    So in the end, the batching is completely random. It is said in the docs that if you want objets to batch, they must be close. Here, I think we can say that 1 unit is close enough, can we ?

    addendum : I noticed that if I turned the camera to Orthographic, drawcalls would stay at 2.
    But, the more new sprites (= new uv) from the same atlas I would put in the scene, the more the drawcall would rise. As opposed to how packing different models inside the same texture atlas is supposed to be batched into 1 drawcall (which is part of why I purchased Unity Pro...)
    And it's not a problem of too many vertics, as they're only quads.


    edit :

    Also, as a reaction to Joachim's quote on another thread :

    It's not "chatting", it's "reporting in a continued diary". As users, we find a bug, but don't necessarly have enough elements to give you at the time. A thread lets us put more infos as time and tests go by, if we can't file you a project sample.

    It's also "searching for a dialog". The Unity Bug reporting is nice, but of all 10 I filed over 3 years, I only had roughly 2 or 3 with an answer. I even had half of them stay in "Opened" state, even if I sent an update saying that the problem was solved. Considering that rate, you can understand we just want to have a dialog about the problem, which we will have with other users if we post it under these forums.
    So yes, it's often just some noise, but at least there is a sign of life.

    Plus, creating a thread can also gather other members opinion, and sometimes solution, or just seeing that we're not alone having this problem. This can save us a lot of time from searching for a potential bug in our own game framework.

    I understand the procedure is easier with bug report automatic forwarding, but the more serious projects go, the more we need answers. And as not 100% of bug reports receive an answer, we're turning ourselves toward the community.
    (and no I won't kill my wallet with private Support for something that can very potentially be a Unity 3.5 bug).

    Anyway, I try to be not stupid, so I filed a bug report with the written repro case above.
     
    Last edited: Mar 31, 2012
  24. Dambusters

    Dambusters

    Joined:
    Jan 6, 2012
    Posts:
    52
    My project uses 2 projector lights and terrain on iOS. The draw calls have doubled when moving from 3.5b to 3.5f. I've just reloaded the same scene in both versions and switching the blob projector lights on - 3.5b reports that the draw calls go from 38 to 42 (about what I would expect), with the identical scene in 3.5f the draw calls go from 38 to 84.

    I reported problems with projector lights and terrain (#436960) in 3.5b back in early January which is marked as closed as it will be fixed in the next release (which is 3.5f) - I suspect this was related to the current problems.

    I've read on this forum that Unity is looking at this and knows about the projector light problems - I've also read that they intend to do a hot fix. BUT WHEN?

    This has been reported by many users over several weeks, so (aside from telling us to file more bug reports) can anyone from Unity give us any indication of when this is likely to get resolved? Or even give us SOME indication of how long this will take? 1 week, 1 month, 3 months?

    Like many others using Unity Pro to develop on, I am stuck waiting to upload an App until this is resolved (as it makes my game unplayable on some platforms). This has financial implications for many of us as we are trying to run a business: We have a launch event which we are about to cancel as we won't have a product ready to show and we have no idea if Unity is taking this seriously and intend to fix it or not.

    Ideally, there would be a UNITY hotline or a blog keeping us up to date on such crucial issues but if there is I'm not aware of it.

    So come on Unity, be professional - PLEASE let us know what's going on !!!
     
  25. khaosenygma

    khaosenygma

    Joined:
    May 5, 2011
    Posts:
    27
    A project of mine had high draw calls. up to 200 from our usual 40-50. we found out that the blob shadow caused the massive spike in draw calls. once we turned it off. the draw calls returned to normal
     
  26. Joachim_Ante

    Joachim_Ante

    Unity Technologies

    Joined:
    Mar 16, 2005
    Posts:
    5,203
    The issue caused by increased drawcalls due to the Projector will be fixed in 3.5.1 We will ship it very soon.
     
  27. Tiles

    Tiles

    Joined:
    Feb 5, 2010
    Posts:
    2,481
    Yay! \o/
     
  28. n0mad

    n0mad

    Joined:
    Jan 27, 2009
    Posts:
    3,732
    So what about the non-projector increased drawcalls ? Any feedback on this ?
     
  29. _rem

    _rem

    Joined:
    Nov 3, 2006
    Posts:
    55
    this is true, this lack of communication is incomprehensible. There is not too long ago, at the slightest problem, David Helgason himself responded to the message before 24 hours, Unity does not become the Apple of 3D please ;)
     
  30. Dambusters

    Dambusters

    Joined:
    Jan 6, 2012
    Posts:
    52
    Thank you Joachim!
    I presume Unity Editor will announce that an upgrade is available?

    (I only ask because 3.5b didn't let me know that 3.5f was ready, I only found out reading posts on this forum)
     
  31. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    Guys, unity are responding more now than they've done in a year, it is absurd to criticise them when Joachim himself is looking into your posts. This is a major unity developer and if that is not a dialogue I don't know what is.

    Bear in mind if you're the staff of a highly populated forum like this you need to judge how much you promise your users. People will generally take what is said in stone and run amok with it causing all sorts of havoc. I mean, even I sort of did when I was looking for the BRDF stuff. But thankfully that got shipped on the blog.

    What we need to do is give them very strong test cases and focus all their energy not in a dialogue with us, but pinpointing issues of improvement and bug fixes - with clear reasoning and no depending on other people. If your reason can't stand up alone, there's no point in adding other voices. Same for bug reports - it has to stand up and clearly demonstrate the issue.

    It's the best for them and us.
     
  32. _rem

    _rem

    Joined:
    Nov 3, 2006
    Posts:
    55
    I follow Unity software from the beginning, I bought version 2 and version 3. i am working on a project for one year and the lack of communication on the bugs in the 3.5 (always available for download:confused: ) for a client that pays its license is incomprehensible!
    I can understand everything but I must explain... :cool:
     
  33. n0mad

    n0mad

    Joined:
    Jan 27, 2009
    Posts:
    3,732
    Actually, I don't know if you followed the case Hippo, but the thread was treated a bit quickly. A [solved] was put, but the explanation given by Joachim didn't fit the initial scenario (no projector, and even by turning off dynamic lights, DCs still up).
    I even took a lot of time to write down another solid repro case with the HUD, so with no lightmapping involved, but not a single feedback was given, even if Joachim might have read it (I also filed a bug but no feedback either). Even a "we're looking at it" would have been a start. I don't even know if what I found is considered normal by Unity... So what gives ?

    _rem is right, the communication has much changed, I remember 2 years ago when we had whole discussions in these forums with ReJ or even Aras, it was super enlightening. Now, it's very much not like this anymore, we have to admit.
     
    Last edited: Mar 28, 2012
  34. brn

    brn

    Joined:
    Feb 8, 2011
    Posts:
    320
    Just a quick question, Are you guys seeing a relative frame rate decrease to go with the extra draw calls? If not its possible the draw call count itself is the bug.
     
  35. n0mad

    n0mad

    Joined:
    Jan 27, 2009
    Posts:
    3,732
    I wondered this myself, but didn't have the time to make a proper build to test on a phone.
    But I've seen many posts saying the frame rate decreased aswell with the DC increase.
    Plus if Joachim confirmed that one reason for the increase was that in 3.4 lights didn't hit lightmaps, it might be hard to believe there's no frame rate decrease.
     
  36. Tiles

    Tiles

    Joined:
    Feb 5, 2010
    Posts:
    2,481
    Here it also decreased the frame rate. So yes, those are real drawcall issues, not wrong drawcall count.
     
  37. frozenpepper

    frozenpepper

    Joined:
    Sep 17, 2007
    Posts:
    222
    very heavy frame rate decrease for me, going form 55 to 289 draw calls has a terrible effect on device (jumped from 55 FPS to about 20 on iPad 1).
     
  38. Dambusters

    Dambusters

    Joined:
    Jan 6, 2012
    Posts:
    52
    Maybe this isn't the best place to suggest this but for me the ideal situation would be a public list of current confirmed bugs being addressed by Unity with a rough indication when each one might be solved.
    The situation at the moment is that we might get some feedback if someone happens to read a particular thread or (more often than not) complete silence from Unity.

    @Hippo While I do appreciate "Joachim himself" replying, all I actually know at the moment is that it's being looked at and it will be fixed "very soon". I know that it's difficult to make any guess as to how long it takes to track down a bug and squash it, but in reality "very soon" might be one day, one week or one month.
    In the real world, with real clients (and real costs), telling our clients "very soon" day after day doesn't really cut it - very soon we have no clients.

    Now that Unity is a big successful company what I'd really like is something a little less vague and ideally a way of contacting Unity where I can get a straight answer (even "It will take at least 2 weeks" is way better than "very soon").

    I believe that would be best for them and us.