662be1f183995

662be1f183fe7
1 Guest is here.
 

Topic: System Shock 2 VR Read 10401 times  

662be1f18489eHardkern

662be1f18490b
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
662be1f184ad8
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

662be1f184c38voodoo47

662be1f184c8b
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.

662be1f184d6cHardkern

662be1f184dc2
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.

662be1f184ee1icemann

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

662be1f185117voodoo47

662be1f18515f
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.

662be1f18529fHardkern

662be1f1852fc
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

662be1f185602JosiahJack

662be1f185658
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

662be1f1857c8Hardkern

662be1f185817
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?

662be1f185949JosiahJack

662be1f18599e
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?

662be1f185ac2Starspawn

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

662be1f185baficemann

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

662be1f185d07Hardkern

662be1f185d54
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"

662be1f185e6fHardkern

662be1f185eb3
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?

662be1f185ff2JosiahJack

662be1f18603f
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)

662be1f186121voodoo47

662be1f18616c
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.

662be1f1866a6ZylonBane

662be1f18670f
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.

662be1f186818JosiahJack

662be1f186869
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.

662be1f18691bicemann

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

662be1f186a8dHardkern

662be1f186ad8
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?

662be1f186ba0JosiahJack

662be1f186bec
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.

662be1f186cf8JosiahJack

662be1f186d4c
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

662be1f186e23Hardkern

662be1f186e60
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 »
1 Guest is here.
They really know how to dangle a carrot, eh?
Contact SMF 2.0.19 | SMF © 2016, Simple Machines | Terms and Policies
FEEP
662be1f1879b3