Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Changed default numBuffers to 2 with vsync enabled. #410

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

DuFF14
Copy link
Member

@DuFF14 DuFF14 commented Mar 30, 2016

No description provided.

@DuFF14
Copy link
Member Author

DuFF14 commented Apr 13, 2016

Can we merge this? Will also want to update when ATW is working.
How about client prediction, are we leaving that out for now?

@DuFF14
Copy link
Member Author

DuFF14 commented Apr 20, 2016

@russell-taylor are the settings in these RenderManager config files what we want to ship by default with the OSVR installation?

@DuFF14
Copy link
Member Author

DuFF14 commented Apr 20, 2016

Should prediction be in there by default? Is that working with all client apps?

@russell-taylor
Copy link
Contributor

Prediction should be there by default, and should work with all client apps. I don't know that we've yet settled on the best all-around render params (1 vs. 2 buffer, amount of wait, etc.).

The only issue with turning on client-side prediction is that it doesn't work with servers that don't send velocity info, and the current predicting server does not. On the other hand, it does no harm -- the client side just avoids predicting in that case.

# Conflicts:
#	apps/sample-configs/renderManager.direct.portrait.json
…distortion mesh v2. Added client-side prediction section and updated values.
@DuFF14
Copy link
Member Author

DuFF14 commented May 31, 2016

Updated OSVR_HDK_1_3_with_mesh to use built-in distortion mesh v2 and new FOV values.
Updated default renderManagerConfig settings -- enabling/disabling vsync settings for direct/extended modes, decreased renderOverfillFactor from 1.5 to 1.2.

I didn't change the OSVR_HDK_1_3 COP or FOV values, as it didn't look correct with the polynomial coefficient distortion method. But it seems odd to have different FOV values for the same display...

@russell-taylor
Copy link
Contributor

The FOV depends on the distortion correction. Two different corrections can have different FOVs so long as they move the pixels into consistent places in their distortion correction.

@rpavlik
Copy link
Member

rpavlik commented Sep 23, 2016

Is this outdated and closeable, or still an active issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants