Using seperate frustum for left and right eye

[cor]

Hi

 

I'm trying to find out if Unigine is suitable for my needs.

One of my needs is to be able to define separate frustums for left and right eye (in stereoscopic mode).

 

I found out that one can set one projection frustum using the script. And one can use setStereoDistance and setStereoSeperation.

Unfortunately this is not enough for me.

 

I want to use head tracking to track the position of both eyes. For both eyes I would like to calculate and set the frustum based on the

position of the corresponding eye.

The goal is that both eyes will always 'see' a picture that would be seen when looking thru a window (the screen), regardless of how his head is

positioned. This should also include tilting (or rolling?) the head. Therefore the setStereoDistance and setStereoSeparation are not enough.

 

It would be possible if I could define a separate (assymetrical) frustum for left and right eye. As far as I can see it is not possible with the

scripting. Will it be possible using the C++ API?

[ulf.schroeter]

Will it be possible using the C++ API?

No, C++ API only exposes a subset of UNIGINE script functionality. All in all your special 3D-stereo requirements will be hardly handled by any game engine. Have you checked-out specialized VR-toolkits which might have more specialized 3D-stereo support ?

[steve3d]

source\app\AppStereo check this out, it will suite your need.

[cor]

source\app\AppStereo check this out, it will suite your need.

 

I'm afraid I do not have this example because I'm evaluating Unigine using the Evaluation Kit.

Can you tell me what it does?

[frustum]

We are support parallel stereo projection only.

Internal formulas for stereo matrices are:

 

mat4 projections[2];
float radius = render->getStereoSeparation() * 0.5f;
float distance = render->getStereoDistance();
projections[0] = projection;
projections[1] = projection;
projections[0].m02 += projection.m00 * radius / distance;
projections[1].m02 -= projection.m00 * radius / distance;

mat4 modelviews[2];
modelviews[0] = translate(radius,0.0f,0.0f) * modelview;
modelviews[1] = translate(-radius,0.0f,0.0f) * modelview;

 

There is no problem to add support of script defined stereo matrices to the engine.

[ulf.schroeter]

There is no problem to add support of script defined stereo matrices to the engine.

good news for cor

[cor]

good news for cor

 

Very good news!

[cor]

We are support parallel stereo projection only.

Internal formulas for stereo matrices are:

 

....

 

There is no problem to add support of script defined stereo matrices to the engine.

 

 

@frustum: is this scripting support for stereo matrices added already?

[ulf.schroeter]

@frustum: is this scripting support for stereo matrices added already?

 

Not frustum, but the answer is 'not yet'. You went offline 8 month ago just a second before UNIGINE commitment to implement this feature...nevertheless it would be very simple for UNIGINE to add something like

 

engine.render.setStereoMatrices( mat4 stereo_left, mat4 stereo_right)

 

if you would licence the engine :-) BTW in the meantime they implemented double coordinate precision support definitely required for your flight simulation use case and asymmetric frustum support is also fully implemented now.

[cor]

if you would licence the engine :-) BTW in the meantime they implemented double coordinate precision support definitely required for your flight simulation use case and asymmetric frustum support is also fully implemented now.

 

Well, that is the reason for my new interest. Maybe now it has all that is important for me.

But I'm a little concerned about performance impact of these new features.

 

B.T.W.: was that really 8 months ago? Time is flying. I didn'y sit still however. The machine is making progress.

[ulf.schroeter]

But I'm a little concerned about performance impact of these new features.

 

You shouldn't be too concerned about performance. See this post for double precision impact (just a few % as today's rendering is nearly always fragment-shader-bounded). Also there is no real alternative and other game engines (like Unreal or CryEngine) limited to float precision will simply fail for gaming areas larger than 20x20km (not too much for a flight simulator...)

 

Asymmetric frustums don't have impact on performance as Alexander stated in his last post and also UNIGINE has boosted general engine performance and memory consumption significantly during the last months.

 

I don't think you will find any other engine in the market offering more features required by your application than UNIGINE at the moment (and be sure that I don't get paid for this statement :-)