6741a8a41be68

6741a8a41d782
3 Guests are here.
 

Topic: System Shock 2 VR Read 14955 times  

6741a8a41e0f1Hardkern

6741a8a41e16f
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
« Last Edit: 08. September 2020, 20:08:52 by Moderator »
Acknowledged by: Briareos H
6741a8a41e32d
I see you put in some work. And it's cool if you want to walk around the levels in VR. But I fear you'll find that recreating the game's mechanics is way too much work in the end. Still a nice job.  :thumb:
Acknowledged by: icemann

6741a8a41e483voodoo47

6741a8a41e4e9
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.

6741a8a41e5eeHardkern

6741a8a41e640
I think the main components to get somethings playable are:

1. inventory to pick up and drop items
2. weapons to shoot badguys with
3. roaming enemy AI

Sure SS2 has a wealth of other features, but I think after getting those components I can publish a playable demo.

I'm planning on rewritting the game logic myself, so I don't have to port that horrible c++ mess.

6741a8a41e765icemann

6741a8a41e7bb
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.
6741a8a41e9be
Looks great.
Maybe something like Kolya suggested could be good first milestone. Just a VR environment to experience the levels with improved lighting etc.

6741a8a41ea95voodoo47

6741a8a41eae6
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.

6741a8a41ec74Hardkern

6741a8a41ed29
Maybe something like Kolya suggested could be good first milestone. Just a VR environment to experience the levels with improved lighting etc.

I'm able to import the lights. But there are a lot of them and they kinda tank performance. Don't want to bake them yet.
Also SystemShock2 uses a different light calculation formular. I think they have linear light fall off.

Not sure how this attachment thing works. This forum is different from forums I'm normally on. I have attached 3 comparison images. One from the game, one imported without lights, one imported with lights.

[imported_light.png expired]
[no_light.png expired]
[original.png expired]
« Last Edit: 09. September 2020, 16:18:27 by Moderator »
Acknowledged by 2 members: Gawain, Starspawn

6741a8a41f08cJosiahJack

6741a8a41f0e1
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

6741a8a41f1f9Hardkern

6741a8a41f244
Thanks. I'm aware of most of those things. Been working with Unity for years now. Im still in the rapid prototyping phase and all those optimizations would slow me down. Thats why I decided to not import lights for now.

After the lights are baked they should have almost no runtime cost at all, so I don't worry too much about it.

And I thought VR fps target is 90?

6741a8a41f36eJosiahJack

6741a8a41f3ca
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?

6741a8a41f4d0Starspawn

6741a8a41f51b
VR suits games like SS2 perfectly. Looking forward to seeing what you can pull off, ambitious project for sure.

6741a8a41f5aficemann

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

6741a8a41f708Hardkern

6741a8a41f754
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'm converting the assets into a unity native format so that I can make minor adjustements down the road. Atlasing the textures might be a good thing to do. SystemShocks textures are at most 256px by 256px. But so far everything runs smoothly and you know what they say: "Premature optimization is the root of all evil"

6741a8a41f839Hardkern

6741a8a41f882
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?

6741a8a41f98aJosiahJack

6741a8a41f9d3
I'm probably the best person to answer that other than Night Dive Studios, who are the rightsholders.

As the lead developer of Citadel, I've reached out to Night Dive Studios several years ago as regards my project.  They stated that so long as I don't commercialize Citadel in any way and don't use the "System Shock" name then I can continue with my System Shock 1 fan remake.  I would assume the same goes for SS2 fan projects, but you'd be better off asking them.

You should probably name it before asking.  Here are my lame suggestions:
VR Braun
Goggles VR
View of the Many
VR of the Many
RickenbackVR
CyVRnetic (ok, these are getting really lame now)

6741a8a41faa4voodoo47

6741a8a41faee
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.

6741a8a41ff3bZylonBane

6741a8a41ff93
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.
That depends. What, exactly, do you intend to create? If you're just making a toy to browse SS2 levels in Unity, you're fine. On the other hand, if you intend to make a fully faithful and playable port of SS2... well let's be honest, unless you're a god-tier coder the likes of which the SS2 community has never seen before, it's not happening. Many before you have tried and failed. What you've done so far is the easy part. To make an actual port, you'll have to precisely replicate dozens of complex systems. Act/react. Stims/receptrons. AI. Links. Loot lists. Ecologies. Alarms. Audio propagation. Audio schemas. Dynamic music. Automaps. Psi disciplines. Weapons. Drugs. Scripts. Status effects. Strings. Metaproperties. Message queues. Particles. User interface. Inventory. Research. Minigames. Keys. Object elevatoring. Hacking. Repairing. Swimming. Joint animation. Mantling. Leaning. Lights. Visibility. Gravity. Quest logging. Fogging. Flindering. Emails. Emitters. Materials. And that's just the major stuff.

JJ has been working on his SS1 port for YEARS, and that game's engine is exponentially less complex than SS2's.

6741a8a4200f3JosiahJack

6741a8a420149
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.

6741a8a4201fbicemann

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

6741a8a420388Hardkern

6741a8a4203de
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?

6741a8a42048eJosiahJack

6741a8a4204d7
Well I've definitely learned a lot, but not quiiite done.  I'm finishing the last room of the last area of cyberspace at the moment.

6741a8a4205e0JosiahJack

6741a8a420632
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

6741a8a420707Hardkern

6741a8a420750
New Video up. https://youtu.be/ZxT8-nLrkTE
https://www.youtube.com/watch?v=ZxT8-nLrkTE
Took way too long to make. But I think I have a fast workflow down for them now.
« Last Edit: 19. September 2020, 23:58:35 by Moderator »
3 Guests are here.
»Game is not over«
Contact SMF 2.0.19 | SMF © 2016, Simple Machines | Terms and Policies
FEEP
6741a8a4210a9