Hi,

new to this forum. Really cool that there are still people discussing this game.

I have recently started work on a port of SystemShock2 to Unity3d to enable VR gameplay. I started by looking through the leaked source code and an old recreation attempt. I can now import any level with its geometry, textures, objects and enemies.
Work on importing animations has come far too, but they are still kinda off from what they look like in game.

Please watch this video I made showcasing the level importing.

SystemShock2 VR - Importing Into Unity3d - YouTube
SystemShock2 VR is an on going fan project to port SS2 to Unity3d to enable VR game play. All footage seen is rendered in Unity3d. Levels have been imported ...
https://www.youtube.com/watch?v=xOw--csz_Hs

history has shown us that one-man SS2 porting projects usually don't get too far - Dark is a complex beast, and cloning all its features into a different engine might prove complicated, especially if you are all alone in this.

anyway, good luck, and feel free to post you progress here.

In short, I'd highly recommend putting your energy into making a FM. We could really use a new one of those, far more than VR. VR I suspect will be added at some point in the "enhanced" edition.

about copyright (mentioned in your steam forum topic) - as long as you make your package require the demo or full retail datafiles, you should be good. implementing a simple check for a datafile of a certain size should be easy enough.

Unity Performance:
Only render one camera...EVER.  Each camera has about 3 to 5ms overhead just for culling which is half your budget for VR.  There's a single pass mode: https://docs.unity3d.com/Manual/SinglePassStereoRendering.html

To get away with realtime lights everywhere you'll need to
- Use deferred Unity builtin renderer.  DO NOT USE URP OR HDRP!!  They are half the performance for realtime lights.
- Reduce the number of active lights at any given time by:
    -- Mark your imported models as Static, then bake Occlusion culling and enable it on your camera
    -- Use a proximity script that turns off lights further away from the player than a certain view distance and in general reduce the number of active lights as much as possible by cleverly disabling lights out of view.  The fewer lights, the fewer set passes (aka draw calls)

Physics for moving objects:
- Never mark them static
- Keep your scene hierarchy as flat as possible, you'll save on Transform.Dispatchees if your moving enemies, for instance, are NOT children of any game object.  You can still parent them for organization purposes by using a script that takes all child objects at runtime and moves them out at game startlike this:
https://github.com/JosiahJack/Citadel/blob/master/Assets/Scripts/NPCSubManager.cs

Best of luck hitting 120fps

90fps baseline is the Oculus requirement, yes, but from what I've read higher framerates are better to help with motion sickness by reaching the point where increases in framerate aren't noticeable by most. I forget where I heard 120, but I think it was a rough guideline of double the normal PC requirement of 60fps. I can't afford a good VR set to learn by experience though so I'm a VR baby. 

I merely want to give the biggest examples of performance gains to help speed up your testing and development.  I would have saved countless hours of slow stuttery testing.

Looks nice so far.  Are you pulling in the import data every time you start the game/enter playmode?  Or is it cached somehow?  Are you generating a new material for each texture instance or are you auto-atlasing them somehow?

I expect failure, whilst at the same time wish you luck.

I want to ask you guys what you think about the legal standing of this project. It would really suck to put effort into this, if it just gets shutdown by one email.

Should I contact the IP-holder and ask for permission?
How aggressive is the current IP-Holder in such regards on a scale from Valve to Nintendo?
It would be hard to import all assets at runtime as certain optimizations can only be applied in editor. You guys think its enough to verify the existance of the original game files?
Do I worry too much?

and, as mentioned, requiring some original datafiles (meaning, the full retail game) to run usually is enough to stay on the safe side. so basically, as long as your package asks the user to provide a path to their SS2 crf files on the first run, and does nothing if it's not provided, you should be ok. and sure, the users will find a way to circumvent that, but that's them infringing copyright, not you.

It also takes motivation....like, a LOT.  Because it will suck sometimes and you'll need to remind yourself of the vision of where you are headed.  Love what you do.  Love what it could be.  Take breaks to look at problems with fresh eyes.  How do you eat an elephant?  One byte at a time.

Best of luck with whatever your scope ends up being.

I've contact a community manager on the NightDive discord.

I'd put some research into exactly what is required to make this work, before even remotely thinking about later on in the future.

What do you mean?

It also takes motivation....like, a LOT.  Because it will suck sometimes and you'll need to remind yourself of the vision of where you are headed.  Love what you do.  Love what it could be.  Take breaks to look at problems with fresh eyes.  How do you eat an elephant?  One byte at a time.

I admire you sticking to a project for 5 years. Did you get something out of it?

Hardkern, for when you get to it, this ingame filebrowser worked best for me to have people find the path to original game data.  It also prevents the user from doing any file manipulation, purely for selecting files or folders depending on the mode you use.

FYI
https://assetstore.unity.com/packages/tools/gui/runtime-file-browser-113006
https://github.com/yasirkula/UnitySimpleFileBrowser/tree/master/Plugins/SimpleFileBrowser