Official Progressive GPU Lightmapper preview

Thats just waste of UV space if only one side is visible to player.

 

This is the logic of the game models. You have to use this method
This method makes your model cleaner. Lighting problems become zero
All game modeling uses this method except for models that are in the distance, such as background mountains

 

This is up to the lghtmapper to solve. To have unseen geo and unused UV space is never the answer.
UNity have the double sided GI feature for this. But its porly implemented.

Also rather than have it on the material it should be on the mesh. Why?

For example this pilar has multiple sides and should not have double sided GI




This wall using same material does need double sided GI



Double sided GI on none single plane geo creates artifaces like this



@KEngelstoft ill tag you so you ge the feedback on Double sided GI

 

1. What is the plane behind the wall in the second image? Is it behind the wall?
2. In the third image I don't see any artifaces. what do you mean

 

These are high quality indirect shadows on corners. only can be achieved with PLM

 

I talk about the black outlining on the pillar. Its because of double sided GI settings. Look at the single plane wall with the green arrow. No such artifact.

 

Take screenshot from Lightmap mode

 

edit: its becasuse of double sided GI setting. It shuld be moved to mesh so we can use it for only those meshes are are single planes. Or even better remove the setting and solve it automatic

edit: to comparfe. a object without double side gi, no artifact

 

I have already mentioned my issues so there is no point in doing so. Still, I have made something that is supposed to break on purpose, a probuilder cube. Here is what they look like after baking:





I know exactly what the issue is, I know how to fix this. My point all the time was, why do we have to even fix this kind of issue and waste time to bake the scene a second time? It's not possible to find the existence of this before you start baking.

Here is a scene made in ue4 with the exact same mesh, you can see here glitches but a different kind of them, they exist because I'm using cubes and each is a separate mesh.

 

also remember it slows down the baking process, wastes your memory, and potentially wastes your bandwidth between CPU and GPU.

The method of using cubes instead of planes isn't standard in the industry and most games I have worked on never used that. The main reason is that It brings more problems than it attempts to fix.

Even the default scene in HDRP uses planes for walls instead of cubes. yes, they had to do some workaround for this, but it's less of an issue than having tons of pointless cubes.

 

That will create extra draw calls just for a design time flaw. This needs a better workflow guys. I have found that it needs for pretty much every single plane mesh. I can disable it and rerender a scene and show some screens.

 

Gif compare between Maya Unwrap and Unity Unwrap:

 

Just tested the newly released alpha, it indeed seems like the issue is fixed. Looking forward to the fix landing on 2020 LTS.

 

Is it coming though? There is still nothing on the release notes of 2020.3.11f1 and it has been 5+ months since I first reported this, I'm starting to get frustrated.

I know you fixed it in the alpha, but I can't use the alpha for my game.

 

The newly released 2020.3.12f1 still doesn't contain the fix.

I would think 40 days is enough time for a fix to be back ported into LTS, but I guess it's not?

 

Is the Progressive Lightmapper compatible with Apple M1 Silicon?

It failed with the error "Material Render Job Skipped - Out of System Memory"!

Unity 2020.3.12f1

 

I found Tiled Baking is released.
Just try it. I can baked higher resolution lightmap with GPU lightmapper than before.
Good job.

 

Please advice me what to do I can't do Progressive GPU light bake.

 

How to enable Tiled Baking on Apple M1?

 

It seems that Apple M1 really does not supports GPU Lightmaping.
Tested now with Unity 2021.3

Code (csharp):

1.  
2. OpenCL Error. Falling back to CPU lightmapper. Error callback from context: [CL_DEVICE_NOT_AVAILABLE] : OpenCL Error : Error: build program driver returned (-2)
3.  
4.  
5. OpenCL Error. Falling back to CPU lightmapper. Error callback from context: OpenCL Warning : clBuildProgram failed: could not build program for 0xffffffff (Apple M1) (err:-2)
6.  
7.  
8. OpenCL Error. Falling back to CPU lightmapper. Error callback from context: [CL_BUILD_ERROR] : OpenCL Build Error : Compiler build log:
9. <program source>:49:46: warning: type specifier missing, defaults to 'int'
10. SHARED_INLINE SHARED_float2_type make_float2(float x, float y)
11.                                  ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~
12. /System/Library/Frameworks/OpenCL.framework/Versions/A/lib/clang/3.2/include/cl_kernel.h:3223:36: note: expanded from macro 'make_float2'
13. #define make_float2(A,B) (float2)((A),(B))
14.                                    ^
15. <program source>:49:55: warning: type specifier missing, defaults to 'int'
16. SHARED_INLINE SHARED_float2_type make_float2(float x, float y)
17.                                  ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~
18. /System/Library/Frameworks/OpenCL.framework/Versions/A/lib/clang/3.2/include/cl_kernel.h:3223:40: note: expanded from macro 'make_float2'
19. #define make_float2(A,B) (float2)((A),(B))
20.                                        ^
21. <program source>:49:34: error: redefinition of '__float2' as different kind of symbol
22. SHARED_INLINE SHARED_float2_type make_float2(float x, float y)
23.                                  ^
24. /System/Library/Frameworks/OpenCL.framework/Versions/A/lib/clang/3.2/include/cl_kernel.h:3223:27: note: expanded from macro 'make_float2'
25. #define make_float2(A,B) (float2)((A),(B))
26.                           ^
27. /System/Library/Frameworks/OpenCL.framework/Versions/A/lib/clang/3.2/include/cl_kernel.h:131:18: note: expanded from macro 'float2'
28. #define float2                  __float2
29.                  ^
30. /System/Library/Frameworks/OpenCL.framework/Versions/A/lib/clang/3.2/include/cl_kernel.h:63:54: note: previous definition is here
31. typedef __attribute__(( ext_vector_type(2) ))  float __float2;
32.                                                      ^
33. <program source>:49:46: error: parameter name omitted
34. SHARED_INLINE SHARED_float2_type make_float2(float x, float y)
35.                                              ^
36. /System/Library/Frameworks/OpenCL.framework/Versions/A/lib/clang/3.2/include/cl_kernel.h:3223:36: note: expanded from macro 'make_float2'
37. #define make_float2(A,B) (float2)((A),(B))
38.                                    ^
39. <program source>:49:55: error: parameter name omitted
40. SHARED_INLINE SHARED_float2_type make_float2(float x, float y)
41.                                                       ^
42. /System/Library/Frameworks/OpenCL.framework/Versions/A/lib/clang/3.2/include/cl_kernel.h:3223:40: note: expanded from macro 'make_float2'
43. #define make_float2(A,B) (float2)((A),(B))
44.                                        ^
45. <program source>:52:13: error: use of undeclared identifier 'x'
46.     res.x = x;
47.             ^
48. <program source>:53:13: error: use of undeclared identifier 'y'
49.     res.y = y;
50.             ^
51. <program source>:57:46: warning: type specifier missing, defaults to 'int'
52. SHARED_INLINE SHARED_float3_type make_float3(float x, float y, float z)
53.                                  ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~
54. /System/Library/Frameworks/OpenCL.framework/Versions/A/lib/clang/3.2/include/cl_kernel.h:3224:38: note: expanded from macro 'make_float3'
55. #define make_float3(A,B,C) (float3)((A),(B),(C))
56.                                      ^
57. <program source>:57:55: warning: type specifier missing, defaults to 'int'
58. SHARED_INLINE SHARED_float3_type make_float3(float x, float y, float z)
59.                                  ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~
60. /System/Library/Frameworks/OpenCL.framework/Versions/A/lib/clang/3.2/include/cl_kernel.h:3224:42: note: expanded from macro 'make_float3'
61. #define make_float3(A,B,C) (float3)((A),(B),(C))
62.                                          ^
63. <program source>:57:64: warning: type specifier missing, defaults to 'int'
64. SHARED_INLINE SHARED_float3_type make_float3(float x, float y, float z)
65.                                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~
66. /System/Library/Frameworks/OpenCL.framework/Versions/A/lib/clang/3.2/include/cl_kernel.h:3224:46: note: expanded from macro 'make_float3'
67. #define make_float3(A,B,C) (float3)((A),(B),(C))
68.                                              ^
69. <program source>:57:34: error: redefinition of '__float3' as different kind of symbol
70. SHARED_INLINE SHARED_float3_type make_float3(float x, float y, float z)
71.                                  ^
72. /System/Library/Frameworks/OpenCL.framework/Versions/A/lib/clang/3.2/include/cl_kernel.h:3224:29: note: expanded from macro 'make_float3'
73. #define make_float3(A,B,C) (float3)((A),(B),(C))
74.                             ^
75. /System/Library/Frameworks/OpenCL.framework/Versions/A/lib/clang/3.2/include/cl_kernel.h:132:18: note: expanded from macro 'float3'
76. #define float3                  __float3
77.                  ^
78. /System/Library/Frameworks/OpenCL.framework/Versions/A/lib/clang/3.2/include/cl_kernel.h:64:54: note: previous definition is here
79. typedef __attribute__(( ext_vector_type(3) ))  float __float3;
80.                                                      ^
81. <program source>:57:46: error: parameter name omitted
82. SHARED_INLINE SHARED_float3_type make_float3(float x, float y, float z)
83.                                              ^
84. /System/Library/Frameworks/OpenCL.framework/Versions/A/lib/clang/3.2/include/cl_kernel.h:3224:38: note: expanded from macro 'make_float3'
85. #define make_float3(A,B,C) (float3)((A),(B),(C))
86.                                      ^
87. <program source>:57:55: error: parameter name omitted
88. SHARED_INLINE SHARED_float3_type make_float3(float x, float y, float z)
89.                                                       ^
90. /System/Library/Frameworks/OpenCL.framework/Versions/A/lib/clang/3.2/include/cl_kernel.h:3224:42: note: expanded from macro 'make_float3'
91. #define make_float3(A,B,C) (float3)((A),(B),(C))
92.                                          ^
93. <program source>:57:64: error: parameter name omitted
94. SHARED_INLINE SHARED_float3_type make_float3(float x, float y, float z)
95.                                                                ^
96. /System/Library/Frameworks/OpenCL.framework/Versions/A/lib/clang/3.2/include/cl_kernel.h:3224:46: note: expanded from macro 'make_float3'
97. #define make_float3(A,B,C) (float3)((A),(B),(C))
98.                                              ^
99. <program source>:60:13: error: use of undeclared identifier 'x'
100.     res.x = x;
101.             ^
102. <program source>:61:13: error: use of undeclared identifier 'y'
103.     res.y = y;
104.             ^
105. <program source>:62:13: error: use of undeclared identifier 'z'
106.     res.z = z;
107.             ^
108. <program source>:66:46: warning: type specifier missing, defaults to 'int'
109. SHARED_INLINE SHARED_float4_type make_float4(float x, float y, float z, float w)
110.                                  ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
111. /System/Library/Frameworks/OpenCL.framework/Versions/A/lib/clang/3.2/include/cl_kernel.h:3226:40: note: expanded from macro 'make_float4'
112. #define make_float4(A,B,C,D) (float4)((A),(B),(C),(D))
113.                                        ^
114. <program source>:66:55: warning: type specifier missing, defaults to 'int'
115. SHARED_INLINE SHARED_float4_type make_float4(float x, float y, float z, float w)
116.                                  ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~
117. /System/Library/Frameworks/OpenCL.framework/Versions/A/lib/clang/3.2/include/cl_kernel.h:3226:44: note: expanded from macro 'make_float4'
118. #define make_float4(A,B,C,D) (float4)((A),(B),(C),(D))
119.                                            ^
120. <program source>:66:64: warning: type specifier missing, defaults to 'int'
121. SHARED_INLINE SHARED_float4_type make_float4(float x, float y, float z, float w)
122.                                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~
123. /System/Library/Frameworks/OpenCL.framework/Versions/A/lib/clang/3.2/include/cl_kernel.h:3226:48: note: expanded from macro 'make_float4'
124. #define make_float4(A,B,C,D) (float4)((A),(B),(C),(D))
125.                                                ^
126. <program source>:66:73: warning: type specifier missing, defaults to 'int'
127. SHARED_INLINE SHARED_float4_type make_float4(float x, float y, float z, float w)
128.                                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~
129. /System/Library/Frameworks/OpenCL.framework/Versions/A/lib/clang/3.2/include/cl_kernel.h:3226:52: note: expanded from macro 'make_float4'
130. #define make_float4(A,B,C,D) (float4)((A),(B),(C),(D))
131.                                                    ^
132. <program source>:66:34: error: redefinition of '__float4' as different kind of symbol
133. SHARED_INLINE SHARED_float4_type make_float4(float x, float y, float z, float w)
134.                                  ^
135. /System/Library/Frameworks/OpenCL.framework/Versions/A/lib/clang/3.2/include/cl_kernel.h:3226:31: note: expanded from macro 'make_float4'
136. #define make_float4(A,B,C,D) (float4)((A),(B),(C),(D))
137.                               ^
138. /System/Library/Frameworks/OpenCL.framework/Versions/A/lib/clang/3.2/include/cl_kernel.h:133:18: note: expanded from macro 'float4'
139. #define float4                  __float4
140.                  ^
141. /System/Library/Frameworks/OpenCL.framework/Versions/A/lib/clang/3.2/include/cl_kernel.h:65:54: note: previous definition is here
142. typedef __attribute__(( ext_vector_type(4) ))  float __float4;
143.                                                      ^
144. <program source>:66:46: error: parameter name omitted
145. SHARED_INLINE SHARED_float4_type make_float4(float x, float y, float z, float w)
146.                                              ^
147. /System/Library/Frameworks/OpenCL.framework/Versions/A/lib/clang/3.2/include/cl_kernel.h:3226:40: note: expanded from macro 'make_float4'
148. #define make_float4(A,B,C,D) (float4)((A),(B),(C),(D))
149.                                        ^
150. <program source>:66:55: error: parameter name omitted
151. SHARED_INLINE SHARED_float4_type make_float4(float x, float y, float z, float w)
152.                                                       ^
153. /System/Library/Frameworks/OpenCL.framework/Versions/A/lib/clang/3.2/include/cl_kernel.h:3226:44: note: expanded from macro 'make_float4'
154. #define make_float4(A,B,C,D) (float4)((A),(B),(C),(D))
155.                                            ^
156. <program source>:66:64: error: parameter name omitted
157. SHARED_INLINE SHARED_float4_type make_float4(float x, float y, float z, float w
158.  
159. OpenCL Error. Falling back to CPU lightmapper. Error callback from context: [CL_INVALID_VALUE] : OpenCL Error : clGetProgramBuildInfo failed: return buffer size (1024 bytes) was too small to hold the result: 11814 bytes
160.  
161.  
162. OpenCL Error. Falling back to CPU lightmapper. Error callback from context: CL_INVALID_PROGRAM
163.  
164.  

 

Hi again
Has this problem been fixed in newer versions? Can we use graphics with 2 GB of memory?

• GI: The Unity Editor no longer returns erroneous error messages about GPU driver issues when the user's GPU does not have enough memory to support the GPU Lightmapper. (1289660)
  

 

It has been another month and another 2 LTS versions released without this fix.

I made the mistake of waiting for this bug to get fixed instead of working around it. Surely 6 months of waiting should be more than enough, but it is not. Let this be a lesson to myself: reporting bugs, even regressions, is useless, since the fixes will never arrive soon enough for me to be able to use them.

I don't know who needs to hear this feedback but, your backport process is broken and takes too much time. And it's not like the slowness has benefits, new bugs get introduced to LTS often, we just get really slow fixes.

 

After only a few seconds, Unity falls back from Progressive GPU (Preview) to Progressive CPU.
The error is

OpenCL Error. Falling back to CPU lightmapper. Error callback from context: Not enough GPU memory to fit lightmap in memory, even in tiled baking mode. Available GPU memory: 2.75 GB

I thought about buying a new GPU, but then I took a look at my specs and saw the following for my GPU (also shown in the screenshot):

- 14300 MB total available
- 6144 MB dedicated
- 0 MB system
- 8156 MB used together

So I wondered if a new GPU would really help.

Can somebody tell me what is going on for me? I don't understand the specifics (liked "total", "dedicatd", "system" and "used together".)

Or is it simply a bug in the Lightmapper?

Thank you!

 

Whatever the case, you won't be able to bake a 4k map with a 6gb card. Even with a 16gb card I can't do that.

Other than that, your card may be 6GB, but the OS and other applications you may be running are also using some, so there will be less available for Unity.

 

Hi. Its great to know that there is still hope! Just letting you know that even without the optimizations progressive GPU works fantastic on my 3GB nvidia. (without it Lighmaps are a no no for practical game development). At least maybe add a command line argument that lets you bypass the 4GB restriction for people that know what they are doing. Until that day comes(and hopefully it will) we will have to live in the past and miss out on all the good stuff '-(

 

Or just use bakery like I do. Highly recommend the realtime preview addon too. In fact unless Unity also adds a RT preview one day, I can't see myself switching back.

 

I wonder if it wont be cheaper for Unity, to abondon all projects like this, where they spend years on "making it work", and yet it's still unusable on real projects. Instead of all that money spent on r&d, marketing etc, just give grants to asset store devs who clearly already have solutions that are million times better.

I have of course no idea of the inner goings on at Unity or what management's thought processes or motivations are behind their decisions. Unity shouldn't buy and take over these assets, but in stead give grants to those asset store devs to futher enhance those products. I think in the long rong it will be much cheaper and progress will actually happen faster.

Well, my humble opinion anyway and just writing down some thoughts, however clueless it may be.

 

I think its cross platform compatibility that weights them down. Bakery supports only Nvidia GPU's, where Progressive GPU is also kinda supports AMD cards.

Although, you're completely right, Bakery is miles ahead.

 

Anyone remember when Beast was getting progressive baking and network baking?

Just me? Cool.

 

That's right but if you are a game dev sandwiched between developing and not, you buy a cheap 980 card or less, and bakery works perfect on it (even the RT preview).

This is substantially cheaper than lost hours trying to get PLM working on a couple of boxes without falling over. GPU baking has never worked well in Unity on all our GPUs - in the simplest of scenes. I am not sure what Unity uses to test but there's a really good reason bakery is far out in front. It works.

I suspect the reason is Unity probably ends up not developing on nvidia cards enough with PLM, or something silly like that, because we don't actually use AMD cards here, and have only had problems with our nvidia cards.

I am a big supporter of Unity so make of that what you will.

 

Yeah, I've been using cheap 1050 TI until switched to 3080. It took fairly large scene (4x4km) ~20m to bake with Bakery. On 3080 its 5 min with raytracing enabled.

Still aeons faster and more stable than PLM GPU (it was unable to even bake that scene at all, just crashed).

In general I think if hardware saves this much time, its worth just buying it.


On the crossplatform support topic - I think two separate teams should be (if not already) working it.
Sooooo in theory Unity could just buyout Bakery and integrate it as Nvidia branch.
Win / win.

 

Trying checking the power on the graphic card.I have disconnected the 8 pins out of 16 pins and baking stated fine. the thing worked for me check if it works for you

 

Does this take advantage of the RT cores on RTX cards like Bakery does?

 

GPU не хочет запекаться.

 

Hi,
it's almost a week that with my new rig and Unity 2020.3.25 I can't do the simplest bake using PLM GPU. On a simple scene, with very low settings and numbers of lightmap capped at 1, I get the "OpenCL out of memory" error. My new rig consist of a RTX 3070 8gb, 64 gigs of ram and AMD 5950X. Is there any known issue with Nvidia latest drivers, or some known bug in 2020.3.25? It's really concerning that PLM GPU totally stopped working since last week

 

When is GPU lightmapper coming out of preview? (It's been 40 months now)
Also, why is a preview feature included as standard in the LTS releases?

 

I member network baking. I also wonder how hard is it going to be for unity to expose more of the plm api so I can just send the jobs to workers. The currwnt api only allows half brained hacks that are no good.

 

Don´t you face any problems with Bakery + HDRP?
I do and so I am forced to use Unity PLM on HDRP :-(

 

Frank replied in that thread and asked you to send a file for him to investigate. Did you ever do that and did you get a reply from it?

 

To be honest, due to lack of time I wasn´t able to prepare a separate hdrp project, reliable replicate and document the problem.
I will do so asap, PLM often kills Unity due to not enough GPU Memory which is a pain.

 

Well the author of bakery asked you for a project and he usually fixes things within a few days. So it seems like you want to use PLM?