Re: [osg-users] osgText: font aliasing issue
Hi Bruno, The clue to the solution is in the line: Label.get()-setFontResolution(40,40); FontResolution What you should aim for is for the FontResolution to be roughly the same as the number of pixels in size that you text will be on screen. So if you have been characters then use big font resolution. Don't put it too high though as it'll consume quite a bit of texture memory. Robert. On 2/6/07, Bruno Fanini [EMAIL PROTECTED] wrote: Hi all, In my app, I'm using osgText::Text for creating labels. Now code looks something like this: osg::ref_ptrosgText::Text Label = new osgText::Text; Label.get()-setText(label); Label.get()-setFontResolution(40,40); // etc, just like osgText example They are added as drawables into a single Geode, wich stateset looks like that: osg::ref_ptrStateSet labelSS = new StateSet; labelSS.get()-setMode(GL_LIGHTING,osg::StateAttribute::OFF); labelSS.get()-setMode(GL_FOG,osg::StateAttribute::OFF); Scene is handled by a normal osgUtil::SceneView. The problem is that label fonts are blocky and not antialiased. osgText sample is perfectly antialiased, is there any hidden option or flag to set up? Attached screenshot of my application with blocky fonts and osgText smoothly rendered... Thanks for help, -- Bruno ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] osgText: font aliasing issue
On 2/6/07, Robert Osfield [EMAIL PROTECTED] wrote: Hi Bruno, The clue to the solution is in the line: Label.get()-setFontResolution(40,40); Forgot to mention, ref_ptr is a smart pointer, you can often treat it just like a normal C pointer so the above doesn't need the get() to return a C pointer, the following works just fine: label-setFontResolution(40,40); Robert ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Does thee OpenThreads license conflict with the OSG license?
On 2/5/07, Robert Osfield [EMAIL PROTECTED] wrote: Sean has given me the go ahead to update the license entries to OSGPL/WxWindows license. I'll make these changes in the CVS version of OpenThreads tonight. Ack, another late night :-| This change is now made and checked in to OpenThreads CVS. Please check :-) ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Does thee OpenThreads license conflict with the OSG license?
On 2/6/07, Brede Johansen [EMAIL PROTECTED] wrote: Hi Robert, While you're at it, could you add the OSGPL license to the new OpenFlight loader too? I gave the green light some time ago and assumed the license would appear in the source, like magic ;-). I can do that. The copyright owner should be the one make the change though :-) Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] Names for different threading models
Hi All, Last week I introduced a new threading model in osgViewer::Viewer that allowed the draw thread to run in its own graphics thread, with the cull running in a parallel with this. The implementation last week had the cull running as part of the main thread, but I called it ThreadPerCamera last week as I had plans to make the cull run with its own thread too. Over the weekend, yesterday I wired up the the threading of cull and hoped to get further gains in performance on my dual core/dual GPU system beyond what having cull in the main thread achieved last week. Alas what I have found is that the poor dual core CPU can't manage 5 threads running at the same time all doing stuff required for each frame, the consequence is that things run in series anyway, and not as efficiently as the old ThreadPerContext or just having the main thread do both Camera's culls. This isn't too surprising a finding given I only have two cores. This threading model is clearly waiting for a machine capable of taking full advantage of it, a quad core system is required, AMD/Intel??? Care to send me one :-) Ok so a the above is a bit of background. Now I have fleshed out the implementation of the various threading models I now want to consolidate this work it something end users can use and understand. There are four current threading models now on the table: 1) Main thread does the whole frame, event, update, cull and draw. You'll be familiar with this as SingleThread, both in osgProducer and osgViewer. 2) Main thread does event, update, while a cull-draw pair runs on each context. This mode was called ThreadPerContext in osgViewer, and was effectively ThreadPerCamera in osgProducer/Producer (when one camera per context existed). 3) Main thread does event, update and all camera culls, while draw run on each context. The is the new mode I introduced last week, I called this ThreadPerCamera, but it isn't really as cull wasn't yet threaded. 4) Main thread does event, update, one of the camera and the rest of the camera culls run on a seperate camera thread, and the draws run on separate graphics thread per context. This was where I was heading last week, and now implemented, so is proper ThreadPerCamera (plus ThreadPerContext). Now the names are all getting a bit mixed up, all the extra options for threading have thrown up the need to clearly discriminate between them, and make each model clear as to what it does. My best naming I've come up with so far for the above 4 thread options is: 1) SingleThreaded - this is an easy one ;-) 2) RenderingThreadPerContext or CullDrawThreadPerContext 3) DrawThreadPerContext 4) CullThreadPerCameraDrawThreadPerContext Does this make sense given the above? Is an long winded name for option 4 sensible? Also on the table is an AutomaticSelection option that defers the choice to the realize() implementation to choose what threading model is most appropriate given the hardware and camera/graphics windows setup. Any better suggestions? Which of option 2 works better for you? Thanks, Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] Location for half-float conversions
Dear Robert, I'm doing a fair amount of image manipulation work on RGB8, RGB16F and RGB32F images at the moment. The only tricky one to work with is the 16F, as I need half to float conversions (and backwards). Does this conversion exist already in OSG? If not, and I were to submit it, where would you want it to live - in osg/Math, or osg/Image? Thanks, David ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Location for half-float conversions
Hi David, On 2/6/07, David Spilling [EMAIL PROTECTED] wrote: I'm doing a fair amount of image manipulation work on RGB8, RGB16F and RGB32F images at the moment. The only tricky one to work with is the 16F, as I need half to float conversions (and backwards). Does this conversion exist already in OSG? If not, and I were to submit it, where would you want it to live - in osg/Math, or osg/Image? There isn't any half float support explictly in the OSG. The only place you'd be able to use it would be in osg::Image as a simply path through of image data, with no actual processing on the OSG side. Doing conversion between types is a operation that would most comfortably sit in osgUtil, but possible in the core OSG if the data types were required by core scene graph classes. Could illustrate what type of code you are expecting to need to write? Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] Re: Names for different threading models
Hi All,
On 2/6/07, Robert Osfield [EMAIL PROTECTED] wrote:
1) SingleThreaded - this is an easy one ;-)
2) RenderingThreadPerContext or CullDrawThreadPerContext
3) DrawThreadPerContext
4) CullThreadPerCameraDrawThreadPerContext
Does this make sense given the above? Is an long winded name for
option 4 sensible?
Wow, popular thread...
What I have gone for is:
enum ThreadingModel
{
SingleThreaded,
CullDrawThreadPerContext,
DrawThreadPerContext,
CullThreadPerCameraDrawThreadPerContext,
AutomaticSelection
};
Is there ideal set up of names? If not please ping me with your suggestions.
I have changed the default ThreadingModel to AutomaticSelection, and
this calls the new method Viewer::suggestThreadingModel() to set the
final threading model used. This method will look at how many CPU
cores you have available and how many windows you have and try to
choose the best threading model to run.
Expect single CPU single window apps to use SingelThreaded, dual core
CPU single window apps to use DrawThreadPerContext, multiple CPU +
multiple GPU = num cores to use the
CullThreadPerCameraDrawThreadPerContext, otherwise
CullDrawThreadPerContext or DrawThreadPerContext will be chosen in
cases where you have multiple windows.
The later CullDrawThreadPerContext or DrawThreadPerContext is
something that I have not decided upon yet, CullDrawThreadPerContext
will typically lead to lower frame latency, while
DrawThreadPerContext's double buffer will lead to an extra frames
latency but higher chance of hitting vsync. If you miss vysnc then
you'll pay an extra frames latency anyway...
So if there is any chance you are going to miss a frame
DrawThreadPerContext is your man, while CullDrawThreadPerContext is
best when you are sure you'll hit vsync. Right now I've opted for
DrawThreadPerContext in the multiple window case.
You can also set the threading model yourself.
A word of warning. the CullThreadPerCameraDrawThreadPerContext model
has been implemented and in testing I have found deadlocks that I
haven't got to the bottom of yet. I don't have enough cores to
properly test it either - I really need a 4 core, 2 GPU machine...
Robert.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
Re: [osg-users] Does thee OpenThreads license conflict with the OSG license?
Great! Thanks for being so quick about this Robert (and Sean). It's nice to have a consistent license across OSG/Producer/OpenThreads since OSG/Producer always depend on OpenThreads. Sorry about adding some tension to your life though. :) Ravi On Feb 6, 2007, at 3:07 AM, Robert Osfield wrote: On 2/5/07, Robert Osfield [EMAIL PROTECTED] wrote: Sean has given me the go ahead to update the license entries to OSGPL/WxWindows license. I'll make these changes in the CVS version of OpenThreads tonight. Ack, another late night :-| This change is now made and checked in to OpenThreads CVS. Please check :-) ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Re: Names for different threading models
I really need a 4 core, 2 GPU machine... Don't we all... In my early years working, I was surprised to discover that most of the time, need is a relative term whose meaning is not dependent on your own appraisal of the situation. (If I win the lottery, I'll buy two identical machines and send one your way :-) Drifting OT here, pardon my rambling. J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Re: Names for different threading models
Robert Osfield wrote: Wow, popular thread... Heheh. Thread. I think if you had a count of the number are intently reading this thread, the count would be very high. I may not have anything to contribute but I am watching with eager anticipation. Sounds very similar to stuff Don Tidrow and I were trying to work out back in March 2003. Of course, we weren't quite as motivated and OSG wasn't where it is today. This thread makes for good reading though. -Paul ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] Where is osgPython repository?
Hi all, where is the osgPython repository? Is it down? moved? The only repository I found is at mescriva.okode.com but I can't even ping that host. Thanks, /ulrich ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] Re: Names for different threading models
Hi Robert,
Are the different threading models the same between windows and linux? I
remember seeing that windows osg (probably producer) didn't support thread
per context before.
Zach
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield
Sent: Tuesday, February 06, 2007 12:16
To: osg users
Subject: [osg-users] Re: Names for different threading models
Hi All,
On 2/6/07, Robert Osfield [EMAIL PROTECTED] wrote:
1) SingleThreaded - this is an easy one ;-)
2) RenderingThreadPerContext or CullDrawThreadPerContext
3) DrawThreadPerContext
4) CullThreadPerCameraDrawThreadPerContext
Does this make sense given the above? Is an long winded name for
option 4 sensible?
Wow, popular thread...
What I have gone for is:
enum ThreadingModel
{
SingleThreaded,
CullDrawThreadPerContext,
DrawThreadPerContext,
CullThreadPerCameraDrawThreadPerContext,
AutomaticSelection
};
Is there ideal set up of names? If not please ping me with your
suggestions.
I have changed the default ThreadingModel to AutomaticSelection, and this
calls the new method Viewer::suggestThreadingModel() to set the final
threading model used. This method will look at how many CPU cores you have
available and how many windows you have and try to choose the best threading
model to run.
Expect single CPU single window apps to use SingelThreaded, dual core CPU
single window apps to use DrawThreadPerContext, multiple CPU + multiple GPU
= num cores to use the CullThreadPerCameraDrawThreadPerContext, otherwise
CullDrawThreadPerContext or DrawThreadPerContext will be chosen in cases
where you have multiple windows.
The later CullDrawThreadPerContext or DrawThreadPerContext is something
that I have not decided upon yet, CullDrawThreadPerContext will typically
lead to lower frame latency, while DrawThreadPerContext's double buffer will
lead to an extra frames latency but higher chance of hitting vsync. If you
miss vysnc then you'll pay an extra frames latency anyway...
So if there is any chance you are going to miss a frame DrawThreadPerContext
is your man, while CullDrawThreadPerContext is best when you are sure you'll
hit vsync. Right now I've opted for DrawThreadPerContext in the multiple
window case.
You can also set the threading model yourself.
A word of warning. the CullThreadPerCameraDrawThreadPerContext model has
been implemented and in testing I have found deadlocks that I haven't got to
the bottom of yet. I don't have enough cores to properly test it either - I
really need a 4 core, 2 GPU machine...
Robert.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
RE: [osg-users] Re: Names for different threading models
Hi Robert,
Are the different threading models the same between windows and linux? I
remember seeing that windows osg (probably producer) didn't support thread
per context before.
Zach
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield
Sent: Tuesday, February 06, 2007 12:16
To: osg users
Subject: [osg-users] Re: Names for different threading models
Hi All,
On 2/6/07, Robert Osfield [EMAIL PROTECTED] wrote:
1) SingleThreaded - this is an easy one ;-)
2) RenderingThreadPerContext or CullDrawThreadPerContext
3) DrawThreadPerContext
4) CullThreadPerCameraDrawThreadPerContext
Does this make sense given the above? Is an long winded name for
option 4 sensible?
Wow, popular thread...
What I have gone for is:
enum ThreadingModel
{
SingleThreaded,
CullDrawThreadPerContext,
DrawThreadPerContext,
CullThreadPerCameraDrawThreadPerContext,
AutomaticSelection
};
Is there ideal set up of names? If not please ping me with your
suggestions.
I have changed the default ThreadingModel to AutomaticSelection, and this
calls the new method Viewer::suggestThreadingModel() to set the final
threading model used. This method will look at how many CPU cores you have
available and how many windows you have and try to choose the best threading
model to run.
Expect single CPU single window apps to use SingelThreaded, dual core CPU
single window apps to use DrawThreadPerContext, multiple CPU + multiple GPU
= num cores to use the CullThreadPerCameraDrawThreadPerContext, otherwise
CullDrawThreadPerContext or DrawThreadPerContext will be chosen in cases
where you have multiple windows.
The later CullDrawThreadPerContext or DrawThreadPerContext is something
that I have not decided upon yet, CullDrawThreadPerContext will typically
lead to lower frame latency, while DrawThreadPerContext's double buffer will
lead to an extra frames latency but higher chance of hitting vsync. If you
miss vysnc then you'll pay an extra frames latency anyway...
So if there is any chance you are going to miss a frame DrawThreadPerContext
is your man, while CullDrawThreadPerContext is best when you are sure you'll
hit vsync. Right now I've opted for DrawThreadPerContext in the multiple
window case.
You can also set the threading model yourself.
A word of warning. the CullThreadPerCameraDrawThreadPerContext model has
been implemented and in testing I have found deadlocks that I haven't got to
the bottom of yet. I don't have enough cores to properly test it either - I
really need a 4 core, 2 GPU machine...
Robert.
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
Re: [osg-users] Does thee OpenThreads license conflict with the OSG license?
On 2/6/07, Ravi Mathur [EMAIL PROTECTED] wrote: Great! Thanks for being so quick about this Robert (and Sean). It's nice to have a consistent license across OSG/Producer/OpenThreads since OSG/Producer always depend on OpenThreads. Sorry about adding some tension to your life though. :) No problem, nice to resolve it. Something we should have caught earlier ;-) Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Re: Names for different threading models
Hi Zach, On 2/6/07, Zach Deedler [EMAIL PROTECTED] wrote: Are the different threading models the same between windows and linux? I remember seeing that windows osg (probably producer) didn't support thread per context before. All threading models are available on all platforms. In osgViewer threading is entirely orthogonal to windowing, as long the base GraphicsWindow class provides all the makeCurrent/releaseContext/swapBuffers etc that are required everything else should work just fine. Andre's done a good job with GraphicsWindowWin32 so pretty well all the boxes and ticked and has ensured that multi-thread, multi-graphics windows works. Getting things to work multi-thread also required fixes to the core OSG unrelated to windowing, these were static data structure.initialization issues. Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Re: Names for different threading models
I think if you had a count of the number are intently reading this thread, the count would be very high. I may not have anything to contribute but I am watching with eager anticipation. Ditto ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Where is osgPython repository?
Hi! osgPython repository has been moved to another server ( mescriva.codemaniacs.com) svn co http://mescriva.codemaniacs.com/svn/osgPython/trunk Greets, Miguel 2007/2/6, Ulrich Hertlein [EMAIL PROTECTED]: Hi all, where is the osgPython repository? Is it down? moved? The only repository I found is at mescriva.okode.com but I can't even ping that host. Thanks, /ulrich ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] output arguments in osgPython
Hi Matthew! Tanks for report me this bug! I'll try to fix this next week. I'm very busy this week! Greets, Miguel 2007/2/5, Matthew Koichi Grimes [EMAIL PROTECTED]: In osgPython, how can I call those methods which take output arguments by reference in C++? For example, I'd like to get the angle-axis representation of a quaternion by calling the osgPython version of Quat::getRotate( value_type angle, Vec3d vec), but AFAIK there's no pass-by-reference of primitive types in python. The following brain-dead C++-to-python transcription at least doesn't throw a method not found error, but as expected it doesn't put anything into the output arguments either. The indented lines are the outputs from the interpreter: from initosg import * V = loadWrapper(osg) quat = V.Quat() axis = V.Vec3(1,2,3) angle = 5 quat.getRotate(angle, axis) void() axis osg::Vec3f(1 2 3) angle 5 Any help would be much appreciated; -- Matt ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] Getting Orthoginal View working
Hello, I am currently working with osg 0.9.9 and I am running into some difficulties. First off I am trying to set up an orthoginal view. I found in the osgMatrixd library a function called makeOrtho. This function calls for a left, right, bottom, top, znear and zfar. Does this function return an Orthoginal view matrix? Also where do I get the parameters to pass it? This is what I am doing osg::ref_ptrProducer::Trackball _trackBall; osg::Matrixd *_Matrix = NULL; double left = 0.0; double right = 0.0; double top = 0.0; double bottom = 0.0; double znear = 0.0; double zfar = 0.0; float distance = _trackBall-getDistance(); _Matrix = osg::Matrixd(_trackBall-getMatrix().ptr()); _Matrix-getFrustum(left,right,bottom,top,znear,zfar); _Matrix-makeOrtho(left,right,bottom,top,znear,zfar); I try to populate my left,right,bottom,top,znear and zfar by calling the Frustum function. But the function returns false. I am not sure why because the data in the matrix seems to be valid, but at the begining of the function when it does the check to make sure the matrix is valid it returns false. So when I get to the makeOrtho function I am passing it all 0's. So I would not get a good matrix. I know that I am getting a good matrix from my _trackBall-getMatrix().ptr. Also if I do not get the Frustum from the getFustum function, how do I get the Frustum? Any suggestions or ideas on what I could do here to get this to worik for me. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] Updating My Translation with mouse Coordinates
Hello,
I am helping to develop a 3DViewer to view pcbdesigns in 3D we are using
OSG 0.9.9. I am having some troubles getting new x and y coordinates to
translate my view with.
Basically I am trying to set up a zoom and when you click on a part in
the design you zoom in by 25% of the distance. Then you click it again
and you zoom another 25% of the distance.
I am not having troubles with the zooming but I am having troubles with
where it zooms and the mouse input.
This is what I am doing:
osg::ref_ptrProducer::trackball_trackBall;
osf::ref_ptrosg::Group _root;
mx = getTheMouseXScreenCoordinate;
my = getTheMouseYScreenCoordinate;
button = getthePressedButton;
if(buttom == 2)
{
float distance = _trackBall-getDistance();
float distancePercentage = distance*.25;
float newDistance = distance -distancePercentage;
float newScale = _trackBall-getScale();
const osg::BoundingSphere bs = _root-getBound();
double radius = bs.radius();
double totalSize = radius*newScale;
double xInfo = totalSize*mx;
double yInfo = totalSize*my;
double x = xInfo/newScale;
double y = yInfo/newScale;
_trackBall-reset();
_trackBall-setDistance(newDistance);
_trackBall-translate(-x,-y,0);
}
So on my first click I zoom into the correct place that I want to zoom
into. But on my second click on trying to zoom, I zoom into the
incorrect area and so on and so forth.
So basically I am trying to take the mouse coordinates and convert them
to the design coordinates. To total size of the design or the bounding
sphere around the desing is 3000, the center of the design is roughly
1500. The units don't really matter to me at this point. The mouse
coordinates that I am getting are in decimals, if I click on the lower
left of the design x comes back as roughly .18 and y comes back at
roughly .24. The scale at this intial point is roughly 1100. We zoom
in 25% of our distance in the correct area. No the view is currently a
little more zoomed in and the view is now different. But I am still
able to click on the same spot I was before. So I click on it and it
zooms in but in the incorrect spot. The same stop that was .18 earlier
is not .30 which is the x mouse screen coordinate. The y mouse
coordinate comes back at roughly .36 and was .24 before. The scale at
this point is now .748. So I click again and the design gets more
zoomed in and the coordinates change again.
My question is how do I take the mouse coordinates and get the
coordinates I need to correctly translate them? Any ideas or suggestion
would be wonderful.
Thanks,
Shane
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
RE: [osg-users] Getting Orthoginal View working
I won't be too much help because it's been a LONG time since I've used 0.9.9 and most of what I'm doing today uses osgViewer in current CVS. But I can tell you that trying to create an ortho view by setting the TrackBall manipulator matrix is the wrong approach. If you're using osgProducer and you want an orthographic view, I think you do this by changing the osgProducer::Camera's view matrix. Get the matrix and call setOrtho. The left, right, top, bottom, near, and far parameters are just the same as for a glOrtho call in OpenGL. OSG won't tell you what these values are because it can't read your mind :-) to determine the extent of your view volume. You must specify those values yourself. Sorry this is probably not the help you needed, but I hope it at least points you in the right direction. I'd also advise you to subscribe to the producer-users mailing list and enquire there about changing Producer's camera in an OSG app. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com http://www.skew-matrix.com/ 303 859 9466 _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rogers, Shane Sent: Tuesday, February 06, 2007 3:06 PM To: osg users Subject: [osg-users] Getting Orthoginal View working Hello, I am currently working with osg 0.9.9 and I am running into some difficulties. First off I am trying to set up an orthoginal view. I found in the osgMatrixd library a function called makeOrtho. This function calls for a left, right, bottom, top, znear and zfar. Does this function return an Orthoginal view matrix? Also where do I get the parameters to pass it? This is what I am doing osg::ref_ptrProducer::Trackball _trackBall; osg::Matrixd *_Matrix = NULL; double left = 0.0; double right = 0.0; double top = 0.0; double bottom = 0.0; double znear = 0.0; double zfar = 0.0; float distance = _trackBall-getDistance(); _Matrix = osg::Matrixd(_trackBall-getMatrix().ptr()); _Matrix-getFrustum(left,right,bottom,top,znear,zfar); _Matrix-makeOrtho(left,right,bottom,top,znear,zfar); I try to populate my left,right,bottom,top,znear and zfar by calling the Frustum function. But the function returns false. I am not sure why because the data in the matrix seems to be valid, but at the begining of the function when it does the check to make sure the matrix is valid it returns false. So when I get to the makeOrtho function I am passing it all 0's. So I would not get a good matrix. I know that I am getting a good matrix from my _trackBall-getMatrix().ptr. Also if I do not get the Frustum from the getFustum function, how do I get the Frustum? Any suggestions or ideas on what I could do here to get this to worik for me. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] bumpmapping
Hi. I have a problem with osgFX::BumpMapping I use object from .osg file. Loading via osgDB::readNodeFile is OK. I do something like this: osgFX::BumpMapping* bumping = new osgFX::BumpMapping(); bumping-setLightNumber(1); osg::Image* normalMapImage = new osg::Image(); osg::Image* diffuseMapImage = new osg::Image(); normalMapImage-setFileName(*normalMapFile); diffuseMapImage-setFileName(./texture/torch.tga); osg::Texture2D* normalMap = new osg::Texture2D(normalMapImage); osg::Texture2D* diffuseMap = new osg::Texture2D(diffuseMapImage); bumping-setOverrideNormalMapTexture(normalMap); bumping-setOverrideDiffuseTexture(diffuseMap); osg::Node* pomNode = new osg::Node(); // Load models from files and assign to nodes: pomNode = osgDB::readNodeFile(filename); bumping-addChild(pomNode); bumping-prepareChildren(); modelNode = bumping; modelNode is added to root node. My torch looks only like siluete (light set to 0). I have created light like this: osg::Light* myLight2 = new osg::Light; myLight2-setLightNum(1); myLight2-setAmbient(osg::Vec4(1.0f,0.0f,0.0f,1.0f)); myLight2-setDiffuse(osg::Vec4(1.0f,0.0f,0.0f,1.0f)); myLight2-setPosition(osg::Vec4(1, 1, 1, 0)); osg::LightSource* lightS2 = new osg::LightSource; lightS2-setLight(myLight2); lightS2-setLocalStateSetModes(osg::StateAttribute::ON); lightS2-setStateSetModes(*rootStateSet,osg::StateAttribute::ON); root-addChild(lightS2); Torch is at position (0,0,2). Why is my torch black? Where is the problem? I created it in Blender and use export and it has UV coordinates. If I do't use bumpmapping it looks normal. Can anybody help me? ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
[osg-users] My RemoveChild doesn't work
hi all,
I made a class who have to draw a simple line (see below)
but I don't know why when I delete CLine class, the line is always visible
(but the class is well deleted)
I put the code of the class.
++
class CLine{
private:
osg::ref_ptrosg::Geode SegmentGeode;
osg::ref_ptrosg::Geometry SegmentGeometry;
public:
CLine( double x1,double y1,double z1, double x2,double
y2,double z2);
~CLine();
};
-
CLine::CLine( double x1,double y1,double z1,
double x2,double y2,double z2){
SegmentGeode = new osg::Geode(); //
SegmentGeometry = new osg::Geometry();
SegmentGeode-addDrawable(SegmentGeometry.get());
CGeneral::instance().root-addChild(SegmentGeode.get());
osg::Vec3Array* SegmentVertices = new osg::Vec3Array;
SegmentVertices-push_back( osg::Vec3( x1, y1, z1) );
SegmentVertices-push_back( osg::Vec3( x2, y2, z2) );
SegmentGeometry-setVertexArray( SegmentVertices );
osg::DrawElementsUInt* SegmentBase = new
osg::DrawElementsUInt(osg::PrimitiveSet::LINES, 0);
SegmentBase-push_back(0);
SegmentBase-push_back(1);
SegmentGeometry-addPrimitiveSet(SegmentBase);
osg::Vec4Array* colors = new osg::Vec4Array;
colors-push_back(osg::Vec4(1.0f,1.0f,0.0f,1.0f));
SegmentGeometry-setColorArray(colors);
SegmentGeometry-setColorBinding(osg::Geometry::BIND_PER_VERTEX);
CGeneral::instance().root-addChild(SegmentGeode.get());
}
CLine::~CLine(){
CGeneral::instance().root-removeChild(SegmentGeode.get());
SegmentGeode = 0;
}
THANKS;
a
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
Re: [osg-users] Re: GraphicsWindowWin32 is here! :-)
Hi Andre,
I just downloaded your latest update via cvs and the keyboard support
is now working. Thanks for your excellent work !
-Drew
On 2/6/07, André Garneau [EMAIL PROTECTED] wrote:
Hi Drew,
The value 16 is VK_SHIFT, the virtual key code for the SHIFT key. Since
Windows does not differentiate between the LEFT and RIGHT variants for the
virtual key code, it always send this value in the key press event. There is
an extended key indicator in the message that is set to allow
differentiating between a LEFT and RIGHT key press, but for the SHIFT key it
is not set (but is set properly for the ALT and CTRL keys modifiers). Bottom
line is that the SHIFT key seems to be very special to Windows and it
behaves accordingly... ;-)
André
-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] De la part de Drew Whitehouse
Envoyé : February 5, 2007 2:44 PM
À : osg users
Objet : Re: [osg-users] Re: GraphicsWindowWin32 is here! :-)
I guess the thing I'm not understanding is why neither KEY_Shift_L or
KEY_Shift_R has the value 16, where is 16 coming from ?
-Drew
On 2/6/07, André Garneau [EMAIL PROTECTED] wrote:
Hi Drew,
Yes, this is the expected behavior for the current implementation.
In short, for SHIFT, CTRL and ALT keys, there is not a separate key
value returned for left and right key press variants; this information
is encoded in the modifiers flags returned as part of the key press
information. So in your example below, pressing the left or right
SHIFT key will always return the same key value (16). However if you
also look at the modifier flags value, you will see that it's set to
indicate if the left or right key variant was pressed.
For key release events, the same key value is returned, but this time
without any modifier flag set (so you cannot, with the current
implementation, distinguish between a left SHIFT key release and a
RIGHT shift key release).
As mentioned in the original email, the real issue (a nuisance really)
is the fact that Windows does not readily provide the information on
which key variant (base or extended) a release event applies to. To
fix this will probably require keeping previous key-state information
in the keyboard handler code; keyboard events hooking will likely be
required to achieve this in a multi-window setup.
André
-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] De la part de Drew
Whitehouse Envoyé : February 5, 2007 12:09 AM À : osg users Objet :
Re: [osg-users] Re: GraphicsWindowWin32 is here! :-)
Hi Andre,
I'm not quite sure what you are saying here.
If I put this in a GUIEventHandler
switch (ea.getEventType())
{
// ..etc
case(osgGA::GUIEventAdapter::KEYDOWN):
{
std::cout down ea.getKey()
shift l = osgGA::GUIEventAdapter::KEY_Shift_L
shift r = osgGA::GUIEventAdapter::KEY_Shift_R
std::endl;
I see
down 16 shift l = 65505 shift r = 65506
for both left and right shift keys, and similar for the up event. Is
this what you'd expect ?
-Drew
--
Drew Whitehouse
ANU Supercomputer Facility Vizlab
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
--
Drew Whitehouse
ANU Supercomputer Facility Vizlab
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
--
Drew Whitehouse
ANU Supercomputer Facility Vizlab
___
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
[osg-users] SimpleViewer: shared contexts?
So I thought I would try supporting shared contexts with SimpleViewerCocoa. But the SimpleViewer API seems to discourage this as the SimpleViewer constructor automatically increments the contextID. Currently, my workaround looks like this: simpleViewer = new osgViewer::SimpleViewer; simpleViewer-getSceneView()-getState()-setContextID(0); osg::DisplaySettings::instance()-setMaxNumberOfGraphicsContexts(1); Is this the best way of dealing with it? Thanks, Eric ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
