Jump to content

Correct frustum()-parameters for asymmetric view


photo

Recommended Posts

Hi everybody

 

The Math matrix function frustum() returns a mat4 variable, which I use for a asymmetric viewing frustum. I started with setting the params in meters but this didn't gave me the wished result. As I understand the returned mat4 contains integer values. Wouldn't be floats better?

 

With a bit of try-and-error I found some params which results in a acceptable result. See the attached pictures. But I can't figure out how the params resolve the viewed image. The best result I get with overwriting the returned mat4 value .m11 with a float value...

dmat4 frstmM = frustum(-0.035f, 0.0875f, -0.034453f, 0.034453f, 0.1f, 40000.0f);
frstmM.m11 = 1.72f;

player.setProjection(frstmM);

Can somebody give me a hint?

 

Thanks

post-1459-0-83191800-1408539032_thumb.jpg

post-1459-0-23465900-1408539041_thumb.jpg

Link to comment
  • 2 weeks later...

Hello Renato,

 

First of all, mat4 consists of 16 float values and dmat4 is 16 double values.

 

What we ended up that it's much easier to create a mesh that will represent virtual screens. After that we just need to get that virtual screen sizes & positions and create a bunch of projection & modelview matrices. You can look at all of this stuff in samples/render/viewport_03 sample.

 

Also, take a look at function getViewProjection located in core/scripts/projection.h file.

Link to comment

Hi Unclebob

 

Sorry for the late reply.

 

As we are looking for a solution to fit as well a multi screen setup (90°-Cave, 5-screen, etc.) We have f.ex. a setup were two pilots sitting in the aircraft next to each other and we need to switch the viewing frustum from pilot to co-pilot including the side- and bottom screens.

 

Therefore I was evaluating the AppWall documentation. Right in the beginning it's describing the possibility the create custum frustums. But in the wall.h file and also the examples I checked, I can't find an approach to this. I understand that we can customize the script files to fit our needs. But I don't see the approach to create the asymmetric viewing frustum.

 

Are you proposing to get the asymmetric frustum as you described the last time (with a mesh representing virtual screens) also for this setup? Or can we directly define the needed matrices?

Link to comment

Renato,

 

The AppWall plugin was designed to be used with a flat (well, it might have some small angle between monitors) wall of monitors. So it won't help you if you want to do a complex setups like CAVE.

 

For CAVE, basically, you need several machines acting as an Image Generators. Each of that machine can be synchronized with simulation core in two ways: CIGI plugin or our custom solution called Syncker. The idea is to synchronize world state on each machine and have different camera views.

 

You're able to set asymmetric views by hand but I think it's probably better to have that geometry representing virtual monitors and get that matrices calculated for you.

 

Please refer to this article to get more info about complex setups: https://developer.unigine.com/en/docs/1.0/scripting/scripts/systems/unigine_syncker/

Link to comment

Hi Unclebob

 

I was looking for a solution to run a setup with three projectors each 90° angled from each other with only one computer.

 

As we already using CIGI for our communication, I will probably stick with it. Or would you propose to use Syncker?

 

Thanks a lot

Link to comment

Hi unclebob

 

Yes, I think AppProjection is exactly what I need for my tests. It's running perfectly with the california test scenery. Unfortunately, I get a entry point failure if I try to use the AppProjection in the washington scenery... But I give it a try. =)

 

Thanks a lot!

Link to comment

Hi unclebob

 

Two things:

 

1) AppProjection is looking only for one screen, to achieve this I used a Triplehead2Go from Matrox. But is there an other possibility? I would like to connect the three projectors at the graphic card...

2) AppProjection as well as AppWall crashes after +/- 30min, meaning the whole computer gets blocked and I have to do a hard shut down of the windows...

 

Cheers

Link to comment

2) AppProjection as well as AppWall crashes after +/- 30min, meaning the whole computer gets blocked and I have to do a hard shut down of the windows...

What demo are you launching with AppWall/AppProjection plugins? I can't reproduce such issue with California demo and AppProjection plugin enabled. Is Triplehead2Go was connected when you get crash?

 

Thanks!

How to submit a good bug report
---
FTP server for test scenes and user uploads:

Link to comment

Howdy, Renato!

 

AppProjections supports up to five projectors on one machine. You just need to pass correct launch parameters to the engine. Please refer to this article: https://developer.unigine.com/en/docs/1.0/principles/render/appprojection/#launch

 

So basically, you just need to pass correct "width" parameter which in your case is equal to 3. After that, you'll need to adjust projection & modelview matrices. You can either do it by tools (https://developer.unigine.com/en/docs/1.0/principles/render/appprojection/#set_projections) or by hands (https://developer.unigine.com/en/docs/1.0/principles/render/appprojection/#customizing)

Link to comment
  • 9 months later...

Hi chaps,

 

Sorry for rolling up some old questions =).

 

We were working so far with the AppWall plugin. With medium happiness, since it is difficult to arrange the real world setup with our common workflow.

 

So far, we measured the distances of the near clipping plane to the eyepoint, as well as the offset right/left and top/bottom. And this procedure for every screen in different setups.

post-1459-0-31795000-1436171559_thumb.png

 

It would be a great help to reuse our measuring workflow also with Unigine. Therefore I'm working on setting up the frustum. You proposed a year ago, we should create meshes to represent the screens. But I don't really get it. How/where can we define the distance of the screen as with the near clipping plane. And with this approach we would have to define for every hardware setup the specific meshes, aren't we?

 

Secondly, the frustum() function returns a perspective matrix, which would fulfill all our needs, but I can't find any information about the unit it uses to set it up properly.

 

Thanks a lot in advance,

Renato

Link to comment
  • 1 month later...

Hi Ulf!

 

One thing to correct is that frustum is working with coordinates, not angles. Left/right/top/bottom values are coorditanes (in units) to from near plane center to the left/right/top/bottom bound.

Link to comment
×
×
  • Create New...