Reprisal wrote:What changes are you referring to? What is making such a major difference to the framerate that I'm missing? Telling me that I'm missing something, that you apparently know about, rather than just saying what I'm missing is pointless.
Well, it's not like almost everything has been mentioned in this topic or is quite readily available in the XR VR forum already.
BurnIt! wrote:This was explained in detail during the presentation.
Edit: bah - got distracted rewatching parts of the presentation and now I've been beaten to the punch...
Koboldx wrote:Please developers, VR is available in a good state... we dont need VR exclusive, just the optional VR support, that dont take much development time... its not need to be perfect,
even if its limited to cockpit view it would be awesome.
We were working on X Rebirth VR Edition for a year, that is a LOT of development time. And "just make it optional" doesn't make it any less work, on the contrary.
And especially with a market as young and relatively small as VR if you throw out a low quality product it'll hurt the ecosystem as a whole.
CBJ wrote:1. What Bernd said in the presentation is absolutely true. In order to achieve the consistently high framerates required for VR, we had to make significant changes to the game universe to reduce the number of ships and stations, and also to the UI to make it pleasant to use in 3D. Your assertion that adding a few graphics settings would solve the framerate problem suggests that you have completely misunderstood what the issue really is. In most situations, the framerate in X-series games is much more dependent on the universe simulation than the graphics settings. You can't just "dial down" the simulation, and for non-VR players (who constitute the vast majority of our player base) to have the size and depth of their game universe being determined by VR framerate requirements would be completely unacceptable, both to them and to us.
XR VR Edition is based on Home of Light and also includes all gameplay features from The Teladi Outpost. So most features from the very latest X Rebirth should also be included in XR VR Edition. However, the game is designed to take full advantage of Virtual Reality and this means that we had to make a lot of changes also to gameplay elements. Here is a quick list of some of the more obvious differences:
- The universe was modified. This affects the density of stations, the highways and many other things.
- There is no external camera: XR VR Edition is always played from cockpit perspective or 1st person on platforms.
- Platform gameplay is reduced: While you can still leave your ship and walk around stations, the need for this is much reduced.
- New missions and tutorial
- The X Rebirth original plot is replaced by a tutorial to learn the game and a series of missions. The later storylines from X Rebirth 2.0, 3.0 and 4.0 including the addition of SETA, jumpdrive, weapon mods and much more are all included too.
Most importantly of course the whole UI is changed. As the launch trailer shows, the game can be controlled in a very unique way with VR controllers. See also the images in this gallery.
I completely see where Egosoft are coming from here. The UI and UX in Rebirth VR are so completely different from the regular game, just look at that video of the launch trailer: https://www.youtube.com/watch?v=nM3TYjWfjgw
That takes a long time to develop and test and fine-tune, and it's completely understandable that they wouldn't want a half-arsed version of the VR game to be available (which would likely get ripped apart by reviews etc.)
That said though, I don't see what would be stopping them from making it on a clearly labelled "EXPERIMENTAL" branch on Steam, where people can opt in to the VR experience at any point through development. That way those who want to simply pop the headset on but play the game with regular UI/UX on a kb+mouse can do so from the start.
BlackDemon wrote:
That said though, I don't see what would be stopping them from making it on a clearly labelled "EXPERIMENTAL" branch on Steam, where people can opt in to the VR experience at any point through development. That way those who want to simply pop the headset on but play the game with regular UI/UX on a kb+mouse can do so from the start.
Exactly. This would contribute much more to the receptivity of the game.
Axeface wrote:They said in the presentation that they are not planning on VR at first, if at all. They make a point that VR is very different and requires huge changes to how the game works. As for track IR i dont think it's mentioned.
That definitely rules out X4 for me. Have not purchased a non-vr game since getting the Oculus Rift 2 years ago. Will never go back to flat screen games. Never again. Once you've experienced VR space games/sims, like Elite Dangerous, Lone Echo, From Other Suns, XRebirth-VR, Star Trek, (and many more coming this year) for many of us, there is no way you can go back. I for one, will wait for X4VR, if it's ever released, or won't buy it at all, that I can promise.
I hear that TrackIR is a fairly simple addition to a game as long as it has some form of "Mouse Look" (Take this with a HUGE grain of salt because I DO NOT know what I'm talking about)
TrackIR has been a lovely addition to many games for myself, and would love to see a proper implementation in X4. The X3 version was very limited and did not allow you to look behind you, but I still used it extensively even with its limits.
I have not played enough XR to know how it was done, but I only discovered that it was implemented relatively recently.
TrackIR support was added to XR in one of the later patches. We didn't get a lot of feedback on how well it worked for people, but there is no particular reason why that support would be removed in X4. It's possible that it might be disabled on initial release to keep things simple, but if so then I would be a little surprised if it wasn't added back in later.
CBJ wrote: ↑Thu, 27. Sep 18, 15:07
TrackIR support was added to XR in one of the later patches. We didn't get a lot of feedback on how well it worked for people, but there is no particular reason why that support would be removed in X4. It's possible that it might be disabled on initial release to keep things simple, but if so then I would be a little surprised if it wasn't added back in later.
That would be amazing considering the vast open windowed cockpits some of the ships have!
Android Software Engineer
Try my hands-free notification reader for your car.
CBJ wrote: ↑Thu, 27. Sep 18, 15:07
TrackIR support was added to XR in one of the later patches. We didn't get a lot of feedback on how well it worked for people, but there is no particular reason why that support would be removed in X4. It's possible that it might be disabled on initial release to keep things simple, but if so then I would be a little surprised if it wasn't added back in later.
That would be amazing considering the vast open windowed cockpits some of the ships have!
Seconded ^^ I'm also super excited about the idea of being able to glance around at the rest of the crew on the bridge (thinking about where the Teladi is sitting in this screenshot, and the awesome view of the rest of the bridge that he gets )
CBJ wrote: ↑Thu, 27. Sep 18, 15:07
TrackIR support was added to XR in one of the later patches. We didn't get a lot of feedback on how well it worked for people, but there is no particular reason why that support would be removed in X4. It's possible that it might be disabled on initial release to keep things simple, but if so then I would be a little surprised if it wasn't added back in later.
TrackIR worked well in XR, it just came along very late which is probably why it wasn't used much.
oh and I forgot to add... The original skunk cockpit design wasn't well suited to TrackIR as there were too many visual obstructions, but once you switched to the other cockpit designs (which as I recall came before the TrackIR support) they were much better, less cluttered with respect to head movement.
Hello, long time user here but I don't usually post, however I am doing an exception as I wanted to voice my opinion as it is a subject I care for and I hope devs listen to.
I would like to say that I certainly would look forward to a VR version of X4. After seeing the new trailer with gameplay video (those sent via the newsletter today), I would think that having a VR version of this would be priceless!! Walking around, moving in the cockpits, flying and being immersed in the world. Just the small part where you see a rather large freighter taking off while the camera is down low at somewhat pedestrian height, I can only imagine this in VR, wow!! So make this another interested customer for a VR version.
I understand some of the challenges but there are also other arguments/explanations in this thread that I am not sure about. So this is how I understand things:
-Designing a VR compatible UI is hard, and what X4 attempts to do would indeed be quite challenging for a good VR port. I must however make the obligatory comparison with E:D. They made it, it works perfectly, even the starmap works fine for me. How much work did that require? I can't really say but I understand that it must've been challening. I can only guess that they built the game from the start with VR in mind, which must've helped with designing the UI (rather than a non-VR game getting patched to a VR version afterwards). The result is excellent in E:D for both VR and non-VR users. So, obviously the UI is getting completed now as a non-VR UI so alot of work will be needed on that part to bring it to VR. Its a bit late for fixing this but hopefully this won't stop egosoft from making a VR version.
-The amount of geometry to display, GPU work, would be very demanding (I might have missunderstood the argument here but that's how I interpret it). I am somewhat skeptical about that limitation but I keep an open mind. I currently play VR games with very high amount of details which runs fine on my gtx1080. Space games as well as "ground" based games where you have to render terrain with all the objects associated with it, rather than empty space. Some might be more demanding and worst case, I drop the supersampling a bit. There are alot of tools right now that lets us adjust how much details we want to see which have strong impacts on FPS. In E:D for example, I max out the graphics and boost some SS while I also lock at 45fps ASW, head motion is not impacted as ASW compensates. That's coming from someone that easily sees the difference between a 60 and 120hz panel and that can't stand unstable FPS or drops. I can go thru very dense asteroid fields, large conflicts zones with dozens of ships, stations with heavy traffic and I enjoy it with no slowdowns, the experience might be better at 90FPS but I prefer the better graphical quality.
-The simulation is demanding. I think this is probably the main point here, not necessarily graphics quality. So we are talking about CPU then. I don't know how much the rift uses CPU, I guess tracking might require a good amount of cycles, I don't really know what else. I can't really tell how much of a problem this can become. Is it a question of limiting the background simulation? Have it run independently of the active world that the player sees (untie it from the actual game FPS). I don't know how optimised egosoft is on this level and how difficult it is to work on it, still I often see games not fully use the CPU's threads so maybe this is where work could be needed (rather than stripping the world down?). I am throwing things in the air here but I assume that this is the main issue.
So correct me if I am wrong but the 2 main difficulties I see are
1- Designing the UI
2- Managing the CPU cycles available (background simulation)
The 3rd point, GPU usage, to me this can be player managed either via out of game tools (supersampling for example, this can be implemented in game also) and in game graphical details options (if I turn down those shadows in E:D, I'll get a major boost).
Disclaimer: This is not a rant, just voicing what I understand and hopefully contribute positively to the thread. I do still very much hope that a VR version can be implemented and be implemented without gutting the game down.
It certainly required a lot of work to move XR's UI into worldspace for the VR edition, but that work wasn't thrown away and X4 still makes use of it. The VR control devices are trickier as the control system in X4 has changed a bit more.
It's the CPU performance that is the real issue, though; I will quote the relevant parts of my post from a couple of pages back to avoid repeating myself:
CBJ wrote: ↑Wed, 30. Aug 17, 15:38In order to achieve the consistently high framerates required for VR, we had to make significant changes to the game universe to reduce the number of ships and stations <snip>. In most situations, the framerate in X-series games is much more dependent on the universe simulation than the graphics settings. You can't just "dial down" the simulation, and for non-VR players (who constitute the vast majority of our player base) to have the size and depth of their game universe being determined by VR framerate requirements would be completely unacceptable, both to them and to us.
Being able to "run" a non-VR game while wearing a VR headset is a very long way from actually having a releasable game that fully supports VR and is comfortable to play. <snip>. And as already explained, framerate is very much an issue here, and not one that can be solved by changing a few settings or throwing some more GPU cycles at the problem.
People can doubt this all they like, but we spent months empirically measuring it, finding different ways to optimise things (many of which benefited performance in later versions of XR too) and so on. We don't just think this is the issue with VR in an X-series universe simulation, we know. So while it's possible that we might do more work with VR at some point in the future, it is unlikely that it will take the form of just "adding VR support" to the base X4 game.
Out of curiosity. So far, VR is known for being GPU hungry but we don't often hear about the CPU impact. Can you quantify the difference in CPU usage between VR and non VR? What would it be, 15-20% difference?? Just throwing a number here.
Besides aknowledging the issue, I can only hope you will find ways to make it happen. I guess we have less control over CPU and I don't have the knowledge to find any credible solutions. I guess this is a challenge to any CPU bound game, where if you optimize the CPU, you will want to put that power to good use in the main non-VR game and you will always have to tone it down when you want to add VR. Hmm.
Time to tap those unused CPU threads maybe leave the VR in its own threads and X on those unused threads. Yeah I know, its more complicated than that . j/k.
An important part of CBJs post is the 'consistently' high framerates. having your view stutter is an annoyance on desktop, it could actively be a hazard or disorienting in VR...
CBJ wrote: ↑Tue, 2. Oct 18, 00:11
It certainly required a lot of work to move XR's UI into worldspace for the VR edition, but that work wasn't thrown away and X4 still makes use of it. The VR control devices are trickier as the control system in X4 has changed a bit more.
It's the CPU performance that is the real issue, though; I will quote the relevant parts of my post from a couple of pages back to avoid repeating myself:
CBJ wrote: ↑Wed, 30. Aug 17, 15:38In order to achieve the consistently high framerates required for VR, we had to make significant changes to the game universe to reduce the number of ships and stations <snip>. In most situations, the framerate in X-series games is much more dependent on the universe simulation than the graphics settings. You can't just "dial down" the simulation, and for non-VR players (who constitute the vast majority of our player base) to have the size and depth of their game universe being determined by VR framerate requirements would be completely unacceptable, both to them and to us.
Being able to "run" a non-VR game while wearing a VR headset is a very long way from actually having a releasable game that fully supports VR and is comfortable to play. <snip>. And as already explained, framerate is very much an issue here, and not one that can be solved by changing a few settings or throwing some more GPU cycles at the problem.
People can doubt this all they like, but we spent months empirically measuring it, finding different ways to optimise things (many of which benefited performance in later versions of XR too) and so on. We don't just think this is the issue with VR in an X-series universe simulation, we know. So while it's possible that we might do more work with VR at some point in the future, it is unlikely that it will take the form of just "adding VR support" to the base X4 game.
That's a really good point that I hadn't considered, but now that I think about it, most games made specifically for VR don't seem to have a lot going on in the CPU department... like, single-level, stand-in-the-middle-of-this-dungeon-and-shoot-less-than-20-zombies type of lightweight. The X games do frequently need to take a hot second to deal with background sim stuff, and even in-sector stuff, every now and then. Variably tolerable on a monitor, but probably VERY disorienting in VR. Didn't realize XR:VR was scaled down that much, but knowing that it is, it definitely makes sense to pump the brakes on doing VR for X4.
Definitely VERY excited for regular old head tracking, though.
SVoyager wrote: ↑Wed, 3. Oct 18, 01:25Out of curiosity. So far, VR is known for being GPU hungry but we don't often hear about the CPU impact. Can you quantify the difference in CPU usage between VR and non VR? What would it be, 15-20% difference?? Just throwing a number here.
...
Time to tap those unused CPU threads maybe leave the VR in its own threads and X on those unused threads.
I think you've still maybe misunderstood the issue. VR in and of itself doesn't require significantly more CPU time than the normal game, and any additional CPU time it does need is probably at the driver level, and running on another thread anyway. The issue is that the basic framerate of the game needs to be at least 50% and ideally 100% higher to drive a VR headset than it does to drive a normal screen, because it has to render each eye separately. The only way to achieve that with the game universe simulation running is to reduce the size of that simulation. As Sandalpocalypse mentioned, it is also much more important in a VR game to keep the framerate consistent, in order not to create sickness-inducing stutter, and again that means trying to avoid there being frames in which the simulation takes up too much time.
So in very short, we are talking about these two issues:
-50 to 100% more FPS requirements for VR because of having to render 2 eyes (and that's really hard to do when you add in the background simulation as it has to run at this rate too)
-FPS needs to be stable. Stutters affect the non-VR game but the impact is much greater for VR.
Ok, by 50% more FPS, I suppose we are talking running @ 45FPS with ASW but x2 because of 2 eyes (and 100% would be without running ASW)? I suppose a minimum of 90FPS would be required. I am not sure about that last statement so please correct me if I am wrong. The issue is not limited to GPU (as we can tweak it to make that FPS requirement) but rather the simulation needing to run at the required 90FPS all the while being stable at that 90FPS too, so the CPU is really tasked.
The main issue would then be the fact that the simulation is directly tied to player/client FPS. I am sure it is not as easy as just saying this in one sentence, but wouldn't it be better if the simulation was run separately?
In E:D, they have the amazon server farms running the background simulation and the clients are sending and polling the data to/from it. Should the servers become overloaded, the clients are "mostly" unaffected, things like mission loading screens take a lot longer to populate and probably ships would warp around, etc. All the while, the FPS remains unaffected. What if X would be running similarly but on a smaller scale? I could have my GPU work hard on trying to display the game at max graphics settings, while the CPU would do its thing with the simulation, maximizing resource usage and having a smoother player experience at the same time?
The way I see it, and I exaggerate my example here but for the sake of the argument, my GPU could be on a coffee break playing X as it would be able to handle the FPS requirements but the CPU would be burning itself off trying to run the simulation at the required FPS that my GPU wants to output. If both were not tied, then each on its own would do its task not waiting for the other. That would remove the "50 to 100%" more power required from the simulation, be unaffected by simulation stutters and you could have both games be sold as one without sacrificing anything nor spending huge dev time having to modify the world to accommodate VR vs non-VR. It would future proof your engine as VR will have different requirements in the future (Oculus DK2 was at 75hz, CV1 is at 90hz, what will it be for the next headsets?). It would also smooth out your main non-VR game by eliminating simulation related stutters and unlock the FPS for better gameplay and opportunities to upgrade the graphic detail levels.
Do I make any sense?
Thanks again for the replies and sorry for having to explain everything to me. Maybe others that read this thread can find this conversation valuable!
SV
SVoyager wrote: ↑Wed, 3. Oct 18, 18:40The main issue would then be the fact that the simulation is directly tied to player/client FPS. I am sure it is not as easy as just saying this in one sentence, but wouldn't it be better if the simulation was run separately?
The simulation does run on a separate thread from the rendering, but you cannot decouple the two completely. It's no good the rendering thread saying "oh, I've finished one frame, I'll do the next one" when the simulation thread hasn't finished updating things yet. In the best case you'd end up rendering the same thing twice in consecutive frames (which is essentially the same as halving the framerate again), and in the worst case you'd end up with the simulation thread being half way through the job, and the render thread rendering an inconsistent state with some things updated and others not. In practice it's more complicated still; efficient threading requires sensible locking schemes that prevent nasty clashes (and crashes!) when one thread is trying to read while another tries to write, and there is some processing that has to happen on one thread which you might think could happen on the other in order to make the whole thing work. So in summary, no matter how fast the rendering is, it still has to synchronise with the simulation, and I'm afraid this means that your suggestion simply doesn't work.
Now before you come up with the bright idea that things you can't see could be updated in the simulation less often than those you can, we're way ahead of you there. In fact we've gone beyond that and managed to make it so that some things don't need to be updated at all, and will just be able to give the correct information whenever it is needed rather than needing frame-by-frame attention. Things like asteroid rotation, factory production, and many others fall into this category. Without all this the universe simulation wouldn't even be viable in a non-VR game. You might also think you could magically speed things up by running the simulation on multiple threads, but this is a lot harder than you might imagine. The objects in the game are very heavily inter-connected (consider a ship, trying to dock at another ship, which in turn is flying to a station but has been interrupted by an attack from a group of enemy ships that are all coordinating among themselves) which makes it next-to-impossible to divide it into discrete units which can be processed independently. Quite apart from the complexity, you can quickly run into threading overheads, and that's without even considering the high chance of it all grinding to a halt with one object waiting for a lock on another to be freed, which in turn is waiting for a lock on another object, which itself is waiting for a lock on the first one!
Believe me, we have put a lot of time and effort into analysing this and have explored many, many different possibilities. While we will always be looking for improvements and optimisations, we are quite sure that there is no simple solution which will suddenly make it possible to double the framerate!
)
maybe leave the VR in its own threads and X on those unused threads. Yeah I know, its more complicated than that 
. j/k.
