FPS Sample diffs and custom fork (2019.1 + 2018.3)

Like with Book of the Dead environment, I was interested in seeing what changes Unity made to FPS Samples SRP and PP packages so here are the diffs from regular versions to FPSSample_0.1.1:

SRP diff here
PostProcessing diff here

FPS Sample is based on a SRP version between official 4.1.0 and 4.0.0 and PP version is based on 2.0.12-preview (they got just the version right after github bumped the package version to 2.0.13 but it contains zero of the 2.0.13 changes itself)

 

I'd love to get the diffs in the main repo for sure I've also done diffs for the entities but that's local as Unity hasn't put Entities package into github yet.

Btw, I do have also modified FPSSample repo here for 2018.3.0b11 and latest 2018.3 packages (check the commits for further details):
https://github.com/0lento/FPSSample/tree/2018.3-update

This repo updates all relevant packages, updates scripts to newest ECS and has all FPS sample changes for Entities, PostProcessing (2.0.17-preview, will update this to 2.1.0 final later) and SRP (which is now based on 4.3.0-preview on this instead of 4.0.0-4.1.0 mix on original repository).

I got left with one issue on the project side though, I didn't have time to fix the LitParticle shader (which is apparently modified from Lit or LayeredLit shader) so I just recreated the whole Shuriken shader on Shader Graph using HD Lit Graph. I only implemented functionality that the furnace effect needed (vertex + base color + colormap, normalmap and distortion), I think my custom shader visually matches the effect at least close by, it could have some other negative side effects that I didn't spot though.

My main purpose for this wasn't to upgrade the 2018.3 packages tho, it was just intermediate step to get things running on latest versions first and then port the FPS sample SRP changes to 5.1.0 so I can try to run it on 2019.1 alphas. I've actually done all this work already for 2019.1 but haven't pushed it into github yet as there are still some non-package related issues to be solved on 2019.1 (updated packages themself seem to work fine).

For example some of the API calls that FPS sample does for animation are now forbidden (apparently they were unsafe) so need to figure out how to work them out. Additionally the project loader broke so I can't load the maps properly, need to figure out how to fix the refs for it.

Also worth noting that I haven't verified my changes to work on built game as I'm still primarily focusing on getting it to run on 2019.1 I could play the map in editor using 2018.3 with my changes though.

Also as additional note, I'll probably upload the modified SRP and PP to new branches on my SRP and PP forks at some point, I just need to verify this all works properly before that (especially 5.1.0-preview port needed a lot of manual work because SRPs branched between 4.x.x and 5.x.x).

 

I've got 2019.1 update almost done but I'm still having few remaining issues to solve. Animation Jobs are using API functions that have been removed in 2019.1, I'm getting these three errors in particular:

Any ideas what would be the best way to fix these efficiently? If I just disable the lines, it will run but obviously the gun animations (nor the whole gun) will not show up.

My WIP branch is here:
https://github.com/0lento/FPSSample/tree/2019.1-update

If you try this branch, make sure you reimport prefabs just like docs instructed to do on 2018.3, I may have needed to reimport scriptableobject's too, not 100% sure as I did bunch of things to get the refs working again.

 

Thanks for the reply. I actually tried using streams for these when I ported this to 2019.1 It did seem to do "something" for the transform related ones but using it for property made the whole thing unstable. Also I got into situation where I could point the gun at myself but I didn't investigate if that was because the property's weight thing wasn't working right (or if the stream handle should have been dealt in different place).

 

I put a debug log there and you are right, the property one isn't used at least on the default char. The arm IKs are still messed up if I just naively change those transform scene handles to use stream versions, need to check what other code changes are needed.

 

Got here by searching for:
"is obsolete: 'SceneHandle is now read-only; it was problematic with the engine multithreading and determinism'"

I too am working on upgrading the FPSSample to 2019.X with my focus on 2019.2 for now.

I can confirm that with the latest update from Unity dev...
AimDragJob.cs
TwoBoneIKJob.cs

TransformStreamHandle m_WeaponHandResult;
m_WeaponHandResult from BindSceneTransform to BindStreamTransform

PropertyStreamHandle m_WeightHandle;
m_WeightHandle from BindSceneProperty to BindStreamProperty

The seemed to fix that part, however I cannot visually confirm it as I have now messed up my render pipeline and even if I reimport my t:model 's I still can't see anything. Not looking for help on this yet, I think I can sort it esp. with the 2019.1 repo above. In another attempt I plowed through the HDRP changes and was able to get it rendering but then got caught up on one of the ComponentDataWrapper's that appeared to not do anything but then gave me an error on level_00 test and of course I don't have that error with me now. Confident I can get this working soon and plan to github my results. I will update this reply with more info as I find it, but need to reboot as Unity 2019.1 frozen. Likely my fault had 3x FPSSamples open in 3x different versions trying to debug. Joy.

Ref:
https://forum.unity.com/threads/what-the-componentwrapper-exactly-does.525406/
https://docs.unity3d.com/Packages/c.../Unity.Entities.ComponentDataWrapperBase.html

[UPDATE]
CharPredictedStateComponent.cs
CharPresentationState.cs

had the ComponentDataWrapper beef.
This was fixed by downgrading to Unity.Entities 0.0.12-preview.23, note this gave a false positive at first as showed 6-7 new errors re: ComponentDataWrapper but closing and reopening forced the package system to reload and then that error was gone. Just a few more clean ups and I was able to get it working in 2019.2.0a4 I did end up using @0lento github pacakges for the 5.2.0 tweaks for core RP, HD RP, and Shader Graph only. Entites pack is stock *.23 as discussed. I kept the multiplayer and transform local packs. I think i also used @0lento postprocessing tweaks 2.1.0.



The packages listed on top were the final selection with minimal adjustments. The packages listed behind will most likely work I ran into the rendering error with those as I tried to reintroduce to the HD/Core-SRP's what was taken away by the upgrades. i.e. the stuff in between
//samplegame start...
//samplegame end

this left me with a lit layered data error with no info, couldn't load it was all? and then a ... o wait i did write those down here we go (again this is for the back set on the thumb above, arranged as local packages instead of cached.)
Shader error in 'HDRenderPipeline/LayeredLit': failed to open source file: 'LayeredLitData.hlsl'
Shader error in 'HDRenderPipeline/Lit': failed to open source file: 'ShaderPass/LitSharePass.hlsl'

EyeCandy 2018 Packs VS 2019.2 Packs:




For reference the Packages used in 2018 from github are as follows:


I will say this. In 2019.2 FPSSample level_00 it was the first time I caught my self looking at how pretty the floor was. Good job guys.

 

Ok...my moving from SceneHandle to StreamHandle didn't work after all. Next step will be to try commenting out, as suggested it might be old code. But I can confirm even with this error and the goods above the IK on the terraformer seems just fine in FPS. I will try to further test this and post back. Below is the error when trying to swap out the SceneHandle for StreamHandle because:
SceneHandle is now read-only; it was problematic with the engine multithreading and determinism

InvalidOperationException: The PropertyStreamHandle is invalid. Please use proper function to create the handle.

UnityEngine.Experimental.Animations.PropertyStreamHandle.CheckIsValidAndResolve (UnityEngine.Experimental.Animations.AnimationStream& stream) (at C:/buildslave/unity/build/Modules/Animation/ScriptBindings/AnimationStreamHandles.bindings.cs:234)

UnityEngine.Experimental.Animations.PropertyStreamHandle.GetFloat (UnityEngine.Experimental.Animations.AnimationStream stream) (at C:/buildslave/unity/build/Modules/Animation/ScriptBindings/AnimationStreamHandles.bindings.cs:247)

TwoBoneIKJob.ProcessAnimation (UnityEngine.Experimental.Animations.AnimationStream stream) (at Assets/Scripts/Game/Modules/Character/Animation/AnimationJobs/TwoBoneIkJob.cs:158)

UnityEngine.Experimental.Animations.ProcessAnimationJobStruct`1[T].Execute (T& data, System.IntPtr animationStreamPtr, System.IntPtr methodIndex, Unity.Jobs.LowLevel.Unsafe.JobRanges& ranges, System.Int32 jobIndex) (at C:/buildslave/unity/build/Modules/Animation/Managed/ProcessAnimationJobStruct.cs:49)

 

OMG! CommunityUSHero, more like it Keep it up man!

 

Unity shipped HDRP diffs here for 0.3.0 (but not for visual effect graph):
https://github.com/Unity-Technologi...nity.render-pipelines.high-definition/patches

I did the traditional "what's different to stock HDRP" as well and this is the diff for all HDRP changes:
https://github.com/0lento/ScriptableRenderPipeline/commit/9ac752ee95e77224ee879bf6d25fd910f454934e
and this is the code changes for visual effect graph:
https://github.com/0lento/ScriptableRenderPipeline/commit/869844a2d4400894a9e466948d72bb3fe30cf275
they also updated vfx templates (but I dunno if there's anything different on these nor if there's any practical impact since these are only templates:
https://github.com/0lento/ScriptableRenderPipeline/commit/3e6381fb99b212e672f2c641c5ee0abf3a0d16a6.

If Unity staff is reading this, I'd have two questions about these changes. What is this occlusion threshold change for? I'm asking because besides it, one could run this on stock HDRP now as the debug callbacks aren't really required. And another question is about that visual effect graph change, you added Preserve tags (more about it here), so I'm guessing there was some packaging issue without these but why? I can tell this change hasn't been made for stock visual effect graph but if there's an issue, shouldn't it be solved there too?

 

Alright so the SceneHandle vs StreamHandle was indeed a thing. If I left TwoBoneIkJob.cs's
m_WeightHandle.SetFloat(stream, weight);
(without changing to StreamHandle I would get no gun tracking)

If I simply switched it out to StreamHandle, it did track but got 999+ errors (above)
however, commenting out this:
//m_WeightHandle.SetFloat(stream, weight);
from TwoBoneIkJob.cs gets rid of those 999+ errors and seems to let the weapon track as expected.

Now a few more errors the TargetType offers us {Scene,Stream}
We then see that my simply switching from SceneHandle to StreamHandle doesn't carry all the way back to IK described here:

https://github.com/Unity-Technologies/FPSSample/blob/master/Documentation/Animation.md
https://github.com/Unity-Technologies/FPSSample/blob/master/Documentation/Characters.md

but at this point I am lost and need to buff up on Animator/Ik and learn more about the SceneHandle/StreamHandle business. I will likely try to do a push of this version for learning. It looks like we just got a new version as @rizu mentions https://forum.unity.com/threads/fps-sample-0-3-0-now-available.636883/ is here! fun.




For reference below (attached) was the last packages vers. snapshot in case someone needed it.
I'll stop messing about with this commit and begin exploring the latest and greatest. Thanks for the timely push fps team

 

Did the original poster ever get this working?

I was asked to get a package we developed at work into this project, but that package was developed to run in Unity 2019.4. I have to say, on a personal level, I'm finding Unity's FPS Sample project to be a major disappointment and a bit of a disgrace. Unity promised that they would keep updating this to work on new versions of Unity, but they never even made it to Unity 2018.4. This was developed for Unity 2018.3, and that's were it stayed. The reason why I was impressed by this project was because Unity made a promise that they were going to keep it up to date, and it feels like they gave up on that from the start. I've literally been dealing with this project for the last 11 hours.

I originally tried going straight to Unity 2019.4, and with some effort, I managed to get all the packages to import correctly. Yet, when I looked at the code that was written for this project, it was just a mess of errors. I was able to fix some of the errors that were caused by changes in HDRP, but the network code. So, I figured that I could try smaller updates. Start at 2018.4, then 2019.1, and so on. That way, I could more easily look up where the APIs are changing, and I would be able to focus my searching for finding a solution. Took more effort than it should have, but I got it working in 2018.4. I copied that and converted the copy to 2019.1. Took some effort to get the newer versions of the packages to import, but I managed it. I start looking through the errors, and one of the first things I find is a error telling me that this method is obsolete. I break up both versions (2018.4 and 2019.1) of the documentation and see that the class is now readonly, with no hint of where to look for the functionally that was gutted out.

Unity, WTF!?

 

There is some work in the forks. But the next project slice was found in DOTSSample on github.
https://forum.unity.com/threads/dots-sample.796308/page-4

That didn't get very many commits and now we are on to a 2022 timeline?
https://forum.unity.com/threads/moving-dots-to-2020-1.910931/

 

@fct509 Yes the package is still broken in unity2020 but it is still usefull to study as a project per se.