[osg-users] Visitor concept. No finalize?
Hi, I was writing a Visitor that performed an extraction of certain elements from a scenegraph. My first try was to remove the nodes in question from their parents directly in the apply method which lead to some exceptions. So what am I doing wrong? I mean I would except some finalize method which is called when the visitor is finished. Currently the only remaining function is the getter function for the nodes, that should be extracted. So in apply I have stored references to the object which I can only extract when using the getter so that the removal logic can be executed. This works so far but if I do not call the getter no extraction code is executed and nothing really happened. What am I doing wrong? Thank you, Sam -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35941#35941 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] user rotation manipulator problem
Sorry, the forum thing cut my message off prematurely for some reason. I have posted some of the code, but for some reason it often rotates it to an orientation different that what was shown before these calculations. Does anyone have a more reliable and straightforward approach to this problem? Thanks David -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35937#35937 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] user rotation manipulator problem
Hi,
I am attempting to build a system that lets the users move/rotate objects in my
scene. When the user selects an object an axis is shown that also has thin
toruses around each axis. If they click on one of the axises they can move the
part along that axis. If they click on one of the toruses they can rotate about
that axis. All of the rotation information given to the user is in Euler
angles, but internally that is converted into quaterions. Initially, when I was
trying to get the rotation to work I was simply adding movement values of the
selected rotation axis to the corresponding euler angle and re-calculating the
matrix for the transform. This appeared to work at first, but if I rotated it
along a couple of axises, then future rotations were not along the correct axis
anymore.
To get around this problem I split the transform up into 2 parts. One transform
that was for the current position/orientation, and the second one was used by
the gripper to let them rotate it around the chosen axis based on the current
orientation. When the user quit dragging I tried to multiply those to matrices
together, got the rotation quaterion, and then converted that back to euler
angles. I then reset the current orientation matrix using the new euler angles,
and reset the grip matrix back to default. However, this is still not really
working. I
Thank you!
Cheers,
David
Code:
void VsBody::EndGripDrag(VsGripElement *lpGrip)
{
osg::Matrix mtCombined;
mtCombined.set(m_osgGripMatrix * m_osgLocalMatrix);
osg::Quat qRot = mtCombined.getRotate();
CStdFPoint vGripRot = QuaterionToEuler(qRot);
if(vGripRot != m_lpThis->Rotation())
m_lpThis->Rotation(vGripRot);
}
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=35936#35936
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Slave Camera not following Master's position
Hi Robert,
It could simply be that your subclass from Viewer is interfering with
the mechanism that applies the master's view and projection matrix to
the slaves.
Requiring a subclass from Viewer just to implement so event handling
is rather overkill, you should be able to catch the events in the main
frame loop and pass these on to the viewer, or simply compute the
viewer's master camera's view matrix on each frame and forgo the use
of a camera manipulator.
Robert.
On Mon, Jan 24, 2011 at 6:32 PM, Robert Kern wrote:
> Hi,
>
> I've been having trouble implementing slave cameras for an application I'm
> working on. The camera gets its position and orientation from a motion
> tracking system or through joystick input. When I don't set up slave cameras,
> the camera properly responds to input. However, when I implement slave
> cameras, they do not update their position or orientation with input from the
> motion tracking or joy stick.
>
> In the code below, if I comment out the code that sets up the slave cameras,
> the viewer responds properly to input from the joystick or the motion
> tracker. If it is not commented, the slave cameras will display, but they
> will not respond to the motion tracker or joystick. If anyone could provide
> any suggestions, they would be much appreciated.
>
> Thank you!
> rjkern
>
> Code:
>
> viewer = new FLTViewer(arguments); //FLTViewer is and extension of the
> osgViewer::Viewer class. It receives the camera position and orientation from
> a server program.
>
> //Here is where I set up the slave camera
> int xoffset = 40;
> int yoffset = 40;
>
> // left window + left slave camera
> {
> osg::ref_ptr traits = new
> osg::GraphicsContext::Traits;
> traits->x = xoffset + 0;
> traits->y = yoffset + 0;
> traits->width = 600;
> traits->height = 480;
> traits->windowDecoration = true;
> traits->doubleBuffer = true;
> traits->sharedContext = 0;
>
> osg::ref_ptr gc =
> osg::GraphicsContext::createGraphicsContext(traits.get());
>
> osg::ref_ptr camera = new osg::Camera;
> camera->setGraphicsContext(gc.get());
> camera->setViewport(new osg::Viewport(0,0, traits->width,
> traits->height));
> GLenum buffer = traits->doubleBuffer ? GL_BACK : GL_FRONT;
> camera->setDrawBuffer(buffer);
> camera->setReadBuffer(buffer);
>
> // add this slave camera to the viewer, with a shift left of
> the projection matrix
> viewer->addSlave(camera.get(),
> osg::Matrixd::translate(1.0,0.0,0.0), osg::Matrixd::rotate(45, Vec3f(1,0,0)));
> }
>
> // right window + right slave camera
> {
> osg::ref_ptr traits = new
> osg::GraphicsContext::Traits;
> traits->x = xoffset + 600;
> traits->y = yoffset + 0;
> traits->width = 600;
> traits->height = 480;
> traits->windowDecoration = true;
> traits->doubleBuffer = true;
> traits->sharedContext = 0;
>
> osg::ref_ptr gc =
> osg::GraphicsContext::createGraphicsContext(traits.get());
>
> osg::ref_ptr camera = new osg::Camera;
> camera->setGraphicsContext(gc.get());
> camera->setViewport(new osg::Viewport(0,0, traits->width,
> traits->height));
> GLenum buffer = traits->doubleBuffer ? GL_BACK : GL_FRONT;
> camera->setDrawBuffer(buffer);
> camera->setReadBuffer(buffer);
>
> // add this slave camera to the viewer, with a shift right of
> the projection matrix
> //viewer->addSlave(camera.get(),
> osg::Matrixd::translate(-1.0,0.0,0.0), osg::Matrixd());
> viewer->addSlave(camera.get(),
> osg::Matrixd::translate(-1.0,0.0,0.0), osg::Matrixd::rotate(45,
> Vec3f(1,0,0)));
> }
>
>
> //create socket and set up connections.
> viewer->initRecvSocket();
>
> //Load the scene model
> viewer->setScene(viewer->file_name);
>
> osg::Group* rootnode;
>
> rootnode = viewer->getRootNode();
> if (!rootnode)
> {
> return -1;
> }
>
> viewer->initPerspective(); //initialize the perspective
> viewer->startDataTransfer();
>
> viewer->setCamera(osg::Vec3(0,0,1),osg::Vec3(0,1,0),osg::Vec3(-1,0,0),osg::Vec3(0,0,1));
>
> while( !viewer->done() )
> {
> viewer->frame();
> }
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=35932#35932
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
Re: [osg-users] Texture Buffer Objects status?
Hi Fred, Good to know that you could make it. For sure, I don't think my implementation is the best posible. I just wanted to get something working quickly. My idea is that someone else can take it as a starting point for a future OSG implementation. Cheers, Juan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Slave Camera not following Master's position
Hi,
I've been having trouble implementing slave cameras for an application I'm
working on. The camera gets its position and orientation from a motion tracking
system or through joystick input. When I don't set up slave cameras, the camera
properly responds to input. However, when I implement slave cameras, they do
not update their position or orientation with input from the motion tracking or
joy stick.
In the code below, if I comment out the code that sets up the slave cameras,
the viewer responds properly to input from the joystick or the motion tracker.
If it is not commented, the slave cameras will display, but they will not
respond to the motion tracker or joystick. If anyone could provide any
suggestions, they would be much appreciated.
Thank you!
rjkern
Code:
viewer = new FLTViewer(arguments); //FLTViewer is and extension of the
osgViewer::Viewer class. It receives the camera position and orientation from a
server program.
//Here is where I set up the slave camera
int xoffset = 40;
int yoffset = 40;
// left window + left slave camera
{
osg::ref_ptr traits = new
osg::GraphicsContext::Traits;
traits->x = xoffset + 0;
traits->y = yoffset + 0;
traits->width = 600;
traits->height = 480;
traits->windowDecoration = true;
traits->doubleBuffer = true;
traits->sharedContext = 0;
osg::ref_ptr gc =
osg::GraphicsContext::createGraphicsContext(traits.get());
osg::ref_ptr camera = new osg::Camera;
camera->setGraphicsContext(gc.get());
camera->setViewport(new osg::Viewport(0,0, traits->width,
traits->height));
GLenum buffer = traits->doubleBuffer ? GL_BACK : GL_FRONT;
camera->setDrawBuffer(buffer);
camera->setReadBuffer(buffer);
// add this slave camera to the viewer, with a shift left of
the projection matrix
viewer->addSlave(camera.get(),
osg::Matrixd::translate(1.0,0.0,0.0), osg::Matrixd::rotate(45, Vec3f(1,0,0)));
}
// right window + right slave camera
{
osg::ref_ptr traits = new
osg::GraphicsContext::Traits;
traits->x = xoffset + 600;
traits->y = yoffset + 0;
traits->width = 600;
traits->height = 480;
traits->windowDecoration = true;
traits->doubleBuffer = true;
traits->sharedContext = 0;
osg::ref_ptr gc =
osg::GraphicsContext::createGraphicsContext(traits.get());
osg::ref_ptr camera = new osg::Camera;
camera->setGraphicsContext(gc.get());
camera->setViewport(new osg::Viewport(0,0, traits->width,
traits->height));
GLenum buffer = traits->doubleBuffer ? GL_BACK : GL_FRONT;
camera->setDrawBuffer(buffer);
camera->setReadBuffer(buffer);
// add this slave camera to the viewer, with a shift right of
the projection matrix
//viewer->addSlave(camera.get(),
osg::Matrixd::translate(-1.0,0.0,0.0), osg::Matrixd());
viewer->addSlave(camera.get(),
osg::Matrixd::translate(-1.0,0.0,0.0), osg::Matrixd::rotate(45, Vec3f(1,0,0)));
}
//create socket and set up connections.
viewer->initRecvSocket();
//Load the scene model
viewer->setScene(viewer->file_name);
osg::Group* rootnode;
rootnode = viewer->getRootNode();
if (!rootnode)
{
return -1;
}
viewer->initPerspective(); //initialize the perspective
viewer->startDataTransfer();
viewer->setCamera(osg::Vec3(0,0,1),osg::Vec3(0,1,0),osg::Vec3(-1,0,0),osg::Vec3(0,0,1));
while( !viewer->done() )
{
viewer->frame();
}
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=35932#35932
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How do I extract OSG data?
Hi Christian, On Mon, Jan 24, 2011 at 5:01 PM, Christian Sanelli wrote: > How, for instance, would I determine elevation at a given lat/long? Would ray intersection be the thing you are looking for? See osgintersection example. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph with glut support
I agree with Robert that you need to jettison GLUT. It's a mickey mouse framework for mickey mouse apps. It was never intended to be used in "real" applications. Embedding an OSG viewer in a GLUT window reduces the viewer down to running single threaded which is not good for performance. Our application currently uses OSG and OpenGL together. Our OpenGL rendering is in a wrapper which happens in a post draw callback. This seems to work fine. The key is in state management since OSG and OpenGL share the same render context. Our goal is to eventually port the OpenGL rendering over to OSG but for the time being this is what we're doing to get by. -Shayne -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Mukund Keshav Sent: Saturday, January 22, 2011 11:29 AM To: osg-users@lists.openscenegraph.org Subject: [osg-users] OpenSceneGraph with glut support Hello, im using OpenSceneGraph for the past 2 days. Well, i would be needing it mostly for terrain rendering. i was wondering if i can use OSG with some low level gl functions? What i mean is, say im using OpenSceneGraph. Now i want to use some gl functions, can i use both together. something like this: Code: /* Use gl functions, build the projection matrix */ .. .. /* Now build the modelview matrix */ .. .. /* Now i build some scene using OSG */ .. .. /* gl functions to render */ .. Can i use this approach. i would like to use the lower level flexibility + the ease with higher level APIs. Is this possible? This is exactly like the question asked here: http://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg12497.html Thanks, Mukund -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35897#35897 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org smime.p7s Description: S/MIME cryptographic signature ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How do I extract OSG data?
Robert, Thanks for your response. How, for instance, would I determine elevation at a given lat/long? Thanks, Christian -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35929#35929 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with processing keystokes
Hi Alexander,
I'm afraid I'm not familiar with Win32 API for keyboard bindings so
I've to dive into the GraphicsWindowWin32.cpp to understand your
suggestion about passing a "VirtualKey". From reading the code it
looks to me like the VirtualKey is Win32 specific which would mean the
client code would also need to be platform specific so an ideal
candidate for integration.
>From what I can make of the functionality you are after what you are
after is an unmodified key, i.e. no shift/no control key modification
- just the raw key code.
Reviewing the GraphicsWindowWin32::adaptKey(..) method the lines of code:
else if ((keySymbol & 0xff00)==0)
{
char asciiKey[2];
int numChars = ::ToAscii(wParam, (lParam>>16)&0xff, keyState,
reinterpret_cast(asciiKey), 0);
if (numChars>0) keySymbol = asciiKey[0];
}
Look to me to be the ones that are likely to be applying the key
modification. If this is correct then passing the modifying keySymbol
as well as the modified keySymbol should be sufficient. This would
still require osgGA::GUIEventAdatper to have a new
getRawKey()/getUnmodifiedKey() field and osgViewer to be tweaked to
set this new field, but I open to this.
Thoughts?
Robert.
On Fri, Jan 21, 2011 at 11:20 AM, Alexander Sinditskiy
wrote:
> Hi,
>
> I have a problem with processing keystokes in osg-viewer window.
>
> I would like to tell about this problem and propound resolution.
>
> First i need to explain what is problem i have:
>
> Assume that you want process ASDW keydown like as in Counter-Strike and F to
> flash light.
>
> that you need to do?
> you need to create something like
>
>
> Code:
> case osgGA::GUIEventAdapter::KEYDOWN:
> switch(ea.getKey())
> {
> case 'w':
> // go forward
> break;
> ...
> }
>
>
>
> It will work until you need to add crouch.
>
> let's see what will be in this case:
>
> after key is pressed there is message recieved
>
> Code:
> case WM_KEYDOWN :
> case WM_SYSKEYDOWN :
>
>
>
> their handlers do the following:
>
> adaptKey(wParam, lParam, keySymbol, modifierMask);
> 1. getting a virtual key code
> 2. converting virtual key code to symbol code
>
> then there is a call of
>
> Code:
> getEventQueue()->keyPress(keySymbol, eventTime);
>
>
> with GUIEventAdapter created inside it, what contain keySymbol
>
>
> i.e. now to turn flashlight we have to do steps below:
>
>
> Code:
> case osgGA::GUIEventAdapter::KEYDOWN:
> switch(ea.getKey())
> {
> case 'F':
> case 'f':
> case 'f'-0x40 : // for processing with CTRL
> // do something
> }
>
>
>
> as we don't know whick key is pressed by user, we have to include all
> possibilities:
>
> I suggest using virtual keys codes both with current key handles, as the
> following:
>
> Code:
> adaptKey(wParam, lParam, keySymbol, modifierMask, virtualKey);
> ...
> getEventQueue()->keyPress(keySymbol, virtualKey eventTime);
>
>
>
> What do you think about it?
> Thank you!
>
> Cheers,
> Alexander
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=35850#35850
>
>
>
>
>
> ___
> 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] osgText::Text change size during culling
Hi Andreas, If you are modifying text dynamically in the application then you should set the text DataVariance to DYNAMIC so that the draw traversal knows to hold back the next frame till all the dynamic drawables and state have been dispatched. Robert. On Mon, Jan 24, 2011 at 4:07 PM, Andreas Roth wrote: > Hi, > > I want to create a billboard with an icon and a text. I noticed that it > cannot use SCREEN_COORDS, when i use my own Billboard. It don't want the text > to rotate to screen, i just want the scale-to-screen functionality. To > accomplish that i tried to set the character size during the update pass my > application crashes. It crashes after some traversals are done. It seems to > be a problem, when the viewer renders the scene and another thread does the > update traversal and replaces some data used to render the text object. > Is this behaviour intended or is it a bug? > > Thank you! > > Cheers, > Andreas > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=35926#35926 > > > > > > ___ > 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] osgText::Text change size during culling
Hi, I want to create a billboard with an icon and a text. I noticed that it cannot use SCREEN_COORDS, when i use my own Billboard. It don't want the text to rotate to screen, i just want the scale-to-screen functionality. To accomplish that i tried to set the character size during the update pass my application crashes. It crashes after some traversals are done. It seems to be a problem, when the viewer renders the scene and another thread does the update traversal and replaces some data used to render the text object. Is this behaviour intended or is it a bug? Thank you! Cheers, Andreas -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35926#35926 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Optimizing scene structure and geometry
-Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien Guay Sent: Monday, January 24, 2011 10:35 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Optimizing scene structure and geometry Hi Gordon, > Just little FYI , you can build texture atlases that repeat the caveat being > they can only repeat in one direction so you can build vertical and > horizontal sets :) Yeah, but OSG's TextureAtlasVisitor just rejects textures as soon as they repeat in any direction. If there's another better tool that I can use on an OSG database I'd like to hear about it :-) GT: That's a shame :(, I know Multigen Creators has tools (since around 3.0) than can create composite textures that can have single repeat in Vert or Horiz as well as no repeat, but probably not much help to you > I would also say the 1k verts per primitive set is lowish I would say you can > look at 10k or more on modern hardware ( assuming you model(s) that many) Most of our models are pretty low poly, as you can see in the stats I sent the total number of polys is pretty low compared to the number of transforms. I might be able to get close to 1k but apart from the static scenery, I doubt I'll be able to go higher than that. Still, it's another data point to consider. Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Optimizing scene structure and geometry
Hi Gordon, Just little FYI , you can build texture atlases that repeat the caveat being they can only repeat in one direction so you can build vertical and horizontal sets :) Yeah, but OSG's TextureAtlasVisitor just rejects textures as soon as they repeat in any direction. If there's another better tool that I can use on an OSG database I'd like to hear about it :-) I would also say the 1k verts per primitive set is lowish I would say you can look at 10k or more on modern hardware ( assuming you model(s) that many) Most of our models are pretty low poly, as you can see in the stats I sent the total number of polys is pretty low compared to the number of transforms. I might be able to get close to 1k but apart from the static scenery, I doubt I'll be able to go higher than that. Still, it's another data point to consider. Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com 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
Re: [osg-users] Optimizing scene structure and geometry
Hi J-S, No, we use the ViewBounds type. and I forgot to mention in my arguments to reproducing the results in the osgshadow example that I also used ViewBounds. Sorry about that, seems even with my very long post I was still missing some specifics :-) Command line for osgshadow was not indicating this. Default is DrawBounds and I assumed you use this. One problem unfortunately is that some textures could not be included in the atlases (because they are set to REPEAT), and sometimes not only textures change, but also some render state such as cull face (some fences made with a single polygon set to render both sides, for example). I'll have to get our artist to model these kinds of things as boxes, and replace the textures set to REPEAT. Yeah, but if we can remove texture state attributes we may usually get rid of majority of StateSets and end up with really small number of unique StateSets created by combinations of remaining attributes. Textures cannot be always put into Texture atlasses thats why we finally built Texture2DArray. Btw I just noticed you mentioned that you can send your DB for others to check. If you want you may send it to me, I may try to run the same tool on your DB and report what I got. Cheers, Wojtek ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Optimizing scene structure and geometry
Hi JS Just little FYI , you can build texture atlases that repeat the caveat being they can only repeat in one direction so you can build vertical and horizontal sets :) I would also say the 1k verts per primitive set is lowish I would say you can look at 10k or more on modern hardware ( assuming you model(s) that many) Gordon Tomlinson 3D Technology System Engineering Consultant Overwatch® An Operating Unit of Textron Systems __ "WARNING: Documents that can be viewed, printed or retrieved from this E-Mail may contain technical data whose export is restricted by the Arms Export Control Act (Title 22, U.S.C., Sec 2751, et seq,) or the Export Administration Act of 1979, as amended, Title 50, U.S.C., App. 2401 et seq. and which may not be exported, released or disclosed to non-U.S. persons (i.e. persons who are not U.S. citizens or lawful permanent residents ["green card" holders]) inside or outside the United States, without first obtaining an export license. Violations of these export laws are subject to severe civil, criminal and administrative penalties." -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien Guay Sent: Monday, January 24, 2011 9:36 AM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Optimizing scene structure and geometry Hi Tim and Robert, OK, a few great suggestions, and a possible answer to why the work I've done hasn't sped things up that much. First, I've been focusing mostly on automatic optimizations that I can code up in some processing tool since we already do that now (we use osgconv to convert all our models to ive, so in the past week I've been writing my own tool that uses parts of osgconv, the osgUtil::Optimizer and some slightly modified classes to give better results on our data). My goal was to be minimally intrusive on my artist's work. But I think I'm at a point now that I'll have to get him to modify some things... For the number of transforms, I doubt I'll be able to do much to lower it, since it's a central part of our infrastructure that physics objects are attached to transforms (with the physics object's transformation being copied to the transform node each step). We might be able to get some other kind of relationship, but not in the short term. So I'll have to work on some other areas. Reducing the number of statesets is a worthy goal, I've already tried (building texture atlases mostly). I've gone from over 2500 statesets to 1345 in the stats I gave in my OP. The next steps will be to get my modeler to remove most parts of models set to render both sides (cull face off) and as Tim suggested removing textures set to REPEAT since those are two things that defeat atlas building sometimes. Using the INDEX_MESH | VERTEX_POSTTRANSFORM | VERTEX_PRETRANSFORM optimizers is a good idea, up until now I was compiling my tool against the same version of OSG as our simulator uses (2.8.3) though, so I couldn't use them. I'll see if I can backport them to that version and see if they give better results. About the state graph number. I guess that's pretty much proportional to the number of unique statesets in the graph? I'm at 1345 now, I guess if I get that number down it should reduce the number of state graphs? Tim mentions keeping a figure of about 1000 verts per primitive set in mind. That's good info. It's really hard to find numbers that you can relate to the stats you see in the OSG stats display. Thanks a lot, I'll keep working on it and keep you updated. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Optimizing scene structure and geometry
Hi Tim and Robert, OK, a few great suggestions, and a possible answer to why the work I've done hasn't sped things up that much. First, I've been focusing mostly on automatic optimizations that I can code up in some processing tool since we already do that now (we use osgconv to convert all our models to ive, so in the past week I've been writing my own tool that uses parts of osgconv, the osgUtil::Optimizer and some slightly modified classes to give better results on our data). My goal was to be minimally intrusive on my artist's work. But I think I'm at a point now that I'll have to get him to modify some things... For the number of transforms, I doubt I'll be able to do much to lower it, since it's a central part of our infrastructure that physics objects are attached to transforms (with the physics object's transformation being copied to the transform node each step). We might be able to get some other kind of relationship, but not in the short term. So I'll have to work on some other areas. Reducing the number of statesets is a worthy goal, I've already tried (building texture atlases mostly). I've gone from over 2500 statesets to 1345 in the stats I gave in my OP. The next steps will be to get my modeler to remove most parts of models set to render both sides (cull face off) and as Tim suggested removing textures set to REPEAT since those are two things that defeat atlas building sometimes. Using the INDEX_MESH | VERTEX_POSTTRANSFORM | VERTEX_PRETRANSFORM optimizers is a good idea, up until now I was compiling my tool against the same version of OSG as our simulator uses (2.8.3) though, so I couldn't use them. I'll see if I can backport them to that version and see if they give better results. About the state graph number. I guess that's pretty much proportional to the number of unique statesets in the graph? I'm at 1345 now, I guess if I get that number down it should reduce the number of state graphs? Tim mentions keeping a figure of about 1000 verts per primitive set in mind. That's good info. It's really hard to find numbers that you can relate to the stats you see in the OSG stats display. Thanks a lot, I'll keep working on it and keep you updated. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com 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
Re: [osg-users] Optimizing scene structure and geometry
Hi Wojtek, You have not mentioned which lispsm is used but if thats DrawBounds (flavour) it does 2 extra cull & render passes. No, we use the ViewBounds type. and I forgot to mention in my arguments to reproducing the results in the osgshadow example that I also used ViewBounds. Sorry about that, seems even with my very long post I was still missing some specifics :-) Our DBs are also made from small batches. My observations were that not only the size of primitive sets but small state attribute changes between them were hitting hard as well. Yeah, I had also noticed the large number of state sets and state graphs, and Tim remarked this in his reply too. I'll have a look at reducing that in the next few days. I once did an experiment. We had a DB that was suffering from small batches problem. I have built Texture Atlases, then put all the scene Textures into single Texture2DArray (yes it was huge). Then I removed Statesets and created only one StateSet at scene root with Shaders to use Texture2DArray I built. I think I have not done anything to primitve sets they were the same as before only StateSets were gone. And framerate went up 2 times. Very interesting results. I guess I could make a simple test of traversing our scene graph removing all statesets after loading the scene, and seeing if the framerate improves significantly then. That would at least tell me I'm on the right track with attacking the number of statesets. One problem unfortunately is that some textures could not be included in the atlases (because they are set to REPEAT), and sometimes not only textures change, but also some render state such as cull face (some fences made with a single polygon set to render both sides, for example). I'll have to get our artist to model these kinds of things as boxes, and replace the textures set to REPEAT. Thanks for your insight, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com 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
Re: [osg-users] Jitter problem - OSG & Nvidia Physx
HI It might help if you tell us how you define Jitter as this can mean many things to different people Gordon Tomlinson 3D Technology System Engineering Consultant Overwatch® An Operating Unit of Textron Systems __ "WARNING: Documents that can be viewed, printed or retrieved from this E-Mail may contain technical data whose export is restricted by the Arms Export Control Act (Title 22, U.S.C., Sec 2751, et seq,) or the Export Administration Act of 1979, as amended, Title 50, U.S.C., App. 2401 et seq. and which may not be exported, released or disclosed to non-U.S. persons (i.e. persons who are not U.S. citizens or lawful permanent residents ["green card" holders]) inside or outside the United States, without first obtaining an export license. Violations of these export laws are subject to severe civil, criminal and administrative penalties." -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Arif Yetkin Sarı Sent: Monday, January 24, 2011 4:45 AM To: osg-users@lists.openscenegraph.org Subject: [osg-users] Jitter problem - OSG & Nvidia Physx Hello everyone. We have been using OSG with nvidia physx for a driving simulation and we have jitter problem, where the cars and other objects in the scene (controlled by the physics) jitter annoyingly :). We believe that we update the scenegraph in a wrong way. In our code : There is a physx thread. There is an OSG library thread where we can add new entities, remove them, start rain effects, call an animation of a skeleton character etc. There is an OSG render loop thread, where osgviewer::...frame() is called. Our Nvidia physx thread produces new "x y z pitch head roll" values for the scene entities at 60Hz (or any other frequency we want). Physx thread calls the updateEntity() function of our OSG library thread. This function simply updates scene entities with matrixtransform::void setMatrix(const Matrix& mat). In other words, we move an object with this chunk of code: Code: osg::Matrixd mxT = createTransformMatrix(x,y,z,h,p,r); mt->setMatrix(mx); Here what we tried: 1-we fed OSG lib directly whenever a physx output is produced (every 16.6 ms or so - 60Hz): there is jitter. 2-we maintained a queue of frames on OSG lib, fed OSG at the end of each frame() : there is jitter. 3-we implemented a sampling mechanism on this queue, where OSG requests the interpolated frame from the queue for the current timestamp : there is jitter. 4-we saved a few minutes long log of the physx to a file (many frames). Started a dummy thread, and fed OSG from this log. : there is jitter. When OSG works with 60FPS, and physx thread is running at 60Hz, there seems to be quite low jitter (sometimes unnoticeable) . Thanks in advance for any hints or advices. Arif Yetkin http://www.youtube.com/watch?v=naX3hOkDx8w -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35912#35912 ___ 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] Visibility of point array
Hi Sergey, Thanks for the code example! I will try to get it to work but I might need some days, this is the first custom shader I'm using. Cheers, Oliver -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35914#35914 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture Buffer Objects status?
Hi Juan, I finally managed to make it work. Can't understand exactly what was wrong, I got mangled into several issues at the same time (signed/unsigned sampler1D vs buffer, ATI (bogus) compiler vs nvidia, texture originally too large, incorrect pixel formats...). I just ended up checking every line of code and things actually finally run fine. Your code is fine, thanks for submitting it here. I don't know if this is the best way to implement this, especially w.r.t the buffer object base classes in OSG (osg/BufferObject). Questions like that would be raised on submission for possible inclusion in the OSG code, I guess. Fred -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35913#35913 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Jitter problem - OSG & Nvidia Physx
Hello everyone. We have been using OSG with nvidia physx for a driving simulation and we have jitter problem, where the cars and other objects in the scene (controlled by the physics) jitter annoyingly :). We believe that we update the scenegraph in a wrong way. In our code : There is a physx thread. There is an OSG library thread where we can add new entities, remove them, start rain effects, call an animation of a skeleton character etc. There is an OSG render loop thread, where osgviewer::...frame() is called. Our Nvidia physx thread produces new "x y z pitch head roll" values for the scene entities at 60Hz (or any other frequency we want). Physx thread calls the updateEntity() function of our OSG library thread. This function simply updates scene entities with matrixtransform::void setMatrix(const Matrix& mat). In other words, we move an object with this chunk of code: Code: osg::Matrixd mxT = createTransformMatrix(x,y,z,h,p,r); mt->setMatrix(mx); Here what we tried: 1-we fed OSG lib directly whenever a physx output is produced (every 16.6 ms or so - 60Hz): there is jitter. 2-we maintained a queue of frames on OSG lib, fed OSG at the end of each frame() : there is jitter. 3-we implemented a sampling mechanism on this queue, where OSG requests the interpolated frame from the queue for the current timestamp : there is jitter. 4-we saved a few minutes long log of the physx to a file (many frames). Started a dummy thread, and fed OSG from this log. : there is jitter. When OSG works with 60FPS, and physx thread is running at 60Hz, there seems to be quite low jitter (sometimes unnoticeable) . Thanks in advance for any hints or advices. Arif Yetkin http://www.youtube.com/watch?v=naX3hOkDx8w -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35912#35912 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Optimizing scene structure and geometry
Hi, The KdTrees in the OSG do not affect the cull traversal in any way whatsoever. KdTree we have only affect the intersection performance. Robert. 2011/1/23 Полищук Сергей : > Hi, > > I think you can reduce cull time with build kdtrees option in osgdb registry > or env var OSG_BUILD_KDTREES (if you not already using it). As for draw its > related to large number of state changes i believe, so you should try to > merge statesets. Large number of primitive sets is kinda bad, but with > display lists (at least on nvidia hardware) it's dont hurt that much actually. > > 22.01.2011, 00:13, "Jean-Sébastien Guay" : >> Hi all, >> >> I thought I had a pretty firm grasp on what to optimize given a certain >> set of scene stats, but I've optimized what I can and I'm still getting >> little improvement in results. So I'll explain my situation here and >> hope you guys have some good suggestions. Sorry if this is a long >> message, but I prefer to give all the relevant data now rather than get >> asked later. >> >> The whole scene is about a 200m x 200m square (apart from the ocean and >> skydome but these are not significant, I have removed them and confirmed >> that the situation is the same). The worst case viewpoint is a flying >> view where the whole scene could be visible at once. So I need to >> balance culling cost with draw cost, since in some views we will see >> only part of the scene (so we should be able to cull away at least part >> of what's not visible) and in the flying view everything is visible so >> we shouldn't waste too much time doing cull tests which we know will not >> cull anything. >> >> The other thing is that there are a lot of dynamic objects, so there are >> a lot of transforms. But I can't change this, it's part of our simulation. >> >> So, after doing some optimization (removing redundant groups, building >> texture atlases where possible, merging geodes and geometry, generating >> triangle strips, most of which I did with the osgUtil::Optimizer), I get >> the following stats, which I'll talk about a bit later: >> >> Scene stats: >> StateSets 1345 >> Groups 392 >> Transforms 672 >> Geodes 992 >> Geometry 992 >> Vertices 139859 >> Primitives 87444 >> >> Camera stats: >> State graphs 1282 >> Drawables 2151 >> PrimitiveSets 73953 >> Triangles 3538 >> Tri. Strips 211091 >> Tri. Fans 16 >> Quads 11526 >> Quad Strips 534 >> Total primitives 226705 >> >> And, both in our simulator and in osgViewer, for the same scene and same >> viewpoint, I get: >> >> FPS: ~35 >> Cull: 5.4ms >> Draw: 19ms >> GPU: 19ms >> >> This is on a pretty good machine: Core i7 920, GeForce GTX 260. >> >> First of all, the stats above tell me that the "Primitives" part of the >> scene stats refers to primitive sets, not just primitives... Since the >> camera stats tell me there are over 226000 primitives in the current view. >> >> As you can see, the number of primitiveSets is very high. If I >> understand correctly, each PrimitiveSet will result in an OpenGL draw >> call, and since my draw time is what's high now, I would want to reduce >> that (since I'm currently at about 3 primitives per primitiveSet on >> average). If I remove triangle strip generation from the optimizer >> options, the stats become: >> >> Scene stats: >> StateSets 1345 >> Groups 392 >> Transforms 672 >> Geodes 992 >> Geometry 992 >> Vertices 190392 >> Primitives 51197 >> >> Camera stats: >> State graphs 1254 >> Drawables 2117 >> PrimitiveSets 4899 >> Triangles 17122 >> Tri. Strips 191 >> Tri. Fans 7212 >> Quads 106464 >> Quad Strips 534 >> Total primitives 131523 >> >> This indicates to me that the tristrip visitor in the optimizer does a >> pretty bad job. I looked at an .osg dump, and it seems to generate a >> separate strip for each quad (so one strip for 4 vertices) which is >> ridiculous... But that's a subject for another day. >> >> When I disabled the tristripper, you can see a massive decrease in the >> number of primitiveSets (and even in the number of primitives), however >> there was no significant change in the frame rate and timings. I don't >> understand this. I would have expected, with more primitives per >> primitiveSet (I'm now at about 26 prims per primSet on average, as >> opposed to around 3 before) and much less draw calls, that the draw time >> would have been much lower. That's not what happens in practice. >> >> My previous attempts at optimizing (using the osgUtil::Optimizer) were >> also centered around lowering the number of primitives (by creating >> texture atlases and sharing state so the merging of geodes and geometry >> objects gave good results). And even though that also lowered the >> numbers (I started at around 2215 Geodes and 2521 Geometry objects in >> the same scene, compare that to 992 each now), it also h
Re: [osg-users] osg::Quat
Hi, Ok, Thank you for your reply! Cheers, lucie -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35910#35910 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
