Re: [osg-users] setLODScale affecting near far planes?
Hi all, Good, I am happy it is all clearer now, and I am sorry it wasn't enough at first. So back to the original issue: I observe my problem of auto-changing near/far planes when I modify the LODScale via camera-setLODScale(float). This *always* happens whether or not culling is enabled, but of course I am not affected by this problem when culling is disabled because no matter what values my near/far planes have, my objects do not get culled. I enable culling via: camera-setCullingMode(getCurrent() | osg::CullSttings::near | osg::cullS::far) - I don't have the code in front of me but that is the idea. The problem I encounter is that since I am culling the near/far planes, some objects get culled from my scene if the near/far planes shift positions automatically. Robert already explained that with my current near/far computing settings I will get some slight changes to the near/far planes when changing the LODScale. Although this is undesirable for my application, it makes sense given Robert's earlier explanation. So Paul asks, what if I just keep the original culling mode? Well, that would be great, it looks great and I don't have the culling problem of the changing near/far planes, but there is one *crucial* issue: frame-rate. My terrain is too large and I need a decent level of detail, but it winds up drawing way too many triangles. I am attempting to find the optimal LODScale for my app, which can get me up from 10fps to about 25-30fps at a decent LODScale, and I also want to cull all those extra triangles, which can pump me up to 40-50 fps, at the cost of culling objects when not desired. I think I'll be alright, I need to play some more with the near/far compute settings. Thanks all for your interest in this topic, -Jose On Mon, September 22, 2008 10:52 am, Paul Martz wrote: FYI, Roland is correct, the OSG just does culling on sides of the frustum by default. OpenGL does no culling, is just does near and far *clipping*. The OSG of course doesn't change this so will do near/far clipping and the only way to switch this off is to disable GL_DEPTH_TEST. Even that won't work; DEPTH_TEST is a fragment op, and clipping against the clip planes is done before rasterization. It would seem that Paul and Gordon have confused the clipping and culling a little. Yes, I thought the original poster was talking about enabling OpenGL near/far clipping (probably because I have seen so many newbies ask how to disable this in the OpenGL forums and newsgroups). Clearly, the original poster said culling... My mistake, and thanks to all for the clarification. Back to the original issue: So, you see this problem when you enable OSG culling for near/far. What happens if you leave this disabled (as osgviewer does)? -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] setLODScale affecting near far planes?
Hi all again, Robert: for you last question; yes, I have near/far culling enabled and the near/far setting is compute_near_far_using_bounding_volume. If the near far modification that is taking place should be very small, somehow I am still getting quite significant jumps because some objects near the camera get culled when I would not like that to happen. When I enable culling for near/far planes, it seems like osg takes into account my preferred near/far planes and is NOT auto-computing. It does do some re computation as I change the LODScale. Why does this happen? Paul: Do you get the same behavior when viewing your database in osgviewer and hitting the * and / keys? -Paul Sorry Paul, but it is hard for me to say, because with osgviewer I only notice the terrain loosing or gaining detail, but since I am unable to dump the camera information in osgviewer I cannot compare it to my application's printouts of near far planes, but thanks for the advice. -Jose On Sat, September 20, 2008 1:53 am, Robert Osfield wrote: Hi Jose, The LODScale does not affect the near/far planes and certainly won't affect near/far plane culling if enabled. If you have compute near/far planes on the camera enabled then LODScale might change the depth range a little as different children of LOD gets selected, but generally this would be very small.Could it be that you have enabled near/far plane culling by not disabled the compute of the near/far? Both settings are on the camera. Robert. On Fri, Sep 19, 2008 at 11:01 PM, Joseanibal Colon Ramos [EMAIL PROTECTED] wrote: Hi all, I am getting this rather weird effect when playing with the setLODScale values in my application. I have a large pagedLOD terrain, with near/far planes culling mode enabled for my camera, and I am looking at a certain direction in the scene. I added osg's lod scale handler so that I can modify the value interactively (with the * and / keys, just like in osgviewer) and it turns out that as I change that value, and I dump my application's debug information, I notice the the near/far planes do not remain constant, although I am not moving around the scene and I am always looking in the same direction. This causes problems because the clipping planes change as a result of changing the LOD scale and my non-LOD objects beyond the planes get culled. I don't think that the clipping planes should change at all if I am not moving my camera. I should still see the objects that are within a constant near/far distance, and I should only observe different level of detail on the LOD objects as I change the scale. What am I missing here? I am using osg.2.6.0 on a 64bit intel linux machine. Thanks, -Jose ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] setLODScale affecting near far planes?
Hi all, I am getting this rather weird effect when playing with the setLODScale values in my application. I have a large pagedLOD terrain, with near/far planes culling mode enabled for my camera, and I am looking at a certain direction in the scene. I added osg's lod scale handler so that I can modify the value interactively (with the * and / keys, just like in osgviewer) and it turns out that as I change that value, and I dump my application's debug information, I notice the the near/far planes do not remain constant, although I am not moving around the scene and I am always looking in the same direction. This causes problems because the clipping planes change as a result of changing the LOD scale and my non-LOD objects beyond the planes get culled. I don't think that the clipping planes should change at all if I am not moving my camera. I should still see the objects that are within a constant near/far distance, and I should only observe different level of detail on the LOD objects as I change the scale. What am I missing here? I am using osg.2.6.0 on a 64bit intel linux machine. Thanks, -Jose ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] unrendered objects creating performance problems?
Thanks for the culling mode tip Robert. My terrain was generated using VirtualPlanet builder, but I didn't do it, so I'll get back to you when I get more details on that. I'm running my application on 2 machines getting similar results: a 64-bit-Linux-86 with a double headed Nvidia Quadro 3450. The other is an intel MacBook Pro with a GForce 8600. The available RAM for both is way over 1GB. I am trying OSG 2.6.0. It usually runs smoothly at 60fps, but on this particular terrain, when zoomed in, and at angles on which I look far into the distance, the framerate drops to below 20, which is unacceptable for my application. I believe I end up drawing way too many triangles for the computer to handle efficiently. I am trying to find ways to run at a solid 60fps no matter what. -Jose On Wed, September 10, 2008 12:56 am, Robert Osfield wrote: Hi Joseanibal, By default the OSG does not cull on the near/far planes, and near/far clipping is done down on the GPU only affect the fill rate performance of your application. You can enable culling on the near/far planes, but you have to be careful about setting your near/far planes so that encompass your scene - as the OSG by default computes the near/far planes it'll hide the inappropriately set near/far planes so by toggling these features on you might suddenly find parts of foreground or distance disappearing. To switch off the compute of near far use the Camera methods (inherited from osg::CullSettings) : viewer.getCamera()-setComputeNearFarMode(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR) To enable the culling against the far plane use methods inherited from osg::CullSettings again: int cullingMode = viewer.getCamera()-getCullingMode() | osg::CullSettings::FAR_PLANE_CULLING; viewer.getCamera()-setCullingMode(cullingMode); All of this doesn't really address the performance issue too much. You don't mention the nature of your database at all i.e. how you built it, what scene graph components it uses, or what hardware, or OS, or OSG version you are using, all this info is essential for others to know enough to really guide you in the right direction. Robert. On Wed, Sep 10, 2008 at 1:08 AM, Joseanibal Colon Ramos [EMAIL PROTECTED] wrote: Hi all, I was hoping someone has an idea about why I am encountering the following problem: I have a big terrain and on certain viewing angles it contains a huge amount of triangles to draw and puts a big strain on OSG's performance. I tried playing around with near/far clipping planes to improve performance, by cutting out a lot of the rendering, to the point only a very small fraction (and even none at all) of the terrain is seen through my camera. OSG's framerate, however, behaves just as if I was looking at the whole thing and drawing all the triangles. At certain angles, the framerate increases (where small number of triangles would normally be - even thought I don't see anything), and at other angles, it decreases (the same angles at which the viewer normally tries to draw a large number of triangles - even though I can't see anything). What is going on here?!? help! -J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgTerrain::TerrainTile question
Are you perhaps referring to paged LevelOfDetail (LOD) terrain? OSG database pager automatically processes these types of paged LOD terrains, and loads higher resolution tiles as you zoom in (or the opposite: lower reslution when zooming out). request your application to load your master.ive file of your pagedLOD terrain, and that is all. I hope this might be relevant to you, however, I don't know much about osgTerrain, so I'd advise you to wait for someone to come along with a better answer on osgTerrain. good luck, -J On Tue, September 9, 2008 1:30 pm, Coco wrote: Hi, I'm presently working on a car simulator using OSG 2.2 for the visual. My problem is that I would like to load big areas (such as entire cities or more) which are fragmented in several Open Flight files without loading all those files. I looked at the OSG documentation and found out the osgTerrain::TerrainTile class (which doesn't exist on 2.2 OSG version). By using OSG 2.6, would I be able to load (with the TerrainTile class) only tiles (associated to a FLT file) that I need to see (which means according to the location of the camera)? Or do I need to implement this system by myself to avoid loading all files at the same time? I hope this post is clear enough and wait for answers. Kind regards, Nicolas Duval ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] unrendered objects creating performance problems?
Hi all, I was hoping someone has an idea about why I am encountering the following problem: I have a big terrain and on certain viewing angles it contains a huge amount of triangles to draw and puts a big strain on OSG's performance. I tried playing around with near/far clipping planes to improve performance, by cutting out a lot of the rendering, to the point only a very small fraction (and even none at all) of the terrain is seen through my camera. OSG's framerate, however, behaves just as if I was looking at the whole thing and drawing all the triangles. At certain angles, the framerate increases (where small number of triangles would normally be - even thought I don't see anything), and at other angles, it decreases (the same angles at which the viewer normally tries to draw a large number of triangles - even though I can't see anything). What is going on here?!? help! -J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] unrendered objects creating performance problems?
Hi Gordon, Those are great questions, thank you. I do not think my terrain tiles have their own geode or node, and maybe that can be a reason why the unneeded tiles are not being efficiently culled. I my terrain is maintained as a single geometry (which would be as you say: I am keeping the whole tri' under one node), but it IS a Paged LOD terrain in '*.ive' format and it is clearly divided into tiles for every level of detail. I thought that OSG's database pager would take care of culling unneeded tiles for me... How would you advise I break up the terrain as a distributed node-graph? Can I load it that way at run-time, or do I have to re-create the terrain differently? Thanks for your insight, I think, this is the right track! -Jose On Tue, September 9, 2008 6:19 pm, Gordon Tomlinson wrote: Have you broken your terrain in to tiled regions such that each tile has its one geode/node and uses an distributed node graph so that nodes that are not need can efficiently be culled, or do you have all the tri' under one node ? ( is your scene graph more like the top one in this basic diagram http://www.vis-sim.com/imgdp/vp_db_partion_01.jpg ) Have you considered using LOD's, Paged LOD's OSV VPB ( aka osgDem ) __ Gordon Tomlinson [EMAIL PROTECTED] IM: [EMAIL PROTECTED] www.vis-sim.com www.gordontomlinson.com __ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joseanibal Colon Ramos Sent: Tuesday, September 09, 2008 8:08 PM To: OpenSceneGraph Users Subject: [osg-users] unrendered objects creating performance problems? Hi all, I was hoping someone has an idea about why I am encountering the following problem: I have a big terrain and on certain viewing angles it contains a huge amount of triangles to draw and puts a big strain on OSG's performance. I tried playing around with near/far clipping planes to improve performance, by cutting out a lot of the rendering, to the point only a very small fraction (and even none at all) of the terrain is seen through my camera. OSG's framerate, however, behaves just as if I was looking at the whole thing and drawing all the triangles. At certain angles, the framerate increases (where small number of triangles would normally be - even thought I don't see anything), and at other angles, it decreases (the same angles at which the viewer normally tries to draw a large number of triangles - even though I can't see anything). What is going on here?!? help! -J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] suggestions for performance using shadowed scenes
Hello Jean, Thanks so much for the tips. For reference I am working on a 64-bit Linux-86, with Nvidia Quadro 3450, and OSG 2.6.0. I don't think I am being affected by exuberant resolutions on shadow map, since I am using whatever is osg default (i'm not setting any resolutions, except the graphic contexts). I don't know if my driver is rolling back to software emulation, but I'll update my graphic card driver, to see if it helps. Anyways, I started looking into PSSM by looking at the OSG osgshadow example. The frame-rate gets worse using PSSM in that case. Are there any settings that I should set to improve performance when making use of PSSM? Thanks again! -Jose On Thu, August 28, 2008 5:34 pm, Jean-Sébastien Guay wrote: Hello Jose, I have a HUGE terrain which uses paged LOD. ... Using ShadowTexture technique drops my frame-rate from 60+ to low 30's to high teens. ... Finally, using ShadowMap puts OSG on its knees at ~6 fps. You neglected to tell us what kind of hardware you're using, and what version of OSG. I've only seen ShadowMap do so bad in two cases: 1. when the video card driver was falling back to software emulation for FBOs (for the shadowmap render to texture) 2. when the shadow map texture resolution is higher than the video card can support (most of the time, 4096x4096 or 8192x8192 is the limit on recent video cards) Perhaps one of those could be your problem? If you have a large terrain, using ShadowMap with a very large texture size is not a solution. Other shadow techniques are more adapted to large scenes, such as PSSM or LiSPSM (the former is already in OSG, the latter should be integrated soon). Hope this helps, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] suggestions for performance using shadowed scenes
Hi all, I've given a trick subject. I don't have any suggestions, but I am looking for some. I have a HUGE terrain which uses paged LOD. I've been trying to implement shadows on my scene using this terrain, but the performance is terrible. Using ShadowTexture technique drops my frame-rate from 60+ to low 30's to high teens. Moreover, ShadowTexture doesn't work very well on my models, because depending on my camera's position, certain geometries of my models get blackened (Any ideas why this ugly artifact occurs with ShadowTexture?). Finally, using ShadowMap puts OSG on its knees at ~6 fps. Is there a way to implement shadows efficiently in a situation like this one? Thanks, -Jose P.S Perhaps worth mentioning: If I use the 'cessna.osg' on my scene, OSG goes crazy and flashes chunks of the cessna geometry all over the screen. It is hard to capture for a screen-shot, but I wonder if anyone has ever gotten this. To replicate, put cessna (particularly with ShadowMap), on a scene together with a big paged LOD terrain (it doesn't happen with other models - only with cessna.osg so far). This is not for just my application, it happens in OSG viewer. If someone is interested in seeing this, I could make a bigger effort to take a screen-shot. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Moving from Producer to osgViewer
Take a look at this:
http://www.openscenegraph.org/documentation/OpenSceneGraphReferenceDocs/classes.html
It will help you find the proper function name changes (or similar
functions) for the new classes you will be using.
For instance:
osgProducer::Viewer* viewer_obj; -
ref_ptrosgViewer::Viewer viewer_obj; //re_ptr's are safer than
pointers alone. instead of dereferencing you do: viewer_obj.get()
Producer::Camera *camera_obj; -
osg::Camera camera_obj;
and so on. Most of the things stay the same. Good luck.
-J
On Fri, July 25, 2008 5:20 am, Gordon Tomlinson wrote:
Have you tried ?
It took us not more than a couple days to move away form producer in our
apps
Some things a little different and you pick up those up quickly when you
convert
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bruno
Carneiro de Castro
Sent: Friday, July 25, 2008 7:40 AM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] Moving from Producer to osgViewer
Hi all
I'm moving an app from Producer to osgViewer and have doubts about the
equivalence between some Producer methods vs. osgViewer methods.
May you help me, indicating the methods more suitable to change in the
Producer code fragment below, in order to get it working under osgViewer?
Thanks,
Bruno
-
//variables (just to contextualize)
osgProducer::Viewer* viewer_obj;
Producer::Camera *camera_obj;
int x, y, width, height;
double d_left, d_right, d_bottom, d_top, d_nearClip, d_farClip, d_xshear,
d_yshear;
float f_near, f_far, f_hfov, f_vfov;
osg::Matrix matrix;
osg::Matrixd matrixd;
std::string name = My Camera;
osg::Group* hud;
//methods that need conversion
viewer_obj-getGlobalStateSet()-setMode( GL_FOG,
osg::StateAttribute::OVERRIDE|osg::StateAttribute::ON );
camera_obj-getLensParams(d_left, d_right, d_bottom, d_top, d_nearClip,
d_farClip, d_xshear, d_yshear);
camera_obj-setLensFrustum( d_left, d_right, d_bottom, d_top, d_near,
d_far,
d_xshear, d_yshear );
viewer_obj-getCameraConfig()-addCamera( name, camera_obj );
camera_obj-setProjectionRectangle ( x, y, width, height );
camera_obj-setLensAutoAspect(true);
camera_obj-setLensPerspective( f_hfov, f_vfov, f_near, f_far );
camera_obj = viewer_obj-getCameraConfig()- findCamera( name.c_str() );
camera_obj-setOffset( matrix.ptr() );
viewer_obj-setSceneDecorator( hud );
viewer_obj-setViewByMatrix( Producer::Matrix( matrixd.ptr() ) );
viewer_obj-update();
camera_obj-frame( false );
osgDB::Registry::instance()-getOrCreateDatabasePager()-
setUseFrameBlock(true);
for(SceneHandlerList::iterator itr = viewer_obj-_shvec.begin(); itr !=
viewer_obj-_shvec.end(); ++itr) {
osgDB::Registry::instance()-getOrCreateDatabasePager()-
setCompileGLObjectsForContextID(
(*itr)-getSceneView()-getState()-getContextID(), false ); }
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Slave Cameras projection matrices and aspect ratio
Thanks Robert,
Here is the Producer config file I am using:
***
Camera Camera-1
{
RenderSurface Window-1
{
Visual { SetSimple }
Screen 0;
WindowRect 0 30 426 341;
Border on;
InputRectangle -1.0 1.0 -1.0 1.0;
}
Offset {
Rotate 42.4 0 1 0;
}
}
Camera Camera-2
{
RenderSurface Window-2
{
Visual { SetSimple }
Screen 0;
WindowRect 426 30 426 341;
Border on;
InputRectangle -1.0 1.0 -1.0 1.0;
}
Offset {
Rotate 0.0 0 1 0;
}
}
Camera Camera-3
{
RenderSurface Window-3
{
Visual { SetSimple }
Screen 0;
WindowRect 852 30 426 341;
Border on;
InputRectangle -1.0 1.0 -1.0 1.0;
}
Offset {
Rotate -42.4 0 1 0;
}
}
InputArea
{
RenderSurface Window-1 ;
RenderSurface Window-2 ;
RenderSurface Window-3 ;
}
***
I have tested and compared it with OSG 2.4 and OSG 1.2 with (very)
slightly different results. I need the results to be exactly the same as
in OSG 1.2.
My understanding is that the InputArea is no longer required, but is is
still there for backwards compatibility with OSG 1.2 . For each
RenderSurface block I used to have a Lens configuration block like this
one:
Lens {
Perspective 42.4 45.0 1.0 100.0;
}
but I no longer use it because I set the parameters in my code as:
vwr.getCamera()-setProjectionMatrixAsPerspective(VerticalFOV, AspectRatio,
NearClip, FarClip); //for the master cam.
I've tried doing it for each of the Slave cams as well:
vwr.getSlave(int i)._camera-setProjectionMat. (same thing) . but it
doesn't change anything.
In this example:
AspectRatio = 1.33
VerticalFOV = 42.4/AspectRatio
NearClip = doesn't matter right now
FarClip = doesn't matter right now
Whe I run my program (version OSG 2.4) I get the following runtime values:
Master cam: (fov, aspect, near, far)31.807951987997, 1.333, 0.02, 199.
Slave cam # 0 (fov, aspect, near, far): 31.8079530956935,
1.31249230769231, 305.702400933255, 70223.0343790709
Slave cam # 1 (fov, aspect, near, far): 31.8079530956935,
1.31249230769231, 443.807876894962, 43394.6435810508
Slave cam # 2 (fov, aspect, near, far): 31.8079530956935,
1.31249230769231, 292.024441391996, 54427.4475917436
You may ignore the Near/Far values. You can notice how the slave cams
manipulated the aspect ratio slightly. The VerticalFOV seems right.
When I run OSG 1.2 I get this:
(no master cam concept)
camera 0 FOV(h,v) = 42.4,31.808
aspect_ratio : 1.36129
camera 1 FOV(h,v) = 42.4,31.808
aspect_ratio : 1.36129
camera 2 FOV(h,v) = 42.4,31.808
aspect_ratio : 1.36129
I don't know how the aspect ration became that value either, because the
aspect ratio should have been forced to 1.33. Anyways this works fine.
I'd like to get the OSG 1.2 results, although none of these numbers quite
make sense to me, and the corresponding values of each version are very
close. I'll also provide the projection matrices which are a bit off as
well:
OSG2.4:
Slave cam 0:
projectionMatrix : {
2.67399874028772 0 0 0
0 3.50960277740655 0 0
0 0 -1.00874468153415 -1
0 0 -614.078072006898 0
}
Slave cam 1:
projectionMatrix : {
2.67399874028772 0 0 0
0 3.50960277740655 0 0
0 0 -1.02066585525608 -1
0 0 -896.787423135345 0
}
Slave cam2:
projectionMatrix : {
2.67399874028772 0 0 0
0 3.50960277740655 0 0
0 0 -1.01078866385069 -1
0 0 -587.199436318357 0
}
What they should be: (OSG 1.2):
Cam 0:
2.57815,0,0,0
0,3.5096,0,0
0,0,-1,-1
0,0,-20,0
Cam 1:
2.57815,0,0,0
0,3.5096,0,0
0,0,-1,-1
0,0,-20,0
Cam2:
2.57815,0,0,0
0,3.5096,0,0
0,0,-1,-1
0,0,-20,0
(all the same). In OSG 2.4, if I hard-code my Master cam's
projectionMatrix to be like the one printed out in OSG 1.2 I get the good
image result.
The big question is: What parameter is off? Why? and How do I fix it?
Any help with anything here mentioned will be VERY welcomed!!
Thanks,
-Jose
On Thu, July 24, 2008 3:12 am, Robert Osfield wrote:
Hi Joseanibal,
Could you provide a Producer .cfg that you are having problem with.
Could you also please specify which versions of the OSG you've tried.
Robert.
On Thu, Jul 24, 2008 at 3:43 AM, Joseanibal Colon Ramos
[EMAIL PROTECTED] wrote:
Hi Anyone,
I need to fix this ASAP. I am using OSG 2.4+ with old Producer Config
files. OSG creates slave cameras for my multiple window configuration
(one
for each). The resulting settings are not quite like specified in my
configuration file. Field of Views are mostly OK, but it is altering the
aspect ratios of the slave cams and providing me with an image slightly
off from how it should be. I've tried setting the Slave
[osg-users] Slave Cameras projection matrices and aspect ratio
Hi Anyone, I need to fix this ASAP. I am using OSG 2.4+ with old Producer Config files. OSG creates slave cameras for my multiple window configuration (one for each). The resulting settings are not quite like specified in my configuration file. Field of Views are mostly OK, but it is altering the aspect ratios of the slave cams and providing me with an image slightly off from how it should be. I've tried setting the Slave cams' projection matrix, (setProjectionMatrixAsPerspective) with particular aspect ratios etc, but the aspect ratio value is being overriden somewhere and adjusted a little bit. However, the Master cam's aspect ratio is correct. How do I correctly set the Slave cam's aspect ratios?? and Why are the Producer Configuration files not doing what they used to in OSG 1.2 ?? Anyone please let me know soon, THANKS! -JCOLON ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
