Re: [osg-users] Request for input
Hi, On 26/01/2012 01:20, Jason Daly wrote: On 01/25/2012 04:59 PM, Jason Daly wrote: Hi, all, This is a general request to the community for some advice and expertise. This is a bit lengthy, but if you can spare a few minutes to look over this and send along your thoughts, we would really appreciate it. very interesting and thorough investigation. I can't really add anything and unfortunately don't have representative hardware to test on. It would be interesting to see if different bus configs (motherboards/chipsets) make any difference. I also would not rule out the NVidia driver doing silly things. I remember once looking at some of the glue code for the binary blob and seeing TLB flushes that caused a Xenomai kernel to fail ito timing in interesting ways. Have you tried OProfile to get some idea of time spent in the driver? I should also mention that the source code and data sets used in this work can be made available if anyone would like to try these tests on their own hardware. I suggest sending your test apps with your report to NVidia. rgds jp --"J" ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Render osgViewer::View main camera view solely to texture using FBO
Hi again, Thanks for following up. I've tried it before with an attached pbuffer, but was - and still have been - getting unpredictable results. As before, if I simply place a camera as a node in the scene and attach a texture with FBO implementation, it will render the subgraph to the texture no problem. If I attach a texture to the main or slave camera of a view, whether I use a pbuffer for offscreen rendering or have a separate window, the texture will simply be filled with random data in video memory. The camera will otherwise work properly, as if I comment out any RTT-related lines and change the graphics context to the window's, it will render to a viewport without issues. I would have simply used the currently working method and updated the camera's matrices directly, but we're using more complex manipulators and making that functionality redundant is an ugly solution. I took a look at examples like osgdistortion, and, implementation purposes aside, can't see any differences in camera and scene setup that might cause this. It clearly has to be me, given the fact that this exact functionality is used as an example and I've gotten the same result on two different computers (running Windows 7 on Nvidia GTX460/560). -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=45029#45029 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for input
Hi Jason, Any thoughts on these issues or other thoughts you could provide would be very valuable. I don't have that much to add. I commend you on your investigations, you really went to the crux of the problem and kept at it until you found the answer. The mesh optimizers I've mentioned in the past (and I was tipped off to them by others, so it's not my own idea :-) ) really helped in the problem cases I was investigating too. I think it's really easy for modeling programs to produce bad data, and it's really hard in general to see that it's bad data until it's too late. Some bad aspects of the data can be dealt with by doing a post-optimization on the artists' data, but some bad aspects are very hard to automatically optimize and so require knowledge. Us 3D programmers have this task in addition to all our programming duties, we have to educate the data producers and others to be able to make good data! :-) ---(aside)--- As a side note, I think OSG suffers a bit from not having a "blessed" content creation pipeline. It allows implementers and users total flexibility, but also in so doing assumes a lot of knowledge that might not be there or take a long time to acquire, and indirectly promotes unoptimized bad data as described above. At a minimum, I would see benefit to adding a) a set of "standard" export plugins for the most popular 3D modeling applications (3DSMax, Maya, Blender) which all give the same results and have the same options. b) a "standard" optimizer that produces optimized models and textures. This optimizer would essentially be a beefed up osgconv that would do some optimizations automatically. These would need to be maintained beside OSG itself so that people who download OSG will immediately know they can use them, instead of explicitly having to know they exist and searching for them (like the current Maya, Max and Blender plugins). It's a large task, but I think it's totally worth it. ---(/aside)--- I think the remaining case that is not scaling well might indeed be down to some other part of OSG or the OpenGL driver that is being exercised more in that example than in others. Hard to say really, but if it's a plausible use case you can probably use the same methodology you used to investigate the previous issue, and you'll find the cause. J-S -- __ Jean-Sebastien Guay jean_...@videotron.ca http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgdem segmentation fault
osgdem --xx 10 --yy 10 -t ps_texture_16k.tif --xx 10 --yy 10 -d ps_height_16k.tif -l 8 -v 0.1 -o puget.ive -a pegout.osga Warning: archive option -a is temporarily disabled, building with archive. --xx 10 --yy 10 -t ps_texture_16k.tif ADD: ps_texture_16k.tif loaded layer ps_texture_16k.tif --xx 10 --yy 10 -d ps_height_16k.tif ADD: ps_height_16k.tif loaded layer ps_height_16k.tif -o puget.ive Adding terrainTile DataSet::_run() 0 0 Now checking for plug-in osgPlugins-3.0.0/osgdb_nvtt.so DataSet::assignDestinationCoordinateSystem() : assigning first source file as the destination coordinate system started DataSet::createDestination(8) Time for after_reproject 0.08 DataSet::assignDestinationCoordinateSystem() : assigning first source file as the destination coordinate system local_extents = xMin() 0.00 163850.00 yMin() 0.00 163850.00 AR=1.00 C1=1 R1=1 createNewDestinationGraph Time for _destinationGraph->computeMaximumSourceResolution() = 0.005384 Time for createDestinationGraph 0.038835 Time for after_computeNeighbours 0.005547 completed DataSet::createDestination(8) There are 2 contributing source files: ps_height_16k.tif ps_texture_16k.tif Segmentation fault -- Regards, Rashad ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for input
On 01/25/2012 04:59 PM, Jason Daly wrote: Hi, all, This is a general request to the community for some advice and expertise. This is a bit lengthy, but if you can spare a few minutes to look over this and send along your thoughts, we would really appreciate it. I should also mention that the source code and data sets used in this work can be made available if anyone would like to try these tests on their own hardware. --"J" ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Render to FBO and multiSamples
Hi, I use a camera to render my main graph to an FBO. Then I render this FBO to screen with another camera and a quad. Like this : Code: Main camera (render to FBO) | |-- Main graph | |--- Camera (render to screen) | |- Quad I try to setup multisampling for the main camera : Code: p_camera->setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT); p_camera->attach(osg::Camera::COLOR_BUFFER, p_renderTextureColor, 0, 0, false, 4, 4); p_camera->attach(osg::Camera::DEPTH_BUFFER, p_renderTextureDepth, 0, 0, false, 4, 4); I also try to set "sampleBuffers" and "samples" on the traits before creating context, but all I get is a black screen. When I render to screen, MSAA works great, but how to configure it for a FBO target ? My textures are created as follow : Code: // Main color texture p_renderTextureColor = new osg::Texture2D(); p_renderTextureColor->setTextureSize(p_osgViewport->width(), p_osgViewport->height()); p_renderTextureColor->setInternalFormat(GL_RGBA32F_ARB); p_renderTextureColor->setSourceFormat(GL_RGBA); p_renderTextureColor->setSourceType(GL_FLOAT); p_renderTextureColor->setFilter(osg::Texture2D::MIN_FILTER, osg::Texture2D::NEAREST); p_renderTextureColor->setFilter(osg::Texture2D::MAG_FILTER, osg::Texture2D::NEAREST); p_renderTextureDepth->setWrap(osg::Texture::WRAP_S, osg::Texture::CLAMP_TO_EDGE); p_renderTextureDepth->setWrap(osg::Texture::WRAP_T, osg::Texture::CLAMP_TO_EDGE); // Main depth texture p_renderTextureDepth = new osg::Texture2D(); p_renderTextureDepth->setTextureSize(p_osgViewport->width(), p_osgViewport->height()); p_renderTextureDepth->setSourceFormat(GL_DEPTH_COMPONENT); p_renderTextureDepth->setSourceType(GL_FLOAT); p_renderTextureDepth->setInternalFormat(GL_DEPTH_COMPONENT32F); p_renderTextureDepth->setFilter(osg::Texture2D::MIN_FILTER, osg::Texture2D::NEAREST); p_renderTextureDepth->setFilter(osg::Texture2D::MAG_FILTER, osg::Texture2D::NEAREST); p_renderTextureDepth->setWrap(osg::Texture::WRAP_S, osg::Texture::CLAMP_TO_EDGE); p_renderTextureDepth->setWrap(osg::Texture::WRAP_T, osg::Texture::CLAMP_TO_EDGE); Any help would be greatly appreciated. Aurelien -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=45024#45024 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Android GLES2 example help
Thanks for your kind reply. I have found only 2 instances of LOCAL_ARM_NEON := true one in /PlatformSpecifics/Android/Android.mk.modules.in and one in the Android.mk file of the example. I commented them out but the final result is the same. Am I missing any more of these? Any other suggestion would be welcome. thanks again. Cheers, Maurizio -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=45023#45023 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Request for input
Hi, all, This is a general request to the community for some advice and expertise. This is a bit lengthy, but if you can spare a few minutes to look over this and send along your thoughts, we would really appreciate it. I've been working on a project for NIST recently. For background, you might find this osg-users thread from December 2010 useful: http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/63954/focus=64014 Briefly, an OSG-based test application loads a scene and displays it in a window on one or more screens (Single Viewer, multiple slave cameras, one GPU and context per screen). The problem was that a single screen would draw the scene at a given frame rate, but as additional screens were added, the frame rate would drop significantly (427 fps on one screen, 396 fps on two, 291 on four). Given that the scene is identical and static, four contexts on four GPUs should be able to draw at or at least very nearly the same rate as one screen on one GPU. Based on initial tests (including running a non-OSG, OpenGL-based program), we first suspected that the problem had to do with thread contention inside of OSG itself. To get to the bottom of this, I added a per-thread logging mechanism to OpenThreads::PThread, which allowed each thread to output to a unique file. Using this, I added some timing code at various places in the rendering process. I started with timing the various Operations at the high level, then I started digging into the various function calls, placing timing code at the important points along the way. I eventually drilled all the way down to PrimitiveSet::draw(), and at that level, it became obvious that the code that was taking all of the time (and not scaling well to multiple screens) was the OpenGL draw call itself. For example, on one screen a given PrimitiveSet would take 0.05 ms, and on two screens, it would take 0.11 ms on the first screen and 0.12 ms on the second (roughly twice the amount of time). At this point it was beginning to look like it wasn't OSG's fault. To be sure, I decided to write a pure multithreaded OpenGL program from scratch. I tried to keep the rendering structure the same as OSG (without the scene graph structure, or the update and cull traversals, of course). I wrote enough of a .osg file loaded so that I could load the same data with the same structure, and produce the same OpenGL command stream when drawing a frame as OSG does (verified with gDEBugger). Once this was complete, we saw a similar lack of scalability as additional screens were added (708 fps on one screen, 702 fps on two, 376 fps on four). At this point, I started looking for something else to blame. Examining the data set itself, I discovered that it was composed of about 5500 triangle strips, none of which were longer than 112 vertices (the data set had about 600,000 vertices total). There were only about 10 different StateSets in the scene, so state changes aren't a problem. After some digging, I found the MeshOptimizers portion of osgUtil::Optimizer, and based on a message I found from Jean-Sebastian, I tried a pass of VERTEX_PRETRANSFORM | INDEX_MESH | VERTEX_POSTTRANSFORM, followed by another pass of MERGE_GEODES | MERGE_GEOMETRY. This reduced the number of draw calls from around 5500 to 9, and completely eliminated the scalability problem for both the OSG test program, and the pure OpenGL program. This leads me to believe that bus contention was causing the lack of scalability. As more screens were added, the thousands of draw calls required by the unoptimized data set couldn't fit within the bus bandwidth, effectively causing the draw calls to take longer. The unoptimized data, only requiring 9 draw calls per screen, could easily fit. To demonstrate this effectively, I created a variation of the original OSG test program that would run render the original test data for a given time period, then run a configurable set of optimization passes, and then render the optimized data for a given time period. It then reported the pre-optimization and post-optimization frame rates. We also tried amplifying the data by essentially instancing it 8 times and 64 times (not using instanced drawing, just drawing multiple copies of the same data). We ran the new OSG test app, applying the same optimizations as mentioned above, as well as running the same data (both unoptimized and optimized) through the pure OpenGL program. I've attached the timings for two complete runs. The 1x and 8x data sets appear to scale well in all cases, except for one anomalous case where the fps drops from 76.77 fps on three screens to 53.26 on four (the subsequent run only drops to 70.89, so this may not be a real problem). The 64x data sets are more interesting. The OpenGL program clearly scales well (almost perfectly, in fact) on the optimized data. The OSG program doesn't scale as well, dropping to 8
Re: [osg-users] osgconv with fbx
Hi, Martin, the FBX plugin requires the FBX SDK: http://www.openscenegraph.org/projects/osg/wiki/Support/UserGuides/Plugins<%20http://www.openscenegraph.org/projects/osg/wiki/Support/UserGuides/Plugins> Regards 2012/1/25 Martin Haffner > Hi, > > I wanted to convert a .fbx file to an .osgb, but unfortunately I always > get an error: > Warning: Could not find plugin to read objects from file > "Per3D05MaleAnimatedTx3.fbx". > Error no data loaded. > I check my osgPlugins-3.1.0 folder and it does not contain any > osgdb_fbx.so file. > Are there any special steps needed to build such an osgdb_fbx.so file? > > > Thank you! > > Cheers, > Martin > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=45010#45010 > > > > > > ___ > 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] Backing up osg State
Hi Philip, On 25 January 2012 16:45, Philipp Moeller > The copy is not the problem the assignment is (The operator= is needed > here as this is not the point of declaration). osg::Objects operator= is > private which default deletes the assignment operator in all base > classes and I don't really get why. So it looks like this is by design > although it would be nice to have. There is no copy operator by design. Copying elements in a scene graph is rather open ended as the objects within the graph have children (UseData on osg::Light is a form of child) so you have think about what happens with the child objects - this is what CopyOp's role is, but this obviously isn't available with the standard C++ = operator. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Backing up osg State
Robert Osfield writes: > Hi Philipp > > On 25 January 2012 15:37, Philipp Moeller > wrote: >> I'd like to back-up some osg::StateAttribute for the simple purpose of >> restoring it, if some dialog in my application is rejected. >> >> I'd would like to have something as easy as >> >> Light* light; >> ref_ptr backup = new Light(*light, >> osg::CopyOp(osg::CopyOp::DEEP_COPY_ALL)); >> //back up >> *light = *backup; >> >> This obviously does not work, as Light has no assigment >> operator. > > It should work as it has a copy constructor, it doesn't need a copy > operator for this task. The copy is not the problem the assignment is (The operator= is needed here as this is not the point of declaration). osg::Objects operator= is private which default deletes the assignment operator in all base classes and I don't really get why. So it looks like this is by design although it would be nice to have. > > You can also call clone() if you want. > > Robert. > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Backing up osg State
Hi Philipp On 25 January 2012 15:37, Philipp Moeller wrote: > I'd like to back-up some osg::StateAttribute for the simple purpose of > restoring it, if some dialog in my application is rejected. > > I'd would like to have something as easy as > > Light* light; > ref_ptr backup = new Light(*light, > osg::CopyOp(osg::CopyOp::DEEP_COPY_ALL)); > //back up > *light = *backup; > > This obviously does not work, as Light has no assigment > operator. It should work as it has a copy constructor, it doesn't need a copy operator for this task. You can also call clone() if you want. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Backing up osg State
I'd like to back-up some osg::StateAttribute for the simple purpose of restoring it, if some dialog in my application is rejected. I'd would like to have something as easy as Light* light; ref_ptr backup = new Light(*light, osg::CopyOp(osg::CopyOp::DEEP_COPY_ALL)); //back up *light = *backup; This obviously does not work, as Light has no assigment operator. Copying every attribute and resetting them manually seems like an easy work-around but is not forward compatible or maintainable. Copying the state and using the copy in case of rejection is also possible but quite ugly. Is there something I'm missing or is working around that the only way to do it? -- Philipp Moeller, GeometryFactory ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgconv with fbx
Hi, I wanted to convert a .fbx file to an .osgb, but unfortunately I always get an error: Warning: Could not find plugin to read objects from file "Per3D05MaleAnimatedTx3.fbx". Error no data loaded. I check my osgPlugins-3.1.0 folder and it does not contain any osgdb_fbx.so file. Are there any special steps needed to build such an osgdb_fbx.so file? Thank you! Cheers, Martin -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=45010#45010 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [osgOcean] disabling LOD
Howdy folks, is there a way to control (or disable) the LOD in osgOcean? I am trying to simulate a camera on a UAV that is tracking ships at very large standoff distances and at very high zoom. Because of the large distance between the camera and the ocean scene, the ocean looks way too flat around the ship in the image. Thank you! Cheers, bart -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=45009#45009 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Error with multiple camera
i did an other solution reproducing this problem, with a viewer reproducing
same simplified graph with only one camera and result is the good.
Code is :
GraphComplet.h
Code:
#pragma once
#include
#include
#include
class GraphComplet{
public:
GraphComplet();
osg::Node * getMainNode();
void moveObject(int obj, osg::Vec3 newPos);
private:
osg::ref_ptr root;
osg::ref_ptr cam1;
osg::ref_ptr cam2;
osg::ref_ptr cam3;
osg::ref_ptr cam4;
osg::Switch * createSousGraph(std::string modelFilePath,osg::Vec3 pos);
};
GraphComplet.cpp
Code:
#include "GraphComplet.h"
#include
#include
GraphComplet::GraphComplet()
{
root = new osg::Group;
root->addChild(new osg::Group);
cam1 = new osg::Camera();
cam2 = new osg::Camera();
cam3 = new osg::Camera();
cam4 = new osg::Camera();
root->getChild(0)->asGroup()->addChild(new osg::Group);
root->getChild(0)->asGroup()->addChild(new osg::Group);
root->getChild(0)->asGroup()->getChild(0)->asGroup()->addChild(cam2);
root->getChild(0)->asGroup()->getChild(0)->asGroup()->addChild(cam1);
root->getChild(0)->asGroup()->getChild(1)->asGroup()->addChild(cam4);
root->getChild(0)->asGroup()->getChild(1)->asGroup()->addChild(cam3);
cam1->addChild(new osg::Group);
cam1->addChild(createSousGraph("data\\model.3DS",
osg::Vec3(0.0,0.0,0.0)));
cam3->addChild(new osg::Group);
cam3->addChild(createSousGraph("data\\model.3DS",
osg::Vec3(10.0,0.0,0.0)));
cam1->setClearMask(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
cam2->setClearMask(0);
cam3->setClearMask(0);
cam4->setClearMask(0);
cam1->setRenderOrder(osg::Camera::PRE_RENDER,1);
cam2->setRenderOrder(osg::Camera::PRE_RENDER,2);
cam3->setRenderOrder(osg::Camera::PRE_RENDER,3);
cam4->setRenderOrder(osg::Camera::PRE_RENDER,4);
}
osg::Node * GraphComplet::getMainNode()
{
return root.get();
}
osg::Switch * GraphComplet::createSousGraph(std::string modelFilePath,osg::Vec3
pos)
{
osg::Switch * retour = new osg::Switch;
retour->setAllChildrenOn();
osg::PositionAttitudeTransform * pat = new
osg::PositionAttitudeTransform;
retour->addChild(pat);
pat->setPosition(pos);
pat->addChild(osgDB::readNodeFile(modelFilePath));
return retour;
}
void GraphComplet::moveObject(int obj, osg::Vec3 newPos)
{
osg::PositionAttitudeTransform * toMove = NULL;
if(obj == 1)
{
toMove =
cam1->getChild(1)->asGroup()->getChild(0)->asTransform()->asPositionAttitudeTransform();
}
else if(obj == 2)
{
toMove =
cam3->getChild(1)->asGroup()->getChild(0)->asTransform()->asPositionAttitudeTransform();
}
if(toMove == NULL) return;
toMove->setPosition(newPos);
}
main.cpp
Code:
#include
#include
#include
#include
#include "GraphComplet.h"
#include
#define PI 3.14159265
#include
int main(int,char**)
{
osgViewer::Viewer v2;
v2.setCameraManipulator(new osgGA::TrackballManipulator());
v2.addEventHandler(new osgViewer::StatsHandler);
osg::Group * root = new osg::Group;
osg::PositionAttitudeTransform * patObjet1 = new
osg::PositionAttitudeTransform;
osg::PositionAttitudeTransform * patObjet2 = new
osg::PositionAttitudeTransform;
root->addChild(patObjet1);
root->addChild(patObjet2);
patObjet1->addChild(osgDB::readNodeFile("data\\3d-isuzu-bighorn.3DS"));
patObjet2->addChild(osgDB::readNodeFile("data\\3d-isuzu-bighorn.3DS"));
v2.setUpViewInWindow(600,10,600,600);
v2.setSceneData(root);
v2.realize();
GraphComplet * gc = new GraphComplet();
osgViewer::Viewer v;
v.setCameraManipulator(new osgGA::TrackballManipulator());
v.addEventHandler(new osgViewer::StatsHandler);
v.setSceneData(gc->getMainNode());
osg::Camera * cam = v.getCamera();
cam->setClearMask(0);
v.setUpViewInWindow(0,10,600,600);
v.realize();
osg::Vec3 pos(0,0,0);
double angle = 0;//angle en RAD
while(!v.done() && !v2.done())
{
gc->moveObject(2,pos);
patObjet2->setPosition(pos);
v.frame();
v2.frame();
angle+=0.003;
if(angle>=2*PI)
angle = 0;
pos.x() = 2000*cos(angle);
pos.y() = 2*sin(angle);
}
v.setDone(true);
v2.setDone(true);
return 0;
}
In left view their is the original result i must make it run with this Graph.
Right i have the same model in simple scene with same position for all items.
I must have miss one thing for
Re: [osg-users] KeyboardHandler - Moving an Object Forward
Hi,
you forget this
try:
Code:
class myKeyboardEventHandler : public osgGA::GUIEventHandler
{
public:
myKeyboardEventHandler(tankInputDeviceStateType* tids)
:tankInputDeviceState(tids) ;
{
}
virtual bool handle(const osgGA::GUIEventAdapter&
ea,osgGA::GUIActionAdapter&);
virtual void accept(osgGA::GUIEventHandlerVisitor& v) { v.visit(*this);
};
};
bool myKeyboardEventHandler::handle(const osgGA::GUIEventAdapter&
ea,osgGA::GUIActionAdapter& aa)
{
switch(ea.getEventType())
{
case(osgGA::GUIEventAdapter::KEYDOWN):
{
switch(ea.getKey())
{
case 'w':
tankInputDeviceState->moveFwdRequest = true;
return false;
break;
default:
return false;
}
}
default:
return false;
}
private:
tankInputDeviceStateType * tankInputDeviceState ;
}
Cheers
(http://www.hordes.fr?ref=litllechicken)
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=45006#45006
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
