Re: [osg-users] intersect() methods in LineSegment (probably others)
Hello Andy, J-S, did you get to do any timing with my proposed use of doubles in the intersection code? Sorry, I was out of town finally this weekend. I will try it out tonight. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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] eventState problem in CompositeViewer?
Hello again,
I finally looked into this, and it seems that commenting out the lines
that set the input range in CompositeViewer.cpp fixes the issue. I don't
know why that would cause a problem. While debugging, it always entered
the branch of the if() that set it according to the traits, but it seems
it's still not correct.
Well, turns out that just commenting those lines made the problem appear
when using a single camera per view. So I needed instead to check if the
camera is not a slave camera, and then set the input range.
Corrected file attached. I checked that it works with
setUpViewAcrossAllScreens() and setUpViewOnSingleScreen().
Let me know if that fixes your picking problems, or if you find other
problems.
J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
http://www.cm-labs.com/
http://whitestar02.webhop.org/
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield
*
* This library is open source and may be redistributed and/or modified under
* the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or
* (at your option) any later version. The full license is in LICENSE file
* included with this distribution, and on the openscenegraph.org website.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* OpenSceneGraph Public License for more details.
*/
#include osg/GLExtensions
#include osgUtil/GLObjectsVisitor
#include osgGA/TrackballManipulator
#include osgViewer/CompositeViewer
#include osgViewer/Renderer
#include osgDB/Registry
#include osg/io_utils
using namespace osgViewer;
CompositeViewer::CompositeViewer()
{
constructorInit();
}
CompositeViewer::CompositeViewer(const CompositeViewer cv,const osg::CopyOp
copyop):
ViewerBase()
{
constructorInit();
}
CompositeViewer::CompositeViewer(osg::ArgumentParser arguments)
{
constructorInit();
std::string filename;
bool readConfig = false;
while (arguments.read(-c,filename))
{
readConfig = readConfiguration(filename) || readConfig;
}
while (arguments.read(--SingleThreaded))
setThreadingModel(SingleThreaded);
while (arguments.read(--CullDrawThreadPerContext))
setThreadingModel(CullDrawThreadPerContext);
while (arguments.read(--DrawThreadPerContext))
setThreadingModel(DrawThreadPerContext);
while (arguments.read(--CullThreadPerCameraDrawThreadPerContext))
setThreadingModel(CullThreadPerCameraDrawThreadPerContext);
osg::DisplaySettings::instance()-readCommandLine(arguments);
osgDB::readCommandLine(arguments);
}
void CompositeViewer::constructorInit()
{
_endBarrierPosition = AfterSwapBuffers;
_startTick = 0;
// make sure View is safe to reference multi-threaded.
setThreadSafeRefUnref(true);
_frameStamp = new osg::FrameStamp;
_frameStamp-setFrameNumber(0);
_frameStamp-setReferenceTime(0);
_frameStamp-setSimulationTime(0);
_eventVisitor = new osgGA::EventVisitor;
_eventVisitor-setFrameStamp(_frameStamp.get());
_updateVisitor = new osgUtil::UpdateVisitor;
_updateVisitor-setFrameStamp(_frameStamp.get());
setStats(new osg::Stats(CompsiteViewer));
}
CompositeViewer::~CompositeViewer()
{
osg::notify(osg::INFO)CompositeViewer::~CompositeViewer()std::endl;
stopThreading();
Scenes scenes;
getScenes(scenes);
for(Scenes::iterator sitr = scenes.begin();
sitr != scenes.end();
++sitr)
{
Scene* scene = *sitr;
if (scene-getDatabasePager())
{
scene-getDatabasePager()-cancel();
scene-setDatabasePager(0);
}
}
Contexts contexts;
getContexts(contexts);
// clear out all the previously assigned operations
for(Contexts::iterator citr = contexts.begin();
citr != contexts.end();
++citr)
{
(*citr)-close();
}
osg::notify(osg::INFO)finished
CompositeViewer::~CompsiteViewer()std::endl;
}
bool CompositeViewer::readConfiguration(const std::string filename)
{
osg::notify(osg::NOTICE)CompositeViewer::readConfiguration(filename)std::endl;
return false;
}
void CompositeViewer::addView(osgViewer::View* view)
{
bool threadsWereRuinning = _threadsRunning;
if (threadsWereRuinning) stopThreading();
_views.push_back(view);
view-_viewerBase = this;
view-setFrameStamp(_frameStamp.get());
if (threadsWereRuinning) startThreading();
}
void CompositeViewer::removeView(osgViewer::View* view)
{
for(RefViews::iterator itr = _views.begin();
itr != _views.end();
++itr)
{
if (*itr == view)
{
bool threadsWereRuinning = _threadsRunning;
if (threadsWereRuinning) stopThreading();
[osg-users] New to OSG, some questions (selection buffer, parametric curves)
Hi everyone, I am new to OSG, yet intend to use it for some projects. I've been through implementing some scene graph things before, I find OSG very interesting, I appreciate tight OpenGL integration (no cumbersome abstractions) and clean class design. So far I have a few questions regarding some aspects of OSG: - OpenGL selection buffer seems not recommended as a way of picking in OSG, explicit primitive intersections are used instead. Could someone please comment on this (why...)? - Support for parametric curves / surfaces (Bezier, NURBs and the likes). Are there any plan to support this directly (through GLU or other), or should I export those as polygonal data instead? Thank you very much, Raphael ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DLL versioned MSVC and NMAKE problem, relative paths are wrong
Hello René, If it is possible to use Visual Studio Express Edition and command line build, let me know, as far as I know the command line files are not in the express edition. It is definitely possible, that's what I use at home. They just renamed devenv.exe to vcexpress.exe, but the command line options are still available. See http://msdn2.microsoft.com/en-us/library/xee0c8y7.aspx The main command line option for you is /Build of course. :-) You can specify to build the INSTALL target, which will do the right thing. Be sure to run the vcvarsall.bat script beforehand so it will set up your environment correctly (but you know that, you're using nmake! :-) I also use nmake, because it triggers cmake before building, if this happens in visual studio you will have to reopen all you projects (the project has been changed from outside...). This makes testing cmake scripts more time consuming. If you have nothing else modifying your project files, they will not need to be reloaded, so it's no problem... Plus, if you run the build from the command line as above, you shouldn't have that problem, it should work fine. (if someone knows how to avoid closing/opening visual studio or reloading the projects one by one let me know). That annoys me too, but it isn't very often that I tweak the CMake config files, so I don't mind that much. I have used this build system with osg for over two years now, it worked perfectly until the current cmake hack (adding../../bin to move files) was created. I think a better (cmake) solution is possible. I don't know, I seem to recall that was a workaround for some other problem, though I can't remember which one. Maybe if you search the archives for ../../bin you would find that discussion. I think Luigi Calori was the one who did that modification for versioning the DLL files, so that might help your search as well. Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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] eventState problem in CompositeViewer?
Hello Roni,
I recently changed my application from using Viewer to CompositeViewer with
one view (currently...).
Everything seems to work as before, except for picking.
I think you may have stumbled onto the same problem I mentioned on the list last
Friday:
http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/23244
But I think you're further along in the investigation... I would love to see
this fixed, but as I mentioned in the thread linked above, I'm not avaliable
for most of next week. If you're able to track this down, please let us know!
I finally looked into this, and it seems that commenting out the lines
that set the input range in CompositeViewer.cpp fixes the issue. I don't
know why that would cause a problem. While debugging, it always entered
the branch of the if() that set it according to the traits, but it seems
it's still not correct.
The problem was actually very easy to reproduce: just running
osgcompositeviewer -1 and then trying to drag to orbit the camera made
the problem apparent (the camera would orbit extremely slowly).
Here is a version of CompositeViewer.cpp with those lines commented
(search for JSG). Check it out, and when Robert comes back we'll check
with him.
J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
http://www.cm-labs.com/
http://whitestar02.webhop.org/
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield
*
* This library is open source and may be redistributed and/or modified under
* the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or
* (at your option) any later version. The full license is in LICENSE file
* included with this distribution, and on the openscenegraph.org website.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* OpenSceneGraph Public License for more details.
*/
#include osg/GLExtensions
#include osgUtil/GLObjectsVisitor
#include osgGA/TrackballManipulator
#include osgViewer/CompositeViewer
#include osgViewer/Renderer
#include osgDB/Registry
#include osg/io_utils
using namespace osgViewer;
CompositeViewer::CompositeViewer()
{
constructorInit();
}
CompositeViewer::CompositeViewer(const CompositeViewer cv,const osg::CopyOp
copyop):
ViewerBase()
{
constructorInit();
}
CompositeViewer::CompositeViewer(osg::ArgumentParser arguments)
{
constructorInit();
std::string filename;
bool readConfig = false;
while (arguments.read(-c,filename))
{
readConfig = readConfiguration(filename) || readConfig;
}
while (arguments.read(--SingleThreaded))
setThreadingModel(SingleThreaded);
while (arguments.read(--CullDrawThreadPerContext))
setThreadingModel(CullDrawThreadPerContext);
while (arguments.read(--DrawThreadPerContext))
setThreadingModel(DrawThreadPerContext);
while (arguments.read(--CullThreadPerCameraDrawThreadPerContext))
setThreadingModel(CullThreadPerCameraDrawThreadPerContext);
osg::DisplaySettings::instance()-readCommandLine(arguments);
osgDB::readCommandLine(arguments);
}
void CompositeViewer::constructorInit()
{
_endBarrierPosition = AfterSwapBuffers;
_startTick = 0;
// make sure View is safe to reference multi-threaded.
setThreadSafeRefUnref(true);
_frameStamp = new osg::FrameStamp;
_frameStamp-setFrameNumber(0);
_frameStamp-setReferenceTime(0);
_frameStamp-setSimulationTime(0);
_eventVisitor = new osgGA::EventVisitor;
_eventVisitor-setFrameStamp(_frameStamp.get());
_updateVisitor = new osgUtil::UpdateVisitor;
_updateVisitor-setFrameStamp(_frameStamp.get());
setStats(new osg::Stats(CompsiteViewer));
}
CompositeViewer::~CompositeViewer()
{
osg::notify(osg::INFO)CompositeViewer::~CompositeViewer()std::endl;
stopThreading();
Scenes scenes;
getScenes(scenes);
for(Scenes::iterator sitr = scenes.begin();
sitr != scenes.end();
++sitr)
{
Scene* scene = *sitr;
if (scene-getDatabasePager())
{
scene-getDatabasePager()-cancel();
scene-setDatabasePager(0);
}
}
Contexts contexts;
getContexts(contexts);
// clear out all the previously assigned operations
for(Contexts::iterator citr = contexts.begin();
citr != contexts.end();
++citr)
{
(*citr)-close();
}
osg::notify(osg::INFO)finished
CompositeViewer::~CompsiteViewer()std::endl;
}
bool CompositeViewer::readConfiguration(const std::string filename)
{
osg::notify(osg::NOTICE)CompositeViewer::readConfiguration(filename)std::endl;
return false;
}
void CompositeViewer::addView(osgViewer::View* view)
{
bool threadsWereRuinning = _threadsRunning;
if
[osg-users] issues with latest ATI driver, please confirm
Hi! There seem to be numerous issues regarding the latest ATI driver (8.1, tested on Windows XP): The osgshadow sample complains about the vertex shader missing. If I recompile the sample with a dummy shader, the sample displays the geometry, but all in black. I didn't investigate further yet. In my program, I use perspective shadow maps, rendering to a depth texture using setRenderTargetImplementation(FRAME_BUFFER_OBJECT). This works perfectly with driver version 7.9. In 8.1 however, it appears that the frame buffer image is flipped upside down for some reason. If I invert the y-coordinate for shadow texture lookup, everything works fine again for this driver version. Can anybody confirm these issues? I'm afraid now I'll have to implement a test of whether the frame buffer is flipped to maintain compatibility with the screwed-up ATI driver... I hope this is not the case... regards cm ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Viewer on single screen - other screen black?
Hello, If I use the osgViewer::View::setUpViewOnSingleScreen() method, the view is on the single screen but the other one is black. I would have expected that if there is nothing specifically set to occupy the second screen, my application would not occupy it so I would see (for example) my debugger on it. I can reproduce this by simply adding viewer.setUpViewOnSingleScreen(); before viewer.realize() in the osgviewer application's osgviewer.cpp file. Not sure if this is a known issue. I thought it was related to something we did incorrectly on our side, but it doesn't seem so. We are using OSG 2.2 here, but it still does the same thing in OSG from SVN. Has anyone encountered the same issue, and is there any workaround? Could it be related to fullscreen vs windowed mode? I would like setUpViewOnSingleScreen to just use the one screen (unless I have another view on the other screen of course) and setUpViewAcrossAllScreens to use both screens. Thanks in advance, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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] osgShadow one shot shadow map
Hello Sebastian,
I'm quite confused regarding the osgShadow implementation.
My scene and my light-positions are static. My idea was to capture the
shadow-map only once
and apply it consecutively in all frames. I'm a bit lost where to start.
Neither update nor cull seems to be the right place.
Any hints?
As you have seen, it was not designed to do that. It's designed to
recalculate the shadow map each frame. I guess you could add a boolean
to it to say that it has been calculated, and then not redo it again...
Maybe just something like:
class myShadowMap : public osgShadow::ShadowMap
{
public:
myShadowMap() : _done(false) {}
virtual void update(osg::NodeVisitor nv)
{
if (!_done)
osgShadow::ShadowMap::update(nv);
}
virtual void cull(osgUtil::CullVisitor cv)
{
if (!_done)
{
osgShadow::ShadowMap::cull(cv);
_done = true;
}
}
private:
bool _done;
};
Note that I didn't try this, but it might give you something to start
with? Let us know how it goes.
Hope this helps,
J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
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] osgShadow one shot shadow map
Hi everyone, I'm quite confused regarding the osgShadow implementation. My scene and my light-positions are static. My idea was to capture the shadow-map only once and apply it consecutively in all frames. I'm a bit lost where to start. Neither update nor cull seems to be the right place. Any hints? cheers Sebastian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DLL versioned MSVC and NMAKE problem, relative paths are wrong
Jean-Sébastien Guay wrote: Alternatively, did you know you can invoke Visual Studio with command line options to build a .sln file from the command line? This might be simpler if you want the result to be identical to a build from the IDE, without having to fiddle with CMake to build with nmake. I don't remember the command-line options off-hand but I can dig them up if you're interested. J-S devenv blabla.sln /build Release Hope it helps mario -- Ing. Mario Valle Visualization Group | http://www.cscs.ch/~mvalle Swiss National Supercomputing Centre (CSCS) | Tel: +41 (91) 610.82.60 v. Cantonale Galleria 2, 6928 Manno, Switzerland | Fax: +41 (91) 610.82.82 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow one shot shadow map
I implemented Trapezoidal and LiSpPSM. Actually most of the time was spent on algorithms finding minimal shadowed scene bounds under OSG. It was a key to good shadow mapping results. I will try to contribute LispSM when I am done with all the issues. Cheers, Wojtek -Original Message- From: Jean-Sébastien Guay [mailto:[EMAIL PROTECTED] Sent: Monday, February 11, 2008 9:29 PM To: [EMAIL PROTECTED]; OpenSceneGraph Users Subject: Re: [osg-users] osgShadow one shot shadow map Hello Wojtek, I have spent couple months banging my head against the wall, implementing perspective shadow mapping algortihms and that is the only rason I know how osgShadow::ShadowMap works ;-). Hehehe, I suspect I am on the same road, so only a few months to go if your assessment is correct :-) Any chance you would contribute the PSM implementation? It would make one more on the list. :-) Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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] New to OSG, some questions (selection buffer, parametric curves)
Hello Raphael, Welcome! Hope you enjoy your time working with OSG, and the community around it! - OpenGL selection buffer seems not recommended as a way of picking in OSG, explicit primitive intersections are used instead. Could someone please comment on this (why...)? I'll let others answer this one, I don't know myself. I have always found OpenGL selection buffers cumbersome to use, but with a good wrapper it should be possible to make something that works well and is easy to use I imagine. So I don't know why that was not done. - Support for parametric curves / surfaces (Bezier, NURBs and the likes). Are there any plan to support this directly (through GLU or other), or should I export those as polygonal data instead? I would like to eventually help in adding support for parametric curves and surfaces in OSG. I have used the GLU interface before and would have used that as the first step, followed by an implementation using Geometry Shaders, with the ability to select the implementation you want to use at runtime and a fallback mechanism. I think it would be really cool to support that. But I haven't gotten to it thus far... :-( If you want to start doing something in this direction, I will be glad to test and comment. And search the archives, there was a discussion related to this not too long ago, so there was obviously interest in this. Hope that helps, and again welcome. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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] DLL versioned MSVC and NMAKE problem, relative paths are wrong
Hello Jean-Sébastien,
megamillerzoid wrote:
the versioning is not the problem, but libs also get a prefix. This way
their final location will be in
the bin folder.
Jean-Sébastien Guay wrote:
Libs should go in lib/, and DLLs and executables should go in bin/ ...
I understand, I called the dll's libs... in cmake ${LIB_NAME} is used, and the
${LIB_NAME} target (among others) gets the wrong prefix property. In my fix the
.lib files will go in the lib dir (without a version prefix), just like in
Visual Studio Solutions.
If it is possible to use Visual Studio Express Edition and command line build,
let me know, as far as I know the command line files are not in the express
edition.
I also use nmake, because it triggers cmake before building, if this happens in
visual studio you will have to reopen all you projects (the project has been
changed from outside...). This makes testing cmake scripts more time consuming.
(if someone knows how to avoid closing/opening visual studio or reloading the
projects one by one let me know).
Jean-Sébastien Guay wrote:
Though it seems you are the only one using nmake to build OSG
:-)
I have used this build system with osg for over two years now, it worked
perfectly until the current cmake hack (adding../../bin to move files) was
created. I think a better (cmake) solution is possible.
Thanks for your feedback!
I will take a look at the submission mailing list.
René
_
Bekijk Yes-R's real life soap op MSN Video!
http://video.msn.com/video.aspx?mkt=nl-nltab=m1192527562294vid=8aff5b76-b78d-4b55-8b64-ef7e1d73aab2playlist=videoByUuids:uuids:50b732c2-c105-41e9-adf0-36bd627d4eaa,0813da8c-031b-423f-a79d-35d925aee805,5cce447e-948d-43af-9862-45bb6bb9d6d8,6a39138c-f562-4254-be70-9d93343650f8,f9b8d78f-05a4-4c74-8e4b-28d20a4037abfrom=NLNL_Yes-R
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DLL versioned MSVC and NMAKE problem, relative paths are wrong
Jean-Sébastien Guay wrote:
adapting the build files generated for nmake to make it accept the versioned
DLLs
Nope, I adapted the cmake files so it generates correct build files for nmake.
The changes had to be done at many places in (OsgMacroUtils and two
CmakeLists.txt) (libs, linking, apps, plugins. wrappers)
The problem with the hard-coded paths to move the dll's is this:
Visual Studio creates Release and Debug folders,
the versioning is not the problem, but libs also get a prefix. This way their
final location will be in the bin folder.
For example (for the plugins):
PREFIX = ../../bin/${OSG_PLUGINS} which will become something like
../../../lib/release/../../bin/osg/osgPlugins-2.2.0/
if you generate files for nmake this 'trick' will not work, it has to be:
../bin/${OSG_PLUGINS}
I have created a fix for this...
Let me know if this needs to be submitted.
Rene
_
De mooiste afbeeldingen van Angelina Jolie vind je met Live Search
http://search.live.com/images/results.aspx?q=angelina%20jolieFORM=MIINTM
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New to OSG, some questions (selection buffer, parametric curves)
- OpenGL selection buffer seems not recommended as a way of picking in OSG, explicit primitive intersections are used instead. Could someone please comment on this (why...)? OpenGL's selection render mode is almost universally implemented via software rendering, and is therefore painfully slow for any moderate geometry load. It also tends to be O(n) -- your app just renders everything, even stuff no where near the pick point. You can sidestep these issues by reducing or simplifying the geometry being tested. Selection is the only (sort of direct) support OpenGL has for picking, so if you're using OpenGL and don't want to code a better method, then you're stuck with selection. Fortunately OSG has a superior alternative. One thing scene graphs are good at is spatial organization. As a result, pick testing in a scene graph is O(log(n)). Although it also runs in software, it performs simple ray/sphere intersection tests, which are much more efficient than software rasterization. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com http://www.skew-matrix.com/ 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ANN: osgPython (SWIG) 2.2.0
I just separated an osgswig cmake project from our larger Library. Tomorrow I can try to build some of your version of the wrappers in this structure. (our version has changed a version of yours here and there). You can add me to the Project members of the google code page? I saw another member on there, I worked with him to create our current version. He makes great use of osgPython in combination with IPython gtk and the rest of our Library. Cheers, René 2008/2/12, Hartmut Seichter [EMAIL PROTECTED]: Hi there, I updated the SWIG based python bindings. http://code.google.com/p/osgswig/ Please test and break it. Some, hopefully, clarifying words about licensing: The generating scripts are under the MIT license. The modules directly derived from OpenSceneGraph are following the OSGPL v0.0 or the appropriate licenses. The HITLabNZ (http://www.hitlabnz.org) is promoting the GPL version of osgART 1.1, ARToolKit for OpenSceneGraph, with this release. If you are using this module you also agree to follow the licensing terms of the GPLv2. Shameless plug :) If you need a commercial license for osgART or features beyond marker based tracking please contact ARToolworks Inc. ( http://www.artoolworks.com/) Cheers, Hartmut ___ 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] ANN: osgPython (SWIG) 2.2.0
Hi there, I updated the SWIG based python bindings. http://code.google.com/p/osgswig/ Please test and break it. Some, hopefully, clarifying words about licensing: The generating scripts are under the MIT license. The modules directly derived from OpenSceneGraph are following the OSGPL v0.0 or the appropriate licenses. The HITLabNZ (http://www.hitlabnz.org) is promoting the GPL version of osgART 1.1, ARToolKit for OpenSceneGraph, with this release. If you are using this module you also agree to follow the licensing terms of the GPLv2. Shameless plug :) If you need a commercial license for osgART or features beyond marker based tracking please contact ARToolworks Inc. (http://www.artoolworks.com/) Cheers, Hartmut ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] intersect() methods in LineSegment (probably others)
J-S, did you get to do any timing with my proposed use of doubles in the intersection code? Thanks, andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Looking for CARBON integration example, like osgviewerMFC
if application xcode doesn't build, then remove all files *.cpp and *.h
and add just application.cpp and application.h to the project. (sorry, may i
forget to remove them)
2008/2/11, Adrian Egli OpenSceneGraph (3D) [EMAIL PROTECTED]:
Hi Stephan,
i played arround friday with a small safari osg plugin and did some small
changes in the graphics window files for carbon. may you check out this two
files and extract my safari_osg.tar.gz file. then you should be able to
build them with xcode. first application, second the plugin, and third have
a look into the test.sh and
the *.html files. it sould work.
there is no keyboard, nor mouse event. but if you right-click onto the
menu bar of safari (links) or into the html page with the mouse, a context
menu apprears, then press 'w' or 's' and you see that the events are
transfert to the plugin, strange, or is something really wrong with safari
or my plugin or carbon or .. . .
/adegli
2008/2/8, Stephan Maximilian Huber [EMAIL PROTECTED]:
Hi Adrian,
Adrian Egli OpenSceneGraph (3D) schrieb:
may i do something wrong, or the osgViewer for Carbon is not right, i
don't
know. The result should looking like Bild 3. the Bild 1 and Bild
2 are
wrong, or current state of the integration. (Bild 1 : osg default
when
window not moved, Bild 2 after bild moved)
I am not sure if your usage-scenario is currently doable with
GraphicsWindowCarbon. You want to attach a HIView (or what it is called
in Carbon) , which is part of a window to the osgViewer::Viewer.
GraphicWindowCarbon owns whole windows, it takes all the place, it eats
all the events, so other ui-items get lost. It is not designed to handle
only a view.
The current implementation of GraphicsWindowCarbon does not process any
events, if it gets a foreign window. If you want to install the
eventhandlers, with a foreign window, set
m_windowData-setInstallEventHandler(true);
This may not work for your settings, because GraphicsWindowCarbon
installs several event handlers to catch Application-Quit etc.
Perhaps it is the best way to implement your own native
GraphicsContext-implementation for the plugin-usage or use a
GraphicsWindowEmbedded and do the handling of the AGLContext yourself.
Hope that helps,
Stephan
(P.S. I am attaching a working example using an external window with
GraphicsWindowCarbon)
//
// main.c
// cefixTemplate
//
// Created by Stephan Huber on 26.11.06.
// Copyright __MyCompanyName__ 2006. All rights reserved.
//
#include osgViewer/api/Carbon/GraphicsWindowCarbon
#include osgViewer/Viewer
#include osg/ShapeDrawable
int main(int argc, char* argv[])
{
// create the window:
Rect titleRect = {100,100, 600, 800};
OSStatus err = 0;
WindowRef windowPtr;
WindowAttributes attr = (kWindowStandardDocumentAttributes |
kWindowStandardHandlerAttribute) ~kWindowResizableAttribute;
err = CreateNewWindow(kDocumentWindowClass, attr, titleRect,
windowPtr);
osg::ref_ptrosg::GraphicsContext::Traits traits = new
osg::GraphicsContext::Traits;
// Init the Windata Variable that holds the handle for the
Window to display OSG in.
osg::ref_ptrosgViewer::GraphicsWindowCarbon::WindowData
m_windowData = new osgViewer::GraphicsWindowCarbon::WindowData(windowPtr);
m_windowData-setInstallEventHandler(true);
// Setup the traits parameters
traits-x = titleRect.left;
traits-y = titleRect.top;
traits-width = abs(titleRect.right - titleRect.left);
traits-height = abs(titleRect.bottom - titleRect.top);
osg::notify(osg::ALWAYS) SIZE= traits-width x
traits-height std::endl;
traits-windowDecoration = false;
traits-doubleBuffer = true;
traits-sharedContext = NULL;
traits-setInheritedWindowPixelFormat = false;//true;
traits-inheritedWindowData = m_windowData.get();
// Create the Graphics Context
osg::GraphicsContext* gc =
osg::GraphicsContext::createGraphicsContext(traits.get());
// Init a new Camera (Master for this View)
osg::Camera* camera = new osg::Camera;
// Assign Graphics Context to the Camera
camera-setGraphicsContext(gc);
// Set the viewport for the
Camera
camera-setViewport(new osg::Viewport(0,0, traits-width,
traits-height));
// Add the Camera to the Viewer
osg::ref_ptrosgViewer::Viewer m_osg_simple_viewer = new
osgViewer::Viewer();
m_osg_simple_viewer-addSlave(camera);
m_osg_simple_viewer-setCamera(camera);
osg::Group* g = new osg::Group();
osg::Geode* geode = new osg::Geode();
geode-addDrawable(new osg::ShapeDrawable(new osg::Box()));
Re: [osg-users] New to OSG, some questions (selection buffer, parametric curves)
Hi J-S, Yes, geometry shaders would be a must for these (and also for subdivision surfaces). I'd be interested in contributing to these (time permitting, you know that...), although I first have to catch up with OSG. Thank you! Raphael On Feb 11, 2008 10:29 PM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: Hello Raphael, Welcome! Hope you enjoy your time working with OSG, and the community around it! - OpenGL selection buffer seems not recommended as a way of picking in OSG, explicit primitive intersections are used instead. Could someone please comment on this (why...)? I'll let others answer this one, I don't know myself. I have always found OpenGL selection buffers cumbersome to use, but with a good wrapper it should be possible to make something that works well and is easy to use I imagine. So I don't know why that was not done. - Support for parametric curves / surfaces (Bezier, NURBs and the likes). Are there any plan to support this directly (through GLU or other), or should I export those as polygonal data instead? I would like to eventually help in adding support for parametric curves and surfaces in OSG. I have used the GLU interface before and would have used that as the first step, followed by an implementation using Geometry Shaders, with the ability to select the implementation you want to use at runtime and a fallback mechanism. I think it would be really cool to support that. But I haven't gotten to it thus far... :-( If you want to start doing something in this direction, I will be glad to test and comment. And search the archives, there was a discussion related to this not too long ago, so there was obviously interest in this. Hope that helps, and again welcome. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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] osg python binding
Hartmut Seichter wrote:
If you tried the newest trunk and SWIG you certainly stumbled across the
osg::Vec3f stuff ... do you have a solution for that?
I don't know what stuff ypu mean, I have just tested the latest svn-trunk (osg
2.3.4) with swigwin-1.3.29 without problems.
So maybe using an older swig version is a workaround for now.
I noticed one swig error before, that was solved like this:
//This is a little macro trick to prevent a swig error
#define X_AXIS(a,b,c) X_AXIS=Vec3f(1.0,0.0,0.0);
#define Y_AXIS(a,b,c) Y_AXIS=Vec3f(0.0,1.0,0.0);
#define Z_AXIS(a,b,c) Z_AXIS=Vec3f(0.0,0.0,1.0);
and this might be handy
//create shortcuts for vecs in python
#ifdef SWIGPYTHON
%pythoncode %{
Vec2 = Vec2f
Vec3 = Vec3f
Vec4 = Vec4f
%}
#endif
We changed some other stuff too, but the result in python is this:
In [1]: import osg
In [2]: a = osg.Vec3(1,2,3)
In [3]: a
Out[3]:
In [4]: print a
[1, 2, 3]
In [5]: myvec = osg.Vec3f()
In [6]: myvec[0] = 10
In [7]: print myvec
[10, 0, 0]
When I find some time, I will try to see what the differences between our
trunks are. And I will look at our cmake files.
Have a nice day,
René Molenaar
_
Probeer Live Search: de zoekmachine van de makers van MSN!
http://www.live.com/?searchOnly=true
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow one shot shadow map
Hello Wojtek, I have spent couple months banging my head against the wall, implementing perspective shadow mapping algortihms and that is the only rason I know how osgShadow::ShadowMap works ;-). Hehehe, I suspect I am on the same road, so only a few months to go if your assessment is correct :-) Any chance you would contribute the PSM implementation? It would make one more on the list. :-) Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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] osgShadow one shot shadow map
Hi will this implementation be avaible for the osg community, new shadow implementation ? 2008/2/11, Wojciech Lewandowski [EMAIL PROTECTED]: I implemented Trapezoidal and LiSpPSM. Actually most of the time was spent on algorithms finding minimal shadowed scene bounds under OSG. It was a key to good shadow mapping results. I will try to contribute LispSM when I am done with all the issues. Cheers, Wojtek -Original Message- From: Jean-Sébastien Guay [mailto:[EMAIL PROTECTED] Sent: Monday, February 11, 2008 9:29 PM To: [EMAIL PROTECTED]; OpenSceneGraph Users Subject: Re: [osg-users] osgShadow one shot shadow map Hello Wojtek, I have spent couple months banging my head against the wall, implementing perspective shadow mapping algortihms and that is the only rason I know how osgShadow::ShadowMap works ;-). Hehehe, I suspect I am on the same road, so only a few months to go if your assessment is correct :-) Any chance you would contribute the PSM implementation? It would make one more on the list. :-) Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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 -- Adrian Egli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow one shot shadow map
Hello Wojtek, ShadowMap::cull invokes culls traversal for both main camera (ShadowReceiving) graph shadow camera (ShadowCasting) graphs. So if you block whole cull on ShadowMap level - it won't draw the scene as well. The trick is to block only the portion that culls ShadowCasting graph. Cool, thanks for clearing that up! I didn't know, haven't looked at the code long enough it seems :-) J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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] osgShadow one shot shadow map
Hi,
ShadowMap::cull invokes culls traversal for both main camera
(ShadowReceiving) graph shadow camera (ShadowCasting) graphs. So if you
block whole cull on ShadowMap level - it won't draw the scene as well. The
trick is to block only the portion that culls ShadowCasting graph.
See the osgShadow::ShadowMap::cull method (src/ osgShadow / ShadowMap.cpp)
Line 330: _shadowedScene-osg::Group::traverse(cv);
Thats the line where Scene traversal is invoked
Line 469 : _camera-accept(cv);
Thats the line which calls cull traversal on Shadow Map camera.
Cheers,
Wojtek Lewandowski
- Original Message -
From: Jean-Sébastien Guay [EMAIL PROTECTED]
To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
Sent: Monday, February 11, 2008 4:20 PM
Subject: Re: [osg-users] osgShadow one shot shadow map
Hello Sebastian,
I'm quite confused regarding the osgShadow implementation.
My scene and my light-positions are static. My idea was to capture the
shadow-map only once
and apply it consecutively in all frames. I'm a bit lost where to start.
Neither update nor cull seems to be the right place.
Any hints?
As you have seen, it was not designed to do that. It's designed to
recalculate the shadow map each frame. I guess you could add a boolean
to it to say that it has been calculated, and then not redo it again...
Maybe just something like:
class myShadowMap : public osgShadow::ShadowMap
{
public:
myShadowMap() : _done(false) {}
virtual void update(osg::NodeVisitor nv)
{
if (!_done)
osgShadow::ShadowMap::update(nv);
}
virtual void cull(osgUtil::CullVisitor cv)
{
if (!_done)
{
osgShadow::ShadowMap::cull(cv);
_done = true;
}
}
private:
bool _done;
};
Note that I didn't try this, but it might give you something to start
with? Let us know how it goes.
Hope this helps,
J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
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] View matrix center
Hi, have a look at these two threads. I've done something similar to what I think you are looking for, but had to add some functionality. Look for the getDRC function. http://article.gmane.org/gmane.comp.graphics.openscenegraph.user/19873/match=DRC http://article.gmane.org/gmane.comp.graphics.openscenegraph.user/8612/match=DRC Robert seemed keen to add functions to the manipulators/the base to enhance them in this direction, so if you find a good solution and have time for a submission... cheers jp Jean-Sébastien Guay wrote: Hi Paul, Thanks for the lookAt background, very useful. Yep, read the code. Look for something like getCenter in MatrixManipulator, that would be a good start. I'm already going down that road. Trouble is MatrixManipulator doesn't have getCenter(). TrackballManipulator does, and using that works, but I'd prefer not to assume the manipulator will be of any particular type (other than the base MatrixManipulator). I'm left with using getMatrix(), but if this is also a lookat matrix, I'll have the same problem... Any other leads? Thanks, J-S -- 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. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow one shot shadow map
I have spent couple months banging my head against the wall, implementing perspective shadow mapping algortihms and that is the only rason I know how osgShadow::ShadowMap works ;-). Wojtek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jean-Sebastien Guay Sent: Monday, February 11, 2008 7:16 PM To: OpenSceneGraph Users Subject: Re: [osg-users] osgShadow one shot shadow map Hello Wojtek, ShadowMap::cull invokes culls traversal for both main camera (ShadowReceiving) graph shadow camera (ShadowCasting) graphs. So if you block whole cull on ShadowMap level - it won't draw the scene as well. The trick is to block only the portion that culls ShadowCasting graph. Cool, thanks for clearing that up! I didn't know, haven't looked at the code long enough it seems :-) J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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] DLL versioned MSVC and NMAKE problem, relative paths are wrong
Bonjour René, I am using commandline build system nmake on windows, since the OSG_MSVC_VERSIONED_DLL hack this does not work anymore, because there are hard-coded paths to move the dll's, but nmake has different locations for the files. I don't quite see why versioned DLLs would be a problem with nmake but not with the IDE, as both just call cl.exe (the VC++ command line compiler). So I think you just have to adjust the build files you use with nmake to do the right thing with the versioned DLLs. I really think removing the versioning is not desirable, since its goal is to remove DLL hell on Windows platforms. Since you're using nmake on Windows, this is still a desirable goal :-) BTW, DLLs do not need to be in your lib directory when you compile, they only need to be somewhere where your program can find them when it starts. Either in the program's current directory, on your PATH or in the Windows System32/other predefined location. So I do not understand what you mean above by hard-coded paths to move the dll's. If you have suggestions to improve the CMake config for nmake, it will be appreciated, but I really think you have to approach it from the other angle: adapting the build files generated for nmake to make it accept the versioned DLLs, instead of removing the versioning. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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] Congratulations ag! OpenSceneGraph Chinese Mirror have been finished , try it.
Happy New Year(in China , It is New Year.) Gung hey fat choi! -JD __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New to OSG, some questions (selection buffer, parametric curves)
I didn't know software rasterizer was used... hmm, but thinking about it, it makes sense as retrieving info from the GPU has not always been an easy thing, yet selection buffer exists since a very long time. Anyway, as you said, higher level knowledge of the scene is definitely an advantage. I'll try to reproduce the same configuration (selecting a square of given width around the click in view space, think I saw a pyramid-like intersection primitive for doing this in OSG) as I did before with selection buffer. Thanks for that info, Raphael On Feb 12, 2008 2:52 AM, Paul Martz [EMAIL PROTECTED] wrote: - OpenGL selection buffer seems not recommended as a way of picking in OSG, explicit primitive intersections are used instead. Could someone please comment on this (why...)? OpenGL's selection render mode is almost universally implemented via software rendering, and is therefore painfully slow for any moderate geometry load. It also tends to be O(n) -- your app just renders everything, even stuff no where near the pick point. You can sidestep these issues by reducing or simplifying the geometry being tested. Selection is the only (sort of direct) support OpenGL has for picking, so if you're using OpenGL and don't want to code a better method, then you're stuck with selection. Fortunately OSG has a superior alternative. One thing scene graphs are good at is spatial organization. As a result, pick testing in a scene graph is O(log(n)). Although it also runs in software, it performs simple ray/sphere intersection tests, which are much more efficient than software rasterization. Paul Martz *Skew Matrix Software LLC* http://www.skew-matrix.com 303 859 9466 ___ 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
