7 replies to this topic

[Stainless]

Has anyone done any code for 3d display on 3d compatible tv's

I have to get this working pronto, (usual rubbish, CEO had a meeting, I get email, want's it yesterday)

I have the framework in place and added a red/green stereo mode as well for testing (as usual, I have to code for a device I haven't got yet)

My question is to do with the view frustum.

At the moment I have a fixed focal plane, I'm not at all sure this is correct. I think I may have to move the focal plane to the target's location so the target object is central to the view volume. Not sure.

What I do at the moment is...

1) Work out the physical size of the TV screen from the resolution and DPI
2) Calculate a view frustum based on focal plane, tv size, and desired view depth
3) Create a look at matrix (without the final translation)
4) Rotate the eye offset by the look at matrix
5) Apply the final translation and the eye offset translation

This seems okay most of the time, but when the target object moves away from the view plane, the stereo separation gets very large very quickly.

Anybody done anything like this?

Cheers guys

[Reedbeta]

I haven't done any stereoscopic 3D stuff myself, but I did see some SIGGRAPH presentations last year that talk about setting up the view frustum, managing the "depth budget", etc., kind of an introductory survey of the topic. They're on the web here in case that's helpful at all.

[Stainless]

Thanks Reedbeta, I will read through those and see if they give me any clues.

Apparently I have a 3D TV on the way from China........ hmm ..... heard that before.

[Stainless]

For anyone else who has to deal with this I'll put some notes here.

There are several ways the TV's expect a 3D feed, they seem to be based on the incoming bandwidth.

1) Horizontal split
A single HD frame is considered to be two SD frames placed side by side.
Left eye on left, right eye on right.

2) Vertical split
A single HD frame is considered to be two SD frames placed one above the other.
Will confirm which is which eye when I get a device to test on.

3) Time interlaced
Odd HD frames are considered to be one eye, even frames the other
Again will confirm which is which when I get a device

Solution 1 and 2 result in a reduced screen resolution, which 3 does not suffer from. However 1 and 2 can run twice as fast as solution 3 if the source feed does not increase it's frame rate.

I will post more information on the maths involved when I can prove my equations work, but for now this is the matrix code I am using.

void Application::UpdateiScreen3D() 
{
float w = 518.4f; // Physical display dimension in mm (width)
float h = 324.0f; // height

float z = DisplayPlane; // Distance in the scene from the camera to the display plane.
float a = 65.0f; // Camera inter-axial seperation (eye seperation).
float Near = 1.0; // Distance in the scene from the camera to the near plane.
float Far = 18000.0f; // Distance in the scene from the camera to the far plane.

//Calculations for Left eye/camera frustum
float L_l = -( Near * ( ( w/2 - a/2) / z) ); // Left clipping pane
float L_r = ( Near * ( ( w/2.0 + a/2.0) / z) ); // Right clipping pane
float L_b = -( Near * ( ( h/2.0) / z) ); // Bottom clipping pane
float L_t = ( Near * ( ( h/2.0) / z) ); // Top clipping pane

//Calculations for Right eye/camera frustum
float R_l = -( Near * ( ( w/2.0 + a/2.0) / z) ); // Left clipping pane
float R_r = ( Near * ( ( w/2.0 - a/2.0) / z) ); // Right clipping pane
float R_b = -( Near * ( ( h/2.0) / z) ); // Bottom clipping pane
float R_t = ( Near * ( ( h/2.0) / z) );// Top clipping pane

// Lookat points for left eye/camera
LookAtLeft[0] = (-a/2);
LookAtLeft[1] = 0.0f;
LookAtLeft[2] = 0.0f;
LookAtLeft[3] = (-a/2);
LookAtLeft[4] = 0.0f;
LookAtLeft[5] = -z;
LookAtLeft[6] = 0.0f;
LookAtLeft[7] = 1.0f;
LookAtLeft[8] = 0.0f;

// Lookat points for right eye/camera
LookAtRight[0] = (a/2);
LookAtRight[1] = 0.0f;
LookAtRight[2] = 0.0f;
LookAtRight[3] = (a/2);
LookAtRight[4] = 0.0f;
LookAtRight[5] = -z;
LookAtRight[6] = 0.0f;
LookAtRight[7] = 1.0f;
LookAtRight[8] = 0.0f;

// Parameters for glFrustum (Left)
FrustumLeft[0] = L_l;
FrustumLeft[1] = L_r;
FrustumLeft[2] = L_b;
FrustumLeft[3] = L_t;
FrustumLeft[4] = Near;
FrustumLeft[5] = Far;

// Parameters for glFrustums (Right)
FrustumRight[0] = R_l;
FrustumRight[1] = R_r;
FrustumRight[2] = R_b;
FrustumRight[3] = R_t;
FrustumRight[4] = Near;
FrustumRight[5] = Far;
}

[Stainless]

Note that this means you can generate a 3d view on any hardware that displays on the TV.

Once I get a device I will do some example code for XNA and OpenGL as test applications for those of you lucky enough to have 3d TV's

[geon]

Make sure you "skew" the projection mattix for each eye to take into account that they see the screen from a slightly different perspective. (It is not enough to just point two regular cameras at the same point. The projection planes must be parallell.)

The difference might seem very small, but it can really feel weird and tiering for the eyes, or prevent you from focusing at all.

I have some code for that, that I can't access at the moment. I also never actually got around to test it... I believe I basically used the same projection and world matrix for both eyes, but added a skew matrix of half the distance between my eyes for each image.

[alphadog]

That's interesting. Why is it that you have to go so low-level to code for 3D TVs? Are you coding up some embedded solution?

[Stainless]

The OS I work on is a platform independent OS that runs on a lot of TV's

In fact from next year it's going to be very difficult to buy a new TV / set top box/ mobile phone without AGP on it. (well less so for mobiles, I think we are looking at 50-60% of the phones to be manufactured will either ship with, or have our stuff available), I think...

It's a binary portable system. So you write and test on the PC, then send it to our in house testers who check it works on all devices, then publish it.

The manufacturers we work with are churning out 3D TV's, but so far I don't think there are any compatible games. All the games just run in 2D.

So I am writing a framework that allows both new, and our existing catalogue to be easily made 3D.

I am the lemon who opened his mouth basically.