[osg-users] Request for assistance to embark into PhD
Hello, Being a software engineer, I did my final project study in 3D animation and virtual reality visualization using OpenSceneGraph. Today I want to prepare my thesis in augmented reality. I'm looking for a good topic to prepare in 3 years. What are the themes of current research linking OpenSceneGraph and augmented reality? can you suggest me some possible topics ... for my future thesis? Thank you in advance ! Alji Mohamed ALJI Blog http://aljilogy.blogspot.fr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=56939#56939 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for assistance to embark into PhD
Hi, On Wed, Oct 23, 2013 at 10:51 AM, Mohamed Alji osgfo...@tevs.eu wrote: ** Hello, Being a software engineer, I did my final project study in 3D animation and virtual reality visualization using OpenSceneGraph. Today I want to prepare my thesis in augmented reality. I'm looking for a good topic to prepare in 3 years. What are the themes of current research linking OpenSceneGraph and augmented reality? can you suggest me some possible topics ... for my future thesis? Thank you in advance ! Alji Speaking as someone who did a PhD in virtual reality/computer graphics before, I think you need to look at it from a different angle. Don't look at What topic I can use OSG for. That isn't really interesting at all from a research point of view - OSG is a technology, a tool if you want. If you start with that, you are putting yourself into a really difficult position later on when you will have to explain your actual research contribution in your thesis. We engineers often fall into a trap of building contraptions - but that is engineering, not research. Find an open problem in AR and try to solve that. If you can use OSG to help you, great. If not, well, tough, but the research is the first goal, not to use OSG. I suggest that you speak to your future thesis director (did you find one already?) first - they could help you both by having an overview of the state of the art in the field you are looking at and by knowing what the requirements for a good thesis are. Good luck! Jan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] openscenegraph window in qt not showing
Hi,
what i'm doing:-
i'm creating an OpenSceneGraph based application by integrating
openscenegraph scene with QT GUI windowing system.
i'm using QML based UI navigation (QML views sits inside a QWidget which in
turn sits inside Borderlayout(as center widget) of Parent QWidget(main window)).
I'm switching QML UI's with signal slots mechanism, and on particular button
selection on QML view(qml signal to c++ QWidget), i'm removing current QML
view with QGLWidget which is paintaing OpenSceneGraph by calling osgViewer
frame() from paintEvent(QPaintEvent *):-
my problem :-
getting continues error on console : QOpenGLContext::swapBuffers()
called with non-exposed window, behavior is undefined
code(not full) :-
osg::Camera* createCamera(int x, int y, int w, int h )
{
osg::DisplaySettings* ds = osg::DisplaySettings::instance().get();
osg::ref_ptrosg::GraphicsContext::Traits traits = new
osg::GraphicsContext::Traits;
traits-windowDecoration = false;
traits-x = x;
traits-y = y;
traits-width = w;
traits-height = h;
traits-doubleBuffer = true;
osg::ref_ptrosg::Camera camera = new osg::Camera;
osgQt::initQtWindowingSystem();
QGLFormat format =
osgQt::GraphicsWindowQt::traits2qglFormat(traits.get());
osgQt::GLWidget* glwidget = new osgQt::GLWidget(format,0, 0, 0, true);
camera-setGraphicsContext(new osgQt::GraphicsWindowQt(glwidget));
camera-setClearColor( osg::Vec4(0.2, 0.2, 0.6, 1.0) );
camera-setViewport( new osg::Viewport(0, 0, traits-width,
traits-height) );
camera-setProjectionMatrixAsPerspective(40.0f,
static_castdouble(traits-width)/static_castdouble(traits-height),
0.1f, 1000.0f );
return camera.release();
}
class GuiMainWindow:public QWidget
{
Q_OBJECT
public:
GuiMainWindow()
{
QDesktopWidget desktop;
QRect screen= desktop.screenGeometry();
WIDTH=screen.width();
HIGHT=screen.height();
_camera=createCamera(0,0,WIDTH,HIGHT);
_osgroot=new osg::Group;
_osgroot-addChild(osgDB::readNodeFile(c:/data/tank.flt));
}
virtual void paintEvent(QPaintEvent *)
{
if(osg_init)
_viewer.frame();
}
void setOsgScene(osg::Group* root,osg::Camera* camera)
{
_viewer.setSceneData(root);
_viewer.setCamera(camera);
_viewer.setCameraManipulator(new osgGA::TrackballManipulator);
_viewer.setThreadingModel( osgViewer::Viewer::SingleThreaded);
osgQt::GraphicsWindowQt* gw
=dynamic_castosgQt::GraphicsWindowQt*(camera-getGraphicsContext());
if(gw)
{
_layout_center_widget=gw-getGLWidget();
_layout_center_widget=glw;
_layout_center_widget-setFocusPolicy(Qt::TabFocus);
_base_layout_pane-addWidget(_layout_center_widget,
BorderLayout::Center);
_base_borderLayout-update();
}
connect( _render_timer, SIGNAL(timeout()), this, SLOT(update()));
osg_init=true;
_render_timer.start(16.66);
}
void removeQmlView()
{
qDebug(removing current Qml view..);
if(_qml_view)
_qml_view-destroy();
}
void removeCenterWidget()
{
if(_layout_center_widget)
{
qDebug(removing current center_widget..);
_base_borderLayout-removeWidget(_layout_center_widget);
}
}
void nextUIFrame(QString str)
{
if(str.compare(OSG,Qt::CaseInsensitive)==0)
{
qDebug(OSG Window from QML);
removeQmlView();
removeCenterWidget();
setOsgScene(this-_osgroot,this-_camera);
return;
}
if(str.compare(SPLASH,Qt::CaseInsensitive)==0)
{
Loader* loader=Loader::getInstance();
OSGutil::osgResourceManager*
osgResmng=OSGutil::osgResourceManager::getInstance();
removeQmlView();
_qml_view=new QQuickView();
_qml_view-rootContext()-setContextProperty(GuiWindowCpp,this);
_qml_view-setSource(QUrl::fromLocalFile(c:/splash.qml);
QQuickItem* obj=_qml_view-rootObject();
connect(loader,SIGNAL(feedProgressInfo(QVariant)),obj,SLOT(printCurrentLabel(QVariant)));
connect(osgResmng,SIGNAL(feedProgressData(QVariant)),obj,SLOT(printCurrentValue(QVariant)));
removeCenterWidget();
_layout_center_widget=QWidget::createWindowContainer(_qml_view,this);
Re: [osg-users] Request for assistance to embark into PhD
Hi, Very good point, you are right. OSG is a technology , I have to see it as a tool in my research. Where can I find an open AR problem ? where am I supposed to look ? How to do that ? ps: I found a thesis director, I will speak to him later today. Thank you! Cheers, Mohamed Mohamed ALJI -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=56944#56944 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request for assistance to embark into PhD
Hi, On Wed, Oct 23, 2013 at 12:28 PM, Mohamed Alji osgfo...@tevs.eu wrote: ** Hi, Very good point, you are right. OSG is a technology , I have to see it as a tool in my research. Keep that in mind - it is easy to slip into the engineering mindset and just do some coding or whatever - but that isn't really research and a lot of people get burned by that. They arrive to the thesis defence with a mountain of code, but nothing really new, scientifically speaking. Where can I find an open AR problem ? where am I supposed to look ? How to do that ? Well ... I think that the best thing to do is to look for books, papers, theses etc. in the field you want to work in. That will give you the idea what is known and is considered the state of the art. It takes time, because you must first understand the field sufficiently to essentially know what you don't know :) Then you can pick a problem to work on. Your thesis advisor/director and senior researchers in the lab you are going to do the doctorate at could help you a lot there. Typically they might have a topic or problem for you to work on already. Also don't worry too much about the topic you may be asked to write on your PhD application - one usually puts there something extremely generic, because you won't know a good problem to work on before you have done about a year of research in the field! ps: I found a thesis director, I will speak to him later today. I think that is the best thing to do. J. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [forum] what happened to khronos.org?
Greetings All! Has anyone noticed that khronos.org is down or is it me? Thank you! D Glenn David Glenn --- D Glenn 3D Computer Graphics Entertainment. www.dglenn.com -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=56948#56948 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Preferred method for per-context uniforms
Hi all -- I've been inactive with OSG lately, but from time to time get called back. Given my lack of recent experience, I would appreciate your help with this issue. I have a multicontext/multidisplay app that needs to compute a uniform during cull, and it will have a different value for each context/display. Computing the uniform value is straightforward, but actually executing the uniform per-context during draw is somewhat difficult. I can't simply store the uniform in the Node's StateSet, for example, because doing that during cull is not thread safe. Ideally I would store the uniform in a vector indexed by context ID, but I don't have a context ID during cull. Would it be feasible to store the uniforms in a map indexed by RenderStage address, then execute the uniforms from a Camera per-draw callback? Assuming I use a per-context or per-RenderStage container to store the uniforms, how do I initially grow that container in a thread-safe way during the first frame? What are other people doing in this situation? Thanks in advance for the advice. -- Paul Martz Skew Matrix Software LLC ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Preferred method for per-context uniforms
HI Paul, If you have just a single uniform value per context then I'd simply place the Uniform on the each if the viiewer's osg::Camera's StateSet, such that each Camera assigned to each Context gets it's own state inherited down including the Uniform. If you want to put a vector of Uniform in the scene graph, then It would probably be most robust to use a custom osg::Group node that manages the cull traversal where it push/pops the approach Unifiorm as well as any resizeGLObjectBuffers/releaseGLObjects etc. The key to doing it thread safe is to make sure you have allocated the vector to the required number of contexts prior to traversal - this is what the resizeGLObjectsBuffers() helps with. Robert. On 23 October 2013 17:38, Paul Martz skewmat...@gmail.com wrote: Hi all -- I've been inactive with OSG lately, but from time to time get called back. Given my lack of recent experience, I would appreciate your help with this issue. I have a multicontext/multidisplay app that needs to compute a uniform during cull, and it will have a different value for each context/display. Computing the uniform value is straightforward, but actually executing the uniform per-context during draw is somewhat difficult. I can't simply store the uniform in the Node's StateSet, for example, because doing that during cull is not thread safe. Ideally I would store the uniform in a vector indexed by context ID, but I don't have a context ID during cull. Would it be feasible to store the uniforms in a map indexed by RenderStage address, then execute the uniforms from a Camera per-draw callback? Assuming I use a per-context or per-RenderStage container to store the uniforms, how do I initially grow that container in a thread-safe way during the first frame? What are other people doing in this situation? Thanks in advance for the advice. -- Paul Martz Skew Matrix Software LLC ___ 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] Preferred method for per-context uniforms
Hi, We have to manage some similar problems. We have different shaders and different uniforms in the same scene graph. Some nodes have a cull callback. During the cull traversal, the callback identify the current view/context and push the corresponding state set in the render graph, traverse the children and pop the state set. On 23/10/2013 18:49, Robert Osfield wrote: HI Paul, If you have just a single uniform value per context then I'd simply place the Uniform on the each if the viiewer's osg::Camera's StateSet, such that each Camera assigned to each Context gets it's own state inherited down including the Uniform. If you want to put a vector of Uniform in the scene graph, then It would probably be most robust to use a custom osg::Group node that manages the cull traversal where it push/pops the approach Unifiorm as well as any resizeGLObjectBuffers/releaseGLObjects etc. The key to doing it thread safe is to make sure you have allocated the vector to the required number of contexts prior to traversal - this is what the resizeGLObjectsBuffers() helps with. Robert. On 23 October 2013 17:38, Paul Martz skewmat...@gmail.com mailto:skewmat...@gmail.com wrote: Hi all -- I've been inactive with OSG lately, but from time to time get called back. Given my lack of recent experience, I would appreciate your help with this issue. I have a multicontext/multidisplay app that needs to compute a uniform during cull, and it will have a different value for each context/display. Computing the uniform value is straightforward, but actually executing the uniform per-context during draw is somewhat difficult. I can't simply store the uniform in the Node's StateSet, for example, because doing that during cull is not thread safe. Ideally I would store the uniform in a vector indexed by context ID, but I don't have a context ID during cull. Would it be feasible to store the uniforms in a map indexed by RenderStage address, then execute the uniforms from a Camera per-draw callback? Assuming I use a per-context or per-RenderStage container to store the uniforms, how do I initially grow that container in a thread-safe way during the first frame? What are other people doing in this situation? Thanks in advance for the advice. -- Paul Martz Skew Matrix Software LLC ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] How does geometry get deleted?
I'm using osgSim::LineOfSight to do calculations in an app with no GUI. Everything's working well, except the memory usage keeps growing to the point that it exceeds 4 gigs and crashes. A majority of the time, it's allocating memory in osgTerrain::GeometryTechnique::generateGeometry when it crashes. How would I go about un-generating geometry to keep my memory usage under control? keith.stei...@plexsys.commailto:keith.stei...@plexsys.com (who will be ridiculously grateful for any help he gets) ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
