Re: [osg-users] osgNETDemo
I wrote the osgCppCLIDemo.rar. I use lastest OSG SVN version, you should try upgrade your OSG. [EMAIL PROTECTED] wrote: Hello All, I have been working with Phil Tessier on some work using OSG in a managed code environment. We tried using OsgDotNet, but we had some problems with that, and others on this list recommended we use C++/CLI directly to wrap just what we need form OSG directly, and there is an example provided on the language wrappers page (osgCppCLIDemo.rar). I was able to get that compiled, but it crashes with a __RTDynamicCast exception deep within osgViewer.dll. The last thing I can see in the call stack is in the InitOSG() function, in the line that uses osg::GraphicsContext::createGraphicsContext(traits.get()); The call stack looks funny to me, because it calls osg.dll, and then osgViewer.dll. I am using OSG version 2.0 (because it is compatible with OsgDotNet) and Visual Studio 2005. Perhaps I need to upgrade OSG? Thanks, -- Rick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SceneView and Multi-camera render to texture
Hi, I'm using PRE_RENDER cameras rendering to FrameBufferObjects with SceneView, in some cases multi-pass as well. I've used a similar setup as per the osgprerender example and did not find a difference between using SceneView versus osgViewer. I'll splat some code into the bottom of the email, maybe it helps. It's with svn osg, Linux, NVidia. cheers jp Argentieri, John-P63223 wrote: Robert and pals, We are using osg 2.0. I am trying to duplicate the behavior of the osgdistortion example, but we are using osgUtil::SceneView and not osgViewer::Viewer. I have been unable to mimic the behavior of the example. If I set my texture camera to PRE_RENDER, all I get is a blank quad set to the color of the osg::geometry. If I set it to NESTED_RENDER, which is wrong, I think it draws the texture to the back buffer, because I can see it on the screen. Can anyone offer me some advice in this area? Thanks for your help…. *John Argentieri* *Software Engineer* *GENERAL DYNAMICS* *C4 Systems * *(407) 281-5568* [EMAIL PROTECTED] SceneView setup ---8--- _SceneView = new osgUtil::SceneView(); _SceneView-setDefaults(); osg::StateSet *gstate = _SceneView-getGlobalStateSet(); gstate-setGlobalDefaults(); gstate-setMode(GL_BLEND, osg::StateAttribute::OFF); gstate-setMode(GL_CULL_FACE, osg::StateAttribute::OFF); gstate-setMode(GL_DEPTH_TEST, osg::StateAttribute::OFF); _RootNode = new osg::Group(); _SceneView-setSceneData(_RootNode.get()); _SceneView-setClearColor(osg::Vec4(1.0f, 0.0f, 0.0f, 1.0f)); gstate-setMode( GL_LIGHTING, osg::StateAttribute::OFF); _SceneView-setLightingMode(osgUtil::SceneView::NO_SCENEVIEW_LIGHT); ---8--- Camera setup ---8--- // clearing _Camera-setClearColor(osg::Vec4(1.0f,0.0f,0.0f,1.0f)); _Camera-setClearMask(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); // projection and view _Camera-setProjectionMatrix(osg::Matrix::ortho2D(0,1,0,1)); _Camera-setReferenceFrame(osg::Transform::ABSOLUTE_RF); _Camera-setViewMatrix(osg::Matrix::identity()); // viewport _Camera-setViewport(0, 0, _TextureWidth, _TextureHeight); _Camera-setRenderOrder(osg::Camera::PRE_RENDER); _Camera-setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT); // attach the texture and use it as the color buffer. _Camera-attach(osg::Camera::COLOR_BUFFER, _OutTexture.get()); ---8--- Quad setup ---8--- osg::ref_ptrosg::Group top_group = new osg::Group; osg::ref_ptrosg::Geode quad_geode = new osg::Geode; osg::ref_ptrosg::Vec3Array quad_coords = new osg::Vec3Array; // vertex coords // counter-clockwise quad_coords-push_back(osg::Vec3d(0, 0, -1)); quad_coords-push_back(osg::Vec3d(1, 0, -1)); quad_coords-push_back(osg::Vec3d(1, 1, -1)); quad_coords-push_back(osg::Vec3d(0, 1, -1)); osg::ref_ptrosg::Vec2Array quad_tcoords = new osg::Vec2Array; // texture coords quad_tcoords-push_back(osg::Vec2(0, 0)); quad_tcoords-push_back(osg::Vec2(_TextureWidth, 0)); quad_tcoords-push_back(osg::Vec2(_TextureWidth, _TextureHeight)); quad_tcoords-push_back(osg::Vec2(0, _TextureHeight)); osg::ref_ptrosg::Geometry quad_geom = new osg::Geometry; osg::ref_ptrosg::DrawArrays quad_da = new osg::DrawArrays(osg::PrimitiveSet::QUADS,0,4); quad_geom-setVertexArray(quad_coords.get()); quad_geom-setTexCoordArray(0, quad_tcoords.get()); quad_geom-addPrimitiveSet(quad_da.get()); _StateSet = quad_geom-getOrCreateStateSet(); _StateSet-setMode(GL_LIGHTING,osg::StateAttribute::OFF); _StateSet-setTextureAttributeAndModes(0, _InTexture.get(), osg::StateAttribute::ON); quad_geode-addDrawable(quad_geom.get()); top_group-addChild(quad_geode.get()); return top_group; ---8--- -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Dual-screen configuration
Try using the environment variable OSG_SCREEN=0 or using C++: putenv( OSG_SCREEN=0 ); This configures osgviewer to use only your primary screen. Daniel From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles Han Sent: Monday, March 17, 2008 10:31 PM To: OSG-USERS Subject: [osg-users] Dual-screen configuration Hey people, My application has a problem to run on a dual-screen computer I.e. the viewer can not be initialized properly. Is there a configuration to overcome this since we are not sure if users have dual or single screen. Thanks Charles ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with LightPoint
Hi,
Here comes the whole modified file.
I attach a simple test.osg as well, which can be used in osgviewer to exemplify
the problem.
Regards,
Lars Nilsson
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield
Sent: den 17 mars 2008 17:01
To: OpenSceneGraph Users
Subject: Re: [osg-users] Problem with LightPoint
Hi Lars,
I haven't heard reports of problem before, but perhaps no one has
looked close enough. Could you send me the whole modified file so I
can review it side by side against the original.
Thanks,
Robert.
On Mon, Mar 17, 2008 at 2:43 PM, Nilsson Lars
[EMAIL PROTECTED] wrote:
Hi
When I tested airport lighting with OpenSceneGraph, the directional light
did not work the way I expected.
The light was visible a bit outside the defined sector. Especially for the
PAPI (Precision Approach Path Indicator),
it is important that the angles are correct.
After rewriting a small piece of code in osgSim/Sector.cpp it seemed to work
as I wanted.
The change made was in the function computeMatrix() as shown below.
void DirectionalSector::computeMatrix()
{
double heading = atan2(_direction[0], _direction[1]);
double pitch = atan2(_direction[2], sqrt(_direction[0]*_direction[0] +
_direction[1]*_direction[1]));
double roll= _rollAngle;
_local_to_LP = osg::Matrixd::identity();
_local_to_LP.preMult(osg::Matrix::rotate(heading, 0.0, 0.0, -1.0));
_local_to_LP.preMult(osg::Matrix::rotate(pitch, 1.0, 0.0, 0.0));
_local_to_LP.preMult(osg::Matrix::rotate(roll, 0.0, 1.0, 0.0));
}
I am certainly not sure if this change is correct in all aspects, but it
solved at least the problem for me.
Has anyone else discovered similar problem about light points?
Regards,
Lars Nilsson
___
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
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield
*
* This library is open source and may be redistributed and/or modified under
* the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or
* (at your option) any later version. The full license is in LICENSE file
* included with this distribution, and on the openscenegraph.org website.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* OpenSceneGraph Public License for more details.
*/
#include osgSim/Sector
#include osg/Vec2
using namespace osgSim;
//
// Elevation Range
//
void AzimRange::setAzimuthRange(float minAzimuth,float maxAzimuth,float
fadeAngle)
{
// clamp the azimuth range.
const float twoPI = 2.0f*(float)osg::PI;
while(minAzimuthmaxAzimuth) minAzimuth -= twoPI;
// compute the centerline
float centerAzim = (minAzimuth+maxAzimuth)*0.5f;
_cosAzim = cos(centerAzim);
_sinAzim = sin(centerAzim);
// compute the half angle range of the sector.
float angle = (maxAzimuth-minAzimuth)*0.5f;
_cosAngle = cos(angle);
// clamp the fade angle to valid values.
fadeAngle = osg::clampAbove(fadeAngle,0.0f);
if (angle+fadeAngleosg::PI) _cosFadeAngle = -1.0f;
else _cosFadeAngle = cos(angle+fadeAngle);
}
void AzimRange::getAzimuthRange(float minAzimuth, float maxAzimuth, float
fadeAngle) const
{
float centerAzim = atan2(_sinAzim, _cosAzim);
float angle = acos(_cosAngle);
minAzimuth = centerAzim - angle;
maxAzimuth = centerAzim + angle;
if (_cosFadeAngle == -1.0f) {
fadeAngle = 2.0f * osg::PI;
} else {
fadeAngle = acos(_cosFadeAngle) - angle;
}
}
//
// Elevation Range
//
void ElevationRange::setElevationRange(float minElevation,float
maxElevation,float fadeAngle)
{
if (minElevationmaxElevation)
{
// need to swap angle pair.
float tmp = minElevation;
minElevation = maxElevation;
maxElevation = tmp;
}
minElevation =
osg::clampTo(minElevation,(float)-osg::PI_2,(float)osg::PI_2);
maxElevation =
osg::clampTo(maxElevation,(float)-osg::PI_2,(float)osg::PI_2);
fadeAngle = osg::clampTo(fadeAngle,0.0f,(float)osg::PI_2);
_cosMinElevation = cos(osg::PI_2-minElevation);
_cosMaxElevation = cos(osg::PI_2-maxElevation);
float minFadeAngle = osg::PI_2-minElevation+fadeAngle;
if (minFadeAngle=osg::PI) _cosMinFadeElevation = -1.0f;
else _cosMinFadeElevation = cos(minFadeAngle);
float maxFadeAngle = osg::PI_2-maxElevation-fadeAngle;
if (maxFadeAngle=0.0f) _cosMaxFadeElevation = 1.0f;
else _cosMaxFadeElevation = cos(maxFadeAngle);
}
Re: [osg-users] from opengl.org: RenderMonkey, COLLADA, OSG
The example provided is very nice, these improvements to the dae plugin definitely needs to be added to the core plugin. On Mon, Mar 17, 2008 at 8:01 PM, Mike Weiblen [EMAIL PROTECTED] wrote: Hi all, didn't notice if anyone had mentioned this, from opengl.org: http://www.opengl.org/news/permalink/amd_gpg_developer_tools_group_has_released_an_open_source_collada_opengl_fx/ followed to the AMD page: http://ati.amd.com/developer/rendermonkey/downloads.html and noticed the viewer download: http://www2.ati.com/developer/rendermonkey/files/osg2.2_collada_gl_fx_viewer_031108.zip cheers -- mew Mike Weiblen -- Austin Texas USA -- http://mew.cx/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow example and gerneral question
HI Wojtek, Excellent detective work. I'll have to raise my hand as the culprit of the change to CullVisitor::apply(Camera), done is response to a discussion between Mathias Froehlich and myself about inheritance of settings. I believe the inheritance of settings is now correct, but obviously in my testing after applying this change I didn't spot the regression in osgshadow and the unforseen consequences. Since I think the actual rules of inheritance of settings are correct, and things worked before because of bug in the inheritance of settings, so its a matter of either changing the defaults in CullSettings so that less of the inherited state comes down into the local Camera, or we override the defaults locally. I'd suggest we change the defaults locally and review the defaults in light of how many changes we make. Robert. On Tue, Mar 18, 2008 at 9:18 AM, Wojciech Lewandowski [EMAIL PROTECTED] wrote: Hi Robert, I think I have found the cause of the problem. Problem is not only related to osgShadow::ShadowMap. All Shadow mapping techniques exhibit similar issue (SM, SSM, PSSM). And it looks like problem could be wider and affected other examples as well. Problem appeared when SVN changelist 7912 was added . This submission changes Cameras cull settings inheritance policy during Cull traversal. After this modification Shadow camera DO_NOT_COMPUTE_NEAR_FAR flag gets overriden with main camera COMPUTE_NEAR_FAR setting . This in effect desynchronizes texgen and depth map. Texgen is calculated using not adjusted Shadow camera projection. Shadow depth map is rendered using Shadow camera projection that was additionaly near/far adjusted. Problem could be avoided by adding following line to shadow camera initialization. _camera-setInheritanceMask( _camera-getInheritanceMask() ~osg::Camera::COMPUTE_NEAR_FAR_MODE ); But this topic brings another question: up till 7912 changelist, we were simply using setComputeNearFar( false ) to avoid clamping of projection matrix. Does it mean that from now we will also need to add above aditional line to protect it from inheritance overriding ? If yes then we got a lot of code to review and adjust ...;-( Cheers, Wojtek - Original Message - From: Wojciech Lewandowski [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Monday, March 17, 2008 12:29 PM Subject: Re: [osg-users] osgShadow example and gerneral question Robert, I replicated the problem with osgShadow::ShadowMap. I will try to find the cause... Cheers, Wojtek - Original Message - From: Wojciech Lewandowski [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Monday, March 17, 2008 11:57 AM Subject: Re: [osg-users] osgShadow example and gerneral question Hi Robert, There are few versions from 2000-2002. I found earlier 2000 version on NVidia site. But 2002 version has the PolygonOffset section extended in comparison to 2000. It looks like siggraph 2002 presentation could be found under this link: http://www1.cs.columbia.edu/~ravir/6160/papers/shadowmaps.ppt Slides 20-27 refer to PolygonOffset topic. Cheers, Wojtek - Original Message - From: Robert Osfield [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Monday, March 17, 2008 11:26 AM Subject: Re: [osg-users] osgShadow example and gerneral question Hi Wojtek, Could you post a link, or the actual presentation, or put it up on the wiiki, of Mark Kilgrads paper discussing PolygonOffset. It would nice to isolate the actual differences in implementation of PolygonOffset across hardware so we can pick appropriate settings for different hardware. There are already some factors set in PolygonOffset itself to try and cope with this but the values where just set from basic experience with osgText, and not done is rigorous way. I would to roll this back and do a rigorous testing of different hardware so we can get more consistent results across and models sizes. Robert. On Mon, Mar 17, 2008 at 9:47 AM, Wojciech Lewandowski [EMAIL PROTECTED] wrote: Hi Robert and All, I am back from vacations. Ready to take the responsibility for my changes in osgShadow::ShadowMap ;-). Does the problem Adrian refers happen only with PSSM or standard ShadowMap as well ? Its not obvious from forum emails and I am unable to replicate it with standard ShadowMap. I looked once again at the my submitted osgShadow::ShadowMap code and I have NOT changed polygon offset. PolygonOffset remains untoched in several latest revisions. However, I do have my objections against default ShadowMap cullface/polygon offset settings. I remember that former (pre 2.0 osgShadow nodekit) DepthShadowMap example was using frontface culling and polygon offset factor=1.1 and
Re: [osg-users] osgShadow example and gerneral question
Hi Robert, Since I think the actual rules of inheritance of settings are correct, and things worked before because of bug in the inheritance of settings, so its a matter of either changing the defaults in CullSettings so that less of the inherited state comes down into the local Camera, or we override the defaults locally. I'd suggest we change the defaults locally and review the defaults in light of how many changes we make. In other words from now when we want a fixed projection matrix we need to make two calls: camera-setComputeNearFarMode( osg::Camera::DO_NOT_COMPUTE_NEAR_FAR ); camera-setInheritanceMask( camera-getInheritanceMask() ~osg::Camera::COMPUTE_NEAR_FAR_MODE ); This sounds like backward compatibility problems. I suspect there is a number of examples and users code that call setComputeNearFar method only. Maybe Camera::setComputeNearFarMode() method could also change inheritance mask ? Or maybe adding additional default adjustInheritanceMask = true parameter could be added to setComputeNearFarMode to keep actual inheritance policy and not break compatibility ie: osg::Camera::setComputeNearFarMode( ComputeNearFarMode cnfm, adjustInheritanceMask = true ); ? Cheers, Wojtek - Original Message - From: Robert Osfield [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Tuesday, March 18, 2008 12:40 PM Subject: Re: [osg-users] osgShadow example and gerneral question HI Wojtek, Excellent detective work. I'll have to raise my hand as the culprit of the change to CullVisitor::apply(Camera), done is response to a discussion between Mathias Froehlich and myself about inheritance of settings. I believe the inheritance of settings is now correct, but obviously in my testing after applying this change I didn't spot the regression in osgshadow and the unforseen consequences. Since I think the actual rules of inheritance of settings are correct, and things worked before because of bug in the inheritance of settings, so its a matter of either changing the defaults in CullSettings so that less of the inherited state comes down into the local Camera, or we override the defaults locally. I'd suggest we change the defaults locally and review the defaults in light of how many changes we make. Robert. On Tue, Mar 18, 2008 at 9:18 AM, Wojciech Lewandowski [EMAIL PROTECTED] wrote: Hi Robert, I think I have found the cause of the problem. Problem is not only related to osgShadow::ShadowMap. All Shadow mapping techniques exhibit similar issue (SM, SSM, PSSM). And it looks like problem could be wider and affected other examples as well. Problem appeared when SVN changelist 7912 was added . This submission changes Cameras cull settings inheritance policy during Cull traversal. After this modification Shadow camera DO_NOT_COMPUTE_NEAR_FAR flag gets overriden with main camera COMPUTE_NEAR_FAR setting . This in effect desynchronizes texgen and depth map. Texgen is calculated using not adjusted Shadow camera projection. Shadow depth map is rendered using Shadow camera projection that was additionaly near/far adjusted. Problem could be avoided by adding following line to shadow camera initialization. _camera-setInheritanceMask( _camera-getInheritanceMask() ~osg::Camera::COMPUTE_NEAR_FAR_MODE ); But this topic brings another question: up till 7912 changelist, we were simply using setComputeNearFar( false ) to avoid clamping of projection matrix. Does it mean that from now we will also need to add above aditional line to protect it from inheritance overriding ? If yes then we got a lot of code to review and adjust ...;-( Cheers, Wojtek - Original Message - From: Wojciech Lewandowski [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Monday, March 17, 2008 12:29 PM Subject: Re: [osg-users] osgShadow example and gerneral question Robert, I replicated the problem with osgShadow::ShadowMap. I will try to find the cause... Cheers, Wojtek - Original Message - From: Wojciech Lewandowski [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Monday, March 17, 2008 11:57 AM Subject: Re: [osg-users] osgShadow example and gerneral question Hi Robert, There are few versions from 2000-2002. I found earlier 2000 version on NVidia site. But 2002 version has the PolygonOffset section extended in comparison to 2000. It looks like siggraph 2002 presentation could be found under this link: http://www1.cs.columbia.edu/~ravir/6160/papers/shadowmaps.ppt Slides 20-27 refer to PolygonOffset topic. Cheers, Wojtek - Original Message - From: Robert Osfield [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Monday, March 17, 2008 11:26 AM Subject: Re: [osg-users] osgShadow example and gerneral question Hi Wojtek, Could
Re: [osg-users] osgShadow example and gerneral question
Hi Wojciech, On Tue, Mar 18, 2008 at 12:13 PM, Wojciech Lewandowski [EMAIL PROTECTED] wrote: In other words from now when we want a fixed projection matrix we need to make two calls: camera-setComputeNearFarMode( osg::Camera::DO_NOT_COMPUTE_NEAR_FAR ); camera-setInheritanceMask( camera-getInheritanceMask() ~osg::Camera::COMPUTE_NEAR_FAR_MODE ); If we don't change the default setting then this is true. This sounds like backward compatibility problems. I suspect there is a number of examples and users code that call setComputeNearFar method only. Maybe Camera::setComputeNearFarMode() method could also change inheritance mask ? Or maybe adding additional default adjustInheritanceMask = true parameter could be added to setComputeNearFarMode to keep actual inheritance policy and not break compatibility ie: osg::Camera::setComputeNearFarMode( ComputeNearFarMode cnfm, adjustInheritanceMask = true ); ? I'm open to this approach, but having the two decoupled is cleaner interface wise. This is a general problem with inheritance of properties, if we set the value then it would imply that its important that we retain this value and to not inherit it, this in turn would suggest that we should have the inheritance mask set off by default. Items like back ground colour is certainly something that can be useful to inherit, but... perhaps if the coder wants this then its fair enough to actually require them to set it. Clearly wel need to have a good think about inheritance of settings in viewer and scene graph Cameras, and SceneView which also uses CullSettings behind the scenes in osgViewer. Right now I think the thing to do is apply the fix to osgShadow, then move on to a wider review of inheritance of CullSettings. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow example and gerneral question
Hi Robert, In other words from now when we want a fixed projection matrix we need to make two calls: camera-setComputeNearFarMode( osg::Camera::DO_NOT_COMPUTE_NEAR_FAR ); camera-setInheritanceMask( camera-getInheritanceMask() ~osg::Camera::COMPUTE_NEAR_FAR_MODE ); If we don't change the default setting then this is true. This is a general problem with inheritance of properties, if we set the value then it would imply that its important that we retain this value and to not inherit it, this in turn would suggest that we should have the inheritance mask set off by default. Items like back ground colour is certainly something that can be useful to inherit, but... perhaps if the coder wants this then its fair enough to actually require them to set it. Clearly wel need to have a good think about inheritance of settings in viewer and scene graph Cameras, and SceneView which also uses CullSettings behind the scenes in osgViewer. If I understand correctly you opt for default NULL inheritance mask. Right ? I agree that this should solve this particular issue. Don't know how this would affect other cull settings, though. [...] I'm open to this approach, but having the two decoupled is cleaner interface wise. [...] Right now I think the thing to do is apply the fix to osgShadow, then move on to a wider review of inheritance of CullSettings. I think I understand your motives. Do you want me to add this second line and send a fix for osgShadow::ShadowMap ? I may try to update PSSM and SSM as well but I won't guarantee I will be able to fully test them. Cheers, Wojtek PS. For the reference I attached a list of remaining files from search for setComputeNearFarMode below (removed PSSM, SSM, SM .and files with commented setComputeNearFarMode cases). They may require similar tweaks before you change default inheritance mask. OpenSceneGraph\src\osgSim\OverlayNode.cpp(973): overlayData._camera-setComputeNearFarMode(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR); OpenSceneGraph\examples\osgdepthpartition\DepthPartitionNode.cpp(219): camera-setComputeNearFarMode(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR); OpenSceneGraph\examples\osgdepthpeeling\osgdepthpeeling.cpp(247): viewer.getCamera()-setComputeNearFarMode(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR); OpenSceneGraph\examples\osgfadetext\osgfadetext.cpp(129): viewer.getCamera()-setComputeNearFarMode(osg::CullSettings::COMPUTE_NEAR_FAR_USING_PRIMITIVES); OpenSceneGraph\examples\osgsimulation\osgsimulation.cpp(224): viewer.getCamera()-setComputeNearFarMode(osg::CullSettings::COMPUTE_NEAR_FAR_USING_PRIMITIVES); OpenSceneGraph\examples\osgslice\osgslice.cpp(162): sceneView-setComputeNearFarMode(osgUtil::CullVisitor::DO_NOT_COMPUTE_NEAR_FAR); ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow example and gerneral question
On Tue, Mar 18, 2008 at 2:18 PM, Wojciech Lewandowski [EMAIL PROTECTED] wrote: Items like back ground colour is certainly something that can be useful to inherit, but... perhaps if the coder wants this then its fair enough to actually require them to set it. Clearly wel need to have a good think about inheritance of settings in viewer and scene graph Cameras, and SceneView which also uses CullSettings behind the scenes in osgViewer. If I understand correctly you opt for default NULL inheritance mask. Right ? I agree that this should solve this particular issue. Don't know how this would affect other cull settings, though. Other effects is what we need to be careful about and why making top level changes right now is probably a bit too quick. Without looking into further my guess is that SceneView needs to inherit all CullSettings, slave Cameras should inherit their CullSettings, but scene graph Cameras might be better off not inheriting settings. Or perhaps we always inherit unless one sets a variable locally - this would require an approach like in your extra parameter suggestion. Right now I think the thing to do is apply the fix to osgShadow, then move on to a wider review of inheritance of CullSettings. I think I understand your motives. Do you want me to add this second line and send a fix for osgShadow::ShadowMap ? I may try to update PSSM and SSM as well but I won't guarantee I will be able to fully test them. It may even be worth doing a setInheritanceMask(0x0) on all these osgShadow implements. The right of the Camera usages needs look at as well. I'm just tying up some other work, once this is done I'll do a quick review of Camera usage. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow example and gerneral question
I'm just tying up some other work, once this is done I'll do a quick review of Camera usage. Thanks for explanations, I no longer disturb. Let me know if I could help. Cheers, Wojtek - Original Message - From: Robert Osfield [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Tuesday, March 18, 2008 3:37 PM Subject: Re: [osg-users] osgShadow example and gerneral question On Tue, Mar 18, 2008 at 2:18 PM, Wojciech Lewandowski [EMAIL PROTECTED] wrote: Items like back ground colour is certainly something that can be useful to inherit, but... perhaps if the coder wants this then its fair enough to actually require them to set it. Clearly wel need to have a good think about inheritance of settings in viewer and scene graph Cameras, and SceneView which also uses CullSettings behind the scenes in osgViewer. If I understand correctly you opt for default NULL inheritance mask. Right ? I agree that this should solve this particular issue. Don't know how this would affect other cull settings, though. Other effects is what we need to be careful about and why making top level changes right now is probably a bit too quick. Without looking into further my guess is that SceneView needs to inherit all CullSettings, slave Cameras should inherit their CullSettings, but scene graph Cameras might be better off not inheriting settings. Or perhaps we always inherit unless one sets a variable locally - this would require an approach like in your extra parameter suggestion. Right now I think the thing to do is apply the fix to osgShadow, then move on to a wider review of inheritance of CullSettings. I think I understand your motives. Do you want me to add this second line and send a fix for osgShadow::ShadowMap ? I may try to update PSSM and SSM as well but I won't guarantee I will be able to fully test them. It may even be worth doing a setInheritanceMask(0x0) on all these osgShadow implements. The right of the Camera usages needs look at as well. I'm just tying up some other work, once this is done I'll do a quick review of Camera usage. Robert. ___ 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] Shadow Map and threading mode
Hi Wojtek, I was on vactions. But if you are still interested I did the test you wanted. Of course I am interested. :-) Thanks for testing. Seems like the more recent nVidia drivers give problems when switching threading modes, and older ones are OK. Unfortunately I am on Vista so using old drivers usually gives me other problems :-( Anyways, I think we'll chalk it down to a driver bug until more information is available. Thanks again for testing. 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] Placing Text Labels in Geodetic Projection
Hi all,
I've written a 2D viewer that displays geospatial imagery in an orthographic
projection using a WGS-1984 geodetic projection so the units are in degrees.
I am placing text labels with their character size specified in
SCREEN_COORDS. When I zoom in very close, the quality of the text starts to
suffer b/c the glyph quads are so small that they are losing precision when
rendering. Placing a MatrixTransform above the text to position it locally
reduces the visual problems but there are still some present.
The main problem I have is that the text cannot be selected if I zoom in
close. I can see the text fine, but clicking on it doesn't result in a hit
b/c the intersections are all done using floats and the text glyphs are
extermely small because of the autosizing.
I found a potential solution using the latest version of OpenSceneGraph
which places the text in an orthographic HUD camera and positions it at the
correct space on the earth using the callback at the end of this email.
Intersections work well and the text looks very crisp.
We are currently using OpenSceneGraph 1.2 and are rolling our own viewer
using SceneView and IntersectVisitor (NOT IntersectionVisitor) in our
application and cannot update this spiral due to time constraints.
IntersectVisitor does not seem to work correctly in picking items placed in
a CameraNode in the 1.2 version.
Does anyone have any suggestions on how I could fix this issue using
OpenSceneGraph 1.2 and does the solution I found for using the latest
version of OSG make sense or I am missing something painfully obvious?
Thanks!
Jason
struct HudTextUpdateCallback : public osg::Drawable::UpdateCallback
{
public:
HudTextUpdateCallback(double lon, double lat, Viewer* viewer)
{
_viewer = viewer;
_lon = lon;
_lat = lat;
}
virtual void update(osg::NodeVisitor* nv, osg::Drawable* drawable)
{
Text* text = dynamic_castText*(drawable);
if (text)
{
CameraHelper h;
h.setCamera(_viewer-getCamera());
osg::Vec3 object(_lon,0,_lat);
osg::Vec3 window;
h.projectObjectIntoWindow(object, window);
text-setPosition(osg::Vec3(window.x(), window.y(), 0.0));
}
}
double _lon;
double _lat;
Viewer *_viewer;
};
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow example and gerneral question
On Tue, Mar 18, 2008 at 3:45 PM, Wojciech Lewandowski [EMAIL PROTECTED] wrote: I'm just tying up some other work, once this is done I'll do a quick review of Camera usage. Thanks for explanations, I no longer disturb. Let me know if I could help. You've already been a great help, pinpointing the problem was the hardest part of this jigsaw :-) I've been reviewing the inheritance mask, it covers a wide range of features, including items like lighting, cull masks etc, the types of stuff that is often useful to inherit. The Viewer use of master Camera, slave Camera and SceneView for internal rendering implementation all rely upon top down inheritance of settings, so I believe it makes sense for these to retain the default InheritanceMask of ALL_VARIABLES. However, the needs of InheritanceMask of RTT Camera's is somewhat different, when you actively change the clear colour, or the computing of the projection matrix you really don't want to go inheriting this same value. The old buggy implementation in CullVisitor::apply(Camera) meant that in effect as an inheritance mask set to 0x0, which as this worked better than the current system then to replicate it we'd want to set the inheritince mask to 0x0. Since osg::Camera's are just constructed the same no matter whether they are viewer ones or ones in the scene graph it isn't possible to just choose a different default inheritince mask in each context. Such a scheme would also obscure what is going on under the hood. What we really need it keep a consistent system with clear rules of inheritance that are applied across all types of Cameras, no matter if they are in scene graph or in viewer. The awkward bit is that we need to keep backwards compatibility as well. The solutions I can think of right now are: 1) Change have the CullSetting::InhertacenMask default to 0x0 and have all Viewer code to related Camera's and SceneView to explicitly set the InheritanceMask to ALL_VARIABLES 2) Leave CullSetting::InheritanceMask as ALL_VARIABLE default, and change all RTT/in scene graph Cameras to explictly disable the InhertianceMask they do not need. 3) Leave CullSetting::InheritanceMask as ALL_VARIABLE default and have the CullSettings::setVariable() calls all optional disable the associated part of the InhertianceMask to off. This disabling would be done by default. i.e CullSettings::setComputeNearFarMode(mode, bool disableInhertianceOfComputeNearFarMode=true); I think option 3 would probably give us reasonable backwards compatibility, but... it would hide a bit of what is going on w.r.t InheritanceMask and be inconstistent with the way the rest of the OSG works w.r.t set/get methods. Can anyone else think of any other options? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Earth Model with height relief (BlueMarble)
Hi Umit, Try add a -d in from of the DEM file. i.e osgdem -s build.source --whole-globe -d topo.tif For -l 4 you'll find that you want see an terrain. I'd also recommend using --terrain as the build is well over a hundred times faster. Robert. On Tue, Mar 18, 2008 at 4:11 PM, ümit uzun [EMAIL PROTECTED] wrote: Hi All. I try to make earth model with height relief. I am using this command on Ubuntu 7.10, OpenSceneGraph Library 2.3.4 and VirtualPlanetBuilder/osgdem 0.9.5 ; // Create the build.source file osgdem --bluemarble-west -t ../land_shallow_topo_west.tif \ --bluemarble-east -t ../land_shallow_topo_east.tif \ --geocentric \ -o earth/earth.ive \ --so build.source //creating whole earth elevation data subroutines I download srtm_ramp2.world.21600x10800.jpg from http://visibleearth.nasa.gov/view_detail.php?id=8391 web site. Then I use gdal utility commands; //traslating jpg to geotiff gdal_translate srtm_ramp2.world.21600x10800.jpg topo.tif //adding overview to topo.tif gdaladdo -r average topo.tif 2 4 8 16 32 64 128 //run the build.source osgdem -s build.source --whole-globe topo.tif -v 1000.0 -l 4 But when the process finished I see a globe which is not expected. The height relief and the earth lands surface can't overlap on same coordinate place. what can I do for to create original earth model with height relief. ÜMİT UZUN _ Windows Live Messenger'ın için Ücretsiz 30 İfadeyi yükle http://get.live.com ___ 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] osgShadow example and gerneral question
Hi, On Tuesday 18 March 2008 17:27, Robert Osfield wrote: You've already been a great help, pinpointing the problem was the hardest part of this jigsaw :-) I've been reviewing the inheritance mask, it covers a wide range of features, including items like lighting, cull masks etc, the types of stuff that is often useful to inherit. The Viewer use of master Camera, slave Camera and SceneView for internal rendering implementation all rely upon top down inheritance of settings, so I believe it makes sense for these to retain the default InheritanceMask of ALL_VARIABLES. However, the needs of InheritanceMask of RTT Camera's is somewhat different, when you actively change the clear colour, or the computing of the projection matrix you really don't want to go inheriting this same value. The old buggy implementation in CullVisitor::apply(Camera) meant that in effect as an inheritance mask set to 0x0, which as this worked better than the current system then to replicate it we'd want to set the inheritince mask to 0x0. Since osg::Camera's are just constructed the same no matter whether they are viewer ones or ones in the scene graph it isn't possible to just choose a different default inheritince mask in each context. Such a scheme would also obscure what is going on under the hood. What we really need it keep a consistent system with clear rules of inheritance that are applied across all types of Cameras, no matter if they are in scene graph or in viewer. The awkward bit is that we need to keep backwards compatibility as well. The solutions I can think of right now are: 1) Change have the CullSetting::InhertacenMask default to 0x0 and have all Viewer code to related Camera's and SceneView to explicitly set the InheritanceMask to ALL_VARIABLES 2) Leave CullSetting::InheritanceMask as ALL_VARIABLE default, and change all RTT/in scene graph Cameras to explictly disable the InhertianceMask they do not need. 3) Leave CullSetting::InheritanceMask as ALL_VARIABLE default and have the CullSettings::setVariable() calls all optional disable the associated part of the InhertianceMask to off. This disabling would be done by default. i.e CullSettings::setComputeNearFarMode(mode, bool disableInhertianceOfComputeNearFarMode=true); I think option 3 would probably give us reasonable backwards compatibility, but... it would hide a bit of what is going on w.r.t InheritanceMask and be inconstistent with the way the rest of the OSG works w.r.t set/get methods. Can anyone else think of any other options? Move the inheritance mask from CullSettings to the camera. As you can see from your own suggestions abive the other users of the inheritance mask and CullSettings will just need a copy from its 'parent' settings. Initialize this mask in the camera to inherit all. This is what the previous implementation that ignored the mask completely did. You would preserve backwards compatibility with existing code with this. The reader of the code would better understand what happens and you could implement what you told me for the first cut how it *should* work instead of something you need to dig for in the sources. Well, I did not see that this past change brakes in the shadow thing, when I offered you codework for that old suggestion, but I saw that it will probably cause problems that would be better solved right. Also I expect every usage of a Camera being used in the wrong way since the inheritance mask has never worked in any way before our past change. I also think that a Camera that now makes use of the mask that was previously ignored will break much more of the compatibility than moving the mask to where it is used. Also it is better to get a 'heads up there has something changed' from the compiler than just some subtle errors ... Still offering time to implement that ... Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Earth Model with height relief (BlueMarble)
Hi Robert, I totally agree with dropping support for non-geospecific data in osgdem/VPB if it makes life easier on you and keeps the code simpler. The suite of GDAL tools is easy to use and users should be using them to process the geospatial data instead of expecting OpenSceneGraph to do the work of gdal_translate and gdalwarp out of the box. Thanks! Jason On Tue, Mar 18, 2008 at 12:36 PM, Robert Osfield [EMAIL PROTECTED] wrote: Forgot to mention. When doing whole earth database it's painful not using geospecific imagery and DEMs as you have to specify the coords when pass them to osgdem. Its far easier to just use proper geospecific data, then you just use -t and -d options for the source files, and both can even handle whole directories trees. This way its easy to specify terrabyte databases with just a few command line options. I am actually kinda tempted to drop support for non geospecific imagery in osgdem/VPB as its just hard work supporting users who cobble together data in too a rough form for the task in hand. ___ 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] Earth Model with height relief (BlueMarble)
Hi Robert, I am so sorry for writing wrong command. Actually I used to -d parameter in ; //run the build.source osgdem -s build.source --whole-globe -d topo.tif -v 1000.0 -l 4 command.But I forgot typing this detail. I think my topo.tif hasn't georeference information in it. How can I get whole earth height relief data (for example as 10 km / pixel ) which has georefence information in it? Could you suggest me a web site? Thanks for all your advice; ÜMİT UZUN Date: Tue, 18 Mar 2008 16:31:03 + From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Earth Model with height relief (BlueMarble) Hi Umit, Try add a -d in from of the DEM file. i.e osgdem -s build.source --whole-globe -d topo.tif For -l 4 you'll find that you want see an terrain. I'd also recommend using --terrain as the build is well over a hundred times faster. Robert. On Tue, Mar 18, 2008 at 4:11 PM, ümit uzun wrote: Hi All. I try to make earth model with height relief. I am using this command on Ubuntu 7.10, OpenSceneGraph Library 2.3.4 and VirtualPlanetBuilder/osgdem 0.9.5 ; // Create the build.source file osgdem --bluemarble-west -t ../land_shallow_topo_west.tif \ --bluemarble-east -t ../land_shallow_topo_east.tif \ --geocentric \ -o earth/earth.ive \ --so build.source //creating whole earth elevation data subroutines I download srtm_ramp2.world.21600x10800.jpg from http://visibleearth.nasa.gov/view_detail.php?id=8391 web site. Then I use gdal utility commands; //traslating jpg to geotiff gdal_translate srtm_ramp2.world.21600x10800.jpg topo.tif //adding overview to topo.tif gdaladdo -r average topo.tif 2 4 8 16 32 64 128 //run the build.source osgdem -s build.source --whole-globe topo.tif -v 1000.0 -l 4 But when the process finished I see a globe which is not expected. The height relief and the earth lands surface can't overlap on same coordinate place. what can I do for to create original earth model with height relief. ÜMİT UZUN _ Windows Live Messenger'ın için Ücretsiz 30 İfadeyi yükle http://get.live.com ___ 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 _ Yeni nesil Windows Live Servisleri’ne şimdi ulaşın! http://get.live.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Placing Text Labels in Geodetic Projection
Hi Robert,
I've been using the 2.x branch in personal projects and test projects and
have kept up to date with the SVN version for the most part (it's tough with
so much going on so fast!) and I'm REALLY happy with the way 2.x has
progressed. It's much easier to use and feels *right* to me in nearly every
aspect. The osgViewer project has made things much easier in 2.x and things
are much more consistent.
The issue with us moving to 2.x is that our application is in C# and is
based on hand rolled Managed C++ OSG 1.2 wrappers. I don't want to hand
update these wrappers as I feel this really adds an uneeded layer of
maintainance. Sadly, the osgDotNet project started off great, but still has
unresolved crashes that keep us from using it and it appears that
development has all but stopped on it. The recent discussions on the
mailing list about using C++/CLI directly with OSG by hesicong and others
seem extremely promising though.
Overall though, does the approach I'm suggesting with using the
UpdateCallback and the Hud Camera to get around my intersection problems
sound reasonable or am I overcomplicating things?
Thanks!
Jason
On Tue, Mar 18, 2008 at 12:03 PM, Robert Osfield [EMAIL PROTECTED]
wrote:
Hi Jason,
2.x is generally more consistent w.r.t use of doubles internally so
will tend to suffer less from precision issues. However, without
testing you exact setup I can't say whether these general improvements
will help with this specific problem you have.
W.r.t. porting from OSG-1.x to OSG-2.x, it might not actually be as
bad as you feel, in you are using osgUtil::SceneView you'll find the
majority of the OSG will just recompile with no changes. There is a
few changes in API that might catch you out, but substantially the OSG
is still the same scene graph.
The biggest change between OSG-1.x and OSG-2.x is the osgProducer
replaced by osgViewer and the new CMake build system, since you don't
use osgProducer then the build system is the biggest change. It is
however, a big improvement in terms of cross platform support, so
while a bit of learning curve is well worth it.
Robert.
On Tue, Mar 18, 2008 at 3:54 PM, Jason Beverage [EMAIL PROTECTED]
wrote:
Hi all,
I've written a 2D viewer that displays geospatial imagery in an
orthographic
projection using a WGS-1984 geodetic projection so the units are in
degrees.
I am placing text labels with their character size specified in
SCREEN_COORDS. When I zoom in very close, the quality of the text
starts to
suffer b/c the glyph quads are so small that they are losing precision
when
rendering. Placing a MatrixTransform above the text to position it
locally
reduces the visual problems but there are still some present.
The main problem I have is that the text cannot be selected if I zoom in
close. I can see the text fine, but clicking on it doesn't result in a
hit
b/c the intersections are all done using floats and the text glyphs are
extermely small because of the autosizing.
I found a potential solution using the latest version of OpenSceneGraph
which places the text in an orthographic HUD camera and positions it at
the
correct space on the earth using the callback at the end of this email.
Intersections work well and the text looks very crisp.
We are currently using OpenSceneGraph 1.2 and are rolling our own viewer
using SceneView and IntersectVisitor (NOT IntersectionVisitor) in our
application and cannot update this spiral due to time constraints.
IntersectVisitor does not seem to work correctly in picking items placed
in
a CameraNode in the 1.2 version.
Does anyone have any suggestions on how I could fix this issue using
OpenSceneGraph 1.2 and does the solution I found for using the latest
version of OSG make sense or I am missing something painfully obvious?
Thanks!
Jason
struct HudTextUpdateCallback : public osg::Drawable::UpdateCallback
{
public:
HudTextUpdateCallback(double lon, double lat, Viewer* viewer)
{
_viewer = viewer;
_lon = lon;
_lat = lat;
}
virtual void update(osg::NodeVisitor* nv, osg::Drawable* drawable)
{
Text* text = dynamic_castText*(drawable);
if (text)
{
CameraHelper h;
h.setCamera(_viewer-getCamera());
osg::Vec3 object(_lon,0,_lat);
osg::Vec3 window;
h.projectObjectIntoWindow(object, window);
text-setPosition(osg::Vec3(window.x(), window.y(), 0.0));
}
}
double _lon;
double _lat;
Viewer *_viewer;
};
___
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] Placing Text Labels in Geodetic Projection
On Tue, Mar 18, 2008 at 4:42 PM, Jason Beverage [EMAIL PROTECTED] wrote: Overall though, does the approach I'm suggesting with using the UpdateCallback and the Hud Camera to get around my intersection problems sound reasonable or am I overcomplicating things? It sounds like overcomplicating to me, the more complicated the more difficult it'll be to debug, and even harder for anyone else to be able to try and get their head around what you are doing. Given you are using an older version of the OSG it makes it a next to impossible task to support. OSG-1.2 does support double Matrices by default, so I would have though as MatrixTransform above the text labels would get you most of the way. You could try look for where the precision issue is arising and tweaking the OSG to use doubles to help out. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow example and gerneral question
On Tue, Mar 18, 2008 at 4:55 PM, Mathias Fröhlich [EMAIL PROTECTED] wrote: Move the inheritance mask from CullSettings to the camera. As you can see from your own suggestions abive the other users of the inheritance mask and CullSettings will just need a copy from its 'parent' settings. SceneView inherits from CullSettings as well osg::Camera, and the InheritinceMask is used as well. It's also require for backwards compatibility. CullSetting inheritance also is related to CullSettings variables, so the appropriate place is CullSettings. The only thing you gain by putting setInheritanceMask into osg::Camera is more visibility, but... you break encapsulation with it. Personally I find such a solution a poor OO choice. Initialize this mask in the camera to inherit all. This is what the previous implementation that ignored the mask completely did. You would preserve backwards compatibility with existing code with this. It does inherit all settings right now, and this is what has broken things, so the fix to CullVisitor::apply(Camera) is what has broken backwards compatibility. The status quo doesn't maintain backwards compatibility. The reader of the code would better understand what happens and you could implement what you told me for the first cut how it *should* work instead of something you need to dig for in the sources. I'm afraid I don't follow you. The current implementation does as things as it should, save for fact that honouring the InheriinaceMask is what has broken backwards compatibility. Well, I did not see that this past change brakes in the shadow thing, when I offered you codework for that old suggestion, but I saw that it will probably cause problems that would be better solved right. Also I expect every usage of a Camera being used in the wrong way since the inheritance mask has never worked in any way before our past change. The inheritanace mask did actually work correctly for the Viewer Camera's and SceneView, its only the in scene graph Camera's that were broken before and hence why the inheritance mask didn't work correctly in this case. I also think that a Camera that now makes use of the mask that was previously ignored will break much more of the compatibility than moving the mask to where it is used. The mask hasn't moved one bit for a long time. It's only CullVistor::apply(Camera) that has changed, and the inheritance of in scene graph cameras with it. Moving setInhertianceMask from CullSettings to osg::Camera doesn't solve any technical problems, and its certainly not clearer in terms of encapsulation. Also it is better to get a 'heads up there has something changed' from the compiler than just some subtle errors ... Still offering time to implement that ... I'm not sure what you could do on the front of breaking the build for old usage. While it'd be nice to let the compiler tell the user something is up, I think its impractical - one would be making changes not because they are needed but because they can give you a warning. If anything then a runtime warning might be possible. Robert. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] How to make multiple linear projection
Hi, I'm new in OpenSceneGraph and i wanna display multiple linear projection. I've looked at the example /osgdistortion --dome/, who's very interesting, but i didn't understand how to use it for my problem. My problem, is to display 3 linear projection on the screen of one scene |1|2|3| and to make some operations on the different projection. Is there somebody can help me please. Thanks Mickaël ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] More than one viewer
Ok, just change that line for:
viewer-setThreadingModel(osgViewer::Viewer::ThreadPerContext);
This is what I meant in the first place.
Hope it works.
2008/3/18, Wiedemann, Rudolf, OPS3 [EMAIL PROTECTED]:
Hi Nicolas,
I'm using the svn version of OSG (revision 7946).
When I add
viewer-setThreadingModel( osgViewer::ViewerBase::SingleThreaded );
to the example code below, some more of the frames are rendered, but not
all.
Rudi
--
*Von:* [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED] *Im Auftrag von *nicolas peña
*Gesendet:* Montag, 17. März 2008 21:24
*An:* OpenSceneGraph Users
*Betreff:* Re: [osg-users] More than one viewer
What version of OSG are you using?
What threading model? I had similar issues and setting the threading
model to one thread per context solved them.
Cheers,
Nicolas.
2008/3/17, Wiedemann, Rudolf, OPS3 [EMAIL PROTECTED]:
Hi,
I want to create a viewer, render some frames, then destroy the viewer
and create a second one etc (see code below/ zip-file).
The first viewer renders corectly, the second sometimes, too. But then I
get only black images.
Does someone has an idea what's going wrong?
Thanks in advance!
Rudi
#include iostream
#include osg/Referenced
#include osgDB/ReadFile
#include osgDB/WriteFile
#include osgViewer/Viewer
void render( unsigned int x, unsigned int y, unsigned int width,
unsigned int height, double posx )
{
osg::ref_ptr osgViewer::Viewer viewer = new osgViewer::Viewer;
viewer-setUpViewInWindow( x, y, width, height );
viewer-setSceneData( osgDB::readNodeFile( cow.osg ) );
viewer-getCamera()-setViewMatrixAsLookAt( osg::Vec3d( posx, -15.0,
0.0 ),
osg::Vec3d( 0.0, 0.0,
0.0 ),
osg::Vec3d( 0.0, 0.0,
1.0 ) );
viewer-frame();
sleep( 1 );
viewer = 0;
}
int main( int argc, char * argv[] )
{
double posx = 0.0;
osg::ref_ptr osgViewer::Viewer viewer;
for( unsigned int i = 0; i 4; i++ )
{
std::cout creating viewer #1 std::endl;
render( 10, 20, 500, 250, posx );
std::cout creating viewer #2 std::endl;
render( 600, 50, 112, 80, -posx );
posx += 5.0;
}
return 0;
}
___
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] A question about zooming with orthographic projection
Dear all, In the following post, Robert said that orthographic projection should be avoided. http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/7660/focus=7664 But I know that some OpenGL applications do use orthographic projection with zooming functionality. So I'm a little confused. Can any one give me some enlightenment? Thanks! Ke Li _ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] A question about zooming with orthographic projection
Hi Ke Li You can implement a zooming functionality with the camera function setProjectionMatrixAsOrtho(...) We also use a orthographic projection in 3d. And we implement our zoom with this nice function. I hope this will help... Have a nice evening! Daniel Moos Am 18.03.2008 um 19:55 schrieb Ke Li: Dear all, In the following post, Robert said that orthographic projection should be avoided. http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/7660/focus=7664 But I know that some OpenGL applications do use orthographic projection with zooming functionality. So I'm a little confused. Can any one give me some enlightenment? Thanks! Ke Li Connect and share in new ways with Windows Live. Get it now! ___ 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] osgNETDemo
AHA!!! I found out that the problems I was having are only on the RELEASE versions. When I link to the debug versions of the OSG libraries, all seems to work well. Anyone know why? -- Rick On 3/18/08, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I just used the latest stable build, OSG 2.2.0, and I got a crash at precisely the same point. I do not think it is a versioning problem. Looking at the call stack, I wonder if there is something I am doing wrong with setting up memory, either in the OSG build, or in the managed code that uses the unmanaged code. I am new to VS2005 (have been using VS2003 for a long time), but I just followed the existing instructions, and everything compiles. The call stack seems to have a problem with a dynamic cast: kernel32.dll!7c812a5b() [Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll] kernel32.dll!7c812a5b() ntdll.dll!7c9106eb() msvcr80.dll!malloc(unsigned int size=3765269347) Line 163 + 0x63 bytes C msvcr80.dll!_CxxThrowException(void * pExceptionObject=0x0012ea24, const _s__ThrowInfo * pThrowInfo=0x781b55e0) Line 161 C++ msvcr80.dll!__RTDynamicCast(void * inptr=0xcd010001, long VfDelta=0, void * SrcType=0x005cb25c, void * TargetType=0x005cc438, int isReference=0) Line 315 C++ osg25-osgViewer.dll!005a1516() osg25-osgViewer.dll!005a1a69() msvcr80.dll!operator new(unsigned int size=1) Line 59 + 0x8 bytes C++ osg25-osgViewer.dll!005aa741() osg25-osgViewer.dll!005a1bfd() osg25-osg.dll!1007d866() [Managed to Native Transition] osgNETDemo.exe!osgNETDemo::osgNETDemoForm::InitOSG() Line 65 + 0x18 bytes C++ osgNETDemo.exe!osgNETDemo::osgNETDemoForm::osgNETDemoForm_Load(System::Object^ sender = 0x0012ec40, System::EventArgs^ e = 0x0012ec4c) Line 330 C++ Thanks Again -- Rick On Tue, Mar 18, 2008 at 2:30 AM, hesicong2006 [EMAIL PROTECTED] wrote: I wrote the osgCppCLIDemo.rar. I use lastest OSG SVN version, you should try upgrade your OSG. [EMAIL PROTECTED] wrote: Hello All, I have been working with Phil Tessier on some work using OSG in a managed code environment. We tried using OsgDotNet, but we had some problems with that, and others on this list recommended we use C++/CLI directly to wrap just what we need form OSG directly, and there is an example provided on the language wrappers page (osgCppCLIDemo.rar). I was able to get that compiled, but it crashes with a __RTDynamicCast exception deep within osgViewer.dll. The last thing I can see in the call stack is in the InitOSG() function, in the line that uses osg::GraphicsContext::createGraphicsContext(traits.get()); The call stack looks funny to me, because it calls osg.dll, and then osgViewer.dll. I am using OSG version 2.0 (because it is compatible with OsgDotNet) and Visual Studio 2005. Perhaps I need to upgrade OSG? Thanks, -- Rick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Check us out at http://fringe-online.com/ -- Check us out at http://fringe-online.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Earth Model with height relief (BlueMarble)
Hi Norman, I haven't heard about gdal vrt yet, So I search it and try to understand. I try your advice and It works as you said :) Thanks so much your awesome help. And I want to ask you another question. I have a satellite data which I download from http://glcfapp.umiacs.umd.edu:8080/esdi/index.jsp . This data have four band. And I have all these band part. So I want to collect them in single tiff file. Which command I should use? I am new in using gdal utilities. Thanks. ÜMİT UZUN From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Date: Tue, 18 Mar 2008 13:17:43 -0400 Subject: Re: [osg-users] Earth Model with height relief (BlueMarble) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ümit uzun Sent: Tuesday, March 18, 2008 12:57 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Earth Model with height relief (BlueMarble) Hi Robert, I am so sorry for writing wrong command. Actually I used to -d parameter in ; //run the build.source osgdem -s build.source --whole-globe -d topo.tif -v 1000.0 -l 4 command.But I forgot typing this detail. I think my topo.tif hasn't georeference information in it. How can I get whole earth height relief data (for example as 10 km / pixel ) which has georefence information in it? Could you suggest me a web site? You need to add georeferencing to your topo.tif Probably easiest using GDAL's vrt format http://www.gdal.org/gdal_vrttut.html I think this will do it WGS84 -180,0.01,0,90,0,-0.01 nsform Gray topo.tif 1 Thanks for all your advice; ÜMİT UZUN Date: Tue, 18 Mar 2008 16:31:03 + From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Earth Model with height relief (BlueMarble) Hi Umit, Try add a -d in from of the DEM file. i.e osgdem -s build.source --whole-globe -d topo.tif For -l 4 you'll find that you want see an terrain. I'd also recommend using --terrain as the build is well over a hundred times faster. Robert. On Tue, Mar 18, 2008 at 4:11 PM, ümit uzun wrote: Hi All. I try to make earth model with height relief. I am using this command on Ubuntu 7.10, OpenSceneGraph Library 2.3.4 and VirtualPlanetBuilder/osgdem 0.9.5 ; // Create the build.source file osgdem --bluemarble-west -t ../land_shallow_topo_west.tif \ --bluemarble-east -t ../land_shallow_topo_east.tif \ --geocentric \ -o earth/earth.ive \ --so build.source //creating whole earth elevation data subroutines I download srtm_ramp2.world.21600x10800.jpg from http://visibleearth.nasa.gov/view_detail.php?id=8391 web site. Then I use gdal utility commands; //traslating jpg to geotiff gdal_translate srtm_ramp2.world.21600x10800.jpg topo.tif //adding overview to topo.tif gdaladdo -r average topo.tif 2 4 8 16 32 64 128 //run the build.source osgdem -s build.source --whole-globe topo.tif -v 1000.0 -l 4 But when the process finished I see a globe which is not expected. The height relief and the earth lands surface can't overlap on same coordinate place. what can I do for to create original earth model with height relief. ÜMİT UZUN _ Windows Live Messenger'ın için Ücretsiz 30 İfadeyi yükle http://get.live.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org _ Yeni nesil Windows Live Servisleri'ne şimdi ulaşın! http://get.live.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _ Yeni nesil Windows Live Servisleri’ne şimdi ulaşın! http://get.live.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow example and gerneral question
Thanks for the changes, W.r.t. question you asked earlier I would vote for option #3. Ie: CullSettings::setComputeNearFarMode( mode, bool disableInheritance=true); CullSettings::setCullMask( mode, bool disableInheritance=true); et cetera. I remember I had once a problem with not working setCullMask. It turned out I changed setCullMask but it was ignored because inheritance mask was not set properly. Option #3 would make a life easier in such cases. So I think that solution where cull settings variable setters modify appropriate inheritance flags is actually quite reasonable from usage perspective. If you want to make inheritance masks modification more explicit for users just add second bool parameter without default initialization - this will force compiler error for users code and will annoy some of them but certainly will make community aware of the shift in inheritance policy ;-). On a side note: it would be good to ask this question again in separate post with more appropriate subject. I suppose lots of interested users who don't read every forum email might have skipped it. Cheers, Wojtek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Robert Osfield Sent: Tuesday, March 18, 2008 7:29 PM To: OpenSceneGraph Users Subject: Re: [osg-users] osgShadow example and gerneral question A little update. To get osgShadow back working again I've applied a tempory fix to ShadowMap, ParallelSplitShadowMap and SoftShadowMap such that the setCullInheritance(0x0) is used. Applying this same change to ShadowTexture broke it so I've commented this change out. These changes are now checked in. I don't think these changes are perfect, and they don't solve the other places in the OSG or in user code that might not have the InheritanceMask set appropriately. My current inclination is to change CullSettings so that it when you set variables the associated mask bit is disabled, this behaviour is something that would have to be optional, even it were on by default. My guess is that would give us as close to the original behavior without breaking the rules of inheritince. Robert. ___ 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] osgviewer panel with buttons
Hello, I am playing around with osgWidget which is pretty cool... What I am trying to do is a panel with buttons, maybe you can point me to the right direction J I tried BOX as panel and LABELS as buttons , but I guess BOX just groups the widgets and is only as big as widgets it holds... LABELS as buttons are fine. Then I tried Table class but it cant be placed in a Box. So yes I am a little confused about that Thanks Sergey ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with using IntersectionVisitor to obtain the viewing matrices
Hi Robert,
Please don't bother about my email below. I think I've found the mistake in my
code.
Thanks, and regards,
Ke Li
From: [EMAIL PROTECTED]: [EMAIL PROTECTED]: Tue, 18 Mar 2008 11:44:10
-0700Subject: Re: [osg-users] Problem with using IntersectionVisitor to obtain
the viewing matrices
Hi Robert, Thanks for your reply. What I'm trying to do is to map window
coordinates to object coordinates, but I got incorrect results using the
matrices given by viewer.getCamera().getViewport().computeWindowMatrix(),
viewer.getCamera().getProjectionMatrix() and
viewer.getCamera().getViewMatrix(). So I referred to the OSG source code and
tried the code in my initial email. I didn't know about the matrix stack
methods then. After obtaining the mapped object coordinates, I need to
construct a ray from the viewer's position. The position and the ray then can
be used to create a mouse picking line segment. My code is like this: protected
unsafe bool pick(OsgGA.GUIEventAdapter ea, OsgViewer.Viewer
viewer){..Osg.Matrix VPW = new Matrix();Osg.Matrix inverseVPW = new
Matrix();Vec3d windowPositionStart = new Vec3d((double)(ea.getXnormalized()),
(double)(ea.getYnormalized()), -1.0d);Vec3d windowPositionEnd = new
Vec3d((double)(ea.getXnormalized()), (double)(ea.getYnormalized()), 1.0d);Vec3d
worldPositionStart = new Vec3d();Vec3d worldPositionEnd = new Vec3d();
VPW.preMult(viewer.getCamera().getProjectionMatrix());VPW.preMult(viewer.getCamera().getViewMatrix());
inverseVPW = Osg.Matrix.inverse(VPW);worldPositionStart = windowPositionStart
* inverseVPW;worldPositionEnd = windowPositionEnd * inverseVPW; Vec3d ray1 =
new Vec3d(worldPositionEnd[0]-worldPositionStart[0],
worldPositionEnd[1]-worldPositionStart[1],
worldPositionEnd[2]-worldPositionStart[2]);ray1.normalize(); Vec3 eye = new
Vec3();Vec3 center = new Vec3();Vec3 up = new
Vec3();viewer.getCamera().getViewMatrixAsLookAt(ref eye, ref center,ref up);
Vec3d ray2 = new Vec3d(eye[0]-worldPositionStart[0],
eye[1]-worldPositionStart[1],
eye[2]-worldPositionStart[2]);ray2.normalize();} results: 1. ray1 always
equals {0.0, 0.0, 1.0} after any zooming, rotating, and panning;2. ray2 remains
almost the same after any zooming, rotating, and panning;3. worldPositionStart
looks like the mapping of the screen position. Since I'm using perspective
projection, worldPositionStart and worldPositionEnd are slightly different.
questions:1. why ray1 remains constant?2. is ray2 what I need in this case?3.
is the near clipping plane at z=-1.0 in OSG? I know what I'm trying to do is
kind of simple, but I have been struggling for a while and cannot get the
correct results yet. Thanks, and regards, Ke Li
Date: Sat, 15 Mar 2008 10:19:05 + From: [EMAIL PROTECTED] To:
osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Problem with
using IntersectionVisitor to obtain the viewing matrices Hi Ke Li, I'm
confused by your code and what you are trying to do. The matrix stack
methods in IntersectionVisitor are there for internal usage during the
traversal of the scene graph, as the traversal goes down matrices are pushed
on the respective stacks, and on the return up these matrices are popped.
Once the traversal is complete the stacks will be empty unless you've pushed
ones on yourself. So the quesition still has to be what are you trying to
do? What do you need the matrices for? Robert. On Fri, Mar 14, 2008
at 9:31 PM, Ke Li [EMAIL PROTECTED] wrote: Dear all, I'm trying
to obtain the model matrix, the view matrix, the projection matrix and the
window matrix. I used the following piece of code in my pick event
handler. protected unsafe bool pick(OsgGA.GUIEventAdapter ea,
OsgViewer.Viewer viewer) { .. picker = new
OsgUtil.LineSegmentIntersector(OsgUtil.Intersector.CoordinateFrame.PROJECTION,
ea.getXnormalized(), ea.getYnormalized()); OsgUtil.IntersectionVisitor
iv = new OsgUtil.IntersectionVisitor(picker);
viewer.getCamera().accept(iv); Osg.Matrix VPW = new Matrix(); if
(iv.getWindowMatrix()!=null) { Osg.Matrix mm = new
Osg.Matrix(iv.getWindowMatrix().ptr()); VPW.preMult(mm); } if
(iv.getProjectionMatrix() != null) { Osg.Matrix mm = new
Osg.Matrix(iv.getProjectionMatrix().ptr()); VPW.preMult(mm); } if
(iv.getViewMatrix() != null) { Osg.Matrix mm = new
Osg.Matrix(iv.getViewMatrix().ptr()); VPW.preMult(mm); } if
(iv.getModelMatrix() != null) { Osg.Matrix mm = new
Osg.Matrix(iv.getModelMatrix().ptr()); VPW.preMult(mm); } ..
} But the iv object could never return any matrix and all the Boolean
expression in the if statement always equal to false. I'm wondering
what is wrong here. Is there any thing else that I need to do before I can
obtain the matrices? Any help is appreciated! Regards, Ke
Li Connect and share in new
ways with Windows Live. Get it now!
Re: [osg-users] osgShadow example and gerneral question
I think #3 is a good option, but I would like to suggest using an interface similar to that used for state attributes. I.e. use an enumeration for the possible values instead of a bool, even if only two values are needed initially. Having a more uniform interface for handling inheritance in the scene graph will lessen the learning curve. On Mar 18, 9:27 am, Robert Osfield [EMAIL PROTECTED] wrote: The solutions I can think of right now are: 1) Change have the CullSetting::InhertacenMask default to 0x0 and have all Viewer code to related Camera's and SceneView to explicitly set the InheritanceMask to ALL_VARIABLES 2) Leave CullSetting::InheritanceMask as ALL_VARIABLE default, and change all RTT/in scene graph Cameras to explictly disable the InhertianceMask they do not need. 3) Leave CullSetting::InheritanceMask as ALL_VARIABLE default and have the CullSettings::setVariable() calls all optional disable the associated part of the InhertianceMask to off. This disabling would be done by default. i.e CullSettings::setComputeNearFarMode(mode, bool disableInhertianceOfComputeNearFarMode=true); I think option 3 would probably give us reasonable backwards compatibility, but... it would hide a bit of what is going on w.r.t InheritanceMask and be inconstistent with the way the rest of the OSG works w.r.t set/get methods. Can anyone else think of any other options? Robert. ___ osg-users mailing list [EMAIL PROTECTED]://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph... ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Debug JPEG plugin issues
Hi Mike -- FYI, I recently discovered the same issue with FreeType235_d.lib. The OSG freetype plugin won't load when linked with this library, but works fine when linked with freetype235.lib. Thanks, -Paul -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Weiblen Sent: Monday, March 17, 2008 10:19 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Debug JPEG plugin issues Hi, As Paul mentioned, we hooked up and discussed some of the issues. I'll be doing a scrub of my 3rdParty stuff RSN. cheers -- mew On Fri, March 14, 2008 12:04, Paul Martz wrote: For some time now, I've been unable to load the Debug JPEG plugin osgdb_jpegd.dll. The Release build works just fine. Because I'm on Windows, I had assumed this was some runtime library / PATH issue Today, this finally bugged me enough to investigate it. I looked at osgdb_jpegd.dll the old depends.exe (from VC6 days) and it doesn't indicate any problems. And indeed it turns out it's not a DLL issue, apparently. It seems to be a problem with the 3rdparty binary libjpegD.lib. If I have the CMake variable JPEG_LIBRARY_DEBUG set to libjpegD.lib, then the resulting Debug JPEG plugin refuses to load. On the other hand, with JPEG_LIBRARY_DEBUG set to libjpeg.lib, the Debug JPEG plugin loads and runs just fine. As luck would have it, Mike Weiblen and I are having breakfast tomorrow, so I'll ask him if he knows anything about why this would be happening. Just wanted to post this here in case others are encountering the same issue. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com http://www.skew-matrix.com/ 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. org Mike Weiblen -- Austin Texas USA -- http://mew.cx/ ___ 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] A question about zooming with orthographicprojection
Agreed; this works. In perspective, you zoom bu changing the field of view; in ortho you can achieve the same zoom effect by altering the left/right/bottom/top to display a larger/smaller view volume. -Paul _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Moos Sent: Tuesday, March 18, 2008 1:06 PM To: OpenSceneGraph Users Subject: Re: [osg-users] A question about zooming with orthographicprojection Hi Ke Li You can implement a zooming functionality with the camera function setProjectionMatrixAsOrtho(...) We also use a orthographic projection in 3d. And we implement our zoom with this nice function. I hope this will help... Have a nice evening! Daniel Moos Am 18.03.2008 um 19:55 schrieb Ke Li: Dear all, In the following post, Robert said that orthographic projection should be avoided. http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/7660/focus=7 664 But I know that some OpenGL applications do use orthographic projection with zooming functionality. So I'm a little confused. Can any one give me some enlightenment? Thanks! Ke Li _ Connect and share in new ways with Windows Live. Get it now! http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008 ___ 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] hello,I have a problem.
Hi, I want to write a class from osg::Drawable::UpdateCallback to update a
Geometry call named geom,but there is no update happen.I dot't know what's
wrong.Does someone knows?Thanks in advance!NiuHeming
class niuhm : public osg::Drawable::UpdateCallback{public:
niuhm(const osg::Vec3 v11,const osg::Vec3 v22,const osg::Vec3 v33)
{v1=v11;v2=v22; v2=v33;
bs.radius()*=1.5f;
bs=osg::BoundingSphere(osg::Vec3(0.0f,0.0f,0.0f),4.0f);
bb.expandBy(bs);}virtual void update(osg::NodeVisitor* nv,
osg::Drawable* node){osg::Geometry* geom =
dynamic_castosg::Geometry*(node);const osg::FrameStamp*
frameStamp = nv-getFrameStamp();if (geom frameStamp)
{
osg::PositionAttitudeTransform* mt = new
osg::PositionAttitudeTransform(); { // set
up the animation path osg::AnimationPath* animationPath =
new osg::AnimationPath;
animationPath-insert(0.0,osg::AnimationPath::ControlPoint(bb.corner(0)));
animationPath-insert(1.0,osg::AnimationPath::ControlPoint(bb.corner(1)));
animationPath-insert(2.0,osg::AnimationPath::ControlPoint(bb.corner(2)));
animationPath-insert(3.0,osg::AnimationPath::ControlPoint(bb.corner(3)));
animationPath-insert(4.0,osg::AnimationPath::ControlPoint(bb.corner(0)));
animationPath-setLoopMode(osg::AnimationPath::SWING);
mt-setUpdateCallback(new
osg::AnimationPathCallback(animationPath)); }
// create marker for point light.
osg::Vec3 vertices = mt-getPosition();
unsigned int noXSteps = 100;
unsigned int noYSteps = 100; osg::Vec3Array* coords =
new osg::Vec3Array; coords-reserve(noXSteps*noYSteps);
osg::Vec3 dx = (v2-v1)/((float)noXSteps-1.0f);
osg::Vec3 dy = (v3-v1)/((float)noYSteps-1.0f);
unsigned int rowvertices;
unsigned int colvertices;rowvertices=(unsigned
int)((vertices._v[0])/(dx._v[0]));
colvertices=(unsigned int)((vertices._v[1])/(dy._v[1]));
unsigned int row; osg::Vec3 vRowStart = v1;
for(row=0;rownoYSteps;++row){
osg::Vec3 v = vRowStart;for(unsigned int
col=0;colnoXSteps;++col){ if
((row==rowvertices)(col==colvertices))
coords-push_back(v+osg::Vec3(0.0f,0.0f,-1.0f));
else coords-push_back(v);
v += dx; }
vRowStart+=dy;}
geom-setVertexArray(coords); } }
osg::Vec3 v1; osg::Vec3 v2; osg::Vec3 v3;
osg::BoundingSphere bs;osg::BoundingBox bb;
};
_
MSN圣诞礼物火热登场，免费发放中，快来领取吧！
http://im.live.cn/emoticons/?ID=18___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg-conv collada
could someone please tell me how to create the collada db so osgconv can load collada files? i can't find any documentation on this. thanks On Mon, Mar 17, 2008 at 10:14 AM, skunkwerk [EMAIL PROTECTED] wrote: hi Robert, i can install the collada dom, but how do I build the osg plugin for it? is there documentation for building it somewhere? thanks, imran HI, Have you installed the COLLADA DOM, and built the appropriate OSG plugin? Robert. On Sun, Mar 16, 2008 at 12:46 AM, skunkwerk [EMAIL PROTECTED] wrote: i'm new to openscenegraph. i tried to use osgconv to open/save a collada file, but couldn't find the correct osgdb for .dae files to allow it to work. any suggestions? is all i have to do to generate a texture atlas for the file, to do this from my command line: export OSG_OPTIMIZER=DEFAULT TEXTURE_ATLAS_BUILDER thanks ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg-conv collada
skunkwerk wrote: could someone please tell me how to create the collada db so osgconv can load collada files? i can't find any documentation on this. If you installed the COLLADA DOM, you should just need to make sure CMake can find it (run ccmake . again and specify the path, if necessary) and then re-make OSG. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
