mabrowning wrote:On a different note, I'm in communication with the author of GSound; considering adding in support as an optional 3D audio implementation in minecraft.
http://www.youtube.com/watch?v=buU8gPG2cHI
You can actually download a demo and try it for yourself here! We can simplify quite a bit of the math for Minecraft since the geometry is entirely axis-aligned bounding blocks.
Hmm... what kind of controller do you have? On my original Xbox ("Xbox 1", not "Xbox One"; stupid MS...), the left trigger is "z axis" and the right is "rz axis". However, the all-the-way-out position is -1 and the all the way in is 1, so it traverses through the + and - axis to depress the trigger. Thus, for "button" type keybindings, I map both axis. Not ideal, but I that seemed like the best solution at the time. I'm wondering if maybe your left trigger is 0->-1 and right is 0->1. I'll see if I can come up with a workable solution. Try downloading a joystick tester program to see what values are available and what are reported. If possible, use the LWJGL joystick tester (look at org.lwjgl.test.input.TestControllers). Not sure exactly what that does, but it will probably give some diagnostic output.Tbone wrote:-Both left and right triggers are read as "Z axis axis". Not sure if this is unique to me, but it makes me unable to use the right trigger, so I currently have to bind the left trigger only.
Yeah, I realized that last night after trying to craft some simple items. In general, the inventory management is pretty hard to use. I'll work on that today.Tbone wrote:-The GUI shift doesn't seem to work. I tried a few different buttons and holding it down didn't seem to split quantity
When I set my player height back down to 1.62, that doesn't seem to help the crosshair aiming issue at all.. Rather, it seems aiming just isn't locked to the Crosshairs properly. It actually seems that aiming, with things like the bow or compass-teleporting, is tied to a combination of BOTH the crosshairs and where you're looking. And as a result, neither is an accurate way to aim. It doesn't seem to be a direct combination or center point between the 2 either. Just messed up.StellaArtois wrote:With the crosshair interaction bug; does the issue correct itself if you set player eye height to 1.62m (the Minecraft defaut)?
The jitter-bug () - don't like the sound of that. Do you think it's due to a change of your Minecrift graphics settings since older builds? Have you tried playing around with the head track prediction values to see if you can remove the jitter effect?
With the calibration / reset origin; sounds like ma's on a mission with that, it may be a work in progress
I haven't touched that code, so its still the default implementation: Minecraft originally only supported one "direction" that a player could be facing: their walking direction. Thats what direction all arrows, water buckets, and things that "come out" of the player originate in. Its only the "click on this particular block" or "click on this particular entity" that I've changed the code (to use free-aim crosshair). If you have look/move fully coupled, then the arrows should come out in your head direction. I think.NikoKun wrote: it's possible to fix that bug, I'd suggest all aiming related interactions be directly tied to the Crosshairs/mouse, and not the player's head-tracking.
Both of these issues should now be fixed in b95.Tbone wrote:-Both left and right triggers are read as "Z axis axis". Not sure if this is unique to me, but it makes me unable to use the right trigger, so I currently have to bind the left trigger only.
-The GUI shift doesn't seem to work. I tried a few different buttons and holding it down didn't seem to split quantity
It works great now, thanks! It's nice to stand up and rotate around a bit while playing! What a great mod!mabrowning wrote:Both of these issues should now be fixed in b95.Tbone wrote:-Both left and right triggers are read as "Z axis axis". Not sure if this is unique to me, but it makes me unable to use the right trigger, so I currently have to bind the left trigger only.
-The GUI shift doesn't seem to work. I tried a few different buttons and holding it down didn't seem to split quantity
! Right, my Rift devkit! So i took it for a testride:Being a Minecraft n00b I still love to marvel at the 3D effect in a canyon I found. It's my go-to-area whenever testing new functionality. It's a good place to be in the Rift!NeoCortex wrote:Hi guys!
Guess what UPS delivered yesterday
Tuscany demo: sure, nice... a lot of Unity demos: yeah, impressive... the configuration utility: hmm, nice room.. OH there is a car! Titans of space: impressive! And last but not least at all: minecrift!
Boy, what a difference even to my selfmade 7" tablet hmd contraption. I was there, i mean, really, IN my little desert village! Errm, did i say little? Well, actually those 1m blocks are huuuuuge! Seing the minecraft world like this for sure will change the way i build in this world. E.g. i tried to run down a simple 2 blocks high, 45 degree slope (i.e. one block forward, one down). OUCH! It felt like hitting my head to the ceiling every second step
Then there was that lava pond: amazing how those little pieces pop up and 3d curve thru the air!
Oh yes air: diving into a pool i almost forgot to breathe while watching those bubbles all around me.
And something you have to try: look at a sheep that is standing one block above you. That face is something really hard to forget!
So: thank you for creating that wonderful extension to minecraft! It was by far my most impressive first impression wearing my Rift.
I'll definitively will continue to test it and hope to be able to provide some useful feedback too.
Today i'll add the Hydra to the test setup.
cu,
Neo
Yeah, I've got a plan for fixing that so it doesn't matter. A simple "lean forward and backwards" instruction during configuration/calibration will allow us to precisely determine the hydra base station yaw (rotation) offset.Jademalo wrote:All Hydra positional tracking options are inverted in 95, that was REALLY trippy
EDIT: Maybe not, a restart fixed. (Had Hydra directon the wrong way with it strapped to the back of my head, it's where the wire is coming out of and not the end with the analogue stick)
Very strange. I wonder if using shaders is allowing some buffer to build up... it might be that 300fps is actually worse than exactly 60fps (until I fix the buffering).Jademalo wrote: EDIT2: First real issue I'm coming in to is sluggishness with the tracking. It's strange because I've sorted it in almost every other game, but not in here. The only way I can completely remove it is to turn distortion off, when thats disabled it's snappy. When I shake my head slowly with it on, everything is a bit slow. When it's off, everything "snaps" when I stop moving my head. I have >120fps at all times, and turning off distortion doesnt change it much, so its not totally FPS related.
I'll give you a more detailed review when I've had the rift for a week or so.
EDIT3: This is really strange... It seems like this sluggishness has nothing to do with framerate. I got to a point where I had >300fps at all times, and with distortion or FSAA enabled, it felt really sluggish. Even at 300fps. If I disabled both distortion and FSAA then enabled options so I had the same average framerate of ~300, it was incredibly responsive. Making the distortion border larger improved it slightly too.
Those tests were all done with an average framerate of just above 300, and when I enabled resource intense settings I offset the difference by changing the render distance to keep the framerate at a similar benchmark for everything. From those tests, it feels like enabling Minecrift's FSAA adds latency to the tracker, and enabling distortion also adds latency, even when the framerate is high enough to be a non issue. The menu does not have this problem either.
I'm basing "Not Sluggish" on both Tuscany and Minecrift without distortion.
It's so strange
That sounds logical - It wouldn't be an issue but I'm extremely sensitive to even the slightest bit of latency it seems, lol.mabrowning wrote:Very strange. I wonder if using shaders is allowing some buffer to build up... it might be that 300fps is actually worse than exactly 60fps (until I fix the buffering).
I've got to head off to work, but I'll be puzzling throughout the day over what could be causing this extra latency with shaders turned on... I suspect its the same reason you see additional latency with distortion. In both cases, we're using Framebuffer objects as render targets. I've only ever tested on AMD hardware/drivers. Perhaps nVidia's OpenGL implementation needs some different treatment with regards to FBOs? I'm baffled.Jademalo wrote:Alright, thank you!
I'll probably not be able to try it again until after I've slept, so another 12 hours or so. That session sent me spinning more than others for some reason, it was probably just how I was testing it though.
The reason as well I'm holding off with giving a full review is I want to make sure I'm doing it after properly aclimatising to the Rift, Yesterday I went to sleep pretty stroppy but after today It's steadily getting better =p
One thing to note, I am using SLI. I've tried running it with SLI disabled, but there wasn't any apparent difference when I last tried it. Not 100% sure though.
Another thing, is there any reasoning why AA would increase the latency further? I assumed it would purely affect the framerate, but even when that's stupidly high it still slows it down. I tried the native downsampling with the rift, but the effect wasn't really enough. 2x FSAA really sorts out the Jaggies.
No, that doesn't sound right. The cursor should be at "infinite" depth as far as convergence goes, but still be drawn "on top" of everything, no matter what(including the GUI when GUI occlusion is turned on... oops). The color should be inverted with respect to whatever its drawn over, so it should always be visible. I don't think I've changed how the crosshair is rendered in any recent build... could have accidently, though. I'll test that tonight when I get home.Jademalo wrote:And finally, is the cursor meant to disappear when it hits the sky? It's really distracting when it suddenly vanishes, and I don't remember it doing that when I was first testing :S
Yeah, it's literally vanishing when it hits the sky, as if it's not visible since it's not on top of anything. It's really strange. My Vert keyhole is about 120deg, trying to get it close to TF2's.mabrowning wrote:No, that doesn't sound right. The cursor should be at "infinite" depth as far as convergence goes, but still be drawn "on top" of everything, no matter what(including the GUI when GUI occlusion is turned on... oops). The color should be inverted with respect to whatever its drawn over, so it should always be visible. I don't think I've changed how the crosshair is rendered in any recent build... could have accidently, though. I'll test that tonight when I get home.
It can move out of your FOV if you have a vertical keyhole height that allows it., but from what you described, this doesn't sound like what is happening...
That is an interesting thought... Jademalo, what happens if you enable FSAA, but not distortion? Do you still see the high latency? Sadly, I suspect you will, but if not then it narrows our search significantly.StellaArtois wrote:Good find that it seems to be distortion causing excessive latency to the head tracking.
Absolutely. Its on the issue tracker as #71. The FTB 1.5.2 beta worked pretty well for me, too.Jademalo wrote:If you do solve this, is it possible to merge and do another build of 1.4.7 and 1.5.2? FyreUK is still on 1.5.2, and obviously FTB is 1.4.7.
ma, do you think Minecraft is reporting the FPS correctly with the stereo rendering? I had a cursory look at this before and it seemed that the answer was 'Yes, it does' currently...mabrowning wrote:That is an interesting thought... Jademalo, what happens if you enable FSAA, but not distortion? Do you still see the high latency? Sadly, I suspect you will, but if not then it narrows our search significantly.StellaArtois wrote:Good find that it seems to be distortion causing excessive latency to the head tracking.
I'm looking into more explicit GPU synchronization primitives now in order to A) properly clear the command buffers; I suspect drivers are ignoring glFInish(), and B) instrument things so we get an idea of what the actual latency from head orientation poll->swap buffers is.
On top of that, there will be an additional frametime (16.66ms @60Hz). For me personally, I am driving the Rift at 75Hz and that helps to make things snappier(13.33ms). Easy in Linux with xrandr, and there are instruction on how to do it on Windows as well.
I did *cough* try to change the alpha blending for the crosshair back to the original Minecraft style. However perhaps I've messed something up somewhere (not unknown). I have seen the crosshair disappear over grey coloured blocks however...Jademalo wrote:Yeah, it's literally vanishing when it hits the sky, as if it's not visible since it's not on top of anything. It's really strange. My Vert keyhole is about 120deg, trying to get it close to TF2's.mabrowning wrote:No, that doesn't sound right. The cursor should be at "infinite" depth as far as convergence goes, but still be drawn "on top" of everything, no matter what(including the GUI when GUI occlusion is turned on... oops). The color should be inverted with respect to whatever its drawn over, so it should always be visible. I don't think I've changed how the crosshair is rendered in any recent build... could have accidently, though. I'll test that tonight when I get home.
It can move out of your FOV if you have a vertical keyhole height that allows it., but from what you described, this doesn't sound like what is happening...
The peripheral blurring seriously irked me day 1, I'm on B lenses now since As we're unusable for me =pStellaArtois wrote:Jade; I still get ill sometimes, but the sweats are taking longer to appear...
With the next Rift I want:
- no peripheral blurring
- greater FOV
- better screen
- built in pos track
In that order.
)Oh please do. mabrowning is Mark Alan Browning, not "ol ma' browning let dem chickens loose again".Jademalo wrote:What are your settings for 75hz Rift Ma? (Also can I call you Mark? You arent my mother )
Code: Select all
ModeLine "1280x800" 107.21 1280 1360 1496 1712 800 801 804 835 -HSync +VsyncHere is our current distortion shader. Nothing in here looks too fishy at all... 1 texture lookup, a few multiplies, a few clamp()s...Jademalo wrote:Tests done, there is very little latency with 4x FSAA and no distortion shader. It's almost 100% definitely caused by that!
Code: Select all
#version 120
uniform sampler2D bgl_RenderTexture;
uniform int half_screenWidth;
uniform vec2 LeftLensCenter;
uniform vec2 RightLensCenter;
uniform vec2 LeftScreenCenter;
uniform vec2 RightScreenCenter;
uniform vec2 Scale;
uniform vec2 ScaleIn;
uniform vec4 HmdWarpParam;
uniform vec4 ChromAbParam;
// Scales input texture coordinates for distortion.
vec2 HmdWarp(vec2 in01, vec2 LensCenter)
{
vec2 theta = (in01 - LensCenter) * ScaleIn; // Scales to [-1, 1]
float rSq = theta.x * theta.x + theta.y * theta.y;
vec2 rvector = theta * (HmdWarpParam.x + HmdWarpParam.y * rSq +
HmdWarpParam.z * rSq * rSq +
HmdWarpParam.w * rSq * rSq * rSq);
return LensCenter + Scale * rvector;
}
void main()
{
// The following two variables need to be set per eye
vec2 LensCenter = gl_FragCoord.x < half_screenWidth ? LeftLensCenter : RightLensCenter;
vec2 ScreenCenter = gl_FragCoord.x < half_screenWidth ? LeftScreenCenter : RightScreenCenter;
vec2 oTexCoord = gl_TexCoord[0].xy;
vec2 tc = HmdWarp(oTexCoord, LensCenter);
if (any(bvec2(clamp(tc,ScreenCenter-vec2(0.25,0.5), ScreenCenter+vec2(0.25,0.5)) - tc)))
{
gl_FragColor = vec4(vec3(0.0), 1.0);
return;
}
gl_FragColor = texture2D(bgl_RenderTexture, tc);
}