Forum Discussion
OVR API Redesign needed.
I think that the new OVR API is a bit of a mess. Mostly because its trying to be "smart" by hiding what is going on from the user. All the insertion in to graphics drivers and APIs needs to go. Your dealing with way to fragile stuff to make it stable and you make all kinds of assumptions about how client applications are written that aren't necessarily true.
Here is what the API should look like:
ovr_Initialize() /* can be done at ANY point in the application. Remove the shim completely so that Oculus has nothing to do with your window, DLL calls or influence anything else the client app does what so ever.*/
ovrHmd_Create(X); /* is fine */
ovrHmd_ConfigureRenderingGL(current_hmd, DistortionCaps, MaxEyeFov, eye_render_desc);
/* Divide the configure function in to separate DX and GL versions, the casting of different structures is both ugly, confusing and deprives you of error checking. The assumption that all the data needed will fit in to the union is also dangerous. The use of a union could cause the API and applications to break because of a change to a graphics API or the inclusion of a new grahics API even for applications that aren't using that API! Its OK to have separate functions for different APIs! Everything in the config param is not something oculus should need to know so that needs to go too. ovrHmd_AttachToWindow needs to go.*/
ovrHmd_GetFovTextureSize /* is fine */
Now we get to the main loop. The main loop should be able to work in either:
ovrHmd_BeginFrameGL(current_hmd, 0); /* this function should create its own context and then call wglShareLists to get access to the current GL contexts object list. THIS NEEDS TO BE DOCUMENTED so that all developers know that the context needs to be bound at this point. */
ovrHmd_GetEyePoses(...); /* is fine */
ovrHmd_EndFrameToOculusGL(current_hmd, outEyePoses, render_textures); /* now this function takes two openGL Textures and renders the image that should go in to the oculus using its own context! Stop spilling GL state out in to the client context. This function can use PBOs to get access to the pixel data and post it to the display. it should not draw anything to the client window or in any other way influence the client state. The oculus implementation should not have to attach to the window or know anything about my window setup. Just draw to a texture and grab the pixels. */
You also need a API that simply lets me give oculus pixels to be posted to the display, so that i can write an application that uses a CPU based rendering engine, that doesn't have anything to do with graphics drivers or even opening a window. All the query functionality should be entirely divorced from rendering APIs. I'm talking about the ability to write a command line application, only linking to stdlib and OVR and having OVR be portable so that the same source could compile and run on Mac, Linux and Windows. It should look something like this:
ovrHmd_PostDisplayImage(data, size_x, size_y, OVR_RGB, OVR_UNSIGNED_CHAR);
It should be that simple, why you are doing things like overloading FBO 0 when I already give you all the data you need is beyond me. Stop doing things that aren't 100% clear to the user of the API. If you want something from the client application: ask for it, don't assume that you know where to find it.
If any of you will be at GDC we can talk about it there.
Here is what the API should look like:
ovr_Initialize() /* can be done at ANY point in the application. Remove the shim completely so that Oculus has nothing to do with your window, DLL calls or influence anything else the client app does what so ever.*/
ovrHmd_Create(X); /* is fine */
ovrHmd_ConfigureRenderingGL(current_hmd, DistortionCaps, MaxEyeFov, eye_render_desc);
/* Divide the configure function in to separate DX and GL versions, the casting of different structures is both ugly, confusing and deprives you of error checking. The assumption that all the data needed will fit in to the union is also dangerous. The use of a union could cause the API and applications to break because of a change to a graphics API or the inclusion of a new grahics API even for applications that aren't using that API! Its OK to have separate functions for different APIs! Everything in the config param is not something oculus should need to know so that needs to go too. ovrHmd_AttachToWindow needs to go.*/
ovrHmd_GetFovTextureSize /* is fine */
Now we get to the main loop. The main loop should be able to work in either:
ovrHmd_BeginFrameGL(current_hmd, 0); /* this function should create its own context and then call wglShareLists to get access to the current GL contexts object list. THIS NEEDS TO BE DOCUMENTED so that all developers know that the context needs to be bound at this point. */
ovrHmd_GetEyePoses(...); /* is fine */
ovrHmd_EndFrameToOculusGL(current_hmd, outEyePoses, render_textures); /* now this function takes two openGL Textures and renders the image that should go in to the oculus using its own context! Stop spilling GL state out in to the client context. This function can use PBOs to get access to the pixel data and post it to the display. it should not draw anything to the client window or in any other way influence the client state. The oculus implementation should not have to attach to the window or know anything about my window setup. Just draw to a texture and grab the pixels. */
You also need a API that simply lets me give oculus pixels to be posted to the display, so that i can write an application that uses a CPU based rendering engine, that doesn't have anything to do with graphics drivers or even opening a window. All the query functionality should be entirely divorced from rendering APIs. I'm talking about the ability to write a command line application, only linking to stdlib and OVR and having OVR be portable so that the same source could compile and run on Mac, Linux and Windows. It should look something like this:
ovrHmd_PostDisplayImage(data, size_x, size_y, OVR_RGB, OVR_UNSIGNED_CHAR);
It should be that simple, why you are doing things like overloading FBO 0 when I already give you all the data you need is beyond me. Stop doing things that aren't 100% clear to the user of the API. If you want something from the client application: ask for it, don't assume that you know where to find it.
If any of you will be at GDC we can talk about it there.
3 Replies
- Thanks for your feedback.
ovrHmd_EndFrameToOculusGL(current_hmd, outEyePoses, render_textures); /* now this function takes two openGL Textures and ..
SNAP!
And you just made assumption and forced half of the developers to use two separate textures while we want to use one from performance reasons.- I'm fine with letting both textures be the same and including region data specifying the area used for each.
