simple machines forum

Please login or register.

Login with username, password and session length
 

News:

Remember to make your own backup of posts before submitting.

 
 
Pages: [1] 2

Author Topic: PlayStation VR is on the way...  (Read 4813 times)

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« on: April 29, 2018, 11:56:33 PM »

 :updown: I just realize the subject of this topic/thread has two meanings, since I've order a PSVR (for SOM) that is literally on the way to me, but what I meant to say is it won't be long until SOM has a new VR mode... exclusively using Sony's headset, and no other.

I thought that I was going to purchase a unit while I was in town, but there were not any, and oddly a GameStop store wanted to sell me a used one for $250 while Wal-Mart and Amazon.com had them for $200, new. So I had to order, since there wasn't one in the store.

In the weeks since I learned that Sony's headset is not only viable, but probably just perfect, I've given it some thought. I have a good idea of how SOM+VR is going to work, so I thought I share. And also make a thread to share any new developments in the coming weeks/months.


Anyway, I'm not sure how much there is to say about it that isn't just technical details of the implementation. I don't think it will be difficult to set up, initially. I'm going to stick to Direct3D 9, which doesn't have any features that seem to have envisioned VR (stereo) but I believe it can work reasonably well on Shader Model 3 implementing hardware.


There isn't a question about what to do with the look up/down inputs, since I believe that they will remain integral to play. Because from my experience, I've decided that the right direction forward is to insist that audiences don't look away from the center of their screen. I think that it's best not to do this, if possible, regardless of using VR headsets or not, but that it works espec
ially well with the headsets, because you can just use your neck to look around....

But if in VR you want to use your eyeballs to glance around, SOM will suggest that you do this with your thumbs instead of your eyeballs. IOW, turning and glances will remain the domain of the controller, whereas the headset will enable limited looking around via the headset.

When a headset is used, the thumbstick might be restricted on the vertical axis, or automatically recenter itself when it's released. But it will not be used to do anything novel.


I believe that looking away from the center will not help with immersion, and I think that putting dark circles around the view to create a literal tunnel vision will be helpful, and will mask problems that arise on the edges of the display. For example, I've read that the color changes further to the edge... chromatic aberration... and the GPU code that is required to correct for it is prohibitively costly IMO unless the effect is just so bad that there's no other alternative, which will not be good.


I think that this is a good strategy for "immersion" but it could also be good for the stereoscopic effect... thought I do not know for certain. I've read before that the headsets don't really simulate focal length... or that they seem to always be focused on the far distance. I don't know if that's because they cannot do so, or if it's because they cannot match what the eye is focused. I've read conflicting reports. And sometimes that maybe people with glasses need this to be the case, but I do not know. If the image can simulate focal length, then if the audience is expected to look forward and not deviate, then the game can find out what they are looking at by finding the object that is in the middle of the screen, and matching the focal length to that. If that's possible, then this is what SOM will do. If it's not possible, I wonder if it's even worthwhile to produce two separate images (per eye) or it should just do "mono" mode, which I believe is possible because I've read that some movies play in Mono mode in Sony's headset. (Such a mode will definitely be an option, and I will develop it first.)

As a result, it will be possible to look around in the menus. I think it would feel odd if you cannot, and it might be necessary to focus properly, and to not move your eyes off center.

I do not know what will become of the "HUD" elements. If it works to look off-center to see them, that will be fine. If doing so creates glitches in the image, I'm totally cool with that, because as far as I'm concerned a HUD element is a glitch in the image itself.... by which I mean that looking at them is in a sense a form of "breaking the fourth wall."

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #1 on: May 08, 2018, 06:11:38 AM »

I have news on PSVR, but just stashing this here so I can share this image on Reddit :ssh:

https://www.reddit.com/r/PSVR/comments/8ht21j/put_a_name_to_this_effectordefect_hard_black/

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #2 on: May 08, 2018, 11:49:36 AM »

For the record, SOM with PlayStation VR is :hearton: PERFECTION :hearton: and I don't know what else to say, other than everything on the SOM end works flawlessly, and Sony's end is a world apart from monitor play for $200 or less. The difference is more than an order of magnitude. I'm still trying to process what happened today after the first time I used it to play a game in a significant way. It doesn't tax me at all (maybe there is something wrong with other people's games) and if anything I am enjoying video games again. I could play it for hours I'm sure.

The first VR project I've taken on is to add an extension for making the text larger in the tools (the game text is plenty huge as you know, except for maybe the HP/MP onscreen element, and the function overlay) because the PS headset is fuzzy, and horizontally it cuts resolution in half if you were going to look at the entire screen at once, but you don't usually do so. In any case, small text is often illegible. And it's super inconvenient to take the headset on and off (there are a lot of commonsense ways Sony could've made the PS headset more practical/safe.)

It's not exactly ideal, but as you can see in the attached screenshot, there is a side effect, in that SOM_MAP gets more real-estate for its tile work areas. It's not an awesome trade-off since it also gets a lot of bulk. But it's a simple way to do that, without designing a new language package.

Little things are off everywhere, because it's not a hand tailored job, and the new size depends on the fonts, and to be safe the font used for sizing is made one "point" larger to make room for in case the larger font bumps into things or falls off the edge. Maybe in VR you won't notice so, because it's pretty fuzzy.

The MS Gothic fonts remain 1px wide in terms of their lines. That doesn't seem to be the headsets problem, so much as their being bunched up, with limited space between letters. I tried a bold font, which didn't help for reading. And was harder to stay in the limits being wider. Perhaps it has more variability. And MS Gothic only has one bold font, that is very, very bold. (Synthetic might have been an option, but I didn't look into it.)

The hardest part was SOM_PRM's pie chart like graphs. I did those almost exclusively on day 2 of the job. It draws the graph on a separate bitmap... maybe that helps for compositing it, so the pieces don't break up. But I didn't bother to find the code that creates the bitmap, and there is no way to make the bitmap larger after it's created. So for now I just left it in a weird state that has a lot of character... it kind of looks like a mandala, but basically the lines aren't straight and the labels have a funky appearance, but I think that's alright. I need to revisit the project because presently language/theme packs cannot move the location of the graph. So it'd be good to give them that option.

I also noticed that SOM_MAIN and SOM_EDIT had a significant number of pixels cut off the bottom of their impressive backgrounds. I don't know if that's always been that way, or if they shrunk in time, or if it has something to do with adding a title bar to them, but I just made them taller in the language packages.

Strikeout: It's actually possible a last second change I made did that, since they were changing the size of the window in the program, and I disabled it. I guess I should look into these changes, since they could be in order to match the backgrounds to the pixel. But they interfere with making them enlargeable.


P.S. You can see some new elements I've added to SOM_MAP for the next release, in there is a new "Map Layer" bar, and the profile description area has become a button. The button is to open up PrtsEdit. It's going to open maximized, and on its maximized screen it will just show the extended description, in a very flamboyant way. Like a plaque. Eventually it might have an option to show the 3D models there, or the map_icon.bmp file, for easy editing/selection. (It will only be able to show one of these at a time if so. It's part of a new suite of tools that don't maximize to the desktop, but switch between two modes.)

As for the layer selection bar... I only added it because that part used to look like the description part. And since it got changed into a button, I felt like the other part needed to change in order to be thematically consistent. So the layer is just stuck on the base layer until the feature will come online later.

P.P.S. See. this SOM_MAP layout, while imperfect, has significantly more tiles, although not a great deal more. And its text is larger. The 3D areas seem to be larger also, although they didn't have to be so, and may yet change, but it is less work to let them become larger.
« Last Edit: May 19, 2018, 01:28:24 PM by Holy Diver »

Holy Diver has 2450 posts

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #3 on: May 08, 2018, 11:19:15 PM »

EDITED: Upon reflection "not straight" seems like an understatement, so here is a show of what the enlarged graph looks like. I don't feel a real need to change this. Though it'll probably get corrected some day, if it doesn't become obsolete. (edited: Note, it's not a matter of smoothing the lines/text... that would work, but it's not the right look for this element.)

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #4 on: May 09, 2018, 04:00:57 AM »

The extension became "height_adjustment" that is technically programmable. In addition to the height being adjusted it receives a number identifying the tool in question. In theory it can pick up on an environment variable or not blindly increase the size, or set it to a fixed height.

The new attachment is using 1.3x, which oddly enough, is the same height as 1.25x, but the font is much more robust/legible. Funny what a small difference can make. I guess you just have to try different values, or there may be magic values, but it will depend on the font after all.


There's a new extension called "default_pixel_value2" for setting the color of the new tools' background. I had to add it because the blue background looks very bad with my new PlayStation VR headset. I'm investigating the problem. But in general it seems that greenish and black backgrounds look acceptable.

If it is set to black (0) it becomes default_pixel_value. Whereas if the tools are satellites of SOM_PRM they have a matching black background anyway. A black background always becomes default_pixel_value, which is shared by SOM_MAP. But I think if the tools are minimized, they have the other color. It's optimized for contrast, and so helps on the smaller thumbnail. Plus it signals that you're outside of SOM_PRM territory.

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #5 on: May 10, 2018, 05:55:46 AM »


So, last night I started dabbling at making one display per eyeball. I thought this would go better, but I'd forgotten some things about Direct3D 9. I got it working, but in order to do so, it's a requirement to use buffers to stream data to the video memory... and the problem with that, in the past, is the performance goes off a cliff...

HOWEVER! I got to wondering why that is so, and it led me to an interesting find that is a bug in the player. Problem is, when the map pieces are put in their buffer, the player expects the buffer's memory to be preserved. But what's really messed up, is it actually appears to specifically request that it NOT be preserved...

And so it's a wonder it works at all. That is to say, any driver that didn't just happen to back up the buffer in system memory will have not preserved the buffer, and the game would be a glitchy mess. I don't understand this myself, unless it's just tradition that Direct3D 7 drivers ignored this request.

The problem is that preserving the buffer comes at great cost. So to use buffers, I'm going to have to reprogram the subroutine that fills the buffer with the map pieces.

I doubt switching over to buffers will improve performance, but it might. These buffers are streaming, so they don't live in video memory, other than they reserve a place for the streaming data to deposited. My theory before I discovered this was that reserving a place was actually bad because there wasn't enough time to consume the old data and get it out of the way to make way for new, but after I changed this behavior, the frame rates with buffers were comparable to without. Which bodes well for stereo performance.

It took me a while, but I was able to get a stereo picture going (without just doing everything twice/sending duplicate data to the video memory twice.) What I got stuck on is I didn't understand that the newer SetVertexDeclaration API covered multiple buffers when merging streams... which is how the stereo effect is being accomplished. (One stream holds information that says which eye the data belongs to. It's nothing really, but it's the only way to distinguish eyes.)

I don't know if I understand 100% how to change the picture to accomplish a different perspective for each eye. Wanting to keep the impact to a minimum, I'm beginning by just translating the projection matrix, which can be accomplished simply by adding to the X direction of the outputted vertex. I don't know if that's acceptable, but it looks correct. If so it cannot be any simpler. In order to accommodate people with asymmetrical eye sockets, technically there'd need to be a different X offset for each eye, and also Y offsets, in case one eye is higher or lower than the other.

I definitely want to mess around with changing the focal length, though I don't know if VR games normally do so or not. Mainly because the resulting images would be like two crisp afterimages instead of gradually blurred images, and the effect may or may not be acceptable. I looked at "foveated rendering" as a topic, which seemed to be more interested in the gradually blending problem than simply accurately portraying the eyes' alternative perspectives.

P.S. I'm feeling like I'm neglecting the COLLADA-DOM feature I left unfinished a while back. The new tools effort is not coming to a close, so I feel like I should be returning to it, before I go nuts obsessing over the PlayStation VR. I should probably take some time to just play with the headset, since it's such a thrilling experience, instead of diving headlong into development work. Taking time off to resume work on COLLADA-DOM is probably a good way to allow myself time off to do so. If so (depending on my appetites) I think I mean to explore this problem with the map pieces on the side, while otherwise breaking from my SOM activities.

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #6 on: May 10, 2018, 01:47:35 PM »

Stereo effect at a reasonable frame rate :thumbsup: In this screenshot the map pieces are subject to the performance dive described in the prior post, but the rest of the models on display are not... I'm still going to fix that, but this way it's not so different, and turning on stereo doesn't seem to be a problem, or even detectable for that matter.

In fact, the question of whether this was going to perform well enough is the only real obstacle to full stereo. Unless I've greatly underestimated some other necessary effects.

The difference between the two images is exaggerated. As if the eyes were much further apart than possible. I don't even know if the projection is correct, but it has all of the characteristics I'd expect, and no other combination I tried was remotely correct. (edited: Forr the record, I reasoned through everything myself, for better or worse. But I'll probably need to compare references at some point, unless it just looks perfect in the headset out of the box... after a little calibration. The lens distortion stuff I have code for from the same software that is servicing the PlayStation VR. Which is not in use in any way in this screenshot.)

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #7 on: May 11, 2018, 02:57:46 PM »

As of today, everything 3D is showing properly in split-screen. I drove like a demon all night, but didn't get to the 2D elements. I wasn't necessarily planning to work on this, but I guess I'm drawn to it.

As for the bug with the map tiles. After I realized that Direct3D 7 didn't really have a way to do a partial update of the buffers... which is kind of weird, because SOM uses one big buffer for each kind of vertex it likes... I got the idea that drivers probably wait until the data is drawn from the buffers to send it across the AGP bus... which seems like a boneheaded way to work...

And even in Direct3D 9 the vertex buffers are restricted so that you either have to choose between preserving the contents of buffers or just not being able to partially update them. I don't really see the logic in that. So I did look over the subroutine that draws the map elements, but like I say, after I realized the situation, instead I've opted for a mixed model, until I know more, where SOM's map elements gets a system memory buffer (probably what Direct3D 7 drivers are doing anyway) and whenever it draws from it, it's copied into a video memory buffer. So, the down side is two copies are involved, but I have a feeling that SOM is minimizing copying (bad deal today) so it may be that it's not really two copies, most the time.

In any case, it's a sound compromise until it's convenient to uproot whatever the hell it's doing. What's important is to get good frame rates when doing double work to please two eyeballs.

And as far as that goes, on my workstation, I'm not seeing significant differences running in stereo mode. For some reason my games always get bumpy when I try to go to full 1920x1080. Normally I like a more square shape, but when it's split down the middle, that's 960x1080, which is a little unusual being slightly taller than wide. In any case, I mention it, because it's still the case that going full resolution tends to hit speed bumps. You'd think that 1920x1080 would run smoother than a slightly lower resolution in twin-picture mode...

I can't figure out what is the problem. I'm beginning to think my video card just has a very slim margin for sending its picture to the monitor, and just can't seem to do full screen and play a video game at the same time.

P.S. I think it's inevitable that I'll have to work on a custom resolution system. The resolutions that the game lists are more or less a random selection, tied to full screen modes. VR headsets will probably like more exotic options. There just needs to be a list of resolutions either in the SOM or Ex.ini file. It seems like an Ex.ini thing, but I can see how this might be good for the SOM file too.

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #8 on: May 12, 2018, 12:44:00 AM »


Update: I thought I got the shadows/sky working properly yesterday... mainly the shadows... the sky has a high tolerance for error.

But actually I realized I'd only inadvertently disabled the eye specific perspective shift...

What I've realized, is the way that the advanced sky/shadow effects build a depth-buffer and use it to reconstruct the 3D coordinates means there cannot be a projection based shift. This means that each eye ball has to be modeled as its own camera. The best thing about this to me, is it eliminates any doubt about the right path forward. It just means the vertex shaders need to do at least two matrix multiplications. But I don't think the vertex shaders are bottlenecks.

It might even be better to do the multiplications in the GPU, but it just seems so wrong, because the CPU can combine the matrices once, whereas the GPU does it for every single vertex... but that's what GPUs are made to do. It does eat away at registers and code memory, so it might be worth limiting it to Shader Model 3 mode.


P.S. I've decided to not pursue a skin based animation extension, because I think that it's 1) not compatible with instancing, and 2) artificially limits the number of skin weights to 4. I'm actually preferring, going forward, to use the soft-animation mode as much as possible. Because the hard animation mode 1) has to render each little piece separately, or compute it in the CPU, and 2) I like the idea of SOM's animation system being very flexible, and a little imprecise. Plus I think it'd be good to either compute the soft animations on a separate thread, or to put all of their frames into video memory, where I believe they can be stored as 16-bit integers to save memory, since MDL is 16-bit and that's pretty precise down to the millimeter up to a 32m radius. (Before any scaling happens.)

What this means in practical terms is the proprietary model formats should be one way... that is to say, we shouldn't be trying to save our artwork in MDO or MDL formats. No one would do that anyway, but it does make it harder to preserve the models, since the source materials probably don't come with games... but I imagine most publishers would reflexively prefer this anyway.

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #9 on: May 12, 2018, 07:21:11 AM »

For what it's worth, I tried this split-screen work in "VR Mode" and to my surprise it totally works! It looks just like a 3D movie :eek:

I've also remembered to cut the angle that is used to select map tiles for drawing in half. That should improve frame rates somewhat since I've been using a 1600x900 display.

Menus are going to be interesting. I thought they were only height based (at least maps are) but I think it must have been the text that was so, unless I changed the menus to use up the full available space at one point...

There isn't really room for a double-wide menu system. And if the menus are larger than the screen, the middle of the screen would be the crack between the two panels!

It's going to be very tricky I'm afraid.


P.S. I may be returning/exchanging my PlayStation VR for what seems very likely to be manufacturing defects in the picture. I'm waiting to see if anyone else has ever seen the second kind of defect ( https://www.reddit.com/r/PSVR/comments/8iuaao/do_rich_blues_have_a_checkerboard_pattern_on_your/ ) and I'm going to feel bad to ship the little guy back. But if I'm really seeing these problems that no one else is, it seems like the prudent thing to do. I wouldn't hesitate to return most items. This just feels almost like having to return a pet. The process could take weeks. But fact is, I could use a break, and there's no reason I couldn't have developed the necessary features in advance of getting the headset (I'd say I didn't need the headset, but at some point you do have to confirm everything works.)

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #10 on: May 12, 2018, 03:13:09 PM »

Oh man... I'm beginning to think I am very lucky to have found the PlayStation VR, not for VR, but for its hardware facilitated Cinema Mode :hearton: which I wholeheartedly recommend for SOM. It completely enhances SOM in every way, and I cannot do anything to improve it.

Today I've mainly implemented the warping that's required to match the lenses. I don't know if I will have time to try a new way of offsetting the view before I'm likely to send the unit into town. I will see if I can wait until Sunday to send it, since there's no mail on Sunday. It will depend on if people are here on both days.

I don't know what to say. It totally works in VR. At first it felt like a baby crawling on the ground, but with higher FOV settings I began to feel tall... maybe too tall for the 1.5 meter standard hero. I have a feeling the correct FOV setting is 68. Which is not on the scale from 30 to 50, and I don't think it would be pleasant on a monitor.

The code I developed the warp effect from has the FOV constant set to 68 degrees, and it looks right, so I think that it's a vertical figure, which is pretty standard notation. In the the INI file, that currently requires a manual override, but I will likely hardwire in 68. I should do it now. I will make a note instead.

I will put up a demo pseudo-release in a day or two. I need to patch a bug in SOM_MAP from the other day anyway. I just want to make the eyes have their own view vector so that I hope it solves the problem with the shadow effect.

It's a totally different experience from Cinema mode. I'm very glad for Cinema mode. It's going to take a lot of experimentation to get the VR mode to be anything more than a curiosity. I have a feeling that while everyone is making themselves sick trying to play VR they've all completely overlooked the Cinema mode for games.

P.S. I couldn't play at 60fps in VR Mode because for whatever reason, my workstation craps out the moment I put in in 1920x1080. I don't know if it's a Windows thing, or what. I might even try 1918x10?? to see if it works better. The next smallest widescreen resolution down (without doing an override) makes the sides cave in. It's really strange, because the warp normally pushes everything outward, but it seems to pull it in making an hourglass shape from inside the headset.

You really cannot see the onscreen elements. And I don't know how much is actually visible. The junk in the corners of the warp are not visible. I'm going to put in a fade to black ring around it. I think the picture can be reduced and moved to the middle, with a larger band of negative space around it, without being noticeable. That could improve frame rates for struggling machines.

Pixels are all clearly visible in VR Mode. It's more like Minecraft than how I think of SOM. But it is curios. It's 3D, like a 3D movie. It is sickening unlike Cinema Mode... but that could just mean that it needs more work.

For the record, this image is just showing the binocular lens feature. It's too small to use in the headset, but I didn't want to use a full 1920x1080 image.
« Last Edit: May 12, 2018, 03:21:38 PM by Holy Diver »

Holy Diver has 2450 posts

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #11 on: May 13, 2018, 07:03:05 AM »

EDITED: For the record, I'm not getting smooth sailing any longer. I've never seen my workstation do that before, so maybe something did change. But in Windows there's always so much **** running in the background that cannot be controlled that it's hard to say anything definitively. Especially when with graphics it's either 60FPS or if one straw breaks the proverbial camel's back... down to 30FPS hell or ping pong between them purgatory.

In the first of today I've implemented "chromatic aberration" correction, which seems to be necessary.

At first it really hit the frame rate. But I decided that this masking system I'd done just to try to get some minor supersampling going should be used to reduce the number of pixels that have to be color corrected. And I also put in a clipping function so the pixels in the corners are also not corrected (they appear black when correction is enabled.)

Still, I'm pretty sure the frame rates were harsh.

But I wanted to try to see if I could reproduce the glitch that is why I'm looking at returning my unit. I wanted to determine if implementing the correction would reproduce the glitch, in order to understand if it's a byproduct of the correction.

So to do this, I had to get the picture elements working. So that they appear in both eyes. Because I needed to have an event that shows the test image to see if the glitch was present or not. But if it's in the middle of the screen, it's in a blind spot.


The funny thing is, after I did that work (which was kind of tricky because the instancing APIs that are used to double the images don't like 4D--transformed--vertices. I don't understand why that is. But it is what it is...) it seems like the frame rates got a lot smoother. I noticed they were 60fps in Moratheia, which is a hard environment to do at 60fps... and not only that, I'm in 1920x1080, which I've never been able to do with the Moratheia demo before... and what's crazier still, is my system was in low-power mode, which I leave it in to keep the fan tamped down...

So, I was hitting 60 fps at full 1080, in low power mode. So of course I put it in full power mode, and went all over the demo's first map, without issue. If anything it was better performance than I experienced in the past at lower resolution.


My theory is that after eliminating the 2D elements, as the last things on the to-do list, there are no more "immediate mode" draw calls, so everything is going through buffers. I have a feeling that my (Intel) drivers just run much smoother if everything goes through the buffer APIs. It can let its guard down since it doesn't have to manage buffering. I think that's what's going on.


At any rate, it's impressive that the color and all is working, because it's very expensive to do. And it even has the after image going, so it's doing 6 samples instead of 2, to do the final effects pass, but not in the black pixels.


P.S. The funny streaks of color in this image is the color correction, which ironically looks just like how it looks in the headset without the correction. Which if you think about it makes sense, since it needs to do the opposite so that it is reversed in the headset.


HOWEVER the most interesting news here is the apparent dramatic improvement in performance. Of course, whether or not SOM runs better on your system also will depend on the drivers and quirks of your adapter's manufacture.


EDITED: By the way... the current picture extensions work wonderful in the PlayStation VR's "Cinema" mode, but I think for VR mode they are not really applicable. It probably needs to start over with completely different strategies. The 6 samples should probably be pulled back to just 3, and not use the after image... and see if something about the headset already makes after images, or if it looks smooth enough, or if it doesn't matter because it doesn't look great to begin with. Maybe with better performance it can just focus on supersampling.
« Last Edit: May 14, 2018, 06:47:41 AM by Holy Diver »

Holy Diver has 2450 posts

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #12 on: May 17, 2018, 08:25:32 AM »

Update

I've boxed up the PlayStation VR I was using in order to exchange it. It seems like it might have a few problems, and even if a replacement has the same problems, I will have a better idea of what kind of device I'm getting SOM mixed up with than if I never really knew if my unit is representative of others or not.

I was able to make everything work in terms of the picture. My eyes are pretty shot... I think I get sick just looking at anything that reminds me of "VR." I'm feeling sick writing about it right now.

I need a break. Phase 2 will begin with the replacement, or not before then (obviously) and will involve talking to the device; That is controlling it (switching modes) and using it as a form of controller.

My vision for PlayStation VR+SOM is to play games mainly in Cinema Mode, but in places to switch into VR mode, so that a SOM game will be a little bit like a pop-up book... where if you do the pop-up thing, you'll probably get sick after a little while, and need to switch back to the healthier more sustainable way of experiencing the game's story. That is to say, you'll only want to do full VR if you want to inspect something in VR, or specifically experience something in VR, which I think 95% of the time you'll spend in a game, if not more, you will not want to be in full VR...

The brilliant Cinema Mode has all of the real benefits of VR without the nasty side effects. It just switches to seeing the world like a canvas instead of a pop-up book. I think both modes are fine, but the pop-up book mode is obviously more of a novelty... especially since all existing major storytelling media is delivered by a canvas.

It's also made great strides for improving performance/stability; At least on Windows 7 and later.

Right now I'm looking at a demo release. But since I made the text display properly, the menu text is often off the side of the screen. So it's impossible to tell if you are on the Save screen or Load screen, for example... so I think a demo cannot be released in this state.

My thinking is that the full 1920x1080 menu doesn't need to be so wide in the first place. So what needs to be, probably, is to do some work to put a limit on the width of the menus. This way it won't be too narrow, but won't be too wide either.

In VR the menus are going to have to spin around to adjust to where you're looking, and some will probably not be visible, but I think it will be better if these spinning menus are more square than rectangular... though with the twin-panel menus it's hard to say. They will probably look better tilted some... but they will need to be square also (not tall rectangles) but some tilt should make them appear skinnier than they actually are.

Right now, if I can just make the menus not so wide, so that there's a least enough text on screen to tell what's what, I will put that out as a demo.

Other than this, the pop-up text probably needs to be higher up if it's going to be visible in the headset, and the titles need to be centered some also, but depending on how I make the menus less wide, that might well apply to the titles also.


EDITED: I recommend the coming demo in order to try out the performance enhancements, and the binocular mode is accessed with F2, and can be experienced without a PlayStation VR just the same, albeit like the screenshot from Reply #11. I think I have a nice screenshot for a blog post. It's like 2.5MB so I'm waiting to share it with the blog instead of via a forum post's attachment.
« Last Edit: May 17, 2018, 08:34:03 AM by Holy Diver »

Holy Diver has 2450 posts

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #13 on: May 29, 2018, 02:15:21 AM »

Return?

Some days ago the replacement set arrived. Unfortunately or... fortunately it's exactly identical. I prepared some patches that are in the current blog post topic.

Late yesterday I started on the stuff to do motion tracking. Unfortunately it's hit a snag ( https://github.com/gusmanb/PSVRFramework/issues/64 ) where the PSVRToolbox software just seems to be bug-ridden. I can't think of another explanation...

I did talk to the author for some time (edited: not yet about this) but they have stopped replying to my letters, so they may be sour. They seem to have soured on the project itself. And maybe tired of me... having never demonstrated a true interest in PSVR for Windows. Time will tell.

On the plus side, hoping that the sensor data was just chaotic, and not understanding that one thing called "GroupSequence1" was a timestamp, I forged ahead today in the hopes that the raw data just needed some kind of processing. So I've programmed everything that should be necessary to do motion tracking...

If this bug is resolved somehow, SOM should be ready to go with a little work. If it's not resolved it's going to be a much greater challenge to rebuild the entire apparatus from the ground up to figure out what's wrong.

I think that the software is just not processing the USB data correctly for the SIXAXIS units that are inside the head set. I don't know how that could have been missed, but these things happen when no one is using software. I'm very familiar with this from my years working on SOM.

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #14 on: June 01, 2018, 02:51:34 AM »

VR Update

A few things... first of all the current demo is stretched out. You can see the twin pictures are taller than they are wide. Well it turns out they need to be square. This becomes pretty obvious looking at something you know to be a perfect circle.

I have a free-look feature working, and everything is very convenient, but it doesn't seem like it will ever be practical to use it for more than a curiosity without a camera set up, since you have to deal with "drift" and it just tends to not be worth it. The home-theater mode is not bad about drift, but it's more irritating in full 3D. Plus I think rolling your head is probably not worth it, since the effect of its drift is much worse than the value of being able to roll your head... and I'm not sure if even with a camera setup that head rolling will ever be a worthwhile project... since it's really tricky to track with a camera and it brings very little value to the table, since like in real life, if you roll your head, it doesn't change what you see. (Unless you are looking straight up, in which case your brain doesn't know how to right itself... which is actually an area of interest of mine, since I wonder what it would be like to play lying on a couch, in a sleeping like position.)

Last but not least the https://github.com/gusmanb/PSVRFramework/releases page is unlikely to be of any use, because the "binaries" there don't implement the SIXAXIS stuff correctly (head rotation tracking) so whatever happens, I'm going to have to provide up-to-date/working binaries with SOM, like in the TOOL folder or something.

I had no difficulty recreating the project's environment in order to "build" it from scratch. I just had to add C# modules to Microsoft's Visual Studio first. I'm thinking about modifying the "PSVRToolbox" program and using it as a basis to begin the long desired Exselector project. In which case I will add camera stuff to it, and try to add some PlayStation controller functionality to it also.

I consider this VR stuff to be mainly exploratory. But its value is when the day comes that VR is truly viable, all of the code will already be in place and tested. So, in other words, while this is interesting stuff... you have to understand that it's not really useful--in the immediate term--but it's still valuable, and I think it adds something to SOM's pedigree if it has VR built-in, even if VR is not quite ready itself.

Pages: [1] 2