Hi,
I reverted the y axis by adjusting the camera projection matrix:
Code:
camera->setProjectionMatrixAsPerspective(30.0f,
static_cast(traits->width) / static_cast(traits->height), 1.0f,
1.0f);
auto originalProjection = camera->getProjectionMatrix();
osg::Matrixd reverseYMat;
Yes I guess we could do via an EventHandler (which we have done for other
things interested in events) except all our various extended 'camera
manipulators' are added (i.e. set active) via the
View::setCameraManipulator(osgGA::CameraManipulator*) ... so sticking to the
pattern this particular
HI Nick,
The svn/trunk and recent dev releases of the OSG have a
CameraManipulator::updateCamera(osg::Camera) method that allows you to set
any properties you want on the View's Camera rather than pulling the view
matrix as was done previously.
The other bit of the jigsaw for you specific
Excellent, the new updateCamera() method on the trunk sounds exactly what we
need ! :)
We are on osg 3.0.1 so for now, so until we update to the latest, I've just put
in our work around which connects our active manipulator to the camera's update
callback and that seems to work ok.
Also just
Hi Nick,
On 19 July 2013 00:08, Nick McEvoy nmc...@gmail.com wrote:
Excellent, the new updateCamera() method on the trunk sounds exactly what
we need ! :)
We are on osg 3.0.1 so for now, so until we update to the latest, I've
just put in our work around which connects our active manipulator
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Nick,
On 07/17/2013 03:56 AM, Nick McEvoy wrote:
I'm writing a camera manipulator but have an issue where I need the
manipulator to be visited during the update traversal ( after the
scene graph has been updated). Without going into too much
I'm writing a camera manipulator but have an issue where I need the manipulator
to be visited during the update traversal ( after the scene graph has been
updated). Without going into too much detail ... the basic reason I require
this is ... that my manipulator needs to set the orthographic
Hi Judson,
On 29 May 2013 15:01, Judson Weissert jud...@mfrac.com wrote:
My fault, I performed an invalid test. My osgviewer.cpp source was modified,
and I did not realize it. It was still overriding checkNeedToDoFrame(). I
retested, and it appears to be working as expected.
Sorry about
Hi Judson,
On 28 May 2013 20:36, Judson Weissert jud...@mfrac.com wrote:
I just got the 3.1.7 developer release built. Running the osgviewer
application with arguments --run-on-demand --screen 1 dumptruck.osgt
results in a regression where the viewer does not respond to mouse or
keyboard
Robert,
My fault, I performed an invalid test. My osgviewer.cpp source was
modified, and I did not realize it. It was still overriding
checkNeedToDoFrame(). I retested, and it appears to be working as expected.
Sorry about that.
I will continue testing and report back my findings if I find
Robert,
This is great news! I will try out the new code as soon as possible and
report back my findings.
Thanks,
Judson
On 5/24/2013 5:42 AM, Robert Osfield wrote:
Hi Judson.
I have refactored the Viewer/CompositeViewer::checkNeedToDo() method
so that it now calls a new
Hi Robert,
I just got the 3.1.7 developer release built. Running the osgviewer
application with arguments --run-on-demand --screen 1 dumptruck.osgt
results in a regression where the viewer does not respond to mouse or
keyboard input (does not render any new frames, does not allow me to
exit
Hi Judson,
On 23 May 2013 21:57, Judson Weissert jud...@mfrac.com wrote:
I just realized that the modification to osgViewer::Viewer is not actually
required to reproduce the problem in the osgviewer application since there
are no update callbacks installed anyway. Originally, I could not get
Hi Judson.
I have refactored the Viewer/CompositeViewer::checkNeedToDo() method
so that it now calls a new Viewer/CompositeViewer::checkEvents()
method that checks for available events rather than rely upon the more
heavier weight eventTraversals() method.
The eventTraversals() method design is
Hi Judson,
Great detective work. The change to the frame() was done to avoid
issues with events being given times that aren't in sequence -
previously we'd get time delta's that could be negative.
Do you have an idea of how to reproduce the problem now? Once I can
reproduce it I'll be able to
Robert,
I figured out why my case diverges from the osgviewer application. I
override osgViewer::Viewer::checkNeedToDoFrame(), member function, and
call eventTraversal() on a code path where it would otherwise not be
called. Specifically, I don't want the default behavior where a new
frame
Thanks for the code reproducing the problem, I'm just turning in for
the day so will have a look at trying to reproduce the issue tomorrow.
On 23 May 2013 18:32, Judson Weissert jud...@mfrac.com wrote:
Robert,
I figured out why my case diverges from the osgviewer application. I
override
Thanks Robert.
I just realized that the modification to osgViewer::Viewer is not
actually required to reproduce the problem in the osgviewer application
since there are no update callbacks installed anyway. Originally, I
could not get the behavior to happen in the unmodified osgviewer
Hello,
I have recently upgraded to the 3.1.6 development release of the OSG
library (from 3.1.2) and encountered some behavior changes when
manipulating a model using the Trackball Manipulator (I did derive from
it though and modify some non-mouse related
features).
Compiled by VS2010,
HI Judson,
I have done a refactor of osgViewer's internally handling of mouse
events to allow for seamless handling of distortion correction set
ups, there is chance that this might have broken something that I
haven't yet observed in my own testing. Other than this there hasn't
been any changes
Robert,
On 5/22/2013 10:23 AM, Robert Osfield wrote:
HI Judson,
I have done a refactor of osgViewer's internally handling of mouse
events to allow for seamless handling of distortion correction set
ups, there is chance that this might have broken something that I
haven't yet observed in my own
Robert,
The viewer I am running has ON_DEMAND frame updates. When I remove the line
viewer-setRunFrameScheme (osgViewer::ViewerBase::ON_DEMAND);
the disappearing geometry behavior goes away. However, I was not able to
replicate the problem by applying ON_DEMAND frame updating to the
Hi Judson,
It's a curious set of circumstances but as yet I can't think of a
specific cause.
Is there any chance you can create a small example that illustrates
the problem so that I can try it out and see if I can spot the
problems.
Cheers,
Robert.
On 22 May 2013 18:31, Judson Weissert
Robert,
I have made some progress. The problem appears to be caused by an
eventTimeDelta of zero which is calculated within
StandardManipulator::performMovement(). It eventually results in a
divide by zero and the propagation of non-finite value(s) through the
remainder of the call chain.
Robert,
I found the revision that caused the regression. Ironically, it occurred
way before the 3.1.6 release...
See r13092 associated with
http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk/src/osgViewer/Viewer.cpp
The 3.1.2 behavior returned when I reverted that revision. A notable
Hi,
Is there an easy way to invert the wheel zoom factor on
TrackballCameraManipulator? I have a feeling that once I've seen a property
where you can set this, and if you set it to -1, the zoom scrolling will behave
opposite.
I have a cameraManipulator derived from TrackballCam..Man.. the
I am sorry about the useless topic.
I was searching the property on a wrong object
manipulator-setWheelZoomFactor()
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=53189#53189
___
osg-users
Hi Peterakos,
There isn't any way a third party will be able to diagnose the problem
with your code with such a tiny extract of code. The best I can
suggest is develop your own skills of hunting down and fixing bugs.
Using a debug to see the flow of control, or add debug message that
output
Hello.
I try to make my own camera manipulator in which the push events with
X lower than the half of the window will be ignored.
I created a class, which derives trackball manipulator.
Here is the handle method
virtual bool handle( const osgGA::GUIEventAdapter ea,
osgGA::GUIActionAdapter us )
You can find it from the settings.
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=49674#49674
___
osg-users mailing list
osg-users@lists.openscenegraph.org
On 8/27/2012 3:14 PM, Jeremy Moles wrote:
A Drawable can have a special ComputeBoundsCallback() (something like
that, I'm on my phone right now and can't look it up), so you could use
that as well...
Here is the code I came up with after your suggestion that does resolve
my problem (I attach
Hello,
I was hoping someone could help me with a camera manipulator/scaling
problem that I have been having.
I have a scene graph that contains geometry representing a hydraulic
fracture. The fracture length is of the order 1000ft, the height is of
the order 100ft, and the width is of the order
On Mon, 2012-08-27 at 13:54 -0400, Judson Weissert wrote:
Hello,
I was hoping someone could help me with a camera manipulator/scaling
problem that I have been having.
I have a scene graph that contains geometry representing a hydraulic
fracture. The fracture length is of the order 1000ft,
On Mon, 2012-08-27 at 15:12 -0400, Judson Weissert wrote:
On 8/27/2012 2:22 PM, Jeremy Moles wrote:
On Mon, 2012-08-27 at 13:54 -0400, Judson Weissert wrote:
Hello,
I was hoping someone could help me with a camera manipulator/scaling
problem that I have been having.
I have a scene
On 8/27/2012 2:22 PM, Jeremy Moles wrote:
On Mon, 2012-08-27 at 13:54 -0400, Judson Weissert wrote:
Hello,
I was hoping someone could help me with a camera manipulator/scaling
problem that I have been having.
I have a scene graph that contains geometry representing a hydraulic
fracture.
Hi Robert,
I agree that the Camera as an argument makes more sense.
Thanks for merging the submission.
Cheers,
Ricky
On Mon, Jul 9, 2012 at 7:38 PM, Robert Osfield robert.osfi...@gmail.comwrote:
Hi Riccardo,
On review of the submission I've decided that passing in a Camera
rather than a
Hi Riccardo,
Sorry for the very long delay in getting to review your suggested
changes, I've now done the review and the changes look good, the only
amendment I made to rename the parameter name Camera* pCamera to
Camera* camera as from the context it's obvious that camera is a
Camera* one
Hi Riccardo,
On review of the submission I've decided that passing in a Camera
rather than a pointer would make it clear that a valid Camera object
should be passed in rather than a pointer which could be NULL or
pointing to a valid Camera object. This brings the method more into
line with how
Hi Robert and All,
I just wanted to know if the proposal I made some weeks ago doesn't seem to
fit some requirements,
or simply passed unnoticed.
Thank you,
Ricky
On Wed, Mar 14, 2012 at 15:42, Riccardo Corsi riccardo.co...@kairos3d.itwrote:
Hi all,
sorry that it took long to setup the
Hi Riccardo,
On 5 April 2012 11:37, Riccardo Corsi riccardo.co...@kairos3d.it wrote:
I just wanted to know if the proposal I made some weeks ago doesn't seem to
fit some requirements,
or simply passed unnoticed.
I'm afraid I haven't had a chance to review it yet.
Robert.
Hello -
I am attempting to use the output from an attitude heading reference
system to orient the Camera over some terrain which I created using the
National Elevation Dataset and VirtualPlanetBuilder. When I view the
terrain database using osgviewer, I see everything as I expect.
Hi Riccardo,
The current osgGA::CameraManipulator's are a bit of mess, the way they
just control the view matrix is one of their flaws. I merged a set of
sweeping changes from Jan Perciva back in May 2010 that added a new
inheritance hierarchy and more features, but in hindsight I feels
these
Hi Robert,
I totally agree on the general approach.
Still, if you want to go for the change on the osgGA::CameraManipulator
base class as a first step,
I'd be glad to help with that.
Ricky
On Tue, Mar 6, 2012 at 11:44, Robert Osfield robert.osfi...@gmail.comwrote:
Hi Riccardo,
The current
HI Ricky,
On 6 March 2012 14:36, Riccardo Corsi riccardo.co...@kairos3d.it wrote:
I totally agree on the general approach.
Still, if you want to go for the change on the osgGA::CameraManipulator
base class as a first step,
I'd be glad to help with that.
Why not have a bash at modifying
Hi Robert and All,
in more than one occasion I've noticed that having access to the camera
manipulator in use is not enough to have full control over the camera
motion handling.
An example is if you want to temporary disable the manip to set the camera
position explicitly (in this case you need
Ted Morris writes:
Hi,
I need to set an initial viewpoint of my camera manipulators with respect to
the local coordinate system of the object. What is the best way to go about
that?
Hi Ted,
I think that osg::Node::getWorldMatrices and
osgGA::MatrixManipulator::setHomePosition can help
Hi,
I need to set an initial viewpoint of my camera manipulators with respect to
the local coordinate system of the object. What is the best way to go about
that?
Thanks!
T
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=26694#26694
Greetings,
I'm running into a little snag here.
I utilized the CameraNodeFollower Camera Manipulator as presented in the
NPS tutorial. For all who don't know it basically attaches a node with a
NodeCallback that
obtains the current NodePath of the parent, and multiplies its own offset
from the
Greetings all,
I'm using the CameraManipulator from the NPS 11.x tutorial to follow a
MatrixTransform
object. The MatrixTransform position/orientation per usual with an Node
UpdateCallback.
The manipulator simply attaches a node to the MatrixTransform node
with a callback which grabs the parent
Hola,
Let me ask it another way.
I'm in a fragment shader.
I have the vec4 gl_FragCoord.
I do:
Code:
vec3 windowcoord = vec3(gl_FragCoord.xy, 1.0);
vec3 clipcoord = viewportMatrixInverse * windowcoord;
vec4 eyecoord = gl_ProjectionMatrixInverse * vec4(clipcoord, 1.0);
eyecoord = eyecoord /
Hi,
Really quick question.
In a shader I get back a gl_FragCoord.
I use it to try getting back in world space. I did it several ways and I really
have the impression that piece of code:
Code:
ref_ptr osgGA::MatrixManipulator cammanipulator = new
osgGA::TrackballManipulator();
Hello forum,
I am going through the example osgimpostor to get the idea of how the
quaternion camera is implemented there.
The camera manipulator has been derived from the MatrixManipulator class and
one of the function that has been over-ridden is
setNode();
I would like to find out when
Hi, Sajjad
El Martes 07 Abril 2009ES 10:57:01 ami guru escribió:
Hello forum,
I am going through the example osgimpostor to get the idea of how the
quaternion camera is implemented there.
The camera manipulator has been derived from the MatrixManipulator class
and one of the function that
Hello Sajjad,
I would like to find out when that particular function is called and who
is calling that. I am definite that it is called, but could not find out
who is calling that(some function in another class probably ).
Basic debugging technique: Run the code in the debugger, put a
54 matches
Mail list logo
