Re: [osg-users] OpenSceneGraph-2.7.8 dev release tagged
Hi Robert, Robert Osfield a écrit : ps. FlightGear contributors... you guys have gone quite over the last two days, no doubt busy with other pressing work... any chance of an update? Is FG going for a release today? Is 2.7.8 sufficient for your purposes? Do you need a 2.8 branch? The release is still schedule for later today. There will be 2.7.8 in the binary release. But as flightgear has a huge display bug when compiled with OSG versions older than 2.7.3, we can predict problems with people wanting to install FG from source, but relying on the OSG available in their distro. I presume a warning will accompany the release announcement -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] RenderInfo UserData property: how to set it?
Hi Russel,
That FAQ is obviously a bit out of date. With the 2.x series of the
OSG the most convinient way to embed the OSG is to use
osgViewer::GraphicsWindowEmbedded. The osgviewerglut and osgviewersdl
examples demonstrate this usage model.
As for RenderInfo user data, I couldn't really follow what you are
doing or why. The best I can do is point you at code that I've used
the RenderInfo user data for, and that the osgText::FadeText so go
look at src/osgText/FadeText.cpp. Note, there isn't any application
level hardwiring here - it's all created on the fly.
Robert.
On Sat, Dec 20, 2008 at 12:19 AM, Russell East russellae...@gmail.com wrote:
I use the approach outlined in
http://www.3drealtimesimulation.com/osg/osg_faq_1.htm#f40 for embedding OSG
within an existing application, and I'm using OSG 2.6.0 on Windows XP.
I have some custom Drawables that I add to the scenegraph, and I pass them
some frame rendering context data into their drawImplementation method
during the rendering phase like this:
// sets up the application context data
osg::ref_ptr MyRenderInfoUserData rpUserData = new
MyRenderInfoUserData({my frame rendering context data});
// makes the context data available to Drawables that do *not* use GL
DisplayLists
mySceneView-getRenderInfo().setUserData( rpUserData.get() );
// makes the context data available to Drawables that *do* use GL
DisplayLists
osg::NodeVisitor *pNodeVisitor = mySceneView-getInitVisitor();
osgUtil::GLObjectsVisitor *pGLObjectsVisitor =
dynamic_castosgUtil::GLObjectsVisitor *(pNodeVisitor);
if (pGLObjectsVisitor)
{
pGLObjectsVisitor-getRenderInfo().setUserData( rpUserData.get() );
}
// make the rendering calls
mySceneView-update ();
mySceneView-cull ();
mySceneView-draw ();
where
class MyRenderInfoUserData : public osg::Referenced { ... }
This seems a bit convoluted, is there a more elegant way to do what I want?
-- Russell
___
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] Stereo with HMD in OpenSceneGraph
Hi Dat, The screen distance and fusion distance are relevant to monitor or projection based stereo systems, not for HMD's. The OSG doesn't use a convergence angle as this is not appropriate for proper stereo effect in monitor or projection based stereo system, instead the OSG uses the mathematically correct system of shearing the projection matrix. Things a bit different for HMD, as the projection matrix is identical for both eyes, and only the view matrix is offset (and perhaps rotated). One method to accurate control this is to use a SceneView::ComputeStereoMatricesCallback, but now with have the osgViewer it's probably easier just to manually create two slave Camera's with the appropriate view matrix translation to account for the inter-ocular distance. FYI, osgViewer hasn't yet taken over management of all stereo modes from the lower level SceneView, but this is my plan - to migrate all stereo support into the high level class, and then provide configuration file support for it. This will be done well after 2.8. Robert. On Sat, Dec 20, 2008 at 3:37 AM, tien dat tienda...@gmail.com wrote: Hi all, I have a question about controlling stereo with HMD in OpenSceneGraph. Basically to setup stereo display you need the distance of two eyes and the convergence angle. When I take a look at OpenSceneGraph code for setting up stereo with HMD, I see two other variables which are screen distance and fusion distance. There is also a matrix to multiple with each view for each eye that uses these variables. So could any of you tell me what they mean and what happens if I change these variables. Thank you very much, Dat ___ 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] OpenSceneGraph-2.7.8 dev release tagged
Hi Fred, On Sat, Dec 20, 2008 at 8:32 AM, Frederic Bouvier fredlis...@free.fr wrote: The release is still schedule for later today. There will be 2.7.8 in the binary release. But as flightgear has a huge display bug when compiled with OSG versions older than 2.7.3, we can predict problems with people wanting to install FG from source, but relying on the OSG available in their distro. I presume a warning will accompany the release announcement Will there be a follow up release? Will the release docs be able refreshed to map to OSG-2.8 once 2.8 goes out? Once OSG-2.8 is out I would like to get this supported in the various distro's. If the distro's want to go with the new FG release as well then what will they need to do? If the FG release maps to 2.8 then things will be clearer. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Building the Collada plugin
Randolph Fritz wrote: DOM 2.1 isn't even available on sourceforge any more. Basically I think I'm scrod, or some other sort of fish. I'll experiment some more with 2.2, and I suppose I can try the 2.7.8 release, but writing an OSG export script for SketchUp is looking better and better. Randolph Smeenk, R.J.M. (Roland) wrote: Randolph, The Collada plugin has only be used with the Collada DOM 2.1 library. DOM 2.2 was silently released two weeks ago, but I haven't tested it yet. There have been a few changes to the Cmake files since osg 2.6.1 so maybe the older version does not work right out of the box. -- Roland -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of R Fritz Sent: donderdag 18 december 2008 3:14 To: OpenSceneGraph Users Subject: [osg-users] Building the Collada plugin OSG 2.6.1, VS 2008. So far I've downloaded COLLADA_1.4.1_DOM_1.3.0.zip, built it, and got a slew of errors trying to build the plugin. (Collada DOM 2.2, which looks like it might be downward compatible, uses a different library structure, and I've no idea which files are still needed.) Which version of Collada is known to work? Does the plugin work at all with VS 2008? Randolph I build against https://collada-dom.svn.sourceforge.net/svnroot/collada-dom/tags/2.1/dom, that works fine for me. There is a lot of work by various people going on in the Collada plugin at the moment which is not quite ready for prime time. I will try a build against the latest DOM before I make a submission. I am afraid I have not yet moved to Visual Studio 2008, my production environment is VS2005 and will remain that way for some time. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.7.8 dev release tagged
Robert Osfield a écrit : Hi Fred, On Sat, Dec 20, 2008 at 8:32 AM, Frederic Bouvier wrote: The release is still schedule for later today. There will be 2.7.8 in the binary release. But as flightgear has a huge display bug when compiled with OSG versions older than 2.7.3, we can predict problems with people wanting to install FG from source, but relying on the OSG available in their distro. I presume a warning will accompany the release announcement Will there be a follow up release? Will the release docs be able refreshed to map to OSG-2.8 once 2.8 goes out? Once OSG-2.8 is out I would like to get this supported in the various distro's. If the distro's want to go with the new FG release as well then what will they need to do? If the FG release maps to 2.8 then things will be clearer. There shouldn't be a long period before 1.9.1 ( this one is flagged 1.9.0 ). Usually, we don't produce binary release for Linux. So the distro maintainers may want to wait OSG 2.8 before packaging flightgear 1.9.0, or directly 1.9.1 if it is ready in the meantime. -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] High resolution screencast
Hi Simon,
My loop was something totally independant from the camera movement. You can
imagine what you want with it.
And about capturing a different size, I guess no, you'll probably have to
resize your image with your encogind API.
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
Le Fri, 19 Dec 2008 17:57:15 +0100, Simon Loic simon1l...@gmail.com a écrit:
Thanks Jean-Sebastien,
Your reply is very helpful. I don't have the time to day to implement it but
I will try during the next week.
Of course I'm interested by your new ScreenCaptureHandler class. BTW do you
think that with this approach it's possible to have a capture resolution
different from the one of the screen?
I will give a look to ffmpeg too.
On Fri, Dec 19, 2008 at 4:40 PM, Jean-Sébastien Guay
jean-sebastien.g...@cm-labs.com wrote:
Hello Simon,
Second, I tried some times ago to do an offscreen rendering but If you
know an easy way in osg to do it I'm interested (I think there are ways
based on osg::Camera::DrawCallBack).
There is now (since OSG 2.6) an osgViewer::ScreenCaptureHandler which you
can use. Unfortunately it only responds to key presses right now, but you
can subclass it like this to get it to capture programmatically:
class OurScreenCaptureHandler :
public osgViewer::ScreenCaptureHandler
{
public:
OurScreenCaptureHandler(CaptureOperation* defaultOperation = 0)
: osgViewer::ScreenCaptureHandler(defaultOperation)
{
}
/** Capture the given viewer's views on the next frame. */
virtual void captureNextFrame(osgViewer::ViewerBase viewer)
{
addCallbackToViewer(viewer);
}
};
Then in your frame loop, you can just call
screenCaptureHandler-captureNextFrame(viewer);
(note: I'll be sending a new version of ScreenCaptureHandler which includes
this method soon, I had to do it for our framework recently, so it will
probably be included in OSG after that, no need to subclass)
Eventually, do you know some good (easy to handle) API for compressing
video?
Once you have images of each frame, you can just use ffmpeg to compress the
sequence into a video. See the ffmpeg man page or web page for more
information.
Hope this helps,
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] osgPPU and change in colors
Hi, I found out that my skybox was darkened because of a flaw in my code, my sky was alpha blended and the clear color was black which reproduced the darkness result in the second example. I missed the part where I changed clear colors when comparing revisions, Thanks a heap --- On Fri, 12/19/08, J.P. Delport jpdelp...@csir.co.za wrote: From: J.P. Delport jpdelp...@csir.co.za Subject: Re: [osg-users] osgPPU and change in colors To: stud_in...@yahoo.de, OpenSceneGraph Users osg-users@lists.openscenegraph.org Date: Friday, December 19, 2008, 5:34 PM Hi, also check if the geom you are applying the final texture to has a white colour, or set the texture mode to GL_REPLACE. jp Art Tevs wrote: Hi, I would suppose, that your lighting cnditions are different. It could be that in one case the scene is lit by some lights and in another case there is no lighting (no lights in use). Check it out. Cheers --- guher b gb...@yahoo.com schrieb am Fr, 19.12.2008: Von: guher b gb...@yahoo.com Betreff: [osg-users] osgPPU and change in colors An: osg-users@lists.openscenegraph.org Datum: Freitag, 19. Dezember 2008, 15:17 Hi, I used osgPPU nodekit and I only used UnitByPass and UnitOut to only render the scene graph to fbo and then finally to framebuffer. In the result, my skybox color has changed color (become darker) Has anybody else encountered this behaviour before? May writing the fbo to a texture with viewport dimensions (resolution change) cause this behaviour? Thanks in advance ___ 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 -- 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] CMake error with 2.7.8
Hi Robert, I have a problem trying to build 2.7.8 on Linux (Debian etch). CMake (2.4.5) complains that FindPkgConfig ( .cmake ? ) is not found. It is referenced in src/osgViewer/CMakeLists.txt -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CMake error with 2.7.8
Hi Fred,
Argg... I missed an OPTIONAL entry in the src/osgViewer/CMakeLists.txt
file, alas not enough of the commmunity tested svn/trunk before
2.7.8... it should read:
#use pkg-config to find various modues
INCLUDE(FindPkgConfig OPTIONAL)
IF(PKG_CONFIG_FOUND)
...
I've now added this and checked it in. The file is also attached,
could you please try this.
Robert.
On Sat, Dec 20, 2008 at 12:37 PM, Frederic Bouvier fredlis...@free.fr wrote:
Hi Robert,
I have a problem trying to build 2.7.8 on Linux (Debian etch). CMake
(2.4.5) complains that FindPkgConfig ( .cmake ? ) is not found. It is
referenced in src/osgViewer/CMakeLists.txt
-Fred
--
Frédéric Bouvier
http://my.fotolia.com/frfoto/ Photo gallery
http://fgsd.sourceforge.net/FlightGear Scenery Designer
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
# FIXME: For OS X, need flag for Framework or dylib
IF (DYNAMIC_OPENSCENEGRAPH)
ADD_DEFINITIONS(-DOSGVIEWER_LIBRARY)
ELSE (DYNAMIC_OPENSCENEGRAPH)
ADD_DEFINITIONS(-DOSG_LIBRARY_STATIC)
ENDIF(DYNAMIC_OPENSCENEGRAPH)
SET(LIB_NAME osgViewer)
SET(HEADER_PATH ${OpenSceneGraph_SOURCE_DIR}/include/${LIB_NAME})
SET(LIB_PUBLIC_HEADERS
${HEADER_PATH}/CompositeViewer
${HEADER_PATH}/Export
${HEADER_PATH}/GraphicsWindow
${HEADER_PATH}/Renderer
${HEADER_PATH}/Scene
${HEADER_PATH}/Version
${HEADER_PATH}/View
${HEADER_PATH}/Viewer
${HEADER_PATH}/ViewerBase
${HEADER_PATH}/ViewerEventHandlers
)
SET(LIB_COMMON_FILES
CompositeViewer.cpp
HelpHandler.cpp
Renderer.cpp
Scene.cpp
ScreenCaptureHandler.cpp
StatsHandler.cpp
Version.cpp
View.cpp
Viewer.cpp
ViewerBase.cpp
ViewerEventHandlers.cpp
)
SET(LIB_EXTRA_LIBS)
IF(WIN32)
#
# Enable workaround for OpenGL driver issues when used in
multithreaded/multiscreen with NVidia drivers on Windows XP
# For example: osgviewer dumptruck.osg was showing total garbage (screen
looked like shattered, splashed hedgehog)
# There were also serious issues with render to texture cameras.
# Workaround repeats makeCurrentContext call as it was found that this
causes the problems to dissapear.
#
OPTION(OSG_MULTIMONITOR_MULTITHREAD_WIN32_NVIDIA_WORKAROUND Set to ON if
you have NVidia board and drivers earlier than 177.92 ver OFF)
MARK_AS_ADVANCED(OSG_MULTIMONITOR_MULTITHREAD_WIN32_NVIDIA_WORKAROUND)
IF(OSG_MULTIMONITOR_MULTITHREAD_WIN32_NVIDIA_WORKAROUND)
ADD_DEFINITIONS(-DOSG_MULTIMONITOR_MULTITHREAD_WIN32_NVIDIA_WORKAROUND)
ENDIF(OSG_MULTIMONITOR_MULTITHREAD_WIN32_NVIDIA_WORKAROUND)
SET(LIB_PUBLIC_HEADERS ${LIB_PUBLIC_HEADERS}
${HEADER_PATH}/api/Win32/GraphicsWindowWin32
${HEADER_PATH}/api/Win32/PixelBufferWin32
)
SET(LIB_COMMON_FILES ${LIB_COMMON_FILES}
GraphicsWindowWin32.cpp
PixelBufferWin32.cpp
)
ELSE(WIN32)
IF(APPLE)
SET(OSG_WINDOWING_SYSTEM Carbon CACHE STRING Windowing system type
for graphics window creation, options Carbon or X11.)
ELSE(APPLE)
SET(OSG_WINDOWING_SYSTEM X11 CACHE STRING Windowing system type for
graphics window creation. options only X11)
ENDIF(APPLE)
IF(${OSG_WINDOWING_SYSTEM} STREQUAL Carbon)
# FIXME: OS X needs selection mechanism for Cocoa, Carbon, X11
SET(LIB_PUBLIC_HEADERS ${LIB_PUBLIC_HEADERS}
${HEADER_PATH}/api/Carbon/GraphicsWindowCarbon
${HEADER_PATH}/api/Carbon/PixelBufferCarbon
)
SET(LIB_COMMON_FILES ${LIB_COMMON_FILES}
GraphicsWindowCarbon.cpp
PixelBufferCarbon.cpp
)
ELSE(${OSG_WINDOWING_SYSTEM} STREQUAL Carbon)
# X11 for everybody else
INCLUDE(FindPkgConfig OPTIONAL)
IF (PKG_CONFIG_FOUND)
PKG_CHECK_MODULES(XRANDR xrandr)
IF (XRANDR_FOUND)
OPTION(OSGVIEWER_USE_XRANDR Set to ON to enable Xrandr support
for GraphicsWindowX11. ON)
ELSE(XRANDR_FOUND)
SET(OSGVIEWER_USE_XRANDR OFF)
ENDIF (XRANDR_FOUND)
ELSE(PKG_CONFIG_FOUND)
SET(OSGVIEWER_USE_XRANDR OFF)
ENDIF(PKG_CONFIG_FOUND)
SET(LIB_PUBLIC_HEADERS ${LIB_PUBLIC_HEADERS}
${HEADER_PATH}/api/X11/GraphicsWindowX11
${HEADER_PATH}/api/X11/PixelBufferX11
${XRANDR_INCLUDE_DIRS}
)
SET(LIB_COMMON_FILES ${LIB_COMMON_FILES}
GraphicsWindowX11.cpp
PixelBufferX11.cpp
)
IF(OSGVIEWER_USE_XRANDR)
ADD_DEFINITIONS(-DOSGVIEWER_USE_XRANDR)
SET(LIB_PUBLIC_HEADERS ${LIB_PUBLIC_HEADERS} ${XRANDR_INCLUDE_DIRS})
LINK_LIBRARIES(Xrandr)
ENDIF(OSGVIEWER_USE_XRANDR)
# X11 on Apple requires X11 library plus OpenGL linking hack on Leopard
Re: [osg-users] OpenSceneGraph-2.7.8 dev release tagged
Hi Fred, On Sat, Dec 20, 2008 at 11:06 AM, Frederic Bouvier fredlis...@free.fr wrote: There shouldn't be a long period before 1.9.1 ( this one is flagged 1.9.0 ). Usually, we don't produce binary release for Linux. So the distro maintainers may want to wait OSG 2.8 before packaging flightgear 1.9.0, or directly 1.9.1 if it is ready in the meantime. I thought I'd go and check out this FlightGear release but I can't see any mention of the 1.9.0 release, the cvs docs just refer to flightgear-0.9 so are rather out of date. These webpages don't mention anything about the OSG being a new dependency. Are there more up to date webpages available specifying how to pull down and build the latest version of FlightGear? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgviewerWX example fails to build with debug
Mark Acosta schrieb: Hi guys, I'm running Fedora 10 and trying to build OSG from the latest svn version. Everything compiles fine except for the osgviewerWX example. I'm getting these errors: CMakeFiles/example_osgviewerWX.dir/osgviewerWX.o: In function `wxStringBase': /usr/include/wx-2.8/wx/string.h:351: undefined reference to `wxOnAssert(wchar_t const*, int, char const*, wchar_t const*, wchar_t const*)' CMakeFiles/example_osgviewerWX.dir/osgviewerWX.o:(.rodata._ZTV8wxOsgApp[vtable for wxOsgApp]+0x130): undefined reference to `wxApp::OnAssertFailure(wchar_t const*, int, wchar_t const*, wchar_t const*, wchar_t const*)' CMakeFiles/example_osgviewerWX.dir/osgviewerWX.o:(.rodata._ZTV8wxOsgApp[vtable for wxOsgApp]+0x138): undefined reference to `wxAppConsole::OnAssert(wchar_t const*, int, wchar_t const*, wchar_t const*)' I looked into this a bit and the routines listed above are only defined if __WXDEBUG__ is defined. Looking at /usr/include/wx-2.8/wx/debug.h, it's not clear to me how __WXDEBUG__ is getting defined. I noticed that if I define NDEBUG that it will undefine __WXDEBUG__. The example compiles if I do this, but it's more of a kluge than a solution. I'm no wx expert. Maybe someone on the list has an idea of what's going on here and what the proper fix is. Mark ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Hi, it looks as if you didn´t link to the debug-libs of wx. Check your cmake-settings, if there is a difference between release and debug for the wx dependency. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.7.8 dev release tagged
Hi Robert, Robert Osfield a écrit : Hi Fred, On Sat, Dec 20, 2008 at 11:06 AM, Frederic Bouvier fredlis...@free.fr wrote: There shouldn't be a long period before 1.9.1 ( this one is flagged 1.9.0 ). Usually, we don't produce binary release for Linux. So the distro maintainers may want to wait OSG 2.8 before packaging flightgear 1.9.0, or directly 1.9.1 if it is ready in the meantime. I thought I'd go and check out this FlightGear release but I can't see any mention of the 1.9.0 release, the cvs docs just refer to flightgear-0.9 so are rather out of date. These webpages don't mention anything about the OSG being a new dependency. Are there more up to date webpages available specifying how to pull down and build the latest version of FlightGear? We are still preparing packages. The location of the files will be announced later -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CMake error with 2.7.8
Hi Fred, On Sat, Dec 20, 2008 at 1:57 PM, Frederic Bouvier fredlis...@free.fr wrote: Thank you. Here is another one, in main CMakeLists.txt:25 IF had incorrect arguments : POLICY CMP0008 ( Unknown arguments specified ) I checked if there is a newer than 2.4.5 version of CMake under Etch but it seems there isn't. Could you try putting a if cmake version check around the offending lines? There are other such checks in the main CMakeLists.txt so you should be able to copy these. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CMake error with 2.7.8
Robert Osfield a écrit :
Hi Fred,
On Sat, Dec 20, 2008 at 1:57 PM, Frederic Bouvier fredlis...@free.fr wrote:
Thank you. Here is another one, in main CMakeLists.txt:25
IF had incorrect arguments : POLICY CMP0008 ( Unknown arguments specified )
I checked if there is a newer than 2.4.5 version of CMake under Etch but
it seems there isn't.
Could you try putting a if cmake version check around the offending
lines? There are other such checks in the main CMakeLists.txt so you
should be able to copy these.
I enclosed the line and the other two below in a
IF(CMAKE_MAJOR_VERSION EQUAL 2 AND CMAKE_MINOR_VERSION GREATER 4)
ENDIF(CMAKE_MAJOR_VERSION EQUAL 2 AND CMAKE_MINOR_VERSION GREATER 4)
or
IF(${CMAKE_MAJOR_VERSION} EQUAL 2 AND ${CMAKE_MINOR_VERSION} GREATER 4)
ENDIF(${CMAKE_MAJOR_VERSION EQUAL} 2 AND ${CMAKE_MINOR_VERSION} GREATER 4)
bloc, but the error is still there. I removed the 3 lines for the moment
-Fred
--
Frédéric Bouvier
http://my.fotolia.com/frfoto/ Photo gallery
http://fgsd.sourceforge.net/FlightGear Scenery Designer
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CMake error with 2.7.8
Hi Fred, Robert,
In this case (cmake version 2.6) the if(COMMAND cmake_policy) should
fail and not run line 25 at all. It seems that the command
(cmake_policy) was availbale in 2.4.5 however completely undocumented
(and later announched a new feature in the 2.6.0 release).
Find attached a CMakeLists.txt with fix
Mattias
On Sat, Dec 20, 2008 at 2:57 PM, Frederic Bouvier fredlis...@free.fr wrote:
Thank you. Here is another one, in main CMakeLists.txt:25
IF had incorrect arguments : POLICY CMP0008 ( Unknown arguments specified )
I checked if there is a newer than 2.4.5 version of CMake under Etch but
it seems there isn't.
-Fred
Robert Osfield a écrit :
Hi Fred,
Argg... I missed an OPTIONAL entry in the src/osgViewer/CMakeLists.txt
file, alas not enough of the commmunity tested svn/trunk before
2.7.8... it should read:
#use pkg-config to find various modues
INCLUDE(FindPkgConfig OPTIONAL)
IF(PKG_CONFIG_FOUND)
...
I've now added this and checked it in. The file is also attached,
could you please try this.
Robert.
On Sat, Dec 20, 2008 at 12:37 PM, Frederic Bouvier fredlis...@free.fr
wrote:
Hi Robert,
I have a problem trying to build 2.7.8 on Linux (Debian etch). CMake
(2.4.5) complains that FindPkgConfig ( .cmake ? ) is not found. It is
referenced in src/osgViewer/CMakeLists.txt
-Fred
--
Frédéric Bouvier
http://my.fotolia.com/frfoto/ Photo gallery
http://fgsd.sourceforge.net/FlightGear Scenery Designer
___
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
--
Frédéric Bouvier
http://my.fotolia.com/frfoto/ Photo gallery
http://fgsd.sourceforge.net/FlightGear Scenery Designer
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
IF(WIN32)
CMAKE_MINIMUM_REQUIRED(VERSION 2.4.6 FATAL_ERROR)
ELSE(WIN32)
IF(APPLE)
CMAKE_MINIMUM_REQUIRED(VERSION 2.6.0 FATAL_ERROR)
IF(${CMAKE_MAJOR_VERSION} EQUAL 2 AND ${CMAKE_MINOR_VERSION} EQUAL 4
AND ${CMAKE_PATCH_VERSION} LESS 7)
MESSAGE(Warning: A critical CMake bug exists in 2.4.6 and below.
Trying to build Universal Binaries will result in a compile error that seems
unrelated. Either avoid building Universal Binaries by changing the
CMAKE_OSX_ARCHITECTURES field to list only your architecture, or upgrade to the
current CVS version of CMake or a newer stable version if it exists.)
ENDIF(${CMAKE_MAJOR_VERSION} EQUAL 2 AND ${CMAKE_MINOR_VERSION} EQUAL 4
AND ${CMAKE_PATCH_VERSION} LESS 7)
ELSE(APPLE)
CMAKE_MINIMUM_REQUIRED(VERSION 2.4.0 FATAL_ERROR)
ENDIF(APPLE)
ENDIF(WIN32)
if(COMMAND cmake_policy)
# Works around warnings libraries linked against that don't
# have absolute paths (e.g. -lpthreads)
cmake_policy(SET CMP0003 NEW)
# Works around warnings about escaped quotes in ADD_DEFINITIONS
# statements.
cmake_policy(SET CMP0005 NEW)
# cmake-2.6.1 introduces policy cmp0008 decide how to treat full path
libraries that do not appear to be valid library file names
# quote from cvslog Such libraries worked by accident in the VS IDE and
Xcode generators in CMake 2.4 and below.
IF(${CMAKE_MAJOR_VERSION} EQUAL 2 AND ${CMAKE_MINOR_VERSION} GREATER 4)
if(POLICY CMP0008)
cmake_policy(SET CMP0008 OLD)
endif(POLICY CMP0008)
ENDIF(${CMAKE_MAJOR_VERSION} EQUAL 2 AND ${CMAKE_MINOR_VERSION} GREATER 4)
endif(COMMAND cmake_policy)
PROJECT(OpenSceneGraph)
SET(OPENSCENEGRAPH_MAJOR_VERSION 2)
SET(OPENSCENEGRAPH_MINOR_VERSION 7)
SET(OPENSCENEGRAPH_PATCH_VERSION 8)
SET(OPENSCENEGRAPH_SOVERSION 53)
# set to 0 when not a release candidate, non zero means that any generated
# svn tags will be treated as release candidates of given number
SET(OPENSCENEGRAPH_RELEASE_CANDIDATE 0)
SET(OPENSCENEGRAPH_VERSION
${OPENSCENEGRAPH_MAJOR_VERSION}.${OPENSCENEGRAPH_MINOR_VERSION}.${OPENSCENEGRAPH_PATCH_VERSION})
SET(OSG_PLUGINS osgPlugins-${OPENSCENEGRAPH_VERSION})
SET(OSG_PLUGIN_PREFIX )
IF (CYGWIN)
SET(OSG_PLUGIN_PREFIX cygwin_)
ENDIF(CYGWIN)
IF(MINGW)
SET(OSG_PLUGIN_PREFIX mingw_)
ENDIF(MINGW)
# We want to build SONAMES shared librariess
SET(OPENSCENEGRAPH_SONAMES TRUE)
SET(OPENTHREADS_SONAMES TRUE)
SET(OpenThreads_SOURCE_DIR ${OpenSceneGraph_SOURCE_DIR})
# We have some custom .cmake scripts not in the official distribution.
# Maybe this can be used override existing behavior if needed?
SET(CMAKE_MODULE_PATH
${OpenSceneGraph_SOURCE_DIR}/CMakeModules;${CMAKE_MODULE_PATH})
# Okay,
Re: [osg-users] CMake error with 2.7.8
Hi Fred,
Ignore my fix it was the same as yours. The problem perplexes me a
bit. I'll have to find a cmake-2.4.5 and test this myself.
I see that you found the way around.
cheers
Mattias
On Sat, Dec 20, 2008 at 4:40 PM, Frederic Bouvier fredlis...@free.fr wrote:
Robert Osfield a écrit :
Hi Fred,
On Sat, Dec 20, 2008 at 1:57 PM, Frederic Bouvier fredlis...@free.fr wrote:
Thank you. Here is another one, in main CMakeLists.txt:25
IF had incorrect arguments : POLICY CMP0008 ( Unknown arguments specified )
I checked if there is a newer than 2.4.5 version of CMake under Etch but
it seems there isn't.
Could you try putting a if cmake version check around the offending
lines? There are other such checks in the main CMakeLists.txt so you
should be able to copy these.
I enclosed the line and the other two below in a
IF(CMAKE_MAJOR_VERSION EQUAL 2 AND CMAKE_MINOR_VERSION GREATER 4)
ENDIF(CMAKE_MAJOR_VERSION EQUAL 2 AND CMAKE_MINOR_VERSION GREATER 4)
or
IF(${CMAKE_MAJOR_VERSION} EQUAL 2 AND ${CMAKE_MINOR_VERSION} GREATER 4)
ENDIF(${CMAKE_MAJOR_VERSION EQUAL} 2 AND ${CMAKE_MINOR_VERSION} GREATER 4)
bloc, but the error is still there. I removed the 3 lines for the moment
-Fred
--
Frédéric Bouvier
http://my.fotolia.com/frfoto/ Photo gallery
http://fgsd.sourceforge.net/FlightGear Scenery Designer
___
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] [Newbie]: Cannot build OpenVRML; regex.a is missing
Hello, I am following http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/Linux to build VRML plugin Normally I am using Eclipse CDT4 - MingW environment on my Windows PC. But for this task I have installed cygwin with all needed packages to build the three needed libs: - libopenvrml.a - libantlr.a - regex.a There are no problems (error messages etc.) during ./configure .., make and make install But as result I get only: openvrml-0.14.3\lib\antlr\src\.libs\antlr.a openvrml-0.14.3\lib\libopenvrml.a - Where is my regex.a lib? - I am on the right track to build the VRML plugin? - All tips to build the VRML plugin for Eclipse CDT4 - MingW environment are welcomed. I am dealing with this topic now for over two weekends, so any help is really appreciated. Many thanks. Karl ... ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Stereo with HMD in OpenSceneGraph
Hi Robert, I don't totally agree with your answer. In these two functions computeRightEyeViewImplementation() and computeLeftEyeViewImplementation(), you do use iod, screen distance and fusion distance in computing the view matrices. And you don't check to see if the display mode is HEAD_MOUNTED_DISPLAY or not - as you do in computing the projection matrices. So I still think that you do use these variables in computing the view matrices when the display mode is HMD. Could you give me a little more explanation for that. Thanks, Dat On 12/20/08, Robert Osfield robert.osfi...@gmail.com wrote: Hi Dat, The screen distance and fusion distance are relevant to monitor or projection based stereo systems, not for HMD's. The OSG doesn't use a convergence angle as this is not appropriate for proper stereo effect in monitor or projection based stereo system, instead the OSG uses the mathematically correct system of shearing the projection matrix. Things a bit different for HMD, as the projection matrix is identical for both eyes, and only the view matrix is offset (and perhaps rotated). One method to accurate control this is to use a SceneView::ComputeStereoMatricesCallback, but now with have the osgViewer it's probably easier just to manually create two slave Camera's with the appropriate view matrix translation to account for the inter-ocular distance. FYI, osgViewer hasn't yet taken over management of all stereo modes from the lower level SceneView, but this is my plan - to migrate all stereo support into the high level class, and then provide configuration file support for it. This will be done well after 2.8. Robert. On Sat, Dec 20, 2008 at 3:37 AM, tien dat tienda...@gmail.com wrote: Hi all, I have a question about controlling stereo with HMD in OpenSceneGraph. Basically to setup stereo display you need the distance of two eyes and the convergence angle. When I take a look at OpenSceneGraph code for setting up stereo with HMD, I see two other variables which are screen distance and fusion distance. There is also a matrix to multiple with each view for each eye that uses these variables. So could any of you tell me what they mean and what happens if I change these variables. Thank you very much, Dat ___ 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 -- Dat Tien Nguyen Email: tienda...@gmail.com Address: 218/74/7 Tay Son Dong Da Hanoi Vietnam Phone: 844-5370595 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Stereo with HMD in OpenSceneGraph
HI Dat, I didn't implement this specific head mounted elements, it's what an end users submitted for his setup. I don't have any head mounted displays to tests against. This code is also pretty old and not part of the standard stereo setup. I do however I lot of experience with driving projection based stereo systems, head mounted displays aren't a far stretch from this but there are differences as I said in my previous email. Personally I'd set up the slave cameras myself and totally ignore the screen distance as it is has no relevance to HMD's. The only thing of relevance is that inter-occulare distance which requires a horziontal translation of the view matrix. Robert. On Sat, Dec 20, 2008 at 6:43 PM, tien dat tienda...@gmail.com wrote: Hi Robert, I don't totally agree with your answer. In these two functions computeRightEyeViewImplementation() and computeLeftEyeViewImplementation(), you do use iod, screen distance and fusion distance in computing the view matrices. And you don't check to see if the display mode is HEAD_MOUNTED_DISPLAY or not - as you do in computing the projection matrices. So I still think that you do use these variables in computing the view matrices when the display mode is HMD. Could you give me a little more explanation for that. Thanks, Dat On 12/20/08, Robert Osfield robert.osfi...@gmail.com wrote: Hi Dat, The screen distance and fusion distance are relevant to monitor or projection based stereo systems, not for HMD's. The OSG doesn't use a convergence angle as this is not appropriate for proper stereo effect in monitor or projection based stereo system, instead the OSG uses the mathematically correct system of shearing the projection matrix. Things a bit different for HMD, as the projection matrix is identical for both eyes, and only the view matrix is offset (and perhaps rotated). One method to accurate control this is to use a SceneView::ComputeStereoMatricesCallback, but now with have the osgViewer it's probably easier just to manually create two slave Camera's with the appropriate view matrix translation to account for the inter-ocular distance. FYI, osgViewer hasn't yet taken over management of all stereo modes from the lower level SceneView, but this is my plan - to migrate all stereo support into the high level class, and then provide configuration file support for it. This will be done well after 2.8. Robert. On Sat, Dec 20, 2008 at 3:37 AM, tien dat tienda...@gmail.com wrote: Hi all, I have a question about controlling stereo with HMD in OpenSceneGraph. Basically to setup stereo display you need the distance of two eyes and the convergence angle. When I take a look at OpenSceneGraph code for setting up stereo with HMD, I see two other variables which are screen distance and fusion distance. There is also a matrix to multiple with each view for each eye that uses these variables. So could any of you tell me what they mean and what happens if I change these variables. Thank you very much, Dat ___ 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 -- Dat Tien Nguyen Email: tienda...@gmail.com Address: 218/74/7 Tay Son Dong Da Hanoi Vietnam Phone: 844-5370595 ___ 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] The Collada plugin and transparency
Yet more fixes for the DAE plugin.
/*
* Copyright 2006 Sony Computer Entertainment Inc.
*
* Licensed under the SCEA Shared Source License, Version 1.0 (the License);
you may not use this
* file except in compliance with the License. You may obtain a copy of the
License at:
* http://research.scea.com/scea_shared_source_license.html
*
* Unless required by applicable law or agreed to in writing, software
distributed under the License
* is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or
* implied. See the License for the specific language governing permissions and
limitations under the
* License.
*/
#ifndef _DAE_CONV_H_
#define _DAE_CONV_H_
#include string
#include dae.h
#include dae/daeURI.h
#include dae/daeElement.h
#include dom/domCommon_color_or_texture_type.h
#include osg/Node
#include osg/Transform
#include osg/Notify
#include osg/PositionAttitudeTransform
#include osgDB/ReaderWriter
#include osgDB/FileNameUtils
#include osgDB/FileUtils
#include osgDB/Registry
#include osg/Material
class domBind_material;
class domCamera;
//class domCommon_color_or_texture_type;
class domCommon_float_or_param_type;
class domGeometry;
class domInstance_controller;
class domInstance_geometry;
class domInstanceWithExtra;
class domLight;
class domLookat;
class domMatrix;
class domNode;
class domP;
class domProfile_COMMON;
class domScale;
class domSkew;
class domTranslate;
class domRotate;
class domVisual_scene;
#include dom/domInputLocalOffset.h
namespace osgdae {
class domSourceReader;
inline daeElement *getElementFromURI( daeURI uri )
{
if ( uri.getState() == daeURI::uri_loaded || uri.getState() ==
daeURI::uri_pending ) {
uri.resolveElement();
}
return uri.getElement();
}
inline daeElement *getElementFromIDRef( daeIDRef idref )
{
if ( idref.getState() == daeIDRef::id_loaded || idref.getState() ==
daeIDRef::id_pending ) {
idref.resolveElement();
}
return idref.getElement();
}
template typename TInputArray, typename TInputType
bool findInputSourceBySemantic( TInputArray inputs, const char* semantic,
daeElement * element,
TInputType ** input = NULL, int unit = 0 )
{
element = NULL;
int count = 0;
for ( size_t i = 0; i inputs.getCount(); i++ ) {
if ( !strcmp(semantic, inputs[i]-getSemantic()) ) {
if ( count == unit )
{
element = getElementFromURI( inputs[i]-getSource() );
*input = (TInputType*)inputs[i];
return true;
}
count++;
}
}
return false;
}
/// Convert string to value using it's stream operator
template typename T
T parseString(const std::string valueAsString) {
std::stringstream str;
str valueAsString;
T result;
str result;
return result;
}
inline osg::Vec3 parseVec3String(const std::string valueAsString)
{
std::stringstream str;
str valueAsString;
osg::Vec3 result;
str result.x() result.y() result.z();
return result;
}
inline osg::Matrix parseMatrixString(const std::string valueAsString)
{
std::stringstream str;
str valueAsString;
osg::Matrix result;
str result(0,0) result(1,0) result(2,0) result(3,0)
result(0,1) result(1,1) result(2,1) result(3,1)
result(0,2) result(1,2) result(2,2) result(3,2)
result(0,3) result(1,3) result(2,3) result(3,3);
return result;
}
/**
@class daeReader
@brief Read a OSG scene from a DAE file
*/
class daeReader {
public:
daeReader(DAE *dae_);
virtual ~daeReader();
bool convert( const std::string fileURI );
osg::Node* getRootNode(){ return rootNode; }
// Additional Information
std::string m_AssetUnitName;
float m_AssetUnitMeter;
domUpAxisType m_AssetUp_axis;
// Texture unit useage
enum
{
MAIN_TEXTURE_UNIT = 0,
AMBIENT_OCCLUSION_UNIT,
TRANSPARENCY_MAP_UNIT
};
protected:
//scene processing
osg::Node*processVisualScene( domVisual_scene *scene );
osg::Node*processNode( domNode *node );
osg::Node*processOsgMatrixTransform( domNode *node );
//osg::Node* processInstance( domInstanceWithExtra *iwe );
// Processing of OSG specific info stored in node extras
osg::Node* processExtras(domNode *node);
void processNodeExtra(osg::Node* osgNode, domNode *node);
domTechnique* getOpenSceneGraphProfile(domExtra* extra);
void processAsset( domAsset *node );
osg::Node* processOsgSwitch(domTechnique* teq);
osg::Node* processOsgMultiSwitch(domTechnique* teq);
osg::Node* processOsgLOD(domTechnique* teq);
osg::Node* processOsgDOFTransform(domTechnique* teq);
osg::Node* processOsgSequence(domTechnique* teq);
//geometry processing
osg::Geode* processInstanceGeometry( domInstance_geometry *ig );
osg::Geode*
Re: [osg-users] CMake error with 2.7.8
HI Mattias, On Sat, Dec 20, 2008 at 4:17 PM, Mattias Helsing helsin...@gmail.com wrote: Ignore my fix it was the same as yours. The problem perplexes me a bit. I'll have to find a cmake-2.4.5 and test this myself. I see that you found the way around. A search of web comes up with the source for cmake-2.4.5: http://www.cmake.org/files/v2.4/cmake-2.4.5.tar.gz Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Disabling small feature culling for a subgraph
Hi Robert, I've noticed that my fix didn't make it into the 2.7.8 release and just wanted to check if there was a problem with it and that it isn't forgotten. Regards, Per Robert Osfield wrote: Hi Per, I've just done a quick review of your changes and it does feel balanced to me. Is CullVisitor checking the current setting of SmallFeatureCullingPixelSize() from the current CullingSet or CullStack? If so then you own callback should be setting current CullingSet rather than the CullStack. CullStack probably would be best without inheriting from CullingSettings to avoid this confusion, but I suspect I wrote it this may for backwards compatibility. I'll need to dig into CullVisitor to double check all this. Robert. On Mon, Dec 15, 2008 at 2:23 PM, Per Fahlberg pe...@remograph.com wrote: Hi Robert, I've found a way to get it working by slightly modifying CullStack.cpp and by also changing my cull callback. When pushing the CullingSet in CullStack I have added updating the cull mask in the new CullingSet. I needed to change both the cull visitors culling mode and the current CullingSets mask in the callback, because I didn't find a way to propagate the changed mode from the CullVisitor to the current CullingSet. I'm cross posting to osg-submissions and have attached the modified CullStack.cpp, I've also attached a modified osgscribe.cpp that shows the problem. When zooming out one model should always be visible but the other shall disappear when it gets less than 200 pixels in size. Regards, Per Robert Osfield wrote: Hi Per, It sounds like you'll need to directly manipulator or push new settings on the stack in CullVisitor. Robert. On Mon, Dec 15, 2008 at 10:12 AM, Per Fahlberg pe...@remograph.com wrote: Hi Robert, I've traced the problem down now and it seems the culling mode that the CullVisitor uses is correct but the one in the CullingSet is incorrect. This is due to the CullingSet being updated in CullStack::pushProjectionMatrix which is called early on in culling, and when I change the culling mode in my callback it only changes the mode in the CullVisitor and not the mode in the CullingSet. Since I'm not very familiar with the internals in the culling code I would like to ask for some guidance before I dive in and try to code up a fix for the problem. Do you know of a place in the code where the culling set might be updated to reflect the changes in the CullVisitor/CullStack or should I try to directly propagate the changes from the CullSettings::setCullingMode down via CullStack to the CullingSet? Regards, Per Robert Osfield wrote: Hi Per, On Tue, Dec 2, 2008 at 11:34 AM, Per Fahlberg pe...@remograph.com wrote: Perhaps I wasn't clear in my question so I will try once more, is there a way to disable small feature culling for just a subgraph not the entire scene? The only way is is use a cull callback to cache the previous setting, set the new setting do the traverse and the restore the original value. Your original callback does this, but I don't know why it doesn't work. Note, I haven't tried it myself so I can't provide any further direction, you'll just have to dig into the source code. 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 ___ 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 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] CMake error with 2.7.8
Hi Fred and Mattias, I've download cmake 2.4.5 and get the Error: make: *** [cmake_check_build_system] Error 255 And on comment out the block: if(POLICY CMP0008) cmake_policy(SET CMP0008 OLD) endif(POLICY CMP0008) The error goes away and build commence fine. The specific problem in cmake 2.4.5 looks to be how it handles the IF(POLICY CMP0008), if I comment out just this then it also compiles fine: # if(POLICY CMP0008) cmake_policy(SET CMP0008 OLD) # endif(POLICY CMP0008) Attempts at using IF(CMAKE_... version ) to optionally use the above block has failed at my end, just as it did for Fredric. This may well be a bug in Cmake 2.4.5, but given it looks to be an unofficial feature of 2.4.5 perhaps it's not too surprising. What to do about this? How essential is the if(POLICY)? Would it be fine to just go with this commented out? I'm no Cmake expert so can't really answer this, all I know is that block of script came in as part submission and I merged trusting the submission was made be one with a little more cmake knowledge than myself. So again I defer to those more cmake knowledgeable than myself, is it safe to always call cmake_policy(SET CMP8 OLD)? If it's not then I think we'll just have declare cmake 2.4.5 unsupported, and perhaps add the cmake 2.4.6 requirement to the CMakeLists.txt file? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Disabling small feature culling for a subgraph
Hi Per, On Sat, Dec 20, 2008 at 7:50 PM, Per Fahlberg pe...@remograph.com wrote: I've noticed that my fix didn't make it into the 2.7.8 release and just wanted to check if there was a problem with it and that it isn't forgotten. As I mentioned in my reply, the patch doesn't feel right, and to me suggest design problems elsewhere that really deserve looking at. So I shelved the patch till I've had a chance to do this wider review. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CMake error with 2.7.8
Hi Robert, Fred, I can verify this bug. The script code is to blame and I will be posting to osg-submissions. The CMakeLists as is starts to work with cmake-2.4.7 which probably why this hasn't been reported before (so most debian users moved on to Lenny which has cmake-2.6.0 :) Mattias On Sat, Dec 20, 2008 at 8:30 PM, Robert Osfield robert.osfi...@gmail.com wrote: HI Mattias, On Sat, Dec 20, 2008 at 4:17 PM, Mattias Helsing helsin...@gmail.com wrote: Ignore my fix it was the same as yours. The problem perplexes me a bit. I'll have to find a cmake-2.4.5 and test this myself. I see that you found the way around. A search of web comes up with the source for cmake-2.4.5: http://www.cmake.org/files/v2.4/cmake-2.4.5.tar.gz 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] CMake error with 2.7.8
Hi Robert, my kids woke each other up so it took an hour to click that send button :-) As I said though we would need to require 2.4.7. I guess for win32 too. I personally would prefer to up the required cmake version because i'm not very fond of the IF(major_version == 2 AND minor_version y) since they will all break when cmake-3.0 arrives. The IF(POLICY CMPxxx) is much better in that respect and easier to read and understand. Also, the fact that this hasn't been reported before proves that not many developers still use cmake pre 2.4.7 On the other hand etch still uses 2.4.5. I don't know if this is important to you. Is it? On Sat, Dec 20, 2008 at 8:59 PM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Fred and Mattias, I've download cmake 2.4.5 and get the Error: make: *** [cmake_check_build_system] Error 255 And on comment out the block: if(POLICY CMP0008) cmake_policy(SET CMP0008 OLD) endif(POLICY CMP0008) The error goes away and build commence fine. The specific problem in cmake 2.4.5 looks to be how it handles the IF(POLICY CMP0008), if I comment out just this then it also compiles fine: # if(POLICY CMP0008) cmake_policy(SET CMP0008 OLD) # endif(POLICY CMP0008) Attempts at using IF(CMAKE_... version ) to optionally use the above block has failed at my end, just as it did for Fredric. This may well be a bug in Cmake 2.4.5, but given it looks to be an unofficial feature of 2.4.5 perhaps it's not too surprising. What to do about this? How essential is the if(POLICY)? Would it be fine to just go with this commented out? I'm no Cmake expert so can't really answer this, all I know is that block of script came in as part submission and I merged trusting the submission was made be one with a little more cmake knowledge than myself. So again I defer to those more cmake knowledgeable than myself, is it safe to always call cmake_policy(SET CMP8 OLD)? no. I tried this with cmake-2.6.0 and this makes cmake report that you're trying to set a policy that doesn't exist. If it's not then I think we'll just have declare cmake 2.4.5 unsupported, and perhaps add the cmake 2.4.6 requirement to the CMakeLists.txt file? I tried 2.4.5/6/7/8. This won't start to work until 2.4.7. Mattias 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] CMake error with 2.7.8
2.4.5 is also the only binary package (that I know of, at least) that is available for Red Hat Enterprise 5. If you're taking votes, I'd prefer keeping support for 2.4.5. --J Sent from my iPhone On Dec 20, 2008, at 5:38 PM, Mattias Helsing helsin...@gmail.com wrote: Hi Robert, my kids woke each other up so it took an hour to click that send button :-) As I said though we would need to require 2.4.7. I guess for win32 too. I personally would prefer to up the required cmake version because i'm not very fond of the IF(major_version == 2 AND minor_version y) since they will all break when cmake-3.0 arrives. The IF(POLICY CMPxxx) is much better in that respect and easier to read and understand. Also, the fact that this hasn't been reported before proves that not many developers still use cmake pre 2.4.7 On the other hand etch still uses 2.4.5. I don't know if this is important to you. Is it? On Sat, Dec 20, 2008 at 8:59 PM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Fred and Mattias, I've download cmake 2.4.5 and get the Error: make: *** [cmake_check_build_system] Error 255 And on comment out the block: if(POLICY CMP0008) cmake_policy(SET CMP0008 OLD) endif(POLICY CMP0008) The error goes away and build commence fine. The specific problem in cmake 2.4.5 looks to be how it handles the IF(POLICY CMP0008), if I comment out just this then it also compiles fine: # if(POLICY CMP0008) cmake_policy(SET CMP0008 OLD) # endif(POLICY CMP0008) Attempts at using IF(CMAKE_... version ) to optionally use the above block has failed at my end, just as it did for Fredric. This may well be a bug in Cmake 2.4.5, but given it looks to be an unofficial feature of 2.4.5 perhaps it's not too surprising. What to do about this? How essential is the if(POLICY)? Would it be fine to just go with this commented out? I'm no Cmake expert so can't really answer this, all I know is that block of script came in as part submission and I merged trusting the submission was made be one with a little more cmake knowledge than myself. So again I defer to those more cmake knowledgeable than myself, is it safe to always call cmake_policy(SET CMP8 OLD)? no. I tried this with cmake-2.6.0 and this makes cmake report that you're trying to set a policy that doesn't exist. If it's not then I think we'll just have declare cmake 2.4.5 unsupported, and perhaps add the cmake 2.4.6 requirement to the CMakeLists.txt file? I tried 2.4.5/6/7/8. This won't start to work until 2.4.7. Mattias 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Stereo with HMD in OpenSceneGraph
Hi Robert, This might go beyond my original question, but I just want to share my thought about your point. First of all, I think screen distance does have some effect here, since the farther the screen, the smaller the FOV (people have different head shapes, right?). Second, I think iod is not the only one parameter that you concern about. Convergence angle (i.e. fusion distance) should also be one important factor because this is where you really focus at. I don't know how much different if you set this point to infinity instead of some objects that you should focus on. I don't know the answer, so I want to try to see by myself, and have the beginning question. Anyway, thank you very much for your help. I will ask you when I have more question about OSG. Dat On 12/20/08, Robert Osfield robert.osfi...@gmail.com wrote: HI Dat, I didn't implement this specific head mounted elements, it's what an end users submitted for his setup. I don't have any head mounted displays to tests against. This code is also pretty old and not part of the standard stereo setup. I do however I lot of experience with driving projection based stereo systems, head mounted displays aren't a far stretch from this but there are differences as I said in my previous email. Personally I'd set up the slave cameras myself and totally ignore the screen distance as it is has no relevance to HMD's. The only thing of relevance is that inter-occulare distance which requires a horziontal translation of the view matrix. Robert. On Sat, Dec 20, 2008 at 6:43 PM, tien dat tienda...@gmail.com wrote: Hi Robert, I don't totally agree with your answer. In these two functions computeRightEyeViewImplementation() and computeLeftEyeViewImplementation(), you do use iod, screen distance and fusion distance in computing the view matrices. And you don't check to see if the display mode is HEAD_MOUNTED_DISPLAY or not - as you do in computing the projection matrices. So I still think that you do use these variables in computing the view matrices when the display mode is HMD. Could you give me a little more explanation for that. Thanks, Dat On 12/20/08, Robert Osfield robert.osfi...@gmail.com wrote: Hi Dat, The screen distance and fusion distance are relevant to monitor or projection based stereo systems, not for HMD's. The OSG doesn't use a convergence angle as this is not appropriate for proper stereo effect in monitor or projection based stereo system, instead the OSG uses the mathematically correct system of shearing the projection matrix. Things a bit different for HMD, as the projection matrix is identical for both eyes, and only the view matrix is offset (and perhaps rotated). One method to accurate control this is to use a SceneView::ComputeStereoMatricesCallback, but now with have the osgViewer it's probably easier just to manually create two slave Camera's with the appropriate view matrix translation to account for the inter-ocular distance. FYI, osgViewer hasn't yet taken over management of all stereo modes from the lower level SceneView, but this is my plan - to migrate all stereo support into the high level class, and then provide configuration file support for it. This will be done well after 2.8. Robert. On Sat, Dec 20, 2008 at 3:37 AM, tien dat tienda...@gmail.com wrote: Hi all, I have a question about controlling stereo with HMD in OpenSceneGraph. Basically to setup stereo display you need the distance of two eyes and the convergence angle. When I take a look at OpenSceneGraph code for setting up stereo with HMD, I see two other variables which are screen distance and fusion distance. There is also a matrix to multiple with each view for each eye that uses these variables. So could any of you tell me what they mean and what happens if I change these variables. Thank you very much, Dat ___ 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 -- Dat Tien Nguyen Email: tienda...@gmail.com Address: 218/74/7 Tay Son Dong Da Hanoi Vietnam Phone: 844-5370595 ___ 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 -- Dat Tien Nguyen Email: tienda...@gmail.com Address: 218/74/7 Tay Son Dong Da Hanoi Vietnam Phone: 844-5370595 ___ osg-users mailing list
Re: [osg-users] High resolution screencast
Hi Simon, Sukender, And about capturing a different size, I guess no, you'll probably have to resize your image with your encogind API. Yes, Sukender is right, the ScreenCaptureHandler was designed for a screenshot functionality, so just takes the current resolution of any graphics context(s) that you have in the viewer. 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] Building the Collada plugin
On Dec 20, 2008, at 2:24 AM, Roger James wrote: I build against https://collada-dom.svn.sourceforge.net/svnroot/collada-dom/tags/2.1/dom , that works fine for me. There is a lot of work by various people going on in the Collada plugin at the moment which is not quite ready for prime time. I will try a build against the latest DOM before I make a submission. I am afraid I have not yet moved to Visual Studio 2008, my production environment is VS2005 and will remain that way for some time. D'oh! Right, that makes sense. I'll try it. Randolph ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
