Official Unity 2019.3 Is Now Available

webteam: "Hu? New release? And we are told last!"
(warning, bad english?)

 

At first I thought it was a typo, but looking again it indeed seems like 2020 is going to get rebranded as 2021 to match expected release year. This helps making it clearer that you shouldn't ship anything with it until 2021, all they need now is to rename 2021.1 to "2021 alpha" and 2021.2 to "2021 beta".

 

my unity hub shows 2019.3 as a pre-release

 

Please allow us to downgrade HDRP - because Shadergraph is completely broken in the newest HDRP. (Stylesheets are constantly being destroyed for me), can't add nodes, can't delete nodes, can't add properties, can't edit the master output node (gear icon thing), etc. Well you can add a new property - but it ends up looking like a green gradient field that goes from black to green to black horizontally..

I know it's HDRP and not shader graph because I was using the last version of 2019.3 and decided to upgrade the HDRP to newest and it broke shader graph, so naturally I downgraded to get rid of them problems. But now - this Unity is forcing me to use the newest HDRP - which breaks Shardergraph.

 

Yea, I get the same...I wonder if they have pushed it back to pre-release due to some issues, or just categorization issue on their side?

 

Just grab your manufest.json, downgrade the version numbers, delete the Library folder, then reopen your project.

 

Where is the "Stereo (non-head mounted)" XR option?
I can't find it in the Player Settings nor in the new XR Plugin Management settings...

Edit: the option "Stereo (non-head mounted)" is present in the Player Settings in Unity 2019.3 but not in 2020.1

 

You know perfectly well what I mean; you're just trying to deflect from the real issues. But you are entirely right in that there are other engines out there. I'll be making the switch to Unreal very soon. I've waited since 2010 for Unity to finally deliver on their promises. So far, they never have. The rest is smoke and mirrors, and endless, broken promises.

 

LWRP + Post Processing + Linear color space on Android == UI dark;

 

and Oculus quest still has problems in Unity 2019.3.0f6. We have reported the bug, most of us have but it is still not corrected. The problem is as occurs:

(a) Multi-View Rendering/Single-Pass (with Legacy XR and also with new XR Plugin): Oculus Quest lags a lot when the player moves, the textures starts to jitter and its very much noticeable,

(b) Multi-Pass Rendering (with Legacy XR): Oculus Quest works really smooth without any lag but only renders on Left Eye and Right Eye remains completely black,

(c) Multi-Pass Rendering (with new XR Plugin): Oculus Quest lags a lot when the player moves even though only one side of the glass (Right eye) is rendering.

Configuration:
(a) Tried with LWRP and also with URP (all versions starting from 7.0)
(b) Tried with Linear color space with OpenGLES3 settings

The above problems is for multiple users but no one at Unity seems to fix this long term running issue.

 

Could you remove dependencies for older projects in your future SRP?
Namely, older projects doesn't work with new SRP streams. Please, build Unity as future forward environment.

 

Is anyone else getting console spam with "Allocation of 4839 bytes at 000001FA7112F300" when opening a project in Unity 2019.3.0f6? It's one of those lovely context-free log-spam messages that I have already filed about 3 or 4 bugs about (each one with a large list of such log-spam messages). Looks like Unity 2019.3.0f6 was maybe built with debug-logging still active?

Here's more (that may also help investigate the issue more):

Code (CSharp):

1. TLS Allocator ALLOC_TEMP_THREAD, underlying allocator ALLOC_TEMP_THREAD has unfreed allocations, size 43628
2.  
3. Internal: Stack allocator ALLOC_TEMP_THREAD has unfreed allocations, size 43628
4.  
5. To Debug, enable the define: DEBUG_STACK_LEAK in StackAllocator.h. This will output the callstacks of the leaked allocations

Followed by lots and lots of messages like this:

Code (CSharp):

1. Allocation of 4848 bytes at 000001FA7121B630
2. Allocation of 111 bytes at 000001FA72CC02D0
3. Allocation of 37 bytes at 000001FA72BC0350

I have also filed a bug-report for this: (Case 1215429) Log-Spam: Allocation of 4848 bytes at 000001FA7121B630

 

Great! I just updated the bug entry with some new information:

 

Is the Time.deltaTime working ok on the Editor?
After build the project (2D) its looking the same as before the update, but in Editor its behaving veeery slow...

 

I am REALLY happy to hear there will only be 2 point releases - 2020.1 and 2020.2. I think this will give unity employees more time to finesse the product instead of chasing a marketing goal. Marketing is very Imprtant for the overal brand and feel, but sometimes marketing goals create unrealistic expectations for non marketing employees to work towards. With something as complex as unity there is no way to reliably promise to deliver all these new features in solid works condition within the currently tight and in my opinion unrealistic timelines.

I love unity and the only the that’s been breaking my heart is the regressions. A unity focused on stability and compatibility, and less fractured (there are so many renderers, systems etc now) would be a good thing.

 

Would love to try out 2019.3, but every time I try to install it through Unity Hub the download seems to complete, but then show "Incomplete or corrupted download file".

Had similar issue with previous version, which was solved by disabling all modules, but that hasn't help me this time.

Hmm, darn.

 

I like this new version so far. I also like the fact that you guys made it faster to navigate through the (legacy) animation panel of a .fbx but it still takes a long time for the fbx to update after you made your changes and clicked apply.

 

Hi, Visual Studio Code on MacOS does not seem to like 2019.3. I'm suddenly getting a whole lot of warnings that cripple OmniSharp. It starts with warnings like

[warn]: OmniSharp.MSBuild.ProjectLoader The referenced project 'Unity.RenderPipeline.Universal.ShaderLibrary.csproj' does not exist.

and ends with being unable to find assemblies.

The project builds just fine in Unity, I just can't really do any work right now because I don't get any proper compiler warnings or autocomplete and such. I've tried reinstalling VS Code too.

EDIT: Found the culprit, explained here: https://forum.unity.com/threads/vis...d-project-does-not-exist.806628/#post-5416371. TLDR; go into your package manager in Unity and make sure you're on Visual Studio Code Editor 1.1.3 and *not* 1.1.4.

 

The UI seems to have a new aggressive behavior that it didn't in the last RC . Changes that involve opening a new window like color selection, on any change it closes the window on you. Does the same for ALT-CLICK on rect transforms to change the preset.

 

Actually it can get worse. Saves are not immediate really. So if you edited something then click on a color field for example, it opens the color selector, but then immediately closes it as the last save finally kicks in (which itself triggers the window to close).

 

Upgraded to 2019.3 and all my prefabs are broken.

When I click on a prefab in the project window, the inspector shows all default / unset values for all members of the prefab. Double clicking that same prefab in the project window opens up the prefab editor for it, and when selecting objects in the hierarchy within the prefab editor, the inspector shows the correct values that were not displayed when clicking on the same prefab in the project view.

When I drag one of those prefabs from the project view into a scene, an instance of the prefab appear in the scene ... but just like issues in the project view, the instanced object has all default / unset values.

The inspect seems to think I have overrides on all the fields, but reverting them does nothing

Inspect from project


Inspect from prefab editor


Drop in scene, inspect from scene

 

With these settings editor completely hangs on code change while in play mode.
Anyone got the same issue?

 

Well my stylesheet errors went away after just shutting off Unity when I went to sleep.

 

By the way why is VSync systematically set to "off" in the game view? I have to put it on each time I create a new project, which means that I have to remember to do that each time; it's a waste of time. VSync off should be a choice.

 

I just updated and now my footballers are disappearing for a frame but leaving their hair piece in tact before returning about once a second. In real time it look like they are blinking. Oh dear. Reverting.

 

LWRP is dead. You're supposed to use URP now.

 

I'm not keen on updating my 2019.2.19 to 2019.3 because it changes again too much things (lot of post processing V2, lwrp to urp stuff changes and still not ready enough for me overall)

Release-wise, can i expect to see 'Known Issues in 2019.2.19f1' fixed in future 2019.2 releases ? Or won't there be any and I am forced to update to 2019.3 ?

 

Okay, i try it!

 

So I checked with URP but the same result on Device

 

Did you remake the post processing after deinstalling LWRP and installing URP? Or did you just keep it as it was?

 

What you mean remake?

 

He means URP uses a different PP stack by default than LWRP. You can use PP v2, but it is recommended to use the new stack for performance, etc.

I have a post about it here

 

Yeah, I used the new PP.

 

I'd suggest making a ticket with the Support team so they can look into this for you, as something here obviously doesn't sound right. The link to make the ticket is https://support.unity3d.com/hc/en-us/requests/new?ticket_form_id=65905

 

Well I converted my entire (huge) project over to unity 2019.3. Everything went very well, except for a few issues with the Standard Assets using GUITexture, but that wasn't hard to fix.

The big problem I have right now is that some object remain in memory between executions in the editor.

For example if I have a simple class like this.

Code (CSharp):

1. public class CharacterSystem
2. {
3.     public static List<Character> Characters { get; private set; }
4.     public CharacterSystem()
5.     {
6.  
7.         if (Characters == null)
8.         {
9.             Debug.Log("CharacterSystem New List Created");
10.             Characters = new List<Character>();
11.         }
12.         else
13.         {
14.             Debug.Log("CharacterSystem list already created");
15.         }
16. }

If I execute the first time (after starting unity) it creates the list. If I run the game a second or third time the list already exists.

it's strange because I have this code in the Awake() method of one game object.
this.characterSystem = new CharacterSystem();

This was working perfectly in the other versions.

Also, this is not the only issue I'm having between executions in the editor. The others are more complicated to explain. but are probably related.

This makes no sense to me unless Unity is now caching previous executions.

 

None of the kits work with the latest version... errors all over the place.. do I download an earlier version?
Thx!

 

You must use the recommended version that is mentioned on the tutorial page, until the projects are updated to new versions of Unity.

 

I found this interesting at the bottom of the 2019.3 landing page regarding 2020.x:

This will create some minor confusion about what is or is not an LTS release (implied that 2020.3 will be LTS), but not a big deal I guess.

 

Could it be related to the new fast play option? I think you can change it so Unity enter play mode faster but this affects what is rebuilt or something like that. Sorry for the non technical explanation

 

As per my previous post. I managed to fix the problem I was having by disabling
"Enter Play Mode Options (Experimental). "

I really don't understand why that option was enabled by default. Wasted my entire morning.

 

Good to know I think it makes sense to disable it by default if that’s what we’ve been using until now, and then encourage new people to try turning it on

 

It's not actually. I created an empty project and took a look; it's not enabled by default.

 

Interesting. I wonder if it got enabled when my project was converted.... or a gnome clicked on it...

 

It wasn't in mine.

 

Someone could take a look at this weird issue i'm having on 2019.3 ? https://forum.unity.com/threads/asm...h-the-same-key-has-already-been-added.793215/