673f3bba90ad8

673f3bba91b4b
2 Guests are here.
 

Topic: System Shock 2 VR Read 14845 times  

673f3bba92444Hardkern

673f3bba924b5
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
673f3bba92687
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

673f3bba927a7voodoo47

673f3bba92801
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.

673f3bba92963Hardkern

673f3bba929d3
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.

673f3bba92b28icemann

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

673f3bba92d82voodoo47

673f3bba92dcb
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.

673f3bba92ef9Hardkern

673f3bba92f42
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

673f3bba93d97JosiahJack

673f3bba93df5
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

673f3bba93f39Hardkern

673f3bba93f84
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?

673f3bba940cbJosiahJack

673f3bba94500
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?

673f3bba9464aStarspawn

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

673f3bba94769icemann

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

673f3bba97788Hardkern

673f3bba977f5
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"

673f3bba9791bHardkern

673f3bba9796f
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?

673f3bba97a8dJosiahJack

673f3bba97ad8
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)

673f3bba97bb5voodoo47

673f3bba97c00
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.

673f3bba97ff7ZylonBane

673f3bba98060
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.

673f3bba981b2JosiahJack

673f3bba98202
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.

673f3bba982c0icemann

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

673f3bba9844bHardkern

673f3bba98496
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?

673f3bba98544JosiahJack

673f3bba98591
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.

673f3bba98766JosiahJack

673f3bba987c9
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

673f3bba988afHardkern

673f3bba988fb
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 »
2 Guests are here.
Come back, please. You're very much missed.
Contact SMF 2.0.19 | SMF © 2016, Simple Machines | Terms and Policies
FEEP
673f3bba991e7