Jump to content


Photo

I'm working on a VR version - early alpha


  • Please log in to reply
338 replies to this topic

#326 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 1700 posts

Posted 18 August 2018 - 02:28 PM

I think I figured out how to get rid of the two geo's in the drawsurf struct.

Please see svn rev 7625 and advise.

The idea is to not store frontendGeo at all since it's not used anywhere*.

I tested this in TD2: chalice of kings where the guards used to visibly flicker with my earlier unsuccessful attempts.

 

*Deforms and subviews need separate testing.


  • Anderson likes this

#327 cabalistic

cabalistic

    Member

  • Development Role
  • PipPip
  • 384 posts

Posted 18 August 2018 - 03:30 PM

Uhm, but there are still two geos in the struct?! You just made one not a pointer. I'm not really sure what benefits or drawbacks that brings (without thinking about it some more), but I'm not seeing a fundamental change here.

 

The BFG engine actually does not replicate the whole geo structure for the backend, it merely copies the caches. I think it might be better to try and use that approach, as well. I did not initially, because I did not fully understand the implications. BFG works only by caches, whereas the original Doom3 engine did not, so it seemed risky to do it that way. But I think we are at a point where the cache is also always guaranteed to be set in the backend, so the backend no longer needs access to the full geo.

 

By the way, imho you should remove code that you replace, not comment it out. It makes reading the diffs harder, and it leaves a lot of dead code in the repository over time. Source control exists for a reason :)


  • Anderson likes this

#328 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 1700 posts

Posted 18 August 2018 - 04:08 PM

It's one geo, and backendGeo is a mere pointer to that. (So that I could push the code sooner for review without a ton of changes in the backend).

BackendGeo is going to disappear after code review.

Effects how I see it: one geo is less confusing than two. Fewer memory writes (It's micro-optimization weekend BTW lol). One less pointer lookup in the backend if geo is struct member, not a pointer.

On the other hand we might as well try to copy the ambientCache, shadowCache, indexCache, etc.


  • Anderson likes this

#329 cabalistic

cabalistic

    Member

  • Development Role
  • PipPip
  • 384 posts

Posted 18 August 2018 - 04:34 PM

Mh, I have to go through it carefully again to understand the impact. However, keep in mind that we must absolutely, positively, make sure that the backend is reading caches that are not at the same time updated by the frontend for the next frame. That was the whole reason why I had to add the separate backend geo in the first place (or why BFG copies those cache handles). Possibly your copy solves that, but we better be sure about it... Don't think it's going to do anything for performance, though.


  • Anderson likes this

#330 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 1700 posts

Posted 19 August 2018 - 01:04 AM

After some thoughts, I'd rather go the BFG way but can you point me where they copy their ambientCache for ambient and interaction surfaces? Search on github did not show any.

 

NM, found it.

 

The BFG style is great that it does not need full copy of a srfTriangles_t for each surface and it the backend does not need to load srfTriangles_t content from a pointer.


  • Anderson likes this

#331 duzenko

duzenko

    Advanced Member

  • Active Developer
  • PipPipPip
  • 1700 posts

Posted 19 August 2018 - 02:37 AM

Svn rev 7626, partially reverts the previous commit for deforms and subviews.

 

To test: view inside shadow volume.


  • Anderson likes this

#332 Bienie

Bienie

    Member

  • Member
  • PipPip
  • 200 posts

Posted 19 August 2018 - 04:55 PM

I finally gave this a good testing a few days ago! It's really looking good I have to say. I played my own mission (needed to look for bugs and mistakes anyway) and I can happily report that I had no real issues at all in VR. Performance was smooth as butter 90% of the time, no crashes or game breaking glitches spotted.

 

There were a few things, that you're probably already aware of, and are things that are most likely far down the line on your to do list:

 

-Many materials and particles draw completely differently in each eye which looks really odd, when you shut one eye at a time you see it clearly. Fire, water and shadows were the most prominent examples.

 

-The focus of the player is still bound to the mouse, and not the orientation of your head which makes frobbing really hard in many cases. (maybe adding a "crosshair" would be an acceptable solution for now).

 

-Related to the above having to use the mouse with freelook on to navigate around is incredibly nauseating, as it's tricking the brain into thinking the whole world is swinging on a pendulum as you look up and down. I consider myself pretty resistant to motion sickness, but that about put me over the edge.

 

Aside from these things honestly after getting some true roomscale and controller interactions, not being able to look under the hood, I would say it's a finished product, really great work!


  • Anderson likes this

#333 cabalistic

cabalistic

    Member

  • Development Role
  • PipPip
  • 384 posts

Posted 20 August 2018 - 03:04 PM

Thanks. Though I have to point out that adding roomscale is actually the majority of the work, and that's not even been started :) So it's a long way to go.

 

As for differences between the eyes, for the shadows at least there is a workaround. See here: https://github.com/f...kmodvr/issues/4


  • Inimitable, Anderson and Bienie like this

#334 Samson-

Samson-

    Newbie

  • Member
  • Pip
  • 5 posts

Posted 20 August 2018 - 05:33 PM

If I wanted to start poking at this, is https://github.com/f...r/thedarkmodvr/ the repo I should be working from?

 

Thx!


  • Anderson likes this

#335 cabalistic

cabalistic

    Member

  • Development Role
  • PipPip
  • 384 posts

Posted 21 August 2018 - 12:49 AM

Yes, but I'm afraid it's quite outdated by now. TDM has moved on quite a bit since then, anx I have a couple of branches lying around with partial experiments, some of which I want to consolidate. Unless yoz are bored to death right now and desperately looking for work, I'd suggest to wait until I've at least updated the code base to the current TDM version. There is one thing left to do for me on the base game concerning fbos, though, before that really makes sense.
  • Anderson likes this

#336 cabalistic

cabalistic

    Member

  • Development Role
  • PipPip
  • 384 posts

Posted 26 August 2018 - 12:25 PM

I have started porting over the VR changes to the latest trunk version. The initial merge is done, but it's going to take a couple days to fix the remaining issues and get it to actually work again.

 

@Samson: I don't know what time zone you're in (western Europe here), but perhaps we can find some time on a weekend or so to chat or something. Then I could walk you through the current state of things, the particular challenges compared to Doom3 and we could perhaps decide how to proceed? Let me know if you're interested.


  • nbohr1more and Anderson like this

#337 WMan22

WMan22

    Newbie

  • Member
  • Pip
  • 1 posts

Posted 19 September 2018 - 06:44 AM

I am watching this project with interest and check back on this thread every now and again; This will be the thing that gets me back into TDM big time I think.

 

Also, I know it's way too early in development to start suggesting shit so I was gonna wait until this was further along in development past the "Shit, can we even get this working and keep it up to date with the game's current version?" stage, but Vman339 basically all but peer pressured me into starting to give feedback since they're a person as passionate about this game as I am about my VR headset.

 

Last time I played this (which was a reasonable while back and probably a much earlier version), it was more than a bit difficult to understand where your arrow was gonna land when you shot it since your head was independent of your bow and arrow, and having a 3D perspective where the bow and arrow was meant to be operated with a 2D one complicated things even further. I think it would be great to have an optional arrow trajectory indicator like a blue/greenish laser dot (colored after Garrett's new eye) or something along the lines of that specifically for this mod; This is if I assume correctly that it won't ever operate on straight up motion controls like something like say, the Doom 3: Fully Possessed Mod.

 

Apologies if this has been already suggested or already exists in a more recent version.

Anyway, thanks for working on this project, TDM has huge potential in VR if you can wrangle the UI and mechanics well enough.


  • Inimitable likes this

#338 cabalistic

cabalistic

    Member

  • Development Role
  • PipPip
  • 384 posts

Posted 19 September 2018 - 10:53 AM

*
POPULAR

Well, my near-term roadmap currently looks like this:

  • fix one outstanding bug to get the preliminary port to 2.06/2.07 working
  • get UI elements including menu to render to a separate plane so that you can actually see and read them in VR
  • decouple vertical mouse movement from the head motion as it's incredibly confusing

After that, I'll see if I can quickly add some sort of "pointer" like a 3D crosshair to give an indication of where the mouse is currently aiming at. This isn't just important for bow and arrow, but also basic things like looting and picking up stuff, because that's still bound to the mouse aim.

 

As for roomscale: it's always been my distant goal to make this a full roomscale experience, but it is a very long road. And performance is still a huge concern. There is one major change and a few quick wins that are specific to VR that I'm going to try to implement that will probably help a little. But even then there are going to be maps which are not playable in VR, and probably few will be playable without reprojection. Some further performance optimisations will have to go through improvements in the base TDM project, so that will take a while, and it won't do miracles, either. I'll just have to see what's possible in what timespan.

So for a first step, I'm just trying to make it a decent seated experience, because I figure that's better than nothing :) Whether roomscale will ever truly happen remains to be seen.


  • Inimitable, Bikerdude, HMart and 2 others like this

#339 BuckleBean

BuckleBean

    Member

  • Member
  • PipPip
  • 56 posts

Posted 15 October 2018 - 08:19 PM

Thanks for the update! I check back in on this thread from time to time. That looks like a solid roadmap. If you can nail the bullet points, I think it'll be good enough to recommend. I wonder if the 3d cross-hair could be toggle-able...? Crosshairs are weird in VR. Like, it's easy to go cross-eyed, if that makes sense. But I understand the desire for something like that. Sometimes I feel like I'm frobbing forever, struggling to move the mouse over the correct spot. 

 

BTW, I agree seated is better than nothing. Alien Isolation taught me that. Roomscale is great, but it's not everything. Thanks again and keep up the great work!


  • Inimitable likes this




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users