[osg-users] Which matrix decides the world position of the vertex
Hi, This problem has confused me for a long time, I have made a lot of effort to get the matrix which translate the vertex from local coordinate to world space coordinate in osg, however, the result seems that the matirx I get from MatrixTransform does not work in glsl. Though it seems that I can get the world position of the vertex through osg_ViewMatrixInverse combined with gl_ModelViewMatrix, but I think it is not advisable for there are so much instructions for vertex shader. I build the indoor scene using osg2.4. Each object added to the scene is added to a MatrixTransform(mt) node which containing all the information of translation,rotation and so on, this MatrixTransform node is then added to the root. I send the matrix(ModelWorld = mt-getMatrix()) to the vertex shader to get the world position of the vertex, but the result of gl_Vertex * ModelWorld in glsl seems not the world position of the vertex. Any informations about this will be appreciated. Thanks very much for your help! guilianzhang 2008-07-01 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Which matrix decides the world position of the vertex
Hi Guilanzhang, Could it be that you have been confused by the pre-multiple convention of OSG maths, and post-multiple convention of GLSL maths, the opposing conventions has turned out to be rather unfortunate, the OSG's convention fitted we will other tools in it's early days, but alas GLSL came along later and cemented the opposite convention. So in OSG land you have: v' = v * M In GLSL v' = M * v I would ideally like to wave a magic wand and have all the OSG and user code moved across to the GLSL convention, but alas doing this in practice would break lots of code. Robert. On Tue, Jul 1, 2008 at 9:30 AM, guilianzhang [EMAIL PROTECTED] wrote: Hi, This problem has confused me for a long time, I have made a lot of effort to get the matrix which translate the vertex from local coordinate to world space coordinate in osg, however, the result seems that the matirx I get from MatrixTransform does not work in glsl. Though it seems that I can get the world position of the vertex through osg_ViewMatrixInverse combined with gl_ModelViewMatrix, but I think it is not advisable for there are so much instructions for vertex shader. I build the indoor scene using osg2.4. Each object added to the scene is added to a MatrixTransform(mt) node which containing all the information of translation,rotation and so on, this MatrixTransform node is then added to the root. I send the matrix(ModelWorld = mt-getMatrix()) to the vertex shader to get the world position of the vertex, but the result of gl_Vertex * ModelWorld in glsl seems not the world position of the vertex. Any informations about this will be appreciated. Thanks very much for your help! guilianzhang 2008-07-01 ___ 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] Testing of OSG and VPB SVN in prep for 2.5.3 devreleasese
Hi Jason, Mathias has submitted some changed to the cmake Atomic checks/setup, I have now checked these into SVN. Could you do an svn update and clean build, then let us know if it compiles OK now. Thanks, Robert. On Sat, Jun 28, 2008 at 12:01 AM, Jason Daly [EMAIL PROTECTED] wrote: Jean-Sébastien Guay wrote: Wow, many thanks for testing across all these combinations. Now will anyone else pitch in for other platforms?? :-) Red Hat Enterprise 5.2 32-bit, g++ 4.1, cmake 2.4.5 Pentium D 955, Nvidia 7950GX2 on 169.12 drivers Builds and runs fine, although I had to manually specify CXXFLAGS=-march=i686 as an environment variable to get the new atomic ref counting to work properly. Without that, it failed the atomic tests. I tried specifying the architecture inside ccmake, but it seemed that once the test failed, it never ran it again (I don't know if there's a cmake-specific command line option that would work). --J ___ 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] Rendering to multiple graphics cards
Hi Bob, Last summer when testing multiple GPU rendering I found that if I forced the serialization of the draw dispatch I actually got better performance. This suggest a performance problem in the driver, or it could also have been a hardware contention. Either way even on my quad core, dual GPU machine serializing draw dispatch was a winner - against what I would have expected for a properly balanced system. I did call for testing of draw serialization from the community, but alas got 0 feedback on this issue, so had to go with the only data point that I had - my own experience with my system, and choice the default to serialize the draw. This option is configurable via the osg::DisplaySetting classes setSerializeDrawDispatch method, or its default setting via the env var OSG_SERIALIZE_DRAW_DISPATCH, if you set this env var to OFF, then it'll allow the draw dispatch to run multi-threaded. For your tests it's unlikely to make too much difference as draw dispatch for a textured cube will be far less than 1ms, so even doing for draw traversals in series won't be something that breaks frame. I'll do some more testing today to see if things have changed in the last year, feedback on other system would be really really useful. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Composite viewer resize
Hi Fabien,
Does osgcomposite resize correctly for you? i.e.
osgcompositeviewer cow.osg
I have just tried resizing and it all three views adjust their aspect
ratio correctly. This relies upon the Camera's projection matrices
being resized by the GraphicsContext itself, your own code shouldn't
need to handle the resize, unless of course you actually want to
implement some custom resize. You can control the resize behaviour of
the projection matrix via the Camera::setProjectionResizePolicy(..)
options are:
enum ProjectionResizePolicy
{
FIXED, /** Keep the projection matrix fixed, despite
window resizes.*/
HORIZONTAL, /** Adjust the HORIZOTNAL field of view on
window resizes.*/
VERTICAL /** Adjust the VERTICAL field of view on window resizes.*/
};
Robert.
On Tue, Jul 1, 2008 at 10:59 AM, fabien rioli
[EMAIL PROTECTED] wrote:
Hi All,
I'm currently having problems with the resize event redistribution with
multiple views (in a composite viewer).
It seems that only one of the viewers receives the resize event.
See the attached example (.cpp) witch illustrate the problem (two viewers
with a resize handler).
In the resise handlers I change the projection matrix in order to show witch
view gets the event.
The following sreenshots shows different steps of the test.
1.jpg : no event
2.jpg : a first resize event ( the window have been moved)
3.jpg : a second resize event ( resise from the bottom right corner)
From what I have understood from osgViewer/CompositeViewer.cpp (in the
eventTraversal) the viewer witch receives the event is the one who have the
focus.
I think that because every viewer in the same window is affected by the
resizing, the may have to receive the event each other.
Is this an intended behaviour ?
Thank you in advance,
Fabien
--
Fabien Rioli
www.tharsis-software.com
___
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] Rendering to multiple graphics cards
Hi Bob and Robert, We managed to get our system to run stable. Intel Core 2 Duo E6600 + 2 X GeForce 8800 GTS 320 MB + 3 monitors. Former crashes were indeed power related. It turned out we did not connect aditional 12V/5V connector to motherboard. It was needed when two 16xPCIex lanes were used. We also observed performance issues. With our demo code we had around 20 fps. Its not much but I would not consider this total disaster either. This was only a test for us. In target solution we could probably use much better graphics and better cpu. Plus we may try to make some additional optimizations if needed. So in the end I consider this a complete success. OSG works in Vista in multithreaded / multi gfxcard / multimonitor configurations. Thanks for the hints and all support. Cheers, Wojtek I can draw successfully with slave cameras to all 4 screens in various configs in Vista, either the osgviewer across all screens, 4 independent screens (i.e. screens 0-3, each set @ 1440x900), or 2 double-wide screens (screen 0 2, each set to 2880x900). Note that in the Vista display settings all 4 screens are set up as 1 big extended desktop. But I'm having TROUBLE MAINTAINING 60HZ, even though my rendered scene consists solely of a textured cube. For example, with osgviewer.exe (ver 2.4) spread across all 4 screens (4 graphics contexts): Threading model: CullDrawThreadperContext Event, Update, all 4 Cull,Draw,GPU vals are small (0.xx) The scene achieves 60Hz at times, but feels choppy, and I notice the middle two GPUs at times show long orange bars, which are killing the 60Hz rate. All 4 CPUs are running @ approx 52% (osgviewer.exe @ 30% and dwm.exe @ 20%) So I also disabled desktop composition on the osgviewer.exe task, which sent the dwm.exe (desktop window manager) down to 0% (disabled), which made the rotating cube less choppy, but now can only achieve 45Hz??? I am experiencing similar results with my own osg2.4-based fourDscape task, with 4 cameras rendered to screen 0-3 (each @ 1440x900), with the same very small Cull/Draw/GPU numbers (all 4 CPUS @ 22%), but can only achieve 47Hz. Any suggestions as to where to look for who/what in Vista is stealing resources and how to make it stop? With a single screen, 60Hz is no problem. thanks. Bob. - Robert Osfield wrote: Hi Wojteck, As a hardware sanity check you could just dual boot the machine with Linux, this itself will bring its own learning curve, but at least you'll have a setup that others have known work just fine. Robert. On Mon, Jun 30, 2008 at 3:24 PM, Wojciech Lewandowski [EMAIL PROTECTED] wrote: Hi Everyone, I have done some OSG testing with Vista 64 bit + 2 x GeForce 8800 GTS 320 MB + 3 monitors. I have attached only 3 monitors but I am sure 4 would work either. Unfortunately results are mixed. I was able to start osgviewer and our demo app on 3 monitors. I was able to get some visual but after few frames driver was dying and after few moments Vista popped up with msgbox that graphics driver failed but now it is ok (or something like this). I may not have the power supply decent enough to provide the stable current so this crash could be power related. I will try to arrange some heavy duty power supply and redo the tests again later this week. Anyway it looks like at this stage results are more promising than with XP and two different GeForces. Cheers, Wojtek - Original Message - From: Wojciech Lewandowski To: OpenSceneGraph Users Sent: Monday, June 30, 2008 10:34 AM Subject: Re: [osg-users] Rendering to multiple graphics cards Thanks, Bob. This is a relief ;-). I don't have the acces to similar Vista setup yet. Will try to grab two boards and do the checks this week.Will post a meesage with results when I am done. Thanks again. Wojtek - Original Message - From: Bob Balfour To: OpenSceneGraph Users Sent: Sunday, June 29, 2008 2:32 AM Subject: Re: [osg-users] Rendering to multiple graphics cards I have two Nvidia 8800 cards on a Windows Vista platform (HP), and setting traits-screenNum to 0 or 1 as Robert indicated does send the rendering to the appropriate graphics cards. I used code very similar to the osgcamera example, multipleWindowMultipleCameras method. Does anyone have experience setting up a 4-monitor (each 1440x900) system on Windows Vista? I have 2 osgcameras/contexts rendering left-half/right-half of the scene. With 2 Nvidia graphics cards both in dual-head mode, if I render each camera to a viewport 2880x900 I'm hoping that the scene will be spread properly over the 4 monitors (will try it shortly once I round up four HD monitors), without configuring the extending the desktop option in Windows, which seems to take considerable resources in the dwm.exe task (dynamic window manager), which appears to have an OSG rendering performance impact. Anyone
Re: [osg-users] The story continues: osgthirdpersonview crashes on Linux
Last SVN checkout works perfectly! Now I have only to understand why the GCC builtins are not configured on my system. You say I'm forced to define the environment variable CXXFLAGS to -march=i686 before running ccmake . ? It is not possible to define CMAKE_CXX_FLAGS and CMAKE_C_FLAGS inside Cmake? Thanks! mario Mathias Fröhlich wrote: Hi, On Monday 30 June 2008 15:51, Mario Valle wrote: Hope this helps you. Ciao! Yep this helps, thanks. The fix needs to look somehow different, but I will provide a full submission to Robert ... Greetings Mathais -- Ing. Mario Valle Data Analysis and Visualization Services | 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] The story continues: osgthirdpersonview crashes on Linux
Hi, On Tuesday 01 July 2008 13:14, Mario Valle wrote: Last SVN checkout works perfectly! Good to hear. Now I have only to understand why the GCC builtins are not configured on my system. You say I'm forced to define the environment variable CXXFLAGS to -march=i686 before running ccmake . ? It is not possible to define CMAKE_CXX_FLAGS and CMAKE_C_FLAGS inside Cmake? And don't forget to switch on optimizations of your choice, since this might override the release C*FLAGS settings ... Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Reg: Using Multiple viewers in split screen
Hi, I want to use split screen showing 2-4 screens but I want different viewers. For eg. one is default and the other must follow a node. I tried to read from the tutorials on the site but they seem to be outdated. I didn't get a clear view from the osgcamera example either. Any help is deeply appreciated. Thanks in advance. Neeraj Bagdia IIIT-Hyderabad India ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Composite viewer resize
On Tue, Jul 1, 2008 at 12:23 PM, Robert Osfield [EMAIL PROTECTED]
wrote:
Hi Fabien,
Does osgcomposite resize correctly for you? i.e.
osgcompositeviewer cow.osg
Thanks for your answer Robert.
Yes, the composite viewer does work fine for the aspect ratio. The
projection matrices changes in my example were only here to show that the
resize event wasn't send to the two viewers.
I work on an application with multiple viewers that needs to shows a grid of
objects of a setted number of collums and lines.
I also need to display objects of the same ratio, so I change horizontal and
vertical space between the objects to have the same number of objecst
*and*keep their aspect. Sometimes the viewer with the grid gets the
resize event,
sometimes it's an other one, but never both of them.
Fabien.
I have just tried resizing and it all three views adjust their aspect
ratio correctly. This relies upon the Camera's projection matrices
being resized by the GraphicsContext itself, your own code shouldn't
need to handle the resize, unless of course you actually want to
implement some custom resize. You can control the resize behaviour of
the projection matrix via the Camera::setProjectionResizePolicy(..)
options are:
enum ProjectionResizePolicy
{
FIXED, /** Keep the projection matrix fixed, despite
window resizes.*/
HORIZONTAL, /** Adjust the HORIZOTNAL field of view on
window resizes.*/
VERTICAL /** Adjust the VERTICAL field of view on window
resizes.*/
};
Robert.
On Tue, Jul 1, 2008 at 10:59 AM, fabien rioli
[EMAIL PROTECTED] wrote:
Hi All,
I'm currently having problems with the resize event redistribution with
multiple views (in a composite viewer).
It seems that only one of the viewers receives the resize event.
See the attached example (.cpp) witch illustrate the problem (two viewers
with a resize handler).
In the resise handlers I change the projection matrix in order to show
witch
view gets the event.
The following sreenshots shows different steps of the test.
1.jpg : no event
2.jpg : a first resize event ( the window have been moved)
3.jpg : a second resize event ( resise from the bottom right corner)
From what I have understood from osgViewer/CompositeViewer.cpp (in the
eventTraversal) the viewer witch receives the event is the one who have
the
focus.
I think that because every viewer in the same window is affected by the
resizing, the may have to receive the event each other.
Is this an intended behaviour ?
Thank you in advance,
Fabien
--
Fabien Rioli
www.tharsis-software.com
___
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
--
Fabien Rioli - Directeur Commercial Tharsis-software
Portable: 06 76 96 59 98
Paris innovation 5 rue d'Uzès 75002 Paris Fixe: 01 40 13 53 49
www.tharsis-software.com
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Reg: Using Multiple viewers in split screen
Hi Neeraj, If you want multiple views then the class to use is a single osgViewer::CompositeViewer, this will allow you to set up different views, and set them sharing a single graphics window, or each with it's own window/screen. Robert. On Tue, Jul 1, 2008 at 12:40 PM, Neeraj Bagdia [EMAIL PROTECTED] wrote: Hi, I want to use split screen showing 2-4 screens but I want different viewers. For eg. one is default and the other must follow a node. I tried to read from the tutorials on the site but they seem to be outdated. I didn't get a clear view from the osgcamera example either. Any help is deeply appreciated. Thanks in advance. Neeraj Bagdia IIIT-Hyderabad India ___ 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] Composite viewer resize
Hi Fabian,
osgViewer::CompositeViewer directs events to camera with focus. If
you want different behavior you can always override the
CompositeViewer::eventTravesals() method.
Robert.
On Tue, Jul 1, 2008 at 1:31 PM, fabien rioli
[EMAIL PROTECTED] wrote:
On Tue, Jul 1, 2008 at 12:23 PM, Robert Osfield [EMAIL PROTECTED]
wrote:
Hi Fabien,
Does osgcomposite resize correctly for you? i.e.
osgcompositeviewer cow.osg
Thanks for your answer Robert.
Yes, the composite viewer does work fine for the aspect ratio. The
projection matrices changes in my example were only here to show that the
resize event wasn't send to the two viewers.
I work on an application with multiple viewers that needs to shows a grid of
objects of a setted number of collums and lines.
I also need to display objects of the same ratio, so I change horizontal and
vertical space between the objects to have the same number of objecst and
keep their aspect. Sometimes the viewer with the grid gets the resize event,
sometimes it's an other one, but never both of them.
Fabien.
I have just tried resizing and it all three views adjust their aspect
ratio correctly. This relies upon the Camera's projection matrices
being resized by the GraphicsContext itself, your own code shouldn't
need to handle the resize, unless of course you actually want to
implement some custom resize. You can control the resize behaviour of
the projection matrix via the Camera::setProjectionResizePolicy(..)
options are:
enum ProjectionResizePolicy
{
FIXED, /** Keep the projection matrix fixed, despite
window resizes.*/
HORIZONTAL, /** Adjust the HORIZOTNAL field of view on
window resizes.*/
VERTICAL /** Adjust the VERTICAL field of view on window
resizes.*/
};
Robert.
On Tue, Jul 1, 2008 at 10:59 AM, fabien rioli
[EMAIL PROTECTED] wrote:
Hi All,
I'm currently having problems with the resize event redistribution with
multiple views (in a composite viewer).
It seems that only one of the viewers receives the resize event.
See the attached example (.cpp) witch illustrate the problem (two
viewers
with a resize handler).
In the resise handlers I change the projection matrix in order to show
witch
view gets the event.
The following sreenshots shows different steps of the test.
1.jpg : no event
2.jpg : a first resize event ( the window have been moved)
3.jpg : a second resize event ( resise from the bottom right corner)
From what I have understood from osgViewer/CompositeViewer.cpp (in the
eventTraversal) the viewer witch receives the event is the one who have
the
focus.
I think that because every viewer in the same window is affected by the
resizing, the may have to receive the event each other.
Is this an intended behaviour ?
Thank you in advance,
Fabien
--
Fabien Rioli
www.tharsis-software.com
___
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
--
Fabien Rioli - Directeur Commercial Tharsis-software
Portable: 06 76 96 59 98
Paris innovation 5 rue d'Uzès 75002 Paris Fixe: 01 40 13 53 49
www.tharsis-software.com
___
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] Rendering to multiple graphics cards
On Tue, 01 Jul 2008 00:34:09 +0200, Bob Balfour [EMAIL PROTECTED] wrote: The scene achieves 60Hz at times, but feels choppy, and I notice the middle two GPUs at times show long orange bars, which are killing the 60Hz rate. This is probably obvious for you, but the fancy aero rendering is turned off, right? or 2 double-wide screens (screen 0 2, each set to 2880x900). Note that in the Vista display settings all 4 screens are set up as 1 big extended desktop. How do you configure extended desktop in Vista? I mean, microsoft (or nvidia) has removed the horizontal/vertical span possibility. But if I understand you correctly, there is a possibility to fool vista, so it believes your multiple monitors is only one monitor with a very large resolution? -- Joakim Simonsson ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget updated file for CMake 2.6
On Tue, 2008-07-01 at 00:17 -0400, Jean-Sébastien Guay wrote:
Hello Jeremy,
Hoping to help osgWidget get into OSG 2.6, I did a test build tonight
having freshly updated from SVN. I needed to make some changes to the
CMakeLists.txt file, similar to what needed to be done for OSG and VPB.
I'm attaching the changed file to this message.
Note that the minimum required version at the top of the file is just
what I felt is a safe minimum. It could possibly be a lower version
(like 2.4.5 or whatever) but I think realistically most people have
2.4.7 or higher anyways, and I didn't personally test on an older
version, so I have no way to guarantee that it works.
I have built on Visual Studio 2005 (8.0) SP1. It built fine, and from
what I can see, most of the examples run fine too. Exceptions:
- osgwidgetinput: I don't seem to be able to type any values in the
fields, and clicking the button to create the sphere does nothing.
Yeah, unfortunately I won't be able to do much more with Input Widget
objects until there are some changes made to osgText. As it is, the
example currently doesn't do much of anything.
- osgwidgetscrolled: can't do anything other than resize the box
horizontally, is there something else I should be able to do?
It should resize in all directions, and should change the image display
when you scroll your mouse wheel up and down?
- osgwidgetstyled: what is it supposed to do?
This just demonstrates calling various method on a few Widget objects
using a style string (kind of like CSS).
Note that I didn't build with Python or Lua support, perhaps I need one
of those for the examples above to work properly?
All in all, looking good. :-)
J-S
plain text document attachment (CMakeLists.txt)
cmake_minimum_required(VERSION 2.4.7)
PROJECT(osgWidget)
if(COMMAND cmake_policy)
cmake_policy(SET CMP0003 OLD)
endif(COMMAND cmake_policy)
INCLUDE(FindPkgConfig)
INCLUDE(FindPythonLibs)
PKG_CHECK_MODULES(LUA lua)
SET(SRC_FILES
src/Box.cpp
src/Canvas.cpp
src/Frame.cpp
src/Input.cpp
src/Label.cpp
src/Lua.cpp
src/Python.cpp
src/StyleManager.cpp
src/Table.cpp
src/Util.cpp
src/Version.cpp
src/ViewerEventHandlers.cpp
src/Widget.cpp
src/Window.cpp
src/WindowManager.cpp
)
SET(HEADER_FILES
${osgWidget_SOURCE_DIR}/include/osgWidget/Box
${osgWidget_SOURCE_DIR}/include/osgWidget/Canvas
${osgWidget_SOURCE_DIR}/include/osgWidget/EventInterface
${osgWidget_SOURCE_DIR}/include/osgWidget/Frame
${osgWidget_SOURCE_DIR}/include/osgWidget/Input
${osgWidget_SOURCE_DIR}/include/osgWidget/Label
${osgWidget_SOURCE_DIR}/include/osgWidget/Lua
${osgWidget_SOURCE_DIR}/include/osgWidget/Python
${osgWidget_SOURCE_DIR}/include/osgWidget/ScriptEngine
${osgWidget_SOURCE_DIR}/include/osgWidget/StyleInterface
${osgWidget_SOURCE_DIR}/include/osgWidget/StyleManager
${osgWidget_SOURCE_DIR}/include/osgWidget/Table
${osgWidget_SOURCE_DIR}/include/osgWidget/Types
${osgWidget_SOURCE_DIR}/include/osgWidget/UIObjectParent
${osgWidget_SOURCE_DIR}/include/osgWidget/Util
${osgWidget_SOURCE_DIR}/include/osgWidget/ViewerEventHandlers
${osgWidget_SOURCE_DIR}/include/osgWidget/Widget
${osgWidget_SOURCE_DIR}/include/osgWidget/Window
${osgWidget_SOURCE_DIR}/include/osgWidget/WindowManager
${osgWidget_SOURCE_DIR}/include/osgWidget/Version
)
SET(CMAKE_INCLUDE_PATH /usr/local/include CACHE STRING Put your OSG include
dir here...)
SET(CMAKE_LIBRARY_PATH /usr/local/lib CACHE STRING Put your OSG lib dir
here...)
SET(CMAKE_DEBUG_POSTFIX d)
# Add our Lua cmake variable for turning it off and on.
# NOTE: You must be using Lua 5.1 or greater...
IF(LUA_VERSION STRGREATER 5.0)
SET(OSGWIDGET_USELUA TRUE CACHE BOOL Build with LUA support?)
ELSE(LUA_VERSION STRGREATER 5.0)
SET(OSGWIDGET_USELUA FALSE CACHE BOOL Build with LUA support?)
ENDIF(LUA_VERSION STRGREATER 5.0)
# Add our Python cmake variable for turning it off and on.
IF(PYTHON_LIBRARY)
SET(OSGWIDGET_USEPYTHON TRUE CACHE BOOL Build with Python support?)
ELSE(PYTHON_LIBRARY)
SET(OSGWIDGET_USEPYTHON FALSE CACHE BOOL Build with Python support?)
ENDIF(PYTHON_LIBRARY)
# Stuff that should be in every build...
INCLUDE_DIRECTORIES(include ${CMAKE_INCLUDE_PATH})
LINK_DIRECTORIES(${CMAKE_LIBRARY_PATH})
LINK_LIBRARIES(
debug osgd optimized osg
debug osgUtild optimized osgUtil
debug osgViewerd optimized osgViewer
debug osgTextd optimized osgText
debug osgDBd optimized osgDB
debug osgGAd optimized osgGA
debug OpenThreadsd optimized OpenThreads
)
ADD_LIBRARY(osgWidget SHARED ${SRC_FILES} ${HEADER_FILES})
# Stuff that is just available when LUA is toggled on.
IF(OSGWIDGET_USELUA)
Re: [osg-users] Rendering to multiple graphics cards
Joakim Simonsson wrote: On Tue, 01 Jul 2008 00:34:09 +0200, Bob Balfour [EMAIL PROTECTED] wrote: The scene achieves 60Hz at times, but feels choppy, and I notice the middle two GPUs at times show long orange bars, which are killing the 60Hz rate. This is probably obvious for you, but the fancy aero rendering is turned off, right? I set the theme to windows classic, which I assumed would do away with the aero stuff (with no discernible difference), but is there something else to specifically turn off? or 2 double-wide screens (screen 0 2, each set to 2880x900). Note that in the Vista display settings all 4 screens are set up as 1 big extended desktop. How do you configure extended desktop in Vista? I mean, microsoft (or nvidia) has removed the horizontal/vertical span possibility. But if I understand you correctly, there is a possibility to fool vista, so it believes your multiple monitors is only one monitor with a very large resolution? rt.click desktop-Personalize-Display Settings (Monitor tab) shows 4 monitors that you can select, then check the Extend the desktop onto this monitor box. I can also seem to stop the dwm.exe from executing (Vista desktop window manager) by checking disable desktop composition (rt.click on the .exe-properties(compatibility tab)). With the dwm off I can only get to 47Hz max, but pretty steady. With dwm.exe on (taking about 20% of the CPU) I can get to 60Hz, but not consistently, and my rendered cube rotates with a discernible choppiness. Is Microsoft punishing me for disabling dwm? Bob. -- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Planning for upcoming OpenSceneGraph 2.6 release
Hi Robert, I'll be building them over the next couple days (holiday weekend travel etc). I'll check the new binaries into the osgToy SVN, we can then decide how to integrate into OSG and CMake. I'll let you know when ready. I'm curious if anyone has experience with those new versions, and if anyone has opinions pro/con on moving to them? Also, are there any other packages to be updated that I've missed? thanks -- mew On Mon, Jun 30, 2008 at 12:58 PM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Mike, Updating the Cmake dependencies should be pretty straight forward, I guess the first step is to get these dependencies building, then update the dependency checks. Do you have any idea how long it might take to get things updated? Robert. On Mon, Jun 30, 2008 at 6:49 PM, Mike Weiblen [EMAIL PROTECTED] wrote: wrt planning for OSG 2.6, I notice several of the upstream dependencies have advanced since my last 3rdParty binary build. Specifically: - libpng 1.2.29 - freetype 2.3.7 - curl 7.18.2 - gdal 1.5.2 I suppose it would be good to update those, but my main concern is updating the CMake dependency search to find the new versions. Thoughts? -- mew -- Mike Weiblen -- Austin Texas USA -- http://mew.cx/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] setNestRenderBins questions
Hi all -- I don't recall who submitted this change, but I took it for a short test drive today and here are some observations and questions. The value of setNestRenderBins isn't being saved to the .osg file format. I didn't test .ive. Is this intentional, or an oversight? My first instinct was to setNestRenderBins(false) at my root node to disable nesting for the entire scene graph, expecting the value would inherit down to all StateSets below it. My thinking was that I could then re-enable it further down the scene graph, if desired. This isn't the case; to disable RenderBin nesting, one must setNestRenderBins(false) on the one StateSet for which you want nesting disabled. Is this the desired behavior? It's inconsistent with the inheritance of the bin number and name. Thanks, Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com http://www.skew-matrix.com/ +1 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] Rendering to multiple graphics cards
On Tue, 01 Jul 2008 17:59:59 +0200, Bob Balfour [EMAIL PROTECTED] wrote: Joakim Simonsson wrote: On Tue, 01 Jul 2008 00:34:09 +0200, Bob Balfour [EMAIL PROTECTED] wrote: The scene achieves 60Hz at times, but feels choppy, and I notice the middle two GPUs at times show long orange bars, which are killing the 60Hz rate. This is probably obvious for you, but the fancy aero rendering is turned off, right? I set the theme to windows classic, which I assumed would do away with the aero stuff (with no discernible difference), but is there something else to specifically turn off? No, with turning aero off, I meant to switch to classic. When having aero on, i have discovered that osgviewer reports 60hz, but the real frame rate i clearly bellow 60hz. or 2 double-wide screens (screen 0 2, each set to 2880x900). Note that in the Vista display settings all 4 screens are set up as 1 big extended desktop. How do you configure extended desktop in Vista? I mean, microsoft (or nvidia) has removed the horizontal/vertical span possibility. But if I understand you correctly, there is a possibility to fool vista, so it believes your multiple monitors is only one monitor with a very large resolution? rt.click desktop-Personalize-Display Settings (Monitor tab) shows 4 monitors that you can select, then check the Extend the desktop onto this monitor box. So if you have 4 1024x768 monitors. Can you make Vista believe that you have ONE 2048x1536 or 4096x768 monitor? (as with nvidia's vertical/horizontal span) rotates with a discernible choppiness. Is Microsoft punishing me for disabling dwm? That is strange. -- Joakim Simonsson ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] XPath in osg
Hi everyone, I was wondering if there are any plans on adding some sort of search-querys into osg, XPath for example? Something like: osg::Node* n = Group-SelectSingleNode(//[EMAIL PROTECTED]node1\]); std::vectorosg::Node* nodeList = Group-SelectMultipleNodes(/[EMAIL PROTECTED]somethingelse\); or, just get a node based on their names. osg::Node* n = Group-SelectNode(/Tank/Turret); If any of this has already been addressed i would be happy if someone would point me in the correct direction. For thoose not familiar with XPath, its a way to search thorough XML-nodes. See. http://www.w3schools.com/xpath/xpath_syntax.asp?output=print David Johansson ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] swapBuffers warning when window minimized
All, When an osg application is minimized, osg complains about swapbuffers failing, on every frame. This output can be overwhelming. Can we fix this somehow? Is there some kind of verbosity level? Is that even a word? John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] XPath in osg
Hi David, Instead of including it into the Core OSG, a possible addition should be a XPath visitor class (deriving from NodeVisitor) into osgUtil, which takes the query and traverse the tree to get the results. I think it's a bit intrusive to put such a feature into the core node class, and making a visitor is more in the OSG philosophy. On Tue, Jul 1, 2008 at 6:31 PM, David Johansson [EMAIL PROTECTED] wrote: Hi everyone, I was wondering if there are any plans on adding some sort of search-querys into osg, XPath for example? Something like: osg::Node* n = Group-SelectSingleNode(//[EMAIL PROTECTED]node1\]); std::vectorosg::Node* nodeList = Group-SelectMultipleNodes(/[EMAIL PROTECTED]somethingelse\); or, just get a node based on their names. osg::Node* n = Group-SelectNode(/Tank/Turret); If any of this has already been addressed i would be happy if someone would point me in the correct direction. For thoose not familiar with XPath, its a way to search thorough XML-nodes. See. http://www.w3schools.com/xpath/xpath_syntax.asp?output=print David Johansson ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] StateSet issues with parent\child node
Hi, I must be doing something wrong. I have a function that adds a sphere map and material to a node. When I apply this function to a parent, it also affects the child. How can I make it just affect the parent and not the child? Also, if I call the same function with different settings for the child, it still gets the parent's settings even if I call the function on the child last. In the algorithm I do the following: find the node by name that I want to apply the state to - currNode. make a new group node (gnode) and insert that between the currNode and it's parent. I use this gnode to get or create the state. Then I add my settings to this state. I also give it a unique name. I have also tried just applying the state to the currNode directly and I get the same behavior no matter what. Judie ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] swapBuffers warning when window minimized
Hi John, I have just checked on linux box and it works fine, so I presume it's a windowing specific issue. What windowing setup are you using? If swap buffers is failing then it suggest the best thing that could be done would be to detect the window iconise event and stop the frame loop from executing till the window opens up again. This could possible be something put into osgViewer itself, although there is probably multiple ways one could handle it - for instance keep the frame loop running but stop the rendering dispatch the problem windows. Robert. On Tue, Jul 1, 2008 at 5:36 PM, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: All, When an osg application is minimized, osg complains about swapbuffers failing, on every frame. This output can be overwhelming. Can we fix this somehow? Is there some kind of verbosity level? Is that even a word? John ___ 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] setNestRenderBins questions
Hi Paul, The setNestRenderBins only affects where the bin (if any) associated with the StateSet gets placed in the rendering graph, it doesn't enable or disable what happens for child StateSet. I don't believe it's a feature that you'd want to inherit, its not state like modes and StateAttributes, it's a control associated with RenderBin placement and that is tightly bound to the StateSet. Robert. On Tue, Jul 1, 2008 at 5:19 PM, Paul Martz [EMAIL PROTECTED] wrote: Hi all -- I don't recall who submitted this change, but I took it for a short test drive today and here are some observations and questions. The value of setNestRenderBins isn't being saved to the .osg file format. I didn't test .ive. Is this intentional, or an oversight? My first instinct was to setNestRenderBins(false) at my root node to disable nesting for the entire scene graph, expecting the value would inherit down to all StateSets below it. My thinking was that I could then re-enable it further down the scene graph, if desired. This isn't the case; to disable RenderBin nesting, one must setNestRenderBins(false) on the one StateSet for which you want nesting disabled. Is this the desired behavior? It's inconsistent with the inheritance of the bin number and name. Thanks, Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 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
Re: [osg-users] StateSet issues with parent\child node
Judie, The default behavior is for States/StateSets to be inherited down the scene graph, from parent to child. However, in the default configuration, setting the StateSet of the child directly should cause that child (and any children that it itself has) to use the new StateSet parameters. This inheritance method is controlled by the OverrideValue flag, which can be set when attributes and modes are enabled or disabled on a StateSet. It sounds like what you're doing should work (set the state on the parent, then reset the state on the child), but I don't understand why you're creating and adding another group node in between the parent and child, as this is completely unnecessary to manipulate state changes. All you need to do is to query the StateSet from the parent (using getOrCreateStateSet() ) and make any appropriate changes. Then get the StateSet from the child, and remove/reverse any changes (e.g., disable materials, or apply 'empty' Programs in the case of shaders). Alternatively, you could set the child's OverrideValue to PROTECTED in order to prevent the parent's state values from being inherited. -- Matthew W. Fuesz Software Engineer Asc. Lockheed Martin STS 1210 Massillon Road Akron, OH 44315 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Judie Sent: Tuesday, July 01, 2008 1:57 PM To: osg-users@lists.openscenegraph.org Subject: [osg-users] StateSet issues with parent\child node Hi, I must be doing something wrong. I have a function that adds a sphere map and material to a node. When I apply this function to a parent, it also affects the child. How can I make it just affect the parent and not the child? Also, if I call the same function with different settings for the child, it still gets the parent's settings even if I call the function on the child last. In the algorithm I do the following: find the node by name that I want to apply the state to - currNode. make a new group node (gnode) and insert that between the currNode and it's parent. I use this gnode to get or create the state. Then I add my settings to this state. I also give it a unique name. I have also tried just applying the state to the currNode directly and I get the same behavior no matter what. Judie ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] AutoTransform scale implementation
I'd like to know more about the AutoTransform auto-scale implementation. We want something similar, but we think we need to account for non-uniform scaling. Could I get a description of CullingSet::computePixelSizeVector()? I see it was written in 2002, but I'd appreciate any help in understanding it. I see that it uses the projection matrix. It seems to get the same scaling for objects at different depths, so I think it takes perspective into account. On the other hand, the projection matrix is changed after the cull (after calculating near and far), so it won't be the same as used in AutoTransform to get this scale. Any info on what this does would be appreciated. Thanks, andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Testing of OSG and VPB SVN in prep for 2.5.3devreleasese
Robert Osfield wrote: Hi Jason, Mathias has submitted some changed to the cmake Atomic checks/setup, I have now checked these into SVN. Could you do an svn update and clean build, then let us know if it compiles OK now. Hi, Robert, Just updated. Now, if I don't do anything to the environment, it settles on USE_MUTEX. This is an improvement (it previously didn't pick any method). I still have to set CXXFLAGS=-march=i686 in the environment for it to pick USE_GCC_BUILTINS. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] VPB/osgdem and transparent textures
Hello, I'm using OSG 2.4 and VPB 0.9.8 and I'm having an issue. I'm handing osgdem raster texture files with transparency but the resulting terrain models seem to ignore the alpha channels entirely. Also, I thought VPB alpha'd out NODATA regions. For some reason, it seems to be coloring them solid black instead, for me. Does VPB support having transparency in the texture imagery? I've tried various PNG and GeoTIFF images and seem to come upon the same result. I've tried the various --RGBA and --default-color command line options to no avail. Am I missing something? Thanks ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Testing of OSG and VPB SVN in prep for 2.5.3devreleasese
Hi Jason, On Tue, Jul 1, 2008 at 7:57 PM, Jason Daly [EMAIL PROTECTED] wrote: Just updated. Now, if I don't do anything to the environment, it settles on USE_MUTEX. This is an improvement (it previously didn't pick any method). Good to hear, thanks for the testing. I still have to set CXXFLAGS=-march=i686 in the environment for it to pick USE_GCC_BUILTINS. I'm afraid I don't know of any alternative to this for getting CMake to trigger a build for a different architecture. Perhaps those more expert in CMake might have something to suggest, until then perhaps this is somthing to add to CMake wiki files on openscenegraph.org. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VPB/osgdem and transparent textures
Hi Mike, What makes you think that the alpha is being ignored? Have you enabled GL_BLEND in your app? Robert. On Tue, Jul 1, 2008 at 8:39 PM, Mike Lewis [EMAIL PROTECTED] wrote: Hello, I'm using OSG 2.4 and VPB 0.9.8 and I'm having an issue. I'm handing osgdem raster texture files with transparency but the resulting terrain models seem to ignore the alpha channels entirely. Also, I thought VPB alpha'd out NODATA regions. For some reason, it seems to be coloring them solid black instead, for me. Does VPB support having transparency in the texture imagery? I've tried various PNG and GeoTIFF images and seem to come upon the same result. I've tried the various --RGBA and --default-color command line options to no avail. Am I missing something? Thanks ___ 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] multiple models, single texture
It looks like SharedStateManager is appropriate for what I'm doing,
but it doesn't seem to be quite as flexible as I'd like. With the
wide variety of modelers, exporters, and loaders, I can't always be
assured that the DataVariance on StateSets and Textures will be
static. This is currently a requirement for sharing, though.
The current share modes are
enum ShareMode
{
SHARE_NONE = 0x00,
SHARE_TEXTURES = 0x01,
SHARE_STATESETS = 0x02,
SHARE_ALL = SHARE_TEXTURES |
SHARE_STATESETS
};
Would it be too weird to append these modes like so?
enum ShareMode
{
SHARE_NONE = 0x00,
SHARE_TEXTURES = 0x01,
SHARE_STATESETS = 0x02,
SHARE_ALL = SHARE_TEXTURES |
SHARE_STATESETS,
SHARE_TEXTURES_DYNAMIC = 0x04,
SHARE_TEXTURES_UNSPECIFIED = 0x08,
SHARE_STATESETS_DYNAMIC = 0x10,
SHARE_STATESETS_UNSPECIFIED = 0x20
};
I've already tried it with textures and it helps out a lot when you
can't easily control what's in your model files; I can submit it if
this looks good.
The only problem I see is that SHARE_ALL no longer makes much sense,
but changing it would break backward compatibility. And it would look
weird to have SHARE_ALL_NO_REALLY_SHARE_ALL.
- Terry
Message: 11
Date: Fri, 27 Jun 2008 09:32:15 +0100
From: Robert Osfield [EMAIL PROTECTED]
Subject: Re: [osg-users] multiple models, single texture
To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
Message-ID:
[EMAIL PROTECTED]
Content-Type: text/plain; charset=ISO-8859-1
Hi Terry,
On Fri, Jun 27, 2008 at 5:01 AM, Terry Welsh [EMAIL PROTECTED] wrote:
Is it possible to load multiple model files that use the same texture
but only have the texture get loaded once? It seems like a good way
to save memory and reduce state changes.
The loaders don't cache images and textures, but it is possible to
combine duplicate state once the data is loaded. The
osgUtil::Optimize::RemoveDuplicateState can be used on a whole scene
graph, and the osgDB::SharedStateManager can be used when you are
incrementally loading subgraphs.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] multiple models, single texture
And it would look weird to have SHARE_ALL_NO_REALLY_SHARE_ALL. SHARE_ALL_NO_REALLY_EVEN_IF_YOU_THINK_YOU_SHOULDNT_I_MEAN_IT_JUST_SHARE_THE_WHOLE_DAMN_THING_WILL_YOU_JUST_DO_WHAT_I_SAY_OH_AND_FORGET_IT_THIS_IS_EVEN_WORSE_THAN_USING_MS_WORD :-) 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] setNestRenderBins questions
If it only applies to a single render bin, then perhaps the name should not be plural, which implies (to me, at least), that this setting affects more than one bin. The code comment also implies this: to prevent render bins being nested, call setNestRenderBins(false) perhaps should instead read as follows: to prevent a render bin from being nested, call setNestRenderBin(false). And, I'll repeat my question regarding .osg/.ive support for this feature. If I disable render bin nesting, save to a .osg file, then display with osgviewer, the nesting is no longer enabled... -Paul Hi Paul, The setNestRenderBins only affects where the bin (if any) associated with the StateSet gets placed in the rendering graph, it doesn't enable or disable what happens for child StateSet. I don't believe it's a feature that you'd want to inherit, its not state like modes and StateAttributes, it's a control associated with RenderBin placement and that is tightly bound to the StateSet. Robert. On Tue, Jul 1, 2008 at 5:19 PM, Paul Martz [EMAIL PROTECTED] wrote: Hi all -- I don't recall who submitted this change, but I took it for a short test drive today and here are some observations and questions. The value of setNestRenderBins isn't being saved to the .osg file format. I didn't test .ive. Is this intentional, or an oversight? My first instinct was to setNestRenderBins(false) at my root node to disable nesting for the entire scene graph, expecting the value would inherit down to all StateSets below it. My thinking was that I could then re-enable it further down the scene graph, if desired. This isn't the case; to disable RenderBin nesting, one must setNestRenderBins(false) on the one StateSet for which you want nesting disabled. Is this the desired behavior? It's inconsistent with the inheritance of the bin number and name. Thanks, Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 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-opensce negraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] multiple models, single texture
Hi Terry,
I haven't used SharedStateManager personally (it was developed by a
member of the community), so am not in a strong position to dive in a
guide proceedings.
You suggest about breaking the enum out into
DYANMIC/STATIC/UNSPECIFIED variants looks like something that might be
required. Or perhaps this could be placed in a separate options. In
general I'd suggest that STATIC and UNSPECIFIED are ones that you
could merge by default but not DYNAMIC state. So SHARE_TEXTURES
would be equal to SHARE_STAITC_TEXTURES | SHARE_UNSPECIFIED_TEXTURES,
and the same for SHARE_STATESET.
Robert.
On Tue, Jul 1, 2008 at 9:12 PM, Terry Welsh [EMAIL PROTECTED] wrote:
It looks like SharedStateManager is appropriate for what I'm doing,
but it doesn't seem to be quite as flexible as I'd like. With the
wide variety of modelers, exporters, and loaders, I can't always be
assured that the DataVariance on StateSets and Textures will be
static. This is currently a requirement for sharing, though.
The current share modes are
enum ShareMode
{
SHARE_NONE = 0x00,
SHARE_TEXTURES = 0x01,
SHARE_STATESETS = 0x02,
SHARE_ALL = SHARE_TEXTURES |
SHARE_STATESETS
};
Would it be too weird to append these modes like so?
enum ShareMode
{
SHARE_NONE = 0x00,
SHARE_TEXTURES = 0x01,
SHARE_STATESETS = 0x02,
SHARE_ALL = SHARE_TEXTURES |
SHARE_STATESETS,
SHARE_TEXTURES_DYNAMIC = 0x04,
SHARE_TEXTURES_UNSPECIFIED = 0x08,
SHARE_STATESETS_DYNAMIC = 0x10,
SHARE_STATESETS_UNSPECIFIED = 0x20
};
I've already tried it with textures and it helps out a lot when you
can't easily control what's in your model files; I can submit it if
this looks good.
The only problem I see is that SHARE_ALL no longer makes much sense,
but changing it would break backward compatibility. And it would look
weird to have SHARE_ALL_NO_REALLY_SHARE_ALL.
- Terry
Message: 11
Date: Fri, 27 Jun 2008 09:32:15 +0100
From: Robert Osfield [EMAIL PROTECTED]
Subject: Re: [osg-users] multiple models, single texture
To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
Message-ID:
[EMAIL PROTECTED]
Content-Type: text/plain; charset=ISO-8859-1
Hi Terry,
On Fri, Jun 27, 2008 at 5:01 AM, Terry Welsh [EMAIL PROTECTED] wrote:
Is it possible to load multiple model files that use the same texture
but only have the texture get loaded once? It seems like a good way
to save memory and reduce state changes.
The loaders don't cache images and textures, but it is possible to
combine duplicate state once the data is loaded. The
osgUtil::Optimize::RemoveDuplicateState can be used on a whole scene
graph, and the osgDB::SharedStateManager can be used when you are
incrementally loading subgraphs.
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] setNestRenderBins questions
Hi Paul, On Tue, Jul 1, 2008 at 9:34 PM, Paul Martz [EMAIL PROTECTED] wrote: If it only applies to a single render bin, then perhaps the name should not be plural, which implies (to me, at least), that this setting affects more than one bin. The code comment also implies this: to prevent render bins being nested, call setNestRenderBins(false) perhaps should instead read as follows: to prevent a render bin from being nested, call setNestRenderBin(false). Yes the plaural is misleading here, removing the s would seem more apprioate. It looks like I missed the s when I reviewed it... here's the log: svn log StateSet r8455 | robert | 2008-06-19 12:09:20 +0100 (Thu, 19 Jun 2008) | 4 lines From Michael Platings and Robert Osfield, added support for controlling, via StateSet::setNestedRenderBin(bool) whether the new RenderBin should be nested with the existing RenderBin, or be nested with the enclosing RenderStage. And, I'll repeat my question regarding .osg/.ive support for this feature. If I disable render bin nesting, save to a .osg file, then display with osgviewer, the nesting is no longer enabled... This support is missing, I'm afraid it didn't come along with the original submission and I've been swept away with work so haven't had the time to fill in all the missing gaps. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Performance hit caused by porting from VS 7.1 to VS 9
Hello All, We have succesfully ported from OSG 1.2 to the newest SVN version (well, almost newest, I think we are on 8512 at the moment). Thanks again for all the fantastic forum support. We have been using VS 7.1 for all of our work so far, but since we were missing a well build freetype library, I figured it was time to make the jump there as well. I downloaded VS 9 express and ran CMake to build OSG. All built just fine. The converter in VS 9 converted all of the projects without fuss, and I was able to get it all compiling and running pretty easily. Unfortunately, I am seeing this 30% drop in framerate :(. I was seeing about 28-30 fps (yes, I know, I have some scene optimizing to do) with the VS 7.1 build, which dropped to 20-21 fps using VS 9 express. Has anyone seen anything like that before? Am I missing some setting somewhere? Perhaps the converter in VS 9 does not like me? Any ideas? -- Thanks Rick Check us out at http://fringe-online.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Performance hit caused by porting from VS 7.1 to VS 9
Do you get the same behavior if you generate fresh VS9 project files with cmake, instead of generating VS7.1 files and converting them? I'm not sure this will have any effect, but it seems like it might be worth a shot... -Paul _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Pingry Sent: Tuesday, July 01, 2008 3:14 PM To: OpenSceneGraph Users Subject: [osg-users] Performance hit caused by porting from VS 7.1 to VS 9 Hello All, We have succesfully ported from OSG 1.2 to the newest SVN version (well, almost newest, I think we are on 8512 at the moment). Thanks again for all the fantastic forum support. We have been using VS 7.1 for all of our work so far, but since we were missing a well build freetype library, I figured it was time to make the jump there as well. I downloaded VS 9 express and ran CMake to build OSG. All built just fine. The converter in VS 9 converted all of the projects without fuss, and I was able to get it all compiling and running pretty easily. Unfortunately, I am seeing this 30% drop in framerate :(. I was seeing about 28-30 fps (yes, I know, I have some scene optimizing to do) with the VS 7.1 build, which dropped to 20-21 fps using VS 9 express. Has anyone seen anything like that before? Am I missing some setting somewhere? Perhaps the converter in VS 9 does not like me? Any ideas? -- Thanks Rick Check us out at http://fringe-online.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Performance hit caused by porting from VS 7.1 to VS 9
Yes, the only ones I converted were my own projects. I used a fresh CMake configuration with everything OSG. It might be that only my own projects are slower. -- Rick On Tue, Jul 1, 2008 at 5:45 PM, Paul Martz [EMAIL PROTECTED] wrote: Do you get the same behavior if you generate fresh VS9 project files with cmake, instead of generating VS7.1 files and converting them? I'm not sure this will have any effect, but it seems like it might be worth a shot... -Paul -- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Rick Pingry *Sent:* Tuesday, July 01, 2008 3:14 PM *To:* OpenSceneGraph Users *Subject:* [osg-users] Performance hit caused by porting from VS 7.1 to VS 9 Hello All, We have succesfully ported from OSG 1.2 to the newest SVN version (well, almost newest, I think we are on 8512 at the moment). Thanks again for all the fantastic forum support. We have been using VS 7.1 for all of our work so far, but since we were missing a well build freetype library, I figured it was time to make the jump there as well. I downloaded VS 9 express and ran CMake to build OSG. All built just fine. The converter in VS 9 converted all of the projects without fuss, and I was able to get it all compiling and running pretty easily. Unfortunately, I am seeing this 30% drop in framerate :(. I was seeing about 28-30 fps (yes, I know, I have some scene optimizing to do) with the VS 7.1 build, which dropped to 20-21 fps using VS 9 express. Has anyone seen anything like that before? Am I missing some setting somewhere? Perhaps the converter in VS 9 does not like me? Any ideas? -- Thanks Rick Check us out at http://fringe-online.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Rick Check us out at http://fringe-online.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] StateSet issues with parent\child node
On Jul 1, 11:27 am, Fuesz, Matthew [EMAIL PROTECTED] wrote: Judie, The default behavior is for States/StateSets to be inherited down the scene graph, from parent to child. However, in the default configuration, setting the StateSet of the child directly should cause that child (and any children that it itself has) to use the new StateSet parameters. This inheritance method is controlled by the OverrideValue flag, which can be set when attributes and modes are enabled or disabled on a StateSet. It sounds like what you're doing should work (set the state on the parent, then reset the state on the child), but I don't understand why you're creating and adding another group node in between the parent and child, as this is completely unnecessary to manipulate state changes. OK, I thought someone had told me this needed to be done but that was a while ago. It works as you say. All you need to do is to query the StateSet from the parent (using getOrCreateStateSet() ) and make any appropriate changes. Then get the StateSet from the child, and remove/reverse any changes (e.g., disable materials, or apply 'empty' Programs in the case of shaders). Alternatively, you could set the child's OverrideValue to PROTECTED in order to prevent the parent's state values from being inherited. This did the trick! Thanks, Judie ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] mouse/viewport issues with CompositeViewer
I am wondering about the status of this bug/fix (below) that I originally saw discussed back in late Feb. by Paul M., Jean-Sebastien and Robert, and again in late May, with no firm resolution. I am using OSG 2.4 and appear to be experiencing this same problem using CompositeViewer and slave cameras. Is the only current option to drop down to osgViewer::Viewer, or will doing a current SVN checkout resolve it? -(from J-S G., 28feb08) Look closely - the scene moves, just *very very* little. It's a bug in osgViewer/CompositeViewer.cpp which I submitted a fix for about a week ago. When a single view is on multiple displays (so the slave camera mechanism in osgViewer::View is used) the viewport extents are not set correctly in the eventTraversal, so when the mouse events are translated they have wrong values and the mouse movement has very little effect. -- Bob. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] GL_LINE and GL_POINT question
Hello, how do i set the GL_POINT_SIZE and equivalent GL_LINE_SIZE ? Thanks in advance ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GL_LINE and GL_POINT question
http://www.opengl.org/sdk/docs/man/xhtml/glLineWidth.xml On Tue, Jul 1, 2008 at 4:51 PM, Hugo Gomes [EMAIL PROTECTED] wrote: Hello, how do i set the GL_POINT_SIZE and equivalent GL_LINE_SIZE ? 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
Re: [osg-users] GL_LINE and GL_POINT question
Aren't they wrapped by osg ? ... Can't i specify that info in a stateset ? On Wed, Jul 2, 2008 at 1:36 AM, Willy P [EMAIL PROTECTED] wrote: http://www.opengl.org/sdk/docs/man/xhtml/glLineWidth.xml On Tue, Jul 1, 2008 at 4:51 PM, Hugo Gomes [EMAIL PROTECTED] wrote: Hello, how do i set the GL_POINT_SIZE and equivalent GL_LINE_SIZE ? 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] error in tutorial Loading Models from Files...
Hi, in tutorial Loading Models from Files and Positioning Them in a Scene there is : osgViewer::Viewer viewer; viewer.addCameraManipulator(new osgGA::TrackballManipulator); compiler errors ; error C2039: 'addCameraManipulator' : is not a member of 'osgViewer::Viewer' and error C2039: 'TrackballManipulator' : n'est pas membre de 'osgGA' is there up to date tutorials ? thanks. _ Envoyez avec Yahoo! Mail. Une boite mail plus intelligente http://mail.yahoo.fr___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GL_LINE and GL_POINT question
Yes... and in general when looking for something OpenGL-ish in OSG one need only glance through the header names. I've never used them but the state attributes: Point and LineWidth look to be what you are looking for: http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/include/osg/Point http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/include/osg/LineWidth Just an educated guess. -Paul Hugo Gomes wrote: Aren't they wrapped by osg ? ... Can't i specify that info in a stateset ? On Wed, Jul 2, 2008 at 1:36 AM, Willy P [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: http://www.opengl.org/sdk/docs/man/xhtml/glLineWidth.xml On Tue, Jul 1, 2008 at 4:51 PM, Hugo Gomes [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hello, how do i set the GL_POINT_SIZE and equivalent GL_LINE_SIZE ? Thanks in advance ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] error in tutorial Loading Models from Files...
Hi Zamo, you can try this article if you like: http://osghelp.com/readarticle.php?article_id=6 it's a simplified version how to load models. and this article is a simplified version how to transform your models: http://osghelp.com/readarticle.php?article_id=7 hope this helps, Peter On Wed, Jul 2, 2008 at 3:04 AM, Zamo Cédrik [EMAIL PROTECTED] wrote: Hi, in tutorial Loading Models from Files and Positioning Them in a Scene there is : osgViewer::Viewer viewer; viewer.addCameraManipulator(new osgGA::TrackballManipulator); compiler errors ; error C2039: 'addCameraManipulator' : is not a member of 'osgViewer::Viewer' and error C2039: 'TrackballManipulator' : n'est pas membre de 'osgGA' is there up to date tutorials ? thanks. -- Envoyé avec Yahoo! Mailhttp://us.rd.yahoo.com/mailuk/taglines/isp/control/*http://us.rd.yahoo.com/evt=52423/*http://fr.docs.yahoo.com/mail/overview/index.html . Une boite mail plus intelligente. ___ 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
