Analizing the VRTemplate, where and what ?

[ox]

( still Giles here )

Ok .. I am analyzing/tring to understand the VR template .. ( wondering if I am missing some docs somewhere ??? )

It seems to me there's this class "app" that seems to "initialize a world of stuff".

And it seems to me that "Most" boils down to "Frame" which calls this "DrawEyeView ( eye, fov ) " ..

I am tracing it down to Modelview.cpp and I see it seems to call something else that I suppose draws a list (?) of
"surfaces".

Hum .. let's say I want to override/replace this with my own DrawEyeView() .. where do I render what in for the left/right eye ? I suppose there has to be a couple of textures and/or Render Targets I must use ?

If I understrand correctly "all the magic of Timewarp" happens/gets applied in "Frame" when

app->DrawEyeViewsPostDistorted() is called ?

Fundamentally "I don't want any scene", "I don't want anything", it's fine the DrawEyeView ( eye, fov ), just
tell me what I have to render where 🙂

Basically at some point I will be calling some glDrawArrays() or similar ( and lot else ).. I saw also you activate
culling, can I disable it ? We don't normally use culling.

I am trying to wrap my head around all this and once more again I'd be glad maybe in a future to see "a much more simplified" sample/template.

Thanks in advance for any help.

[cybereality]

Sorry for the delay. I don't know the answer, but I'll see if anyone here knows more.

Please be sure to follow up if you figure it out. Thanks.

[ox]

I stopped yesterday evening around 22, I'll restart soon today, I think I figured out most of the stuff I needed by analyzing what OvrScene and TimeWarp.cpp does, as I said I have now to put a more complex scene in than just a triangle floating in the air to see how it looks ( and if the timewarp really applies correctly ).

One of the thing that always gives me a bit of confusion in all these systems is that I normally use a Left Hand coordinate system ( Z positive pointing away from the observer into the screen ) while all this VR stuff seems to use a Right Hand one, the other thing is that I tend to use row vectors instead of column ones, this creates a bit of a thing with matrices.

For the moment I want to arrive the point where I have all I need working and the way I need it, then there will be quite a few bits and pieces of the "VR Template" that I need to drop out and change because they do stuff I don't need/want into my code.

I still need to fix that bloody thing with the "indexer" in the Eclipse IDE that throw me stupid errors all time because it seems that it cannot find the paths of certain things, as I said before beware you install instructions/procedure they don't seem to work as stated on WIN 8 ( 64 bits ) , something does not quite go according to the plan.

[edit] one more thing .. what do I have to do as "Giles" to have access to this forum ? , otherwise I continue to make posts as "ox" when it's not him really .

[edit2] - I just found out, finally, that to remove all those nasty "indexer errors" from the projects you need to manually add into :

Properties - C/C++ General - Paths and Symbols -> your_install_dir\android-ndk-r9c\toolchains\arm-linux-androideabi-4.8\prebuilt\windows-x68-64\include

It seems for some reason that is completely missing from anywhere and then the Eclipse IDE Indexer can't find the files.

[edit3] - forget it .. they disappered and reappeared, it seems to be a "common problem" with NDK and this Eclipse and still looking around the internet nobody seems to really know why it happens and how to fix it.

[cybereality]

OK, I added GilesGoat to the group. You should be all set now.

[Anonymous]

"cybereality" wrote:
OK, I added GilesGoat to the group. You should be all set now.

Thanks, just testing and seems to work I am finally in as myself 😉

All the posts in this thread just to be clear always been me so far.

Going good, implementing/porting bit by bit all the pieces of our "engine" in the stuff, so far all good.

[JohnCarmack]

I haven't had a chance to digest all of this yet, but a couple comments:

The depth buffer should be cleared for you, but the color buffer is only invalidated to prevent the tiled GPU from pre-reading it, under the assumption that the app will completely cover the screen. If you are just going to float a model, you will have to clear the color buffer yourself.

We transpose the matrices because OpenGL ES 2.0 officially ignored the transpose flag on glUniformMatrix. It is supported in ES 3.0, but TimeWarp currently has to run in both 2.0 and 3.0 mode because most Unity projects are still 2.0. It probably still works on a 2.0 context in a 3.0 driver, but I haven't tried.

[Anonymous]

"JohnCarmack" wrote:
I haven't had a chance to digest all of this yet, but a couple comments:

The depth buffer should be cleared for you, but the color buffer is only invalidated to prevent the tiled GPU from pre-reading it, under the assumption that the app will completely cover the screen. If you are just going to float a model, you will have to clear the color buffer yourself.

We transpose the matrices because OpenGL ES 2.0 officially ignored the transpose flag on glUniformMatrix. It is supported in ES 3.0, but TimeWarp currently has to run in both 2.0 and 3.0 mode because most Unity projects are still 2.0. It probably still works on a 2.0 context in a 3.0 driver, but I haven't tried.

Ah right, thanks I really did not know this story about the Transpose flag, mind you it's been quite a while ago since last time I used GLES and it's been only on OSX/iOS plattform, I am not even sure I ever used the "transpose" flag in there.

[Anonymous]

Also I have to ask this .. making me a bit "mad" ..

WHY you actually need to transpose that matrix before to use it in a shader like :

gl_Position = m_WorldViewProj * vec4(Position,1.0f);

Something somewhere makes a "transpose" by its own ?

Also once you done that, that "position" is in "projection space" I guess means X -1 .. 1 , Y -1 .. 1 and Z -1 .. 1 ?

[edit] - also why the axis Z seems to be "reversed" (i.e.) negative values makes it more distant from the screen, positive closer ??

What kind of coordinate system is that one ?

[JohnCarmack]

OpenGL eye space has always looked down -Z.

OpenGL's default matrix order has always been backwards from a lot of people's perspective. Desktop OpenGL offered the transpose flag on MatrixParameter calls, but OpenGL ES dropped that for driver convenience. It was officially supported again in OpenGL ES 3.0, so you can use it in your code if you want -- the native setup code always gets a 3.0 context.