[osg-users] osg::Image::copySubImage
Hi. Tell me please why void osg::Image::copySubImage(int s_offset,int t_offset,int r_offset,osg::Image* source); has non-const parameter source? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Getting Started with OpenSceneGraph on Ubuntu
Hi, To install osg, type: sudo apt-get install libopenscenegraph-dev openscenegraph You can use the IDE that you prefer, you'd better try all you can and get the one that is more suited to you. As for the behaviour, there isn't any big differences from MSVC: just make a project and specify the OSG libraries you want to use (osg, osgViewer and so on...) You have OSG's API reference at: http://www.openscenegraph.org/documentation/OpenSceneGraphReferenceDocs/namespaces.html You should also read the examples provided by OSG to learn how to use it. They are located at /usr/share/openscenegraph/examples/. HTH, Alberto El Miércoles 04 Febrero 2009ES 07:41:23 Trịnh Thành Trung GMail escribió: Hi, I am just new in Linux, and I don't know where to start. Currently I am using Ubuntu 8.10, and install osg through Synaptic package manager, and using Code::Block as a C++ IDE. Writing program in Linux is so different with in Windows, and stilll I can't have the osg HelloWorld runable. I have googled for a while but no hope. Can somebody help me with this newbie stuff, please. You may provide me how to install osg, or what IDE I should use, and how I will configure that, with detail step by step. You may give me some useful links, any help is muck appreciate. I am completely lost. Thanks in advance ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osg::notify replaceable backend?
Hi all,
I have a non console based application that has it's own reporting
mechanism built-in. I'd like to be able to set the NotifyLevel and
have these messages sent to my logger tool. My logger tool also has
it's own filters/log-levels, so I'd like to be able to map the
osg::NotifySeverity to some matching log-level.
I've figured out a way to reoute all osg::notify messages to my
logger, but I can't seem to find a way to get the osg::NotifySeverity
mapping. Any thoughts on how this could be done is greatly
appretiated.
What I have done to just flush all osg::notify messages to my logger is:
void main()
{
MyLoggWrapper log;
std::streambuf* notifyBuf = osg::notify().rdbuf();
osg::notify().rdbuf(log.rdbuf());
osg::notify(osg::INFO) This message is passed straight to my
logger, sadly without knowlede of NotifySeverity std::endl;
snip
//osgViewer instantiation and main loop etc.
/snip
osg::notify().rdbuf(notifyBuf);
}
Filip Holm
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi All, On Tue, Feb 3, 2009 at 9:32 PM, Sukender suky0...@free.fr wrote: My mistake, I meant that the volatile and should be removed (not the whole static_cast). May static_castunsigned int do it? (since I'm not certain volatile here is useful, because we simply return a copy). I've just got confirmation from Mathias that removing the cast should be OK, so I've gone ahead and committed this change. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSGEarth precision
Hi David, I haven't dived into the source code of osgEarth, but I do know that it utilises osgTerrain, and osgTerrain internally uses double to locate tiles in their geocentric position (the class that does this is the osgTerrain::Locator). When the geometry for rendering is generated on demand it's created with a local origin and then decorated with a MatrixTransform that places the tile into it's final position. Since the OSG defaults to use double Matrix for MatrixTransform and doubles for all osg::Camera management, and the cull traversal accumulates the camera + transforms in the scene using doubles, it's possible to position the tiles very accurately and maintain precision for as long as possible before passing to OpenGL. When you are close to a tile, such as driving along it the relative translations of the camera and the tile's MatrixTransform largely cancel out with little numerical errors thank's to the use of doubles, so you get the best precision where you need it most, while far away tiles have larger translations left in them so the error is higher, but this is not an issue as vertices and divide by their distance during the transformation from object to clip space so the errors seen on screen remain subpixel so you don't see them. Thanks to this system it's possible to use pre-built VirtualPlanetBuilder or dynamically generated osgEarth databases in geocentric coords without complex additional coding, it just works out of the box. Whether you'd want to use a dynamically generated database from remote data for a simulator is a different matter, one would have to look closely at the latency and consistency of download and generating tiles. Robert. On Wed, Feb 4, 2009 at 7:10 AM, David Karlsson david.karls...@foi.se wrote: Hi, Is OSGEarth suitable to use, as a part of a terrain simulator, together with objects that needs to be positioned with about cm precision - or will I run into problems with precision? I found this page about how they handled it in NASA's World Wind: http://www.urbanrobots.com/Blogs/WW/2006/01/working-to-solution-in-precision.html How is this handled in OSGEarth? Thanks, David ___ 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] Getting Started with OpenSceneGraph on Ubuntu
Thank you very much, I was able to compile the simple osg tutorial. I have googled everywhere but none pointed me to that libopenscenegraph-dev openscenegraph. :D -- TnTonly Corporation === Home: http://www.tntonly.co.cc Mail: http://mail.tntonly.co.cc Forum: http://www.tntonly.co.cc/forum Blog: http://www.tntonly.co.cc/blog OS: http://www.tntonly.co.cc/os (Limited Service) === ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSX issue with the osgviewer class
Hello guys,
I finally get to my other windows laptop and run the testcase on that system
too.
Both compiled in release, using osg as a shared lib; the results:
WIN32:
*** test using GLUT ***
cpu time: 1641 milliseconds
effective time: 1.64645 seconds
average fps: 607.367
*** test using osgviewer class only ***
cpu time: 1656 milliseconds
effective time: 1.66006 seconds
average fps: 602.389
OSX:
*** test using GLUT ***
cpu time: 391.799 milliseconds
effective time: 2.70822 seconds
average fps: 369.246
*** test using osgviewer class only ***
cpu time: 943.835 milliseconds
effective time: 16.8232 seconds
average fps: 59.4417
beside the performance difference (I guess because of the integrated intel
graphics on my macbook), what I feel strange is that on win32 the osgviewer
class is not bound to the 60Hz refresh rate, and the performances are
consistent in GLUT/nonGLUT mode (607 vs 602 fps), while in OSX there is a
huge difference between the two (369 vs 60 fps).
Maybe this is already known, or it's simply a matter of better setting up
the application.
If the testcase is needed I can attach it (is it possible to this mailing
list?) or paste the source code the the email, it's a single file. Or you
can reproduce it using the standard osgviewer application distributed with
osg.
The calls I'm doing to create the viewer are basically:
osgViewer::Viewer* viewer = new osgViewer::Viewer();
viewer-setSceneData( myscenenode*** );
viewer-setCameraManipulator(new osgGA::TrackballManipulator);
viewer-addEventHandler(new osgViewer::StatsHandler);
viewer-realize();
while (true)
{
// update the viewer
viewer-frame();
(...)
}
thanks again!
Davide
Robert,
I set up a simple test, with only a rotating cube displayed with:
1) osgviewer using GLUT
2) osgviewer standalone class
in both I used double-buffered 800x600 window.
I only tested on my mac yet, but tomorrow I will test on windows too.
The results are:
** standalone **
cpu time: 1001.35 milliseconds
effective time: 16.796 seconds
average fps: 59.538
** using glut **
cpu time: 458.949 milliseconds
effective time: 2.71029 seconds
average fps: 368.964
I think that you were right and I was misinterpreting the results: it is
evident that the standalone osgviewer version is fixed on 60Hz, which is my
laptop display refresh rate.
The glut version seems not to be bound to the display refresh but the
doublebuffering is enabled...
Probably there is something I still ignore just under the hood, on how the
refresh is handled.
The same difference appears with the standard osgviewer and
osgviewerGLUT applications built with cmake (in both 2.4.0 and 2.6.0)
Tomorrow I will try on windows, with the same code. For what I observed, I
expect to have a fps higher to 60Hz there, I will let you know.
Just in case, is it possible to attach the testcase to a message directed
to
the mailing list?
thanks!
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Getting Started with OpenSceneGraph on Ubuntu
Hi Trinh? (Could sign with the name you wish to be addressed as please, to prevent others form making mistakes ;-) I develop under Kubuntu 8.10, and don't personally use an IDE, I used to, but... this was back in last century! These days I just open up a win-term and use nedit for editing, and an occasionally use gdb for examining stack traces when looking at crashes. What I have found is this combination suits the way I work, and makes me most productive. Prior to going without IDE's I used to use Visual Studio and the SGI Case Vision tools. I say this to present one extreme - it's possible to me perfectly productive without IDE's, others of course prefer by IDE's and couldn't imagine being productive without them. In your case you are stuck learning a new operating system, a new scene graph library, and new compiler set, a new packaging system and a new IDE, so perhaps looking at learning a couple of these at time, rather all at once. Personally I'd recommend getting used to a winterm for navigating around the OpenSceneGraph directory structure, learn how to use agp-get (it's the packaging tool that is underneath Synatic), and learn how to use a simple editor to look at file, learn a few unix commands like cd, ls, make, grep. There are lots of tutorials on these on the web. It will seem like a huge learning curve at the start, but within a day or two you'll be much more comfortable, then a few weeks you might well grow to love the what you can do with a modern unix style operating system. For me the most magical thing about Ubuntu/Kubuntu is the debian based repositories that apt-get/Synatic make easily accessible to you. No more running off onto the web for 3rd party dependencies, spending days trying to configure, build and install them. A single agp-get line can get your everything you need. This makes it possible to install the Ubuntu/Kubuntu on a compeletely new machine and pull down everything you need for development, cmake, gcc, subversion, OpenGL, all the dependencies required for the OSG and get building within minutes of getting the OS installed. Below is the an extract of a script file that I use as a template for getting the OSG installed and built from source on a fresh machine. It's written long winded to enable me to add the commentary about what is being installed to do what. You can put all the packages on to a single apt-get line. The only line you might need to vary is nvidia packages - as these only apply to Nvidia cards with the proprietary drivers. Robert. -- # compile, build and version control sudo apt-get install cmake subversion g++ # OpenGL/X11 sudo apt-get install libx11-dev sudo apt-get install nvidia-glx-177-dev libglu-dev # image libs sudo apt-get install libpng-dev libjpeg-dev libtiff-dev # get true type font support sudo apt-get install libfreetype6-dev # geospatial imaging sudo apt-get install libgdal-dev # video sudo apt-get install libxine-dev # dicom loader sudo apt-get install dcmtk libdcmtk1-dev # gecko plugin sudo apt-get install libgtk2.0-dev sudo apt-get install libxul-dev # pdf plugin sudo apt-get install libpoppler-glib-dev # vnc plugin sudo apt-get install libvncserver-dev # svg plugin sudo apt-get install librsvg2-dev # check out OSG svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk OpenSceneGraph # compile the OSG cd OpenSceneGraph ./configure make -j 8 Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::notify replaceable backend?
Hi Filip,
From include/osg/Notify you have the getNotifyLevel() function...
/** Range of notify levels from DEBUG_FP through to FATAL, ALWAYS
* is reserved for forcing the absorption of all messages. The
* keywords are also used verbatim when specified by the environmental
* variable OSGNOTIFYLEVEL. See documentation on osg::notify() for
* further details.
*/
enum NotifySeverity {
ALWAYS=0,
FATAL=1,
WARN=2,
NOTICE=3,
INFO=4,
DEBUG_INFO=5,
DEBUG_FP=6
};
/** set the notify level, overriding the default or the value set by
* the environmental variable OSGNOTIFYLEVEL.
*/
extern OSG_EXPORT void setNotifyLevel(NotifySeverity severity);
/** get the notify level. */
extern OSG_EXPORT NotifySeverity getNotifyLevel();
/** is notification enabled, given the current setNotifyLevel() setting? */
extern OSG_EXPORT bool isNotifyEnabled(NotifySeverity severity);
On Wed, Feb 4, 2009 at 8:46 AM, Filip Holm filip.h...@gmail.com wrote:
Hi all,
I have a non console based application that has it's own reporting
mechanism built-in. I'd like to be able to set the NotifyLevel and
have these messages sent to my logger tool. My logger tool also has
it's own filters/log-levels, so I'd like to be able to map the
osg::NotifySeverity to some matching log-level.
I've figured out a way to reoute all osg::notify messages to my
logger, but I can't seem to find a way to get the osg::NotifySeverity
mapping. Any thoughts on how this could be done is greatly
appretiated.
What I have done to just flush all osg::notify messages to my logger is:
void main()
{
MyLoggWrapper log;
std::streambuf* notifyBuf = osg::notify().rdbuf();
osg::notify().rdbuf(log.rdbuf());
osg::notify(osg::INFO) This message is passed straight to my
logger, sadly without knowlede of NotifySeverity std::endl;
snip
//osgViewer instantiation and main loop etc.
/snip
osg::notify().rdbuf(notifyBuf);
}
Filip Holm
___
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] OSX issue with the osgviewer class
Hi Davide,
The osgViewer will attempt by default to enable vysnc, but.. OpenGL
drivers can override this. Go have a look at you OpenGL driver
settings for vysnc.
BTW, it's perfectly ordinary and correct to expect a difference
between vsync on/off. For graphics development often you'll switch
vsync off to get a feel for performance scaling, but for delivery of
the application you almost always should enable vysnc as visual
quality is far higher, and the compute system is more well balanced,
and in terms of user interaction a frame rate higher than vsync is
absolutely no use whatsoever.
For my own work I almost always have vysnc on, only occasionally when
I want to do some particular type of benchmarking do I disable vsync.
When you have vsync on it's still possible to look at performance, for
instance have a look at the on screen stats that the OSG provides -
just run osgviewer on few different models and press 's' a couple of
times to see the different types of stats available.
You need to get over this present hurdle of understanding what is
actually going on, once you have you'll know exactly why you are
getting the results you are, and why there isn't anything at all to
worry about, and finally you start looking at the real metrics that
mean something.
Robert.
On Wed, Feb 4, 2009 at 9:35 AM, Davide Bacchet davide.bacc...@gmail.com wrote:
Hello guys,
I finally get to my other windows laptop and run the testcase on that system
too.
Both compiled in release, using osg as a shared lib; the results:
WIN32:
*** test using GLUT ***
cpu time: 1641 milliseconds
effective time: 1.64645 seconds
average fps: 607.367
*** test using osgviewer class only ***
cpu time: 1656 milliseconds
effective time: 1.66006 seconds
average fps: 602.389
OSX:
*** test using GLUT ***
cpu time: 391.799 milliseconds
effective time: 2.70822 seconds
average fps: 369.246
*** test using osgviewer class only ***
cpu time: 943.835 milliseconds
effective time: 16.8232 seconds
average fps: 59.4417
beside the performance difference (I guess because of the integrated intel
graphics on my macbook), what I feel strange is that on win32 the osgviewer
class is not bound to the 60Hz refresh rate, and the performances are
consistent in GLUT/nonGLUT mode (607 vs 602 fps), while in OSX there is a
huge difference between the two (369 vs 60 fps).
Maybe this is already known, or it's simply a matter of better setting up
the application.
If the testcase is needed I can attach it (is it possible to this mailing
list?) or paste the source code the the email, it's a single file. Or you
can reproduce it using the standard osgviewer application distributed with
osg.
The calls I'm doing to create the viewer are basically:
osgViewer::Viewer* viewer = new osgViewer::Viewer();
viewer-setSceneData( myscenenode*** );
viewer-setCameraManipulator(new osgGA::TrackballManipulator);
viewer-addEventHandler(new osgViewer::StatsHandler);
viewer-realize();
while (true)
{
// update the viewer
viewer-frame();
(...)
}
thanks again!
Davide
Robert,
I set up a simple test, with only a rotating cube displayed with:
1) osgviewer using GLUT
2) osgviewer standalone class
in both I used double-buffered 800x600 window.
I only tested on my mac yet, but tomorrow I will test on windows too.
The results are:
** standalone **
cpu time: 1001.35 milliseconds
effective time: 16.796 seconds
average fps: 59.538
** using glut **
cpu time: 458.949 milliseconds
effective time: 2.71029 seconds
average fps: 368.964
I think that you were right and I was misinterpreting the results: it is
evident that the standalone osgviewer version is fixed on 60Hz, which is
my
laptop display refresh rate.
The glut version seems not to be bound to the display refresh but the
doublebuffering is enabled...
Probably there is something I still ignore just under the hood, on how the
refresh is handled.
The same difference appears with the standard osgviewer and
osgviewerGLUT applications built with cmake (in both 2.4.0 and 2.6.0)
Tomorrow I will try on windows, with the same code. For what I observed, I
expect to have a fps higher to 60Hz there, I will let you know.
Just in case, is it possible to attach the testcase to a message directed
to
the mailing list?
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] Render to Texture and per vertex colors
Hi Art, It would be great to see this demo!!! Another good idea is to use another camera for the 'glow objects', this match perfectly with my pipeline, with minor changes on the shaders. Although i propossed to use OsgPPU on the app we are doing, at this time we use another postprocessing effects, so at this moment we need a quite big change on it to use osgPPU (im sure that when osgPPU gets inside osg core, we will use it). Ill try to send you the small app using osgPPU that crahses. Thanx J. -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=5814#5814 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::Image::copySubImage
HI Valery? (could you sign with the name you wish to be addressed as please to avoid confusion ;-) The osg::Image* source parameter should be const, clearly this was just an oversight in the original implementation, I've fixed this and checked into svn/trunk. So this change will make it into 2.8. Cheers, Robert. On Wed, Feb 4, 2009 at 8:11 AM, Валерий Быков valery.bic...@gmail.com wrote: Hi. Tell me please why void osg::Image::copySubImage(int s_offset,int t_offset,int r_offset,osg::Image* source); has non-const parameter source? ___ 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] Getting Started with OpenSceneGraph on Ubuntu
Wow! I thank you so much for your detailed support. I was able to compile my OSG program with OpenSceneGraph 2.4 with kind help of Alberto Luaces. I will try your instruction soon to get the newest version of OpenSceneGraph, well, as soon as OSG 2.8 becomes available. Uhm, one thing I don't understand is, as you said, Could sign with the name you wish to be addressed as please, to prevent others form making mistakes. Actually I've just had to subscribe to osg-users, again, to be able to post in the group, although I still have recieved osg disgest mails for months. Does it has anything to do with what you said? :-S -- TnTonly Corporation === Home: http://www.tntonly.co.cc Mail: http://mail.tntonly.co.cc Forum: http://www.tntonly.co.cc/forum Blog: http://www.tntonly.co.cc/blog OS: http://www.tntonly.co.cc/os (Limited Service) === ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::notify replaceable backend?
Hi Filip,
From include/osg/Notify you have the getNotifyLevel() function...
/** Range of notify levels from DEBUG_FP through to FATAL, ALWAYS
* is reserved for forcing the absorption of all messages. The
* keywords are also used verbatim when specified by the environmental
* variable OSGNOTIFYLEVEL. See documentation on osg::notify() for
* further details.
*/
enum NotifySeverity {
ALWAYS=0,
FATAL=1,
WARN=2,
NOTICE=3,
INFO=4,
DEBUG_INFO=5,
DEBUG_FP=6
};
/** set the notify level, overriding the default or the value set by
* the environmental variable OSGNOTIFYLEVEL.
*/
extern OSG_EXPORT void setNotifyLevel(NotifySeverity severity);
/** get the notify level. */
extern OSG_EXPORT NotifySeverity getNotifyLevel();
/** is notification enabled, given the current setNotifyLevel() setting? */
extern OSG_EXPORT bool isNotifyEnabled(NotifySeverity severity);
On Wed, Feb 4, 2009 at 8:46 AM, Filip Holm filip.h...@gmail.com wrote:
Hi all,
I have a non console based application that has it's own reporting
mechanism built-in. I'd like to be able to set the NotifyLevel and
have these messages sent to my logger tool. My logger tool also has
it's own filters/log-levels, so I'd like to be able to map the
osg::NotifySeverity to some matching log-level.
I've figured out a way to reoute all osg::notify messages to my
logger, but I can't seem to find a way to get the osg::NotifySeverity
mapping. Any thoughts on how this could be done is greatly
appretiated.
What I have done to just flush all osg::notify messages to my logger is:
void main()
{
MyLoggWrapper log;
std::streambuf* notifyBuf = osg::notify().rdbuf();
osg::notify().rdbuf(log.rdbuf());
osg::notify(osg::INFO) This message is passed straight to my
logger, sadly without knowlede of NotifySeverity std::endl;
snip
//osgViewer instantiation and main loop etc.
/snip
osg::notify().rdbuf(notifyBuf);
}
Filip Holm
___
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] Getting Started with OpenSceneGraph on Ubuntu
Hi ? On Wed, Feb 4, 2009 at 12:13 PM, Trịnh Thành Trung GMail trinhthanhtr...@gmail.com wrote: Uhm, one thing I don't understand is, as you said, Could sign with the name you wish to be addressed as please, to prevent others form making mistakes. When I mean sign your posts I mean, just sign your first name or a pseudonym at the bottom of each post so that we keep track of who's who - this might seem a little formal, but it makes for a much pleasanter online exchanges. Mailing lists such as this one are fundamentally a social activity, it's just a community of like minded individuals trying to scramble through their daily tasks, helping and receiving help. Small little things like being a bit more personal can help this along. Actually I've just had to subscribe to osg-users, again, to be able to post in the group, although I still have recieved osg disgest mails for months. Does it has anything to do with what you said? :-S You can post from a digest enabled mail subscription, it's only the mail dispatch that is different. Contributing to threads using non digest form is much easier though, as you can reply directly to posts, without having to jump through hoops to get the subject line to do some sensible. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi All, I have now made the OpenSceneGraph-2.8 branch, the svn entry for it is: http://www.openscenegraph.org/svn/osg/OpenSceneGraph/branches/OpenSceneGraph-2.8/ If those don't CDash builds (as well as everyone else) move across to using this branch as the base for testing the OSG-2.8 release series. I'll also soon be making an OSG-2.8.0-rc1, but first I'll do a fresh build on the 2.8 branch and see how I get on. It'd be useful to have feedback from others as well on how the OSG-2.8 is fairing. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Different behavior between Linux and Windows when using OpenThreads::Mutex
Hi,
It seems that there is a difference in behavior when using the
OpenThreads::Mutex class in Linux and Windows.
For our (crossplatform) application it is required to synchronize data
between two different threads. In order to prevent a race condition, we
used the OpenThreads mutex lock (OpenSceneGraph 2.6.1).
To test the behavior of the mutex lock, I created a small application
(attached below).
Our Linux machine produces the following output:
[laure...@fedora mutex_test]$ ./main
test 1 (trylock): ok
-- application blocked --
Using the same application under windows (compiled with mingw):
main.exe
test 1 (trylock): ok
test 2 (lock): ok
test 3 (lock again): ok
test 4 (unlock): ok
-- application finished --
The Linux version shows the correct behavior, the Windows version seems
to ignore the lock calls and does not block at all.
Questions:
1. Are additional settings required to use the OpenThreads mutex lock
under windows?
2. What alternatives are available for the OpenThreads mutex lock?
(Manually implement calls using pthread?)
Kind Regards,
- Laurence
-
// main.cpp
// g++ main.cpp -o main -I /home/userx/osg/include -L
/home/userx/osg/lib -lOpenThreads
#include stdlib.h
#include iostream
#include OpenThreads/Mutex
using namespace std;
OpenThreads::Mutex *mt_sync;
int main(int argc, char **argv)
{
mt_sync = new OpenThreads::Mutex();
printf(test 1 (trylock): );
if(mt_sync-trylock() == 0)
printf(ok\n);
else
printf(fail\n);
printf(test 2 (lock): );
if(mt_sync-lock() == 0)
printf(ok\n);
else
printf(fail\n);
printf(test 3 (lock again): );
if(mt_sync-lock() == 0)
printf(ok\n);
else
printf(fail\n);
printf(test 4 (unlock): );
if(mt_sync-unlock() == 0)
printf(ok\n);
else
printf(fail\n);
delete mt_sync;
return 0;
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] MSVC v9
Hi Tanguy, On Wed, Feb 4, 2009 at 12:22 PM, Tanguy Fautre tang...@aristechnologies.com wrote: Robert, do you thing the problem may be serious enough to possibly motivate a code change for all operators of Vec3f and co as a workaround? We could change code, it would all depend on how intrusive the changes are, without code changes in front of me I can't make this judgement call. Could you send me a modified Vec* files so I could do a review? The other approach is to change the compile flags of the OSG to avoid this bug. This wouldn't help 3rd party apps though. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Render to Texture and per vertex colors
Hi Joseba, Yes, I also think that osgPPU is a 'must have' in osg, however I am not the maintainer of the osg code, hence I hope that osgPPU would not die in the future or will not be replaced by something else in the main core, which would be very ungente ;) As to your error in the applied RTT texture. Could you give me the code, which makes the application crashes. Maybe there is some error in osgPPU which cause this, hence I would be able to correct it. As to the glow shader, I would propose to do it in the way, so that it doesn't hurt your already valid pipeline. For example, you could add all objects, which has to be glowed to another camera. Hence you will get 2 cameras in your pipleine. First one renders your scene in a usual way, second one does render only the glowed objects. You then setup osgPPU on the main camera and put the output of the second camera into osgPPU pipeline with UnitCamera and UnitCameraAttachmentBypass. In the main shader you then combine the results of both cameras together, to make the objects glow. Another way would be to use MRT (multiple rendering targets), should be also a way which has better performance, than the first one. Shaders which renders your objets do output something like a bitmask of rendered parts to the second RTT texture (gl_FragData[1]=1, if object has to glow). Use then both output texture in the osgPPU pipeline to combine them. As for the second case, I could write a simple demo code and put it into osgPPU, if you like. This shouldn't be that hard and you could learn how to do this ;) Best regards, art -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=5813#5813 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] modelling geodes with children?
Hi Cory, In my mind, I'm equating the thing with the thing's geometry. And so if something is attached to the thing, I want the data structure to mimic that. I can understand where you're coming from, but I think keeping things separate (at least conceptually) makes them more flexible. It's a matter of opinion, of course, as most design decisions are. :-) Think of the Transform node as being just a change in coordinate systems. I tend to picture the graph upside down, or at least read it going from the leaves to the root (instead of the opposite). The geometry itself is modeled in its local coordinate system (that's just the Geode), then it's transformed to place it where it should be relative to some other thing (that's just the Transform). And so on. 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
Re: [osg-users] Different behavior between Linux and Windows when using OpenThreads::Mutex
Hi,
see also this thread here:
http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/14294/
I've run into this as well.
Also have a look at OpenThreads/Barrier.
jp
Laurence Muller wrote:
Hi,
It seems that there is a difference in behavior when using the
OpenThreads::Mutex class in Linux and Windows.
For our (crossplatform) application it is required to synchronize data
between two different threads. In order to prevent a race condition, we
used the OpenThreads mutex lock (OpenSceneGraph 2.6.1).
To test the behavior of the mutex lock, I created a small application
(attached below).
Our Linux machine produces the following output:
[laure...@fedora mutex_test]$ ./main
test 1 (trylock): ok
-- application blocked --
Using the same application under windows (compiled with mingw):
main.exe
test 1 (trylock): ok
test 2 (lock): ok
test 3 (lock again): ok
test 4 (unlock): ok
-- application finished --
The Linux version shows the correct behavior, the Windows version seems
to ignore the lock calls and does not block at all.
Questions:
1. Are additional settings required to use the OpenThreads mutex lock
under windows?
2. What alternatives are available for the OpenThreads mutex lock?
(Manually implement calls using pthread?)
Kind Regards,
- Laurence
-
// main.cpp
// g++ main.cpp -o main -I /home/userx/osg/include -L
/home/userx/osg/lib -lOpenThreads
#include stdlib.h
#include iostream
#include OpenThreads/Mutex
using namespace std;
OpenThreads::Mutex *mt_sync;
int main(int argc, char **argv)
{
mt_sync = new OpenThreads::Mutex();
printf(test 1 (trylock): );
if(mt_sync-trylock() == 0)
printf(ok\n);
else
printf(fail\n);
printf(test 2 (lock): );
if(mt_sync-lock() == 0)
printf(ok\n);
else
printf(fail\n);
printf(test 3 (lock again): );
if(mt_sync-lock() == 0)
printf(ok\n);
else
printf(fail\n);
printf(test 4 (unlock): );
if(mt_sync-unlock() == 0)
printf(ok\n);
else
printf(fail\n);
delete mt_sync;
return 0;
}
___
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
Re: [osg-users] SVN (2.8) bugs in osgviewerQt
Hi Morné, Thanks again for your help!! You saved me a lot of debugging headache :) You're welcome, we have to stick together when we're doing similar projects so we all move forward much faster! PS. Do you want me to submit a modified osgviewerQt example with these fixes/workarounds? It would be nice to get others' comments on these changes, so I would say yes. Plus it would allow us to test these same features in the future when other things change. 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] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Robert, I checked out a fresh 2.8 source tree (rev 9648) and it built fine on vs 2005 xp! But I still see a few warnings and they are attached. cheers Mattias On 2/4/09, Robert Osfield robert.osfi...@gmail.com wrote: Hi All, I have now made the OpenSceneGraph-2.8 branch, the svn entry for it is: http://www.openscenegraph.org/svn/osg/OpenSceneGraph/branches/OpenSceneGraph-2.8/ If those don't CDash builds (as well as everyone else) move across to using this branch as the base for testing the OSG-2.8 release series. I'll also soon be making an OSG-2.8.0-rc1, but first I'll do a fresh build on the 2.8 branch and see how I get on. It'd be useful to have feedback from others as well on how the OSG-2.8 is fairing. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _nod_Ty,_Alloc::_Node' : default constructor could not be generated 15with 15[ 15 _Ty=triangle_stripper::common_structures::graph_arraytriangle_stripper::triangle,char::arc, 15 _Alloc=std::allocatortriangle_stripper::common_structures::graph_arraytriangle_stripper::triangle,char::arc 15] 15C:\Program Files\Microsoft Visual Studio 8\VC\include\list(38) : see declaration of 'std::_List_nod_Ty,_Alloc::_Node' 15with 15[ 15 _Ty=triangle_stripper::common_structures::graph_arraytriangle_stripper::triangle,char::arc, 15 _Alloc=std::allocatortriangle_stripper::common_structures::graph_arraytriangle_stripper::triangle,char::arc 15] 15C:\Program Files\Microsoft Visual Studio 8\VC\include\list(111) : see reference to class template instantiation 'std::_List_nod_Ty,_Alloc::_Node' being compiled 15with 15[ 15 _Ty=triangle_stripper::common_structures::graph_arraytriangle_stripper::triangle,char::arc, 15 _Alloc=std::allocatortriangle_stripper::common_structures::graph_arraytriangle_stripper::triangle,char::arc 15] 15C:\Program Files\Microsoft Visual Studio 8\VC\include\list(110) : while compiling class template member function 'std::_List_nod_Ty,_Alloc::_Node *std::list_Ty::_Nextnode(std::_List_nod_Ty,_Alloc::_Node *)' 15with 15[ 15 _Ty=triangle_stripper::common_structures::graph_arraytriangle_stripper::triangle,char::arc, 15 _Alloc=std::allocatortriangle_stripper::common_structures::graph_arraytriangle_stripper::triangle,char::arc 15] 15c:\public\openscenegraph-2.8\src\osgutil\TriStrip_graph_array.h(109) : see reference to class template instantiation 'std::list_Ty' being compiled 15with 15[ 15 _Ty=triangle_stripper::common_structures::graph_arraytriangle_stripper::triangle,char::arc 15] 15 c:\public\openscenegraph-2.8\src\osgutil\TriStrip_tri_stripper.h(257) : see reference to class template instantiation 'triangle_stripper::common_structures::graph_arraynodetype,arctype' being compiled 15with 15[ 15nodetype=triangle_stripper::triangle, 15arctype=char 15] 15C:\Program Files\Microsoft Visual Studio 8\VC\include\list(42) : warning C4610: struct 'std::_List_nod_Ty,_Alloc::_Node' can never be instantiated - user defined constructor required 15with 15[ 15 _Ty=triangle_stripper::common_structures::graph_arraytriangle_stripper::triangle,char::arc, 15 _Alloc=std::allocatortriangle_stripper::common_structures::graph_arraytriangle_stripper::triangle,char::arc 15] 16Registry.cpp 15TriStrip_tri_stripper.cpp 15C:\Program Files\Microsoft Visual Studio 8\VC\include\list(42) : warning C4510: 'std::_List_nod_Ty,_Alloc::_Node' : default constructor could not be generated 15with 15[ 15 _Ty=triangle_stripper::common_structures::graph_arraytriangle_stripper::triangle,char::arc, 15 _Alloc=std::allocatortriangle_stripper::common_structures::graph_arraytriangle_stripper::triangle,char::arc 15] 15C:\Program Files\Microsoft Visual Studio 8\VC\include\list(38) : see declaration of 'std::_List_nod_Ty,_Alloc::_Node' 15with 15[ 15 _Ty=triangle_stripper::common_structures::graph_arraytriangle_stripper::triangle,char::arc, 15 _Alloc=std::allocatortriangle_stripper::common_structures::graph_arraytriangle_stripper::triangle,char::arc 15] 15C:\Program Files\Microsoft Visual Studio 8\VC\include\list(111) : see reference to class template instantiation 'std::_List_nod_Ty,_Alloc::_Node' being compiled 15with 15[ 15 _Ty=triangle_stripper::common_structures::graph_arraytriangle_stripper::triangle,char::arc, 15 _Alloc=std::allocatortriangle_stripper::common_structures::graph_arraytriangle_stripper::triangle,char::arc 15
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Robert, If those don't CDash builds (as well as everyone else) move across to using this branch as the base for testing the OSG-2.8 release series. Quick question about this: Since the Nightly build is still called Nightly in the 2.8 branch, it will replace any result of a nightly build of the trunk right? So I don't have to schedule a nightly build of both, just the 2.8 branch, until 2.8 is out. Am I right? BTW, I've got a build from last night on the CDash dashboard (WHITESTAR) and it looks like it built fine, though with 13 warnings from compiling the 29 changed files. I've started a build of the 2.8 branch, since it's the first it will be a complete build and the results should be there in about 20 minutes. 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] Bug in 2.7.9 with collada
Hi Robert Roger, I've tried with another collada file with texture, and it works, so it's probably a problem with mine. Unfortunately i can't send a sample of this file because of property rights, so i will continue to look around it. Thanks anyway for your answers. Patrice Roger James a crit: Patrice Bouvier wrote: Hi All, I'm working under ubuntu 8.04 Hardy. I've just installed the OSG 2.7.9 version. Unfortunately i've a problem with a collada scene, no textures are loaded. With the 2.6.1 version it was ok. I use the collada dom 2.0 version. Could someone give me a fix for that problem ? Thanks Patrice Without any information a fix will be difficult :-) Can you at least supply a copy of your osg notify log. If your model is a large one it would be good if you could cut it down to a single geometry node which fails to show a texture and post that. Collada files are xml and quite easy to hand edit. Roger ___ 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] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Robert, Just built a clean checkout of the 2.8 branch on Windows Vista, Visual Studio 8 SP1. Apart from the std::list warning that we can't do much about, there were 4 left in OSGA_Archive.cpp (below). I tested the build in our app and everything worked as expected. Cheers, Morne warning C4512: 'OSGA_Archive::WriteObjectFunctor' : assignment operator could not be generated c:\P\TestLibs\OSG\OpenSceneGraph-SVN\src\osgPlugins\osga\OSGA_Archive.cpp 727 warning C4512: 'OSGA_Archive::WriteImageFunctor' : assignment operator could not be generated c:\P\TestLibs\OSG\OpenSceneGraph-SVN\src\osgPlugins\osga\OSGA_Archive.cpp 737 warning C4512: 'OSGA_Archive::WriteHeightFieldFunctor' : assignment operator could not be generated c:\P\TestLibs\OSG\OpenSceneGraph-SVN\src\osgPlugins\osga\OSGA_Archive.cpp 747 warning C4512: 'OSGA_Archive::WriteNodeFunctor' : assignment operator could not be generated c:\P\TestLibs\OSG\OpenSceneGraph-SVN\src\osgPlugins\osga\OSGA_Archive.cpp 757 On Wed, Feb 4, 2009 at 1:02 PM, Robert Osfield robert.osfi...@gmail.com wrote: Hi All, I have now made the OpenSceneGraph-2.8 branch, the svn entry for it is: http://www.openscenegraph.org/svn/osg/OpenSceneGraph/branches/OpenSceneGraph-2.8/ If those don't CDash builds (as well as everyone else) move across to using this branch as the base for testing the OSG-2.8 release series. I'll also soon be making an OSG-2.8.0-rc1, but first I'll do a fresh build on the 2.8 branch and see how I get on. It'd be useful to have feedback from others as well on how the OSG-2.8 is fairing. 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] MSVC v9
Hi Robert,
It's not a small set of changes. It's actually quite tedious (but not complex
to do). Unfortunately, we cannot be sure it avoids the invalid code generation
bug in all cases.
Basically, changing the operator (in this case, it's operator -) from:
/** Binary vector subtract. */
inline const Vec3f operator - (const Vec3f rhs) const
{
return Vec3f(_v[0]-rhs._v[0], _v[1]-rhs._v[1], _v[2]-rhs._v[2]);
}
/** Unary vector subtract. */
inline Vec3f operator -= (const Vec3f rhs)
{
_v[0]-=rhs._v[0];
_v[1]-=rhs._v[1];
_v[2]-=rhs._v[2];
return *this;
}
To:
inline Vec3f operator -= (const Vec3f rhs)
{
_v[0] -= rhs._v[0];
_v[1] -= rhs._v[1];
_v[2] -= rhs._v[2];
return *this;
}
inline friend Vec3f operator - (const Vec3f lhs, const Vec3f rhs)
{
return Vec3f(lhs) -= rhs;
}
Seems to work around the problem with VS2005 and VS2008 without requiring
changes in the user code. Also, someone's pointed out the latter is more
correct in some cases (e.g. argument dependent lookup, see below).
But changing all the operators of classes like Vec3f, Vec3d (and I suppose
others such as Matrix classes) would be quite tedious. I guess it really
depends on how many people are really by this problem.
One a broader note, I've noticed Boost has a very nice library for dealing with
this (http://www.boost.org/doc/libs/1_37_0/libs/utility/operators.htm). Too bad
OSG probably cannot use it because of the dependencies it would introduce. But
it's still worth a read, as they explain several issues that may not be obvious
at first sight.
Cheers,
Tanguy
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield
Sent: Wednesday 04 February 2009 12:40
To: OpenSceneGraph Users
Subject: Spam: Re: [osg-users] MSVC v9
Hi Tanguy,
On Wed, Feb 4, 2009 at 12:22 PM, Tanguy Fautre
tang...@aristechnologies.com wrote:
Robert, do you thing the problem may be serious enough to possibly motivate
a code change for all operators of Vec3f and co as a workaround?
We could change code, it would all depend on how intrusive the changes
are, without code changes in front of me I can't make this judgement
call. Could you send me a modified Vec* files so I could do a review?
The other approach is to change the compile flags of the OSG to avoid
this bug. This wouldn't help 3rd party apps though.
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] OpenSceneGraph-2.8.0-rc1 tagged, please test
Hi All, We're finally one the home straight now - OpenSceneGraph-2.8 branch has been made, and the OpenSceneGraph-2.8.0-rc1 has just been created off this. News page: http://www.openscenegraph.org/projects/osg/wiki/News/Press/OSG2.8 Download page: http://www.openscenegraph.org/projects/osg/wiki/Downloads OpenSceneGraph-2.8.0-rc1 source code: source package: http://www.openscenegraph.org/downloads/developer_releases/OpenSceneGraph-2.8.0-rc1.zip svn tag: svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.0-rc1 OpenSceneGraph OpenSceneGraph-2.8 branch: svn tag: svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/branches/OpenSceneGraph-2.8 OpenSceneGraph Updates (since 2.6.1) include: ¶ * New osgVolume library for volume rendering, with support for: o High quality GPU based Ray tracing o Transfer functions o Per pixel lighting o Iso surface rendering o Maximum Intensity rendering o non power of two 3d texture and 3d texture compression o DICOM loader for reading dicom medical data * New osgAnimation library for character and scene animation. * New plugin for reading Biovision hierarchical files (.BVH) to generate character motion animations. * New osgShadow support for Light Space Perspective Shadow Maps. * Three new scene graph widgets for placing traditional 2D capability into fully interactive 3D scenes: o PDF widget support (based on libPoppler) o VNC client widget support (based on libVNCServer) o Internet browser client widget support (based on Gecko/UBrowser) * New plugins for loading Half-Life 2 maps and models. * New plugin for loaded exr, high dynamic range imagery * Improvements to DatabasePager tailored for low latency paging. * Improved runtime stats collection and on screen reporting. * Performance improvements through optimization of matrix operations. * Support for the OpenGL draw instanced extension. * Improvements to COLLADA support. * Build reporting using CDash * New packing support using CPack * A wide range of build and bug fixes Many many thanks to all those who've put in time on testing out 2.7.9 and svn/trunk, I sense that this 2.8.0-rc1 is the more ready for release snapshot we've ever done ;-) But still we can't rest if we want to make 2.8.0 the best we can... so please download/check out the OpenSceneGraph-2.8 branch or the 2.8.0-rc1 and do compile and runtime checks on as wide range of platforms as you have to hand. I would also greatly value feedback on how you own applications are performing with 2.8, if there are issues please just report them on osg-users and we can together have a bash at resolve them. For uploading of packages I have requested ftp access to the server for uploading, I let you know of the details if we can get this set up. Have fun! Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi JS, On Wed, Feb 4, 2009 at 2:32 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Quick question about this: Since the Nightly build is still called Nightly in the 2.8 branch, it will replace any result of a nightly build of the trunk right? So I don't have to schedule a nightly build of both, just the 2.8 branch, until 2.8 is out. Am I right? Yes, move across to making the builds from the 2.8 banch till 2.8.0 is out. Even after 2.8.0 is out, there is some value in having periodic builds of the 2.8 branch as there may well be a 2.8.1+ later released, although we could probably just make a request for new tests of the 2.8 if we actually need to make a 2.8.1+ I've started a build of the 2.8 branch, since it's the first it will be a complete build and the results should be there in about 20 minutes. Thanks. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Multiple GPU
Hi, I have to do a simulation project which needs 8 screens. This system likes a dome. so i want to ask few questions about this: 1) i want to use multiple gpu's. So is there a limit on number of gpu's on a pc? i saw 4 gpu's on a pc and every gpu has 2 outputs. can i render 8 screen with viewer? 2) how can i set which gpu render which screen. is there an auto management system in viewer? if i have screens which have resolutions like 8x1280x1024 or 4x2560x1024 or any other combination of this, should i do an extra thing for this? 3) do you think i will have a critical frame rate problem if i render 8 screens. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] MSVC v9
Hi Robert,
I agree such changes would be too risky to be done for the current
release. But I don't think a compiler flag change would help much at
this point (especially that the bug was reported on this mailing list as
part of the user code, not OSG code).
Neil has expressed that he is willing to implement those changes
himself, which would be introduced post-2.8.0 obviously.
Tanguy
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert
Osfield
Sent: Wednesday 04 February 2009 14:48
To: OpenSceneGraph Users
Subject: Re: [osg-users] MSVC v9
HI Tanguy,
OK, since the changes are intrusive and widespread there certainly are
candidates for inclusion into 2.8.0, it's just too much of risk.
Changing the compile options should be less intrusive so I'd suggest
looking into adding this option to the VS compile options in
OpenSceneGraph/CMakeLists.txt. One could make these extra build
options, optionally so that you can toggle them on/off from with
ccmake/CMakeSetup.
Robert.
On Wed, Feb 4, 2009 at 2:37 PM, Tanguy Fautre
tang...@aristechnologies.com wrote:
Hi Robert,
It's not a small set of changes. It's actually quite tedious (but not
complex to do). Unfortunately, we cannot be sure it avoids the invalid
code generation bug in all cases.
Basically, changing the operator (in this case, it's operator -) from:
/** Binary vector subtract. */
inline const Vec3f operator - (const Vec3f rhs) const
{
return Vec3f(_v[0]-rhs._v[0], _v[1]-rhs._v[1],
_v[2]-rhs._v[2]);
}
/** Unary vector subtract. */
inline Vec3f operator -= (const Vec3f rhs)
{
_v[0]-=rhs._v[0];
_v[1]-=rhs._v[1];
_v[2]-=rhs._v[2];
return *this;
}
To:
inline Vec3f operator -= (const Vec3f rhs)
{
_v[0] -= rhs._v[0];
_v[1] -= rhs._v[1];
_v[2] -= rhs._v[2];
return *this;
}
inline friend Vec3f operator - (const Vec3f lhs, const Vec3f rhs)
{
return Vec3f(lhs) -= rhs;
}
Seems to work around the problem with VS2005 and VS2008 without
requiring changes in the user code. Also, someone's pointed out the
latter is more correct in some cases (e.g. argument dependent lookup,
see below).
But changing all the operators of classes like Vec3f, Vec3d (and I
suppose others such as Matrix classes) would be quite tedious. I guess
it really depends on how many people are really by this problem.
One a broader note, I've noticed Boost has a very nice library for
dealing with this
(http://www.boost.org/doc/libs/1_37_0/libs/utility/operators.htm). Too
bad OSG probably cannot use it because of the dependencies it would
introduce. But it's still worth a read, as they explain several issues
that may not be obvious at first sight.
Cheers,
Tanguy
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert
Osfield
Sent: Wednesday 04 February 2009 12:40
To: OpenSceneGraph Users
Subject: Spam: Re: [osg-users] MSVC v9
Hi Tanguy,
On Wed, Feb 4, 2009 at 12:22 PM, Tanguy Fautre
tang...@aristechnologies.com wrote:
Robert, do you thing the problem may be serious enough to possibly
motivate
a code change for all operators of Vec3f and co as a workaround?
We could change code, it would all depend on how intrusive the changes
are, without code changes in front of me I can't make this judgement
call. Could you send me a modified Vec* files so I could do a review?
The other approach is to change the compile flags of the OSG to avoid
this bug. This wouldn't help 3rd party apps though.
Robert.
___
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.or
g
___
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
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Robert, I'm terribly sorry, but I don't have the time right now. I just hope someone else will do it. PS: I launched an experimental build. I'll tell you about the results. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Wed, 04 Feb 2009 15:57:45 +0100, Robert Osfield robert.osfi...@gmail.com a écrit: Hi Window's users, I've tried really hard to fix all these Windows warnings, while most seem now fixed/workaround/suppressed some have resisted my attempts to remotely fix them, we me doing several unsuccessful attempts at this last persistent warnings. A fundamental problem is that I can't make a change and see whether the problem is fixed or not, this makes it really inefficient... So could a windows hack take over the attempt at fixing these warnings. Suppressing these warnings is fair game at this stage, especially if simple code changes aren't possible, suppressing a warning for a single .cpp is also note such a bad thing, especially if you use the convention set up in the include/osg/Export that allows you to switch off the disabling of the MSVC warnings. The src/osgPlugins/cfg/ConfigLexer.cpp has one such example (that doesn't seem to work... if the latest build results are correct). #if defined(_MSC_VER) defined(OSG_DISABLE_MSVC_WARNINGS) // disable '=' : conversion from 'int' to 'char', possible loss of data style warnings #pragma warning( disable : 4244) #endif Just send me the code changes that resolve these final warnings. Thanks, 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] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Robert, Yes, move across to making the builds from the 2.8 banch till 2.8.0 is out. OK, I've disabled the nightly build of the branch for now. Even after 2.8.0 is out, there is some value in having periodic builds of the 2.8 branch as there may well be a 2.8.1+ later released, although we could probably just make a request for new tests of the 2.8 if we actually need to make a 2.8.1+ We could perhaps have the same thing as for 2.6 - a Nightly-2.8 target, so that the build would end up in a different category and not overwrite the build of the trunk on the dashboard page? I've started a build of the 2.8 branch, since it's the first it will be a complete build and the results should be there in about 20 minutes. Which is now done (20.2 minutes), and it seems that the only warnings were could not open build log for writing... Good job on the warnings fixes. 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] MSVC v9
Hi Tanguy, I wonder, why have I not seen this problem with my OSG builds? Is it that the default optimization options are lower than what generates this bug? (sorry I've been speed-reading this thread and may have missed mention of this) 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] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Robert, I've tried really hard to fix all these Windows warnings, while most seem now fixed/workaround/suppressed some have resisted my attempts to remotely fix them, we me doing several unsuccessful attempts at this last persistent warnings. As I said on my other post, I don't seem to get any warnings (other than can't open build log for writing, which is weird but benign - the warnings if any would still go to stdout and thus get reported in the CDash warnings page for the build). I'll try another full rebuild and see for sure. Then if I get any I'll see what needs to be done. 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] Getting Started with OpenSceneGraph on Ubuntu
Ok, thanks for your suggestion. -- Kind regards. Trung. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple GPU
Hi UFUK ? it would be greate to get see working osg with such high-end technology. may you should use equalizer and openscenegraph doing this. adrian 2009/2/4 ufuk gun ufuk@gmail.com Hi, I have to do a simulation project which needs 8 screens. This system likes a dome. so i want to ask few questions about this: 1) i want to use multiple gpu's. So is there a limit on number of gpu's on a pc? i saw 4 gpu's on a pc and every gpu has 2 outputs. can i render 8 screen with viewer? 2) how can i set which gpu render which screen. is there an auto management system in viewer? if i have screens which have resolutions like 8x1280x1024 or 4x2560x1024 or any other combination of this, should i do an extra thing for this? 3) do you think i will have a critical frame rate problem if i render 8 screens. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Adrian Egli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Spam: Re: MSVC v9
Hi J-S, The bug is apparently triggered by a very specific set of conditions. Most common programming patterns will actually result in the compiler generating the correct code. If you search the thread, you'll find more detailed explanations as well as an example program. I do not expect many people to be affected by it. For all I know, it's been lurking around for years. Tanguy -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien Guay Sent: Wednesday 04 February 2009 15:21 To: OpenSceneGraph Users Subject: Spam: Re: [osg-users] MSVC v9 Hi Tanguy, I wonder, why have I not seen this problem with my OSG builds? Is it that the default optimization options are lower than what generates this bug? (sorry I've been speed-reading this thread and may have missed mention of this) 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] Multiple GPU
Hi Ufuk? Gun? (Could you please sign with your first name so we can adddress you correctly) On Wed, Feb 4, 2009 at 2:54 PM, ufuk gun ufuk@gmail.com wrote: Hi, I have to do a simulation project which needs 8 screens. This system likes a dome. so i want to ask few questions about this: 1) i want to use multiple gpu's. So is there a limit on number of gpu's on a pc? i saw 4 gpu's on a pc and every gpu has 2 outputs. can i render 8 screen with viewer? Yes, osgViewer support novel camera/display combinations, including support for multi-threading. There is a video on youtube of FlightGear running on an 8 screen powerwall all driven from a single PC. I'm afriad I don't have the refernece off hand. I've personally driven four outputs from a single PC using two cards. Scaling up much higher will hit PC hardware/driver bottlenecks. If you are doing a dome, then could also do the distortion correction using the OSG - see the osgViewer::setUpViewFor3DSphericalDisplay(), this uses 6 RTT cameras rendering to a cube map, and a single Camera/subgraph that does the distortion correction. This setup only generates a single output for a fish eye lens, so not an exact match for your requirements but it might give up an idea of how to set up the various slave cameras to do combinations of distortion correction. 2) how can i set which gpu render which screen. is there an auto management system in viewer? if i have screens which have resolutions like 8x1280x1024 or 4x2560x1024 or any other combination of this, should i do an extra thing for this? You just assign the screen number to the GraphicsContext::Traits when setting up the various GraphicsContexts. See the osgcamera example for an example of use Traits to describe your window setup. FYI, Windows is less well suited for this type of multi-screen output, as the drivers try to a bit bit too clever for their own good, duplicating OpenGL calls across contexts. Unices (including Linux) that use X11 work great on complex multi-screen setups as you get exactly what you ask for in terms of screen to GPU mapping. 3) do you think i will have a critical frame rate problem if i render 8 screens. That all depends upon your scene, and your hardware, and your frame-rate needs. It's doable but.. to get the performance you might need to use a cluster rather than a single machine. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple GPU
Hi, Recent post of Stefan Eilemann on Equalizer blog talk about Openscenegraph and Equalizer : http://pogl.wordpress.com/2009/01/24/openscenegraph-and-equalizer/ Maybe, you could use the subversion of Equalizer and Openscengraph 2.8 Yann, On Wed, Feb 4, 2009 at 4:25 PM, Adrian Egli OpenSceneGraph (3D) 3dh...@gmail.com wrote: Hi UFUK ? it would be greate to get see working osg with such high-end technology. may you should use equalizer and openscenegraph doing this. adrian 2009/2/4 ufuk gun ufuk@gmail.com Hi, I have to do a simulation project which needs 8 screens. This system likes a dome. so i want to ask few questions about this: 1) i want to use multiple gpu's. So is there a limit on number of gpu's on a pc? i saw 4 gpu's on a pc and every gpu has 2 outputs. can i render 8 screen with viewer? 2) how can i set which gpu render which screen. is there an auto management system in viewer? if i have screens which have resolutions like 8x1280x1024 or 4x2560x1024 or any other combination of this, should i do an extra thing for this? 3) do you think i will have a critical frame rate problem if i render 8 screens. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Adrian Egli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Yann Le Paih Keraudrono 56150 BAUD Portable: +33(0)610524356 lepaih.y...@gmail.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple GPU
Just to offer an alternative setup... We have OSG running a system of 6 screens representing a single view. The solution we chose was to use a single 8800 GTX and two of the matrox triple-head-to-go devices. Nvidia's twinview lets us treat it as one big screen of resolution 3840x2048, which makes for a very simple setup in OSG. By adding another card you could easily get the number of screens you require. - Ken. I have to do a simulation project which needs 8 screens. This system likes a dome. so i want to ask few questions about this: 1) i want to use multiple gpu's. So is there a limit on number of gpu's on a pc? i saw 4 gpu's on a pc and every gpu has 2 outputs. can i render 8 screen with viewer? 2) how can i set which gpu render which screen. is there an auto management system in viewer? if i have screens which have resolutions like 8x1280x1024 or 4x2560x1024 or any other combination of this, should i do an extra thing for this? 3) do you think i will have a critical frame rate problem if i render 8 screens. ___ 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] SVN (2.8) bugs in osgviewerQt
Hi Robert, J-S, Thanks for the suggestions! I removed the Qt event relay methods and added a dummy view with a zero sized viewport to my viewer. The single context, multiple view tiled viewer now works as expected, adding/removing views and clearing the window as it should. Thanks again for your help!! You saved me a lot of debugging headache :) Regards, Morné PS. Do you want me to submit a modified osgviewerQt example with these fixes/workarounds? On Tue, Feb 3, 2009 at 7:57 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Morné, The other approach might be to create an empty View that does nothing, has no scene, but at least has a Camera with the GraphicsWindow assigned to it. It's viewport could be zero sized so would be litte more than a non op, and you have have the GraphicsWindow do the clear each frame for you. This approach why a bit inelegant would probably prevent the problems you are seeing, and would just require an additionally couple of lines of set up code at the creation time, thereafter you'd just ignore this extra View. Yep, in my testing what Robert suggests would work since as long as you have at least one view there is no problem. It's removing that last view and then adding others that brings up the problem. Sorry I couldn't find anything more definitive on my end. 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] MSVC v9
HI Tanguy,
OK, since the changes are intrusive and widespread there certainly are
candidates for inclusion into 2.8.0, it's just too much of risk.
Changing the compile options should be less intrusive so I'd suggest
looking into adding this option to the VS compile options in
OpenSceneGraph/CMakeLists.txt. One could make these extra build
options, optionally so that you can toggle them on/off from with
ccmake/CMakeSetup.
Robert.
On Wed, Feb 4, 2009 at 2:37 PM, Tanguy Fautre
tang...@aristechnologies.com wrote:
Hi Robert,
It's not a small set of changes. It's actually quite tedious (but not complex
to do). Unfortunately, we cannot be sure it avoids the invalid code
generation bug in all cases.
Basically, changing the operator (in this case, it's operator -) from:
/** Binary vector subtract. */
inline const Vec3f operator - (const Vec3f rhs) const
{
return Vec3f(_v[0]-rhs._v[0], _v[1]-rhs._v[1], _v[2]-rhs._v[2]);
}
/** Unary vector subtract. */
inline Vec3f operator -= (const Vec3f rhs)
{
_v[0]-=rhs._v[0];
_v[1]-=rhs._v[1];
_v[2]-=rhs._v[2];
return *this;
}
To:
inline Vec3f operator -= (const Vec3f rhs)
{
_v[0] -= rhs._v[0];
_v[1] -= rhs._v[1];
_v[2] -= rhs._v[2];
return *this;
}
inline friend Vec3f operator - (const Vec3f lhs, const Vec3f rhs)
{
return Vec3f(lhs) -= rhs;
}
Seems to work around the problem with VS2005 and VS2008 without requiring
changes in the user code. Also, someone's pointed out the latter is more
correct in some cases (e.g. argument dependent lookup, see below).
But changing all the operators of classes like Vec3f, Vec3d (and I suppose
others such as Matrix classes) would be quite tedious. I guess it really
depends on how many people are really by this problem.
One a broader note, I've noticed Boost has a very nice library for dealing
with this (http://www.boost.org/doc/libs/1_37_0/libs/utility/operators.htm).
Too bad OSG probably cannot use it because of the dependencies it would
introduce. But it's still worth a read, as they explain several issues that
may not be obvious at first sight.
Cheers,
Tanguy
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert
Osfield
Sent: Wednesday 04 February 2009 12:40
To: OpenSceneGraph Users
Subject: Spam: Re: [osg-users] MSVC v9
Hi Tanguy,
On Wed, Feb 4, 2009 at 12:22 PM, Tanguy Fautre
tang...@aristechnologies.com wrote:
Robert, do you thing the problem may be serious enough to possibly motivate
a code change for all operators of Vec3f and co as a workaround?
We could change code, it would all depend on how intrusive the changes
are, without code changes in front of me I can't make this judgement
call. Could you send me a modified Vec* files so I could do a review?
The other approach is to change the compile flags of the OSG to avoid
this bug. This wouldn't help 3rd party apps though.
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] Using cpack to create debian packages
Hi All, Now that I've tagged 2.8.0-rc1 my focus has now moved on to helping out on the packaging front. The packaging that I'd like to contribute is the debian packages, so I've started down this journey by enable cpack support in the OSG, then doing: cpack -G DEB --config CPackConfig-libopenscenegraph.cmake -D CPACK_PACKAGE_CONTACT=rob...@openscenegraph.com Which generates a OpenSceneGraph-2.8.0.deb, which is but... if I then do create a package libopenscenegraph-dev pacakge I also get an OpenSceneGraph-2.8.0.deb. Looking at the CPackConfig-libopenscenegraph.cmake I note the CPACK_PACKAGE_FILE_NAME is OpenSceneGraph-2.8.0 which goes a long way to explain why the name is what it is. I have been able to override it using: cpack -G DEB --config CPackConfig-libopenscenegraph.cmake -D CPACK_PACKAGE_CONTACT=rob...@openscenegraph.com -D CPACK_PACKAGE_FILE_NAME=libopenscenegraph-2.8.0.deb I don't yet have the right architecture info in the debian name, and no doubt other items aren't yet set which I'll need to add. I found the following page on the CMake/CPack wiki: http://www.vtk.org/Wiki/CMake:CPackPackageGenerators I do wonder whether there isn't some more we could be doing on the generation of the CPackConfig-* files such as setting the base name a bit more appropriately. I'm rather new to cpack and debian packaging so I'm rather floundering around a bit clueless, but that's how we start learning is it not... Feel free to point me in the right direction. In particular I'm keen to QA the packages I create, is there such a tool for debian? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] about Drawable::ComputeBoundingBoxCallback struct
Hi all osg::Drawable class declares 5 structs which can be used to implement callback functions for different purposes. Except 'ComputeBoundingBoxCallback' struct, other 4 structs inherit virtually from osg::Object class. Is there any particular reason for 'ComputeBoundingBoxCallback' struct to not inherit virtually from osg::Object or this is simply a bug? Regards Moji the Great ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi Window's users, I've tried really hard to fix all these Windows warnings, while most seem now fixed/workaround/suppressed some have resisted my attempts to remotely fix them, we me doing several unsuccessful attempts at this last persistent warnings. A fundamental problem is that I can't make a change and see whether the problem is fixed or not, this makes it really inefficient... So could a windows hack take over the attempt at fixing these warnings. Suppressing these warnings is fair game at this stage, especially if simple code changes aren't possible, suppressing a warning for a single .cpp is also note such a bad thing, especially if you use the convention set up in the include/osg/Export that allows you to switch off the disabling of the MSVC warnings. The src/osgPlugins/cfg/ConfigLexer.cpp has one such example (that doesn't seem to work... if the latest build results are correct). #if defined(_MSC_VER) defined(OSG_DISABLE_MSVC_WARNINGS) // disable '=' : conversion from 'int' to 'char', possible loss of data style warnings #pragma warning( disable : 4244) #endif Just send me the code changes that resolve these final warnings. Thanks, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] MSVC v9
I’ve submitted the bug to Microsoft. Hopefully they will be able to further enlighten us on the issue. Robert, do you thing the problem may be serious enough to possibly motivate a code change for all operators of Vec3f and co as a workaround? https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=411031 Tanguy From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Guy Wallis Sent: Monday 02 February 2009 00:04 To: OpenSceneGraph Users Subject: Spam: Re: [osg-users] MSVC v9 Hi Tanguy, I tried your code on an SGI (IRIX 6.5.22) using the GNU C++ compiler (version 2.4.3) and level 3 optimisation. No errors using either form of the subtraction operator. Cheers, Guy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSGEarth precision
David, I'll just chime in for the record to echo Robert's correct assessment -- osgEarth uses osgTerrain under the hood, and osgTerrain solves the precision issue by localizing each tile at each level of detail with a double-precision matrix. Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : +1.703.652.4791 On Wed, Feb 4, 2009 at 4:14 AM, Robert Osfield robert.osfi...@gmail.comwrote: Hi David, I haven't dived into the source code of osgEarth, but I do know that it utilises osgTerrain, and osgTerrain internally uses double to locate tiles in their geocentric position (the class that does this is the osgTerrain::Locator). When the geometry for rendering is generated on demand it's created with a local origin and then decorated with a MatrixTransform that places the tile into it's final position. Since the OSG defaults to use double Matrix for MatrixTransform and doubles for all osg::Camera management, and the cull traversal accumulates the camera + transforms in the scene using doubles, it's possible to position the tiles very accurately and maintain precision for as long as possible before passing to OpenGL. When you are close to a tile, such as driving along it the relative translations of the camera and the tile's MatrixTransform largely cancel out with little numerical errors thank's to the use of doubles, so you get the best precision where you need it most, while far away tiles have larger translations left in them so the error is higher, but this is not an issue as vertices and divide by their distance during the transformation from object to clip space so the errors seen on screen remain subpixel so you don't see them. Thanks to this system it's possible to use pre-built VirtualPlanetBuilder or dynamically generated osgEarth databases in geocentric coords without complex additional coding, it just works out of the box. Whether you'd want to use a dynamically generated database from remote data for a simulator is a different matter, one would have to look closely at the latency and consistency of download and generating tiles. Robert. On Wed, Feb 4, 2009 at 7:10 AM, David Karlsson david.karls...@foi.se wrote: Hi, Is OSGEarth suitable to use, as a part of a terrain simulator, together with objects that needs to be positioned with about cm precision - or will I run into problems with precision? I found this page about how they handled it in NASA's World Wind: http://www.urbanrobots.com/Blogs/WW/2006/01/working-to-solution-in-precision.html How is this handled in OSGEarth? Thanks, David ___ 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] modelling geodes with children?
Are you suggesting that my root would be a group node and under that would be all the leaf nodes? I don't like that idea because it loses the hierarchy: streamer is attached to grip, grip is attached to handlebar. If I delete the grip node, the streamer should go away as well. Well, I didn't really mean to forego the hierarchy and have a flat scene graph. If you really need the functionality of having the streamers disappear when you remove the grip, then by all means you should use hierarchy to achieve that. I could've implemented my HandNode using existing core functionality, but my client specifically wanted a Hand Node that they could reuse in many applications specifically for rendering a hand. If your HandlebarNode will be used in many apps to render handlebars (I don't know, maybe you intend to make a series of bicycle simulators), then yes, maybe it is best to encapsulate it in its own class. But if you are just using it as an example of some general hierarchical structure, then I doubt you want to create a new class for each unique piece of hierarchical geometry. Perhaps I'm not fully understanding your use case. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::notify replaceable backend?
On 4/2/09 7:46 PM, Filip Holm wrote: I've figured out a way to reoute all osg::notify messages to my logger, but I can't seem to find a way to get the osg::NotifySeverity mapping. Any thoughts on how this could be done is greatly appretiated. I don't believe it is possible to capture the loglevel passed to notify with the current setup. osg::notify() evaluates the given loglevel against the globally set one and only directs the stream if it matches (logLevel = globalLogLevel). It doesn't pass the loglevel on to any function you could specify. /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::notify replaceable backend?
Hi Filip,
From include/osg/Notify you have the getNotifyLevel() function...
/** Range of notify levels from DEBUG_FP through to FATAL, ALWAYS
* is reserved for forcing the absorption of all messages. The
* keywords are also used verbatim when specified by the environmental
* variable OSGNOTIFYLEVEL. See documentation on osg::notify() for
* further details.
*/
enum NotifySeverity {
ALWAYS=0,
FATAL=1,
WARN=2,
NOTICE=3,
INFO=4,
DEBUG_INFO=5,
DEBUG_FP=6
};
/** set the notify level, overriding the default or the value set by
* the environmental variable OSGNOTIFYLEVEL.
*/
extern OSG_EXPORT void setNotifyLevel(NotifySeverity severity);
/** get the notify level. */
extern OSG_EXPORT NotifySeverity getNotifyLevel();
/** is notification enabled, given the current setNotifyLevel() setting? */
extern OSG_EXPORT bool isNotifyEnabled(NotifySeverity severity);
On Wed, Feb 4, 2009 at 8:46 AM, Filip Holm filip.h...@gmail.com wrote:
Hi all,
I have a non console based application that has it's own reporting
mechanism built-in. I'd like to be able to set the NotifyLevel and
have these messages sent to my logger tool. My logger tool also has
it's own filters/log-levels, so I'd like to be able to map the
osg::NotifySeverity to some matching log-level.
I've figured out a way to reoute all osg::notify messages to my
logger, but I can't seem to find a way to get the osg::NotifySeverity
mapping. Any thoughts on how this could be done is greatly
appretiated.
What I have done to just flush all osg::notify messages to my logger is:
void main()
{
MyLoggWrapper log;
std::streambuf* notifyBuf = osg::notify().rdbuf();
osg::notify().rdbuf(log.rdbuf());
osg::notify(osg::INFO) This message is passed straight to my
logger, sadly without knowlede of NotifySeverity std::endl;
snip
//osgViewer instantiation and main loop etc.
/snip
osg::notify().rdbuf(notifyBuf);
}
Filip Holm
___
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] Different behavior between Linux and Windows when using OpenThreads::Mutex
Hi Luarance,
I believe the difference is down to pthreads not allowing two locks on
the same mutex from a single thread, while the windows equivilant
allows this - this means the standard Windows mutex is re-entrant,
whereas the pthread one isn't. To get the same behaviour as windows
under linux you have to use the OpenThreads::ReentrantMutex. You'd
use this in code that sets a lock and the recurses, such a case would
be an osgPlugin that uses a RenentrantMutex to serialize access to it,
but the mutex doesn't prevent it calling itself - a conventional Mutex
under pthreads would lock in this situation.
The Windows mutex does prevent locks from different threads being
acquired multiple times, so if you modified your code to test this it
should work the same under Windows and Pthreads/unix.
Robert.
On Wed, Feb 4, 2009 at 1:53 PM, Laurence Muller l.y.l.mul...@uva.nl wrote:
Hi,
It seems that there is a difference in behavior when using the
OpenThreads::Mutex class in Linux and Windows.
For our (crossplatform) application it is required to synchronize data
between two different threads. In order to prevent a race condition, we used
the OpenThreads mutex lock (OpenSceneGraph 2.6.1).
To test the behavior of the mutex lock, I created a small application
(attached below).
Our Linux machine produces the following output:
[laure...@fedora mutex_test]$ ./main
test 1 (trylock): ok
-- application blocked --
Using the same application under windows (compiled with mingw):
main.exe
test 1 (trylock): ok
test 2 (lock): ok
test 3 (lock again): ok
test 4 (unlock): ok
-- application finished --
The Linux version shows the correct behavior, the Windows version seems to
ignore the lock calls and does not block at all.
Questions:
1. Are additional settings required to use the OpenThreads mutex lock under
windows?
2. What alternatives are available for the OpenThreads mutex lock? (Manually
implement calls using pthread?)
Kind Regards,
- Laurence
-
// main.cpp
// g++ main.cpp -o main -I /home/userx/osg/include -L /home/userx/osg/lib
-lOpenThreads
#include stdlib.h
#include iostream
#include OpenThreads/Mutex
using namespace std;
OpenThreads::Mutex *mt_sync;
int main(int argc, char **argv)
{
mt_sync = new OpenThreads::Mutex();
printf(test 1 (trylock): );
if(mt_sync-trylock() == 0)
printf(ok\n);
else
printf(fail\n);
printf(test 2 (lock): );
if(mt_sync-lock() == 0)
printf(ok\n);
else
printf(fail\n);
printf(test 3 (lock again): );
if(mt_sync-lock() == 0)
printf(ok\n);
else
printf(fail\n);
printf(test 4 (unlock): );
if(mt_sync-unlock() == 0)
printf(ok\n);
else
printf(fail\n);
delete mt_sync;
return 0;
}
___
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.8.0-rc1 tagged, please test
Hi Robert, Built and tested with WinXP VS8 SP1, everything work as espected. Thanks for all this good work ! On Wed, Feb 4, 2009 at 3:40 PM, Robert Osfield robert.osfi...@gmail.comwrote: Hi All, We're finally one the home straight now - OpenSceneGraph-2.8 branch has been made, and the OpenSceneGraph-2.8.0-rc1 has just been created off this. News page: http://www.openscenegraph.org/projects/osg/wiki/News/Press/OSG2.8 Download page: http://www.openscenegraph.org/projects/osg/wiki/Downloads OpenSceneGraph-2.8.0-rc1 source code: source package: http://www.openscenegraph.org/downloads/developer_releases/OpenSceneGraph-2.8.0-rc1.zip svn tag: svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.0-rc1 OpenSceneGraph OpenSceneGraph-2.8 branch: svn tag: svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/branches/OpenSceneGraph-2.8 OpenSceneGraph Updates (since 2.6.1) include: ¶ * New osgVolume library for volume rendering, with support for: o High quality GPU based Ray tracing o Transfer functions o Per pixel lighting o Iso surface rendering o Maximum Intensity rendering o non power of two 3d texture and 3d texture compression o DICOM loader for reading dicom medical data * New osgAnimation library for character and scene animation. * New plugin for reading Biovision hierarchical files (.BVH) to generate character motion animations. * New osgShadow support for Light Space Perspective Shadow Maps. * Three new scene graph widgets for placing traditional 2D capability into fully interactive 3D scenes: o PDF widget support (based on libPoppler) o VNC client widget support (based on libVNCServer) o Internet browser client widget support (based on Gecko/UBrowser) * New plugins for loading Half-Life 2 maps and models. * New plugin for loaded exr, high dynamic range imagery * Improvements to DatabasePager tailored for low latency paging. * Improved runtime stats collection and on screen reporting. * Performance improvements through optimization of matrix operations. * Support for the OpenGL draw instanced extension. * Improvements to COLLADA support. * Build reporting using CDash * New packing support using CPack * A wide range of build and bug fixes Many many thanks to all those who've put in time on testing out 2.7.9 and svn/trunk, I sense that this 2.8.0-rc1 is the more ready for release snapshot we've ever done ;-) But still we can't rest if we want to make 2.8.0 the best we can... so please download/check out the OpenSceneGraph-2.8 branch or the 2.8.0-rc1 and do compile and runtime checks on as wide range of platforms as you have to hand. I would also greatly value feedback on how you own applications are performing with 2.8, if there are issues please just report them on osg-users and we can together have a bash at resolve them. For uploading of packages I have requested ftp access to the server for uploading, I let you know of the details if we can get this set up. Have fun! Robert. ___ 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] Works with 2.8 campaign :-)
Hi All, I would like to see the OSG-2.8 branch tested out across as many platforms and 3rd party applications as we can this week, as this will be the best way for us to shake down the release and make sure it's really ready to go 2.8.0 thank we can all rely upon for months to come. It occurred to me that we might be able to entice end users to come forward and give a public thumbs up that OSG-2.8 works well with their applications, it'll give some focus on the tasks of actually testing OSG-2.8 against their own applications, and it might give the community a bit of buzz knowing what applications/libraries that are out their that are using the OSG. Perhaps we could even coordinate this into a wiki page with links to those projects, with screenshots if you are up to it. Does this sound like a good idea? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] modelling geodes with children?
On Wed, Feb 4, 2009 at 10:48 AM, Paul Martz pma...@skew-matrix.com wrote: If your HandlebarNode will be used in many apps to render handlebars (I don't know, maybe you intend to make a series of bicycle simulators), then yes, maybe it is best to encapsulate it in its own class. But if you are just using it as an example of some general hierarchical structure, then I doubt you want to create a new class for each unique piece of hierarchical geometry. Perhaps I'm not fully understanding your use case. My use case was just a fabricated example (and a poor one at that). I'm working on software for mechanical equipment and I was afraid using an example from the actual domain would have been mired down in domain specific terminology. We don't have a particular arrangement of components that would be repeated, but the equipment in general does have a natural hierarchical order to it (A is connected to B is connected to C etc...). I confessed to Jean-Sebastien that the source of this notion of all-in-one nodes was HOOPS - the first scene graph tool I investigated. I'm starting to come around to the OSG viewpoint though. Not that I dislike HOOPS- it's a fantastic piece of software. It's just a little overkill for what we need. -cr ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Works with 2.8 campaign :-)
Hi Robert, Does this sound like a good idea? Definitely! :-) (when did you turn into a marketing mogul?) 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] Using cpack to create debian packages
Hi Robert, On 2/4/09, Robert Osfield robert.osfi...@gmail.com wrote: Hi All, Now that I've tagged 2.8.0-rc1 my focus has now moved on to helping out on the packaging front. The packaging that I'd like to contribute is the debian packages, so I've started down this journey by enable cpack support in the OSG, then doing: cpack -G DEB --config CPackConfig-libopenscenegraph.cmake -D CPACK_PACKAGE_CONTACT=rob...@openscenegraph.com very cool. To bad I haven't had the time to dig out the debian generator features yet. I will eventually get to improving these but as I realized that I wouldn't make it to 2-8 and that we have a man on making debian packages I dropped it for now. See http://packages.qa.debian.org/o/openscenegraph.html for status of the openscenegraph debs. It seems that he has requested help to get packages delivered and that Alberto Luaces and some others have agreed to help him. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=392266 For ubuntu it the ubuntu-MOTU developers are responsible for the openscenegreph package(s) so we might need to poke them. Which generates a OpenSceneGraph-2.8.0.deb, which is but... if I then do create a package libopenscenegraph-dev pacakge I also get an OpenSceneGraph-2.8.0.deb. Looking at the CPackConfig-libopenscenegraph.cmake I note the CPACK_PACKAGE_FILE_NAME is OpenSceneGraph-2.8.0 which goes a long way to explain why the name is what it is. I have been able to override it using: cpack -G DEB --config CPackConfig-libopenscenegraph.cmake -D CPACK_PACKAGE_CONTACT=rob...@openscenegraph.com -D CPACK_PACKAGE_FILE_NAME=libopenscenegraph-2.8.0.deb All this is due to the workaround I had to do to make the tar archives look like we wanted them with a top folder OpenSceneGraph-2.8.0 and all the different packages would sort themselves in under that. My first submission had debian-like packages names. I (or someone) will have to fix this before we can make proper debs. What you have already done (-DCPACK_PACKAGE_NAME=...) is probably a good solution that one could put in an add_custom_target. I don't yet have the right architecture info in the debian name, and no doubt other items aren't yet set which I'll need to add. I found the following page on the CMake/CPack wiki: http://www.vtk.org/Wiki/CMake:CPackPackageGenerators I do wonder whether there isn't some more we could be doing on the generation of the CPackConfig-* files such as setting the base name a bit more appropriately. I'm rather new to cpack and debian packaging so I'm rather floundering around a bit clueless, but that's how we start learning is it not... Feel free to point me in the right direction. There are some other cmake vars that are/will be used to create the control file that must be part of every deb package. I think the only one that we don't have in the CPackConfig-xxx scripts is the CPACK_DEBIAN_PACKAGE_DEPENDS ...which I have fiddled with but not enough to dare a submission. Perhaps someone more exerienced with debian cuold fill this out properly. I will need to get some information from a real package maintainer to fix this. In particular I'm keen to QA the packages I create, is there such a tool for debian? Can't help here I'm afraid. I see that this mail didn't help much at all but telling you things you already know :-( So to try and help I mailed some questions to the ubuntu-motu developers mailing list asking how we can help getting osg-2.8 into ubuntu packages adn will persue that. For debian perhaps Alberto Luaces or someone else can fill us in on how the debian package is doing and if any further help is needed. cheers 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] Multiple GPU
Hi Ufuk, You can look at Distributed-OSG-Thesis.pdf in http://www.openscenegraph.org/projects/osg/attachment/wiki/Support/Tutorials/OSG_Tutorial_Ball.zipIt would help you. Kolay Gelsin :) Saygilar. 2009/2/4 Sewell, Kenneth R Civ USAF AFMC AFRL/RYZW kenneth.sew...@wpafb.af.mil Just to offer an alternative setup... We have OSG running a system of 6 screens representing a single view. The solution we chose was to use a single 8800 GTX and two of the matrox triple-head-to-go devices. Nvidia's twinview lets us treat it as one big screen of resolution 3840x2048, which makes for a very simple setup in OSG. By adding another card you could easily get the number of screens you require. - Ken. I have to do a simulation project which needs 8 screens. This system likes a dome. so i want to ask few questions about this: 1) i want to use multiple gpu's. So is there a limit on number of gpu's on a pc? i saw 4 gpu's on a pc and every gpu has 2 outputs. can i render 8 screen with viewer? 2) how can i set which gpu render which screen. is there an auto management system in viewer? if i have screens which have resolutions like 8x1280x1024 or 4x2560x1024 or any other combination of this, should i do an extra thing for this? 3) do you think i will have a critical frame rate problem if i render 8 screens. ___ 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 -- Ümit Uzun ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.0-rc1 tagged, please test
Robert Osfield wrote: But still we can't rest if we want to make 2.8.0 the best we can... so please download/check out the OpenSceneGraph-2.8 branch or the 2.8.0-rc1 and do compile and runtime checks on as wide range of platforms as you have to hand. I would also greatly value feedback on how you own applications are performing with 2.8, if there are issues please just report them on osg-users and we can together have a bash at resolve them. Builds with zero warnings on Red Hat Enterprise 5.3, even with our tired old CMake 2.4.5 ;-) Only minor glitch with the build is that I have to pass -march=i686 in CXXFLAGS for OpenThreads to configure properly to use GCC_BUILTINS. I think this was covered in another thread a few months back. Even if I don't do this, it works fine running with mutexes. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 2.8: XUL not completely found
HI Paul, There is pkg-config support in CMake, but I don't know how flexible it is. BTW, what happens on your Gentoo system? Does the half found XUL cause a build failure or does the gecko plugin simply not compile? Robert. On Wed, Feb 4, 2009 at 6:22 PM, Paul Melis osg-us...@assumetheposition.nl wrote: I just noticed (on a Gentoo system) that not all of the parts of XUL are found by CMake. Some of the include directories and libraries are not among the ones in FindXUL.cmake. There does seem to be pkg-config support for it though: # nsEmbedAPI.h pkg-config libxul-embedding --cflags # jsapi.h pkg-config xulrunner-js --cflags # prtypes.h pkg-config xulrunner-nspr --cflags Does CMake have support for parsing the output of pkg-config? Paul ___ 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] About OpenGL materials
Hi all, I have a question about OpenGL materials. From what I can see, if I disable GL_LIGHTING in the stateset of an object, then that object is rendered with the colors specified in its color array only, i.e. the material has no effect. Is there a way to change that? The effect I want is that the object be unaffected by lighting but still has colors according to its material, i.e. even if no light is present in the scene, or if there is only a spotlight but it is not pointing toward the object, its color is defined by its material. The reason I can't just specify the colors in the color array is that then, if I use scribe or outline effects (using osgFX::Effect), the wireframe overlay or outline takes on the vertex colors too instead of being white (or the color I specify). If there's a way to force the scribe to be white (i.e. not use the object's vertex colors) that would work too even though it's the reverse of what I'm asking... Any suggestions would be appreciated. I've never quite understood the intricacies of how OpenGL handles vertex colors, materials, shading and even textures (when one takes precedence over the other, etc.) so I'd like the advice of someone who knows more than me in this respect. Thanks, 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] About OpenGL materials
Hi JS, The OSG is designed around separating geometry data (in Drawables) from state data (in StateSets), the usage model you are suggesting mixing this, and this would struggle in anything other than models that don't have any colour arrays assigned to them, otherwise the local geometry colour array would just override that you provide by the StateSet. Consider that the OSG by default display lists geometry and you can see that the problem isn't one that you can fix easily. However if you carefully manage your scene graph so that the subgraph you are decorating contains no colour arrays then you could define a custom StateAttribute that sets the vertex colour. Robert. On Wed, Feb 4, 2009 at 7:13 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi all, I have a question about OpenGL materials. From what I can see, if I disable GL_LIGHTING in the stateset of an object, then that object is rendered with the colors specified in its color array only, i.e. the material has no effect. Is there a way to change that? The effect I want is that the object be unaffected by lighting but still has colors according to its material, i.e. even if no light is present in the scene, or if there is only a spotlight but it is not pointing toward the object, its color is defined by its material. The reason I can't just specify the colors in the color array is that then, if I use scribe or outline effects (using osgFX::Effect), the wireframe overlay or outline takes on the vertex colors too instead of being white (or the color I specify). If there's a way to force the scribe to be white (i.e. not use the object's vertex colors) that would work too even though it's the reverse of what I'm asking... Any suggestions would be appreciated. I've never quite understood the intricacies of how OpenGL handles vertex colors, materials, shading and even textures (when one takes precedence over the other, etc.) so I'd like the advice of someone who knows more than me in this respect. Thanks, 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] About OpenGL materials
No in straight OSG/OGL No Lighting = No Material You probably could do this with in a shader but you would have to replicate the full fixed pipeline calculation of lighting,materials, textures , fogs etc ( which you have to do anyway ) Gordon __ Gordon Tomlinson Product Manager 3D Email : gtomlinson @ overwatch.textron.com __ (C): (+1) 571-265-2612 (W): (+1) 703-437-7651 Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival - Master Tambo Tetsura -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien Guay Sent: Wednesday, February 04, 2009 2:14 PM To: OpenSceneGraph Users Subject: [osg-users] About OpenGL materials Hi all, I have a question about OpenGL materials. From what I can see, if I disable GL_LIGHTING in the stateset of an object, then that object is rendered with the colors specified in its color array only, i.e. the material has no effect. Is there a way to change that? The effect I want is that the object be unaffected by lighting but still has colors according to its material, i.e. even if no light is present in the scene, or if there is only a spotlight but it is not pointing toward the object, its color is defined by its material. The reason I can't just specify the colors in the color array is that then, if I use scribe or outline effects (using osgFX::Effect), the wireframe overlay or outline takes on the vertex colors too instead of being white (or the color I specify). If there's a way to force the scribe to be white (i.e. not use the object's vertex colors) that would work too even though it's the reverse of what I'm asking... Any suggestions would be appreciated. I've never quite understood the intricacies of how OpenGL handles vertex colors, materials, shading and even textures (when one takes precedence over the other, etc.) so I'd like the advice of someone who knows more than me in this respect. Thanks, 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] About OpenGL materials
Jean-Sébastien Guay wrote: The reason I can't just specify the colors in the color array is that then, if I use scribe or outline effects (using osgFX::Effect), the wireframe overlay or outline takes on the vertex colors too instead of being white (or the color I specify). If there's a way to force the scribe to be white (i.e. not use the object's vertex colors) that would work too even though it's the reverse of what I'm asking... The osgscribe example seems to include code that specifies the color of the wireframe (but in the else branch of an #if 1 ...). Is that what you're looking for? Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn/trunk ready to make OpenSceneGraph-2.8 branch, please do last build test of snv/trunk :-)
Hi JS, Thanks for the warning fixes, I've merged about 2/3rds of them, but will record some of the other ones. The server isn't accessible right now so I'm not able to check in right now. I'll have bash tomorrow morning. These last warning fixes won't affect runtime at all so the 2.8.0-rc1 as it stands right now should be good enough for testing. Robert. On Wed, Feb 4, 2009 at 5:44 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Robert, As I said on my other post, I don't seem to get any warnings (other than can't open build log for writing, which is weird but benign - the warnings if any would still go to stdout and thus get reported in the CDash warnings page for the build). I'll try another full rebuild and see for sure. Then if I get any I'll see what needs to be done. OK, I've had a go at fixing the warnings. I've attached a zip containing the build output before the fixes for you to see, as well as the changed files. The PDB warnings (which come from the fact that a given 3rd party library was compiled with debug information split into a separate file instead of embedded into the library) we can just ignore. They only happen at link time for the given plugin. Same thing for the default library MSVCRT conflicts... warning, though that might indicate a bigger problem. The next time someone makes a 3rd party package, those things should be taken care of. Other than that, here are the warnings I fixed: ___ osgUtil.lib and osglauncher example 4C:\Tools\msvs8\VC\include\list(42) : warning C4510: 'std::_List_nod_Ty,_Alloc::_Node' : default constructor could not be generated (and other similar and related warnings) Simply adding an empty default constructor to the arc class in TriStrip_graph_array.h and the Xample class in osglauncher.cpp fixed this You could see that std::list was not the problem, but the class used as a template argument, because lower in the warning message there was mention of 4 c:\dev\openscenegraph-svn\openscenegraph-2.8-branch\src\osgutil\TriStrip_graph_array.h(109) : see reference to class template instantiation 'std::list_Ty' being compiled 4with 4[ 4 _Ty=triangle_stripper::common_structures::graph_arraytriangle_stripper::triangle,char::arc 4] which pointed to the type to which a default constructor needed to be added. It comes down to deciphering VS's messages... :-) ___ osga plugin 198..\..\..\..\src\osgPlugins\osga\OSGA_Archive.cpp(727) : warning C4512: 'OSGA_Archive::WriteObjectFunctor' : assignment operator could not be generated 198..\..\..\..\src\osgPlugins\osga\OSGA_Archive.cpp(719) : see declaration of 'OSGA_Archive::WriteObjectFunctor' (and so on for the other Write*Functors) I didn't find any way to fix this other than locally suppressing it, since creating a default constructor would imply constructing a default osg::Object, which is abstract so I can't do that. So I suppressed it around those 4 classes. ___ cfg plugin and osgviewerGLUT example You had tried suppressing warnings in these two cases, protected by #if defined(_MSC_VER) defined(OSG_DISABLE_MSVC_WARNINGS) but you needed to include osg/Config before that, so that OSG_DISABLE_MSVC_WARNINGS was defined... ___ osgviewerQT example 26c:\tools\qt\4.4.3\include\qtcore\../../src/corelib/concurrent/qtconcurrentiteratekernel.h(97) : warning C4512: 'QtConcurrent::BlockSizeManager' : assignment operator could not be generated 26 c:\tools\qt\4.4.3\include\qtcore\../../src/corelib/concurrent/qtconcurrentiteratekernel.h(79) : see declaration of 'QtConcurrent::BlockSizeManager' Since this is in Qt's headers, I just suppressed this locally (for both Qt 4 and Qt 3 - I'm using Qt 4 and I have no way of knowing if this appears for Qt 3). ___ I'm doing a full rebuild now (and as you all know now thanks to the dashboard reports, this takes 20 minutes on my machine if nothing else is happening) so I'll tell you when this is done if any fixable warnings remain, but I think it should look good. Of course as we can see from osgviewerQT, there are perhaps warnings lurking in other examples/plugins which I don't compile... Others will have to pitch in for fixing those. 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
Re: [osg-users] OpenSceneGraph-2.8.0-rc1 tagged, please test
I built everything with Visual Studio 2005 on XP with no build problems. One minor glitch that may be my fault- when I ran the built the INSTALL target, it copied the executables to C:\Program Files\OpenSceneGraph rather than C:\Program Files\OpenSceneGraph-2.8 (I specified this in CMake). Cory On Wed, Feb 4, 2009 at 12:50 PM, Jason Daly jd...@ist.ucf.edu wrote: Robert Osfield wrote: But still we can't rest if we want to make 2.8.0 the best we can... so please download/check out the OpenSceneGraph-2.8 branch or the 2.8.0-rc1 and do compile and runtime checks on as wide range of platforms as you have to hand. I would also greatly value feedback on how you own applications are performing with 2.8, if there are issues please just report them on osg-users and we can together have a bash at resolve them. Builds with zero warnings on Red Hat Enterprise 5.3, even with our tired old CMake 2.4.5 ;-) Only minor glitch with the build is that I have to pass -march=i686 in CXXFLAGS for OpenThreads to configure properly to use GCC_BUILTINS. I think this was covered in another thread a few months back. Even if I don't do this, it works fine running with mutexes. --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] OpenSceneGraph-2.8.0-rc1 tagged, please test
Done: Experimental build on SUKENDER1, rev 9652 (2.8 branch), VC8sp1 express, all inclusive, CMake cache cleared, full release rebuild. See the dashboard for details. Unfortunately, it has 50 warnings. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Wed, 04 Feb 2009 15:40:21 +0100, Robert Osfield robert.osfi...@gmail.com a écrit: Hi All, We're finally one the home straight now - OpenSceneGraph-2.8 branch has been made, and the OpenSceneGraph-2.8.0-rc1 has just been created off this. News page: http://www.openscenegraph.org/projects/osg/wiki/News/Press/OSG2.8 Download page: http://www.openscenegraph.org/projects/osg/wiki/Downloads OpenSceneGraph-2.8.0-rc1 source code: source package: http://www.openscenegraph.org/downloads/developer_releases/OpenSceneGraph-2.8.0-rc1.zip svn tag: svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.0-rc1 OpenSceneGraph OpenSceneGraph-2.8 branch: svn tag: svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/branches/OpenSceneGraph-2.8 OpenSceneGraph Updates (since 2.6.1) include: ¶ * New osgVolume library for volume rendering, with support for: o High quality GPU based Ray tracing o Transfer functions o Per pixel lighting o Iso surface rendering o Maximum Intensity rendering o non power of two 3d texture and 3d texture compression o DICOM loader for reading dicom medical data * New osgAnimation library for character and scene animation. * New plugin for reading Biovision hierarchical files (.BVH) to generate character motion animations. * New osgShadow support for Light Space Perspective Shadow Maps. * Three new scene graph widgets for placing traditional 2D capability into fully interactive 3D scenes: o PDF widget support (based on libPoppler) o VNC client widget support (based on libVNCServer) o Internet browser client widget support (based on Gecko/UBrowser) * New plugins for loading Half-Life 2 maps and models. * New plugin for loaded exr, high dynamic range imagery * Improvements to DatabasePager tailored for low latency paging. * Improved runtime stats collection and on screen reporting. * Performance improvements through optimization of matrix operations. * Support for the OpenGL draw instanced extension. * Improvements to COLLADA support. * Build reporting using CDash * New packing support using CPack * A wide range of build and bug fixes Many many thanks to all those who've put in time on testing out 2.7.9 and svn/trunk, I sense that this 2.8.0-rc1 is the more ready for release snapshot we've ever done ;-) But still we can't rest if we want to make 2.8.0 the best we can... so please download/check out the OpenSceneGraph-2.8 branch or the 2.8.0-rc1 and do compile and runtime checks on as wide range of platforms as you have to hand. I would also greatly value feedback on how you own applications are performing with 2.8, if there are issues please just report them on osg-users and we can together have a bash at resolve them. For uploading of packages I have requested ftp access to the server for uploading, I let you know of the details if we can get this set up. Have fun! 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] 2.8: XUL not completely found
Hi Robert,
Here's an updated FindXUL.cmake that works for me. It uses pkg-config to
discover some extra paths.
Now osgbrowser google.com works for me!
Two remarks:
- It doesn't do any version checks, although the pkg-config CMake macros
are capable of this (but I don't know if there are any version reqs)
- The paths discovered with pkg-config are put in the front of the
existing lists
Paul
Robert Osfield wrote:
HI Paul,
There is pkg-config support in CMake, but I don't know how flexible it is.
BTW, what happens on your Gentoo system? Does the half found XUL
cause a build failure or does the gecko plugin simply not compile?
Robert.
On Wed, Feb 4, 2009 at 6:22 PM, Paul Melis
osg-us...@assumetheposition.nl wrote:
I just noticed (on a Gentoo system) that not all of the parts of XUL are
found by CMake.
Some of the include directories and libraries are not among the ones in
FindXUL.cmake.
There does seem to be pkg-config support for it though:
# nsEmbedAPI.h
pkg-config libxul-embedding --cflags
# jsapi.h
pkg-config xulrunner-js --cflags
# prtypes.h
pkg-config xulrunner-nspr --cflags
Does CMake have support for parsing the output of pkg-config?
Paul
___
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
# Locate gdal
# This module defines
# XUL_LIBRARIES
# XUL_FOUND, if false, do not try to link to gdal
# XUL_INCLUDE_DIR, where to find the headers
#
# $XUL_DIR is an environment variable that would
# correspond to the ./configure --prefix=$XUL_DIR
#
# Created by Robert Osfield.
FIND_PATH(XUL_INCLUDE_DIR nsEmbedAPI.h
$ENV{OSG_DIR}/include/xulrunner
$ENV{OSG_DIR}/include
$ENV{OSG_DIR}/xulrunner
$ENV{OSG_DIR}
$ENV{OSGDIR}/include/xulrunner
$ENV{OSGDIR}/include
$ENV{OSGDIR}/xulrunner
$ENV{OSGDIR}
$ENV{OSG_ROOT}/include/xulrunner
$ENV{OSG_ROOT}/include
~/Library/Frameworks
/Library/Frameworks
/usr/local/include/xulrunner
/usr/local/include
/usr/include/xulrunner
/usr/include
/sw/include/xulrunner # Fink
/sw/include # Fink
/opt/local/include/xulrunner # DarwinPorts
/opt/local/include # DarwinPorts
/opt/csw/include/xulrunner # Blastwave
/opt/csw/include # Blastwave
/opt/include/xulrunner
/opt/include
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session\
Manager\\Environment;OSG_ROOT]/include/xulrunner
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session\
Manager\\Environment;OSG_ROOT]/include
/usr/freeware/include/xulrunner
/usr/freeware/include
)
FIND_PATH(NSPR_INCLUDE_DIR prtypes.h
$ENV{OSG_DIR}/include/nspr
$ENV{OSG_DIR}/include
$ENV{OSG_DIR}/nspr
$ENV{OSG_DIR}
$ENV{OSGDIR}/include/nspr
$ENV{OSGDIR}/include
$ENV{OSGDIR}/nspr
$ENV{OSGDIR}
$ENV{OSG_ROOT}/include/nspr
$ENV{OSG_ROOT}/include
~/Library/Frameworks
/Library/Frameworks
/usr/local/include/nspr
/usr/local/include
/usr/include/nspr
/usr/include
/sw/include/nspr # Fink
/sw/include # Fink
/opt/local/include/nspr # DarwinPorts
/opt/local/include # DarwinPorts
/opt/csw/include/nspr # Blastwave
/opt/csw/include # Blastwave
/opt/include/nspr
/opt/include
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session\
Manager\\Environment;OSG_ROOT]/include/nspr
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session\
Manager\\Environment;OSG_ROOT]/include
/usr/freeware/include/nspr
/usr/freeware/include
)
FIND_PATH(MOZJS_INCLUDE_DIR jsapi.h
$ENV{OSG_DIR}/include/mozjs
$ENV{OSG_DIR}/include
$ENV{OSG_DIR}/mozjs
$ENV{OSG_DIR}
$ENV{OSGDIR}/include/mozjs
$ENV{OSGDIR}/include
$ENV{OSGDIR}/mozjs
$ENV{OSGDIR}
$ENV{OSG_ROOT}/include/mozjs
$ENV{OSG_ROOT}/include
~/Library/Frameworks
/Library/Frameworks
/usr/local/include/mozjs
/usr/local/include
/usr/include/mozjs
/usr/include
/sw/include/mozjs # Fink
/sw/include # Fink
/opt/local/include/mozjs # DarwinPorts
/opt/local/include # DarwinPorts
/opt/csw/include/mozjs # Blastwave
/opt/csw/include # Blastwave
/opt/include/mozjs
/opt/include
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session\
Manager\\Environment;OSG_ROOT]/include/mozjs
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session\
Manager\\Environment;OSG_ROOT]/include
/usr/freeware/include/mozjs
/usr/freeware/include
)
FIND_PATH(XUL_DIR
NAMES components/appshell.xpt
PATHS
$ENV{OSG_DIR}/lib
$ENV{OSG_DIR}
$ENV{OSGDIR}/lib
$ENV{OSGDIR}
$ENV{OSG_ROOT}/lib
~/Library/Frameworks
[osg-users] osgPango (Stop Worrying Love The Bomb)
Hello all. Before I start hacking on osgWidget again full force (in preparation for OSG-2.9 or OSG-3.0) I wanted to continue peddling my wares here and generating interest in a different (BUT RELATED) project of mine called osgPango. Basically, I'm writing osgPango to achieve the following (in order): 1. TOP quality 2D fonts in OSG on all supported platforms. 2. A sophisticated layout/markup system for complicated text. 3. An extensible rendering backend that lets users create callbacks for the actual rendering of the font character. 4. Speed, speed, and more speed. 5. Clean and intuitive API that exposes all elements of a body of text (the position of each character, etc.) Goals 1, 2, and 3 are accomplished; 4 and 5 are debatable. Lets get started with some obligatory screenshots: http://cubicool.plopbyte.net/osgPango-normal.png Here is some undecorated text (no shadows or outlines) showing one of Robert's posts from earlier this week. Notice how the text is justified to a certain width, and that it is no problem for osgPango to change font style or color midway through a sentence or word! Also notice the font quality, where no character is missing a pixel on any side and straight vertical lines are sharp and not smudged along two pixels. http://cubicool.plopbyte.net/osgPango-shadow.png Same as the above screenshot, except that the paragraph width is shortened and there are now +1, +1 drop shadows (their offset is configurable). http://cubicool.plopbyte.net/osgPango-outline.png Here we change our alignment to RIGHT and add 1px black outlines to the fonts. I'd like to get other people who need high-quality 2D fonts to start keeping an eye on osgPango so I can start seeing how folks want to use and extend it's feature set (where possible). I've tested it personally on Linux and Vista 64, but I'd need someone else to try it on Mac. (As an aside, it should use the ATSUI backend on Mac, giving some pretty nice font quality! It uses FreeType on Linux and ClearType on Windows; to get it compile on Windows I simply used the binaries from the GTK project) The main osgPango website is here: http://osgpango.googlecode.com It won't be long before I consider it done (for me) and move back to osgWidget and start helping more with osgAnimation, so let me know soon if you're interested and need it to do something it doesn't. :) With time I hope to be able to get osgPango in the core and replace osgText, but we'll have to see. :) The advanced layout powers and pluggable rendering backends are two things it would be VERY hard to add to osgText. As far as speed is concerned, osgPango is currently just as fast as osgText for most normal usage, though obviously every time you change font families or color or size you introduce a state change. :) Placeholder code is also in place for someone to add a GLSL shader to do the multitexturing instead of the complicated osg::TexEnvCombine() object I currently use, and I'm sure we'd see some significant speed increases there as well (when effects are used or desired). ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.0-rc1 tagged, please test
Hi Cory, I built everything with Visual Studio 2005 on XP with no build problems. One minor glitch that may be my fault- when I ran the built the INSTALL target, it copied the executables to C:\Program Files\OpenSceneGraph rather than C:\Program Files\OpenSceneGraph-2.8 (I specified this in CMake). Are you sure you changed CMAKE_INSTALL_PREFIX to C:\Program Files\OpenSceneGraph-2.8 ? If you checked out the 2.8 branch to a new empty directory, the cache would have been empty so you would have had to change it again. I always use a different CMAKE_INSTALL_PREFIX than the default, and it works well for me, which is why I suggest you re-check the setting... If it's really set to what you say, then there might be some other problem. 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] osgPango (Stop Worrying Love The Bomb)
Just awesome Jeremy Moles wrote: Hello all. Before I start hacking on osgWidget again full force (in preparation for OSG-2.9 or OSG-3.0) I wanted to continue peddling my wares here and generating interest in a different (BUT RELATED) project of mine called osgPango. Basically, I'm writing osgPango to achieve the following (in order): 1. TOP quality 2D fonts in OSG on all supported platforms. 2. A sophisticated layout/markup system for complicated text. 3. An extensible rendering backend that lets users create callbacks for the actual rendering of the font character. 4. Speed, speed, and more speed. 5. Clean and intuitive API that exposes all elements of a body of text (the position of each character, etc.) Goals 1, 2, and 3 are accomplished; 4 and 5 are debatable. Lets get started with some obligatory screenshots: http://cubicool.plopbyte.net/osgPango-normal.png Here is some undecorated text (no shadows or outlines) showing one of Robert's posts from earlier this week. Notice how the text is justified to a certain width, and that it is no problem for osgPango to change font style or color midway through a sentence or word! Also notice the font quality, where no character is missing a pixel on any side and straight vertical lines are sharp and not smudged along two pixels. http://cubicool.plopbyte.net/osgPango-shadow.png Same as the above screenshot, except that the paragraph width is shortened and there are now +1, +1 drop shadows (their offset is configurable). http://cubicool.plopbyte.net/osgPango-outline.png Here we change our alignment to RIGHT and add 1px black outlines to the fonts. I'd like to get other people who need high-quality 2D fonts to start keeping an eye on osgPango so I can start seeing how folks want to use and extend it's feature set (where possible). I've tested it personally on Linux and Vista 64, but I'd need someone else to try it on Mac. (As an aside, it should use the ATSUI backend on Mac, giving some pretty nice font quality! It uses FreeType on Linux and ClearType on Windows; to get it compile on Windows I simply used the binaries from the GTK project) The main osgPango website is here: http://osgpango.googlecode.com It won't be long before I consider it done (for me) and move back to osgWidget and start helping more with osgAnimation, so let me know soon if you're interested and need it to do something it doesn't. :) With time I hope to be able to get osgPango in the core and replace osgText, but we'll have to see. :) The advanced layout powers and pluggable rendering backends are two things it would be VERY hard to add to osgText. As far as speed is concerned, osgPango is currently just as fast as osgText for most normal usage, though obviously every time you change font families or color or size you introduce a state change. :) Placeholder code is also in place for someone to add a GLSL shader to do the multitexturing instead of the complicated osg::TexEnvCombine() object I currently use, and I'm sure we'd see some significant speed increases there as well (when effects are used or desired). ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- +33 (0) 6 63 20 03 56 Cedric Pinson mailto:morni...@plopbyte.net http://www.plopbyte.net ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.0-rc1 tagged, please test
On Wed, 2009-02-04 at 14:40 +, Robert Osfield wrote: Hi All, We're finally one the home straight now - OpenSceneGraph-2.8 branch has been made, and the OpenSceneGraph-2.8.0-rc1 has just been created off this. News page: http://www.openscenegraph.org/projects/osg/wiki/News/Press/OSG2.8 Download page: http://www.openscenegraph.org/projects/osg/wiki/Downloads OpenSceneGraph-2.8.0-rc1 source code: source package: http://www.openscenegraph.org/downloads/developer_releases/OpenSceneGraph-2.8.0-rc1.zip svn tag: svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.0-rc1 OpenSceneGraph OpenSceneGraph-2.8 branch: svn tag: svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/branches/OpenSceneGraph-2.8 OpenSceneGraph Updates (since 2.6.1) include: ¶ * New osgVolume library for volume rendering, with support for: o High quality GPU based Ray tracing o Transfer functions o Per pixel lighting o Iso surface rendering o Maximum Intensity rendering o non power of two 3d texture and 3d texture compression o DICOM loader for reading dicom medical data * New osgAnimation library for character and scene animation. * New plugin for reading Biovision hierarchical files (.BVH) to generate character motion animations. * New osgShadow support for Light Space Perspective Shadow Maps. * Three new scene graph widgets for placing traditional 2D capability into fully interactive 3D scenes: o PDF widget support (based on libPoppler) o VNC client widget support (based on libVNCServer) o Internet browser client widget support (based on Gecko/UBrowser) * New plugins for loading Half-Life 2 maps and models. * New plugin for loaded exr, high dynamic range imagery * Improvements to DatabasePager tailored for low latency paging. * Improved runtime stats collection and on screen reporting. * Performance improvements through optimization of matrix operations. * Support for the OpenGL draw instanced extension. * Improvements to COLLADA support. * Build reporting using CDash * New packing support using CPack * A wide range of build and bug fixes Many many thanks to all those who've put in time on testing out 2.7.9 and svn/trunk, I sense that this 2.8.0-rc1 is the more ready for release snapshot we've ever done ;-) But still we can't rest if we want to make 2.8.0 the best we can... so please download/check out the OpenSceneGraph-2.8 branch or the 2.8.0-rc1 and do compile and runtime checks on as wide range of platforms as you have to hand. I would also greatly value feedback on how you own applications are performing with 2.8, if there are issues please just report them on osg-users and we can together have a bash at resolve them. For uploading of packages I have requested ftp access to the server for uploading, I let you know of the details if we can get this set up. The warning is gone! :) Wee! (The one from ViewerEventHandlers::InteractiveImageHandler) Happy day... Have fun! 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] OpenSceneGraph-2.8.0-rc1 tagged, please test
Yeah, I started wondering if I built the wrong source tree. I started the whole process over again and should know pretty soon. Even on a 4-core machine, it takes a while to build everything (but at least the build process can mostly run in parallel). Cory On Wed, Feb 4, 2009 at 2:21 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi again Cory, I always use a different CMAKE_INSTALL_PREFIX than the default, and it works well for me, which is why I suggest you re-check the setting... If it's really set to what you say, then there might be some other problem. Just out of curiosity I checked myself and here's what I got: 1-- Build started: Project: INSTALL, Configuration: Debug Win32 -- 1 1Performing Post-Build Event... 1-- Install configuration: Debug 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/doc/OpenSceneGraphReferenceDocs 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/doc/OpenSceneGraphReferenceDocs/osg32-32.png 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/doc/OpenThreadsReferenceDocs 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/doc/OpenThreadsReferenceDocs/osg32-32.png 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/pkgconfig/openscenegraph.pc 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/pkgconfig/openthreads.pc 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/OpenThreadsd.lib 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/ot11-OpenThreadsd.dll 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/include/OpenThreads/Config 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgd.lib 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgd.dll 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/include/osg/Config 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgDBd.lib 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgDBd.dll 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgUtild.lib 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgUtild.dll 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgGAd.lib 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgGAd.dll 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgTextd.lib 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgTextd.dll 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgViewerd.lib 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgViewerd.dll 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/include/osgViewer/GraphicsWindowWin32 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/include/osgViewer/PixelBufferWin32 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgAnimationd.lib 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgAnimationd.dll 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgFXd.lib 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgFXd.dll 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgManipulatord.lib 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgManipulatord.dll 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgParticled.lib 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgParticled.dll 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgShadowd.lib 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgShadowd.dll 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgSimd.lib 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgSimd.dll 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgTerraind.lib 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgTerraind.dll 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgWidgetd.lib 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgWidgetd.dll 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgVolumed.lib 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgVolumed.dll 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osgPlugins-2.8.0/osgdb_osganimationd.dll 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osgPlugins-2.8.0/osgdb_osgfxd.dll 1-- Installing:
Re: [osg-users] OpenSceneGraph-2.8.0-rc1 tagged, please test
Hi Cory, Yeah, I started wondering if I built the wrong source tree. I started the whole process over again and should know pretty soon. You could have just re-run the CMake GUI to see the value CMAKE_INSTALL_PREFIX was set to... Even on a 4-core machine, it takes a while to build everything (but at least the build process can mostly run in parallel). Yes, it's about 20 minutes on my Quad-core Windows machine (if you don't enable wrappers...). On Linux it's quicker (much quicker for those lucky owners of Core i7 machines, eh Robert?). 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] OpenSceneGraph-2.8.0-rc1 tagged, please test
Sorry for the false alarm. I rebuilt everything and and it seems to be working. Cory On Wed, Feb 4, 2009 at 2:45 PM, Cory Riddell c...@codeware.com wrote: Yeah, I started wondering if I built the wrong source tree. I started the whole process over again and should know pretty soon. Even on a 4-core machine, it takes a while to build everything (but at least the build process can mostly run in parallel). Cory On Wed, Feb 4, 2009 at 2:21 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi again Cory, I always use a different CMAKE_INSTALL_PREFIX than the default, and it works well for me, which is why I suggest you re-check the setting... If it's really set to what you say, then there might be some other problem. Just out of curiosity I checked myself and here's what I got: 1-- Build started: Project: INSTALL, Configuration: Debug Win32 -- 1 1Performing Post-Build Event... 1-- Install configuration: Debug 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/doc/OpenSceneGraphReferenceDocs 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/doc/OpenSceneGraphReferenceDocs/osg32-32.png 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/doc/OpenThreadsReferenceDocs 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/doc/OpenThreadsReferenceDocs/osg32-32.png 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/pkgconfig/openscenegraph.pc 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/pkgconfig/openthreads.pc 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/OpenThreadsd.lib 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/ot11-OpenThreadsd.dll 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/include/OpenThreads/Config 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgd.lib 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgd.dll 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/include/osg/Config 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgDBd.lib 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgDBd.dll 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgUtild.lib 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgUtild.dll 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgGAd.lib 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgGAd.dll 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgTextd.lib 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgTextd.dll 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgViewerd.lib 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgViewerd.dll 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/include/osgViewer/GraphicsWindowWin32 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/include/osgViewer/PixelBufferWin32 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgAnimationd.lib 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgAnimationd.dll 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgFXd.lib 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgFXd.dll 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgManipulatord.lib 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgManipulatord.dll 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgParticled.lib 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgParticled.dll 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgShadowd.lib 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgShadowd.dll 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgSimd.lib 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgSimd.dll 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgTerraind.lib 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgTerraind.dll 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgWidgetd.lib 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgWidgetd.dll 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/lib/osgVolumed.lib 1-- Installing: C:/Dev/OpenSceneGraph-SVN/OpenSceneGraph-2.8-branch/bin/osg55-osgVolumed.dll 1-- Installing:
Re: [osg-users] osgPango (Stop Worrying Love The Bomb)
Looks cool. Gordon __ Gordon Tomlinson Product Manager 3D Email : gtomlinson @ overwatch.textron.com __ (C): (+1) 571-265-2612 (W): (+1) 703-437-7651 Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival - Master Tambo Tetsura -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jeremy Moles Sent: Wednesday, February 04, 2009 3:15 PM To: osg-users@lists.openscenegraph.org Subject: [osg-users] osgPango (Stop Worrying Love The Bomb) Hello all. Before I start hacking on osgWidget again full force (in preparation for OSG-2.9 or OSG-3.0) I wanted to continue peddling my wares here and generating interest in a different (BUT RELATED) project of mine called osgPango. Basically, I'm writing osgPango to achieve the following (in order): 1. TOP quality 2D fonts in OSG on all supported platforms. 2. A sophisticated layout/markup system for complicated text. 3. An extensible rendering backend that lets users create callbacks for the actual rendering of the font character. 4. Speed, speed, and more speed. 5. Clean and intuitive API that exposes all elements of a body of text (the position of each character, etc.) Goals 1, 2, and 3 are accomplished; 4 and 5 are debatable. Lets get started with some obligatory screenshots: http://cubicool.plopbyte.net/osgPango-normal.png Here is some undecorated text (no shadows or outlines) showing one of Robert's posts from earlier this week. Notice how the text is justified to a certain width, and that it is no problem for osgPango to change font style or color midway through a sentence or word! Also notice the font quality, where no character is missing a pixel on any side and straight vertical lines are sharp and not smudged along two pixels. http://cubicool.plopbyte.net/osgPango-shadow.png Same as the above screenshot, except that the paragraph width is shortened and there are now +1, +1 drop shadows (their offset is configurable). http://cubicool.plopbyte.net/osgPango-outline.png Here we change our alignment to RIGHT and add 1px black outlines to the fonts. I'd like to get other people who need high-quality 2D fonts to start keeping an eye on osgPango so I can start seeing how folks want to use and extend it's feature set (where possible). I've tested it personally on Linux and Vista 64, but I'd need someone else to try it on Mac. (As an aside, it should use the ATSUI backend on Mac, giving some pretty nice font quality! It uses FreeType on Linux and ClearType on Windows; to get it compile on Windows I simply used the binaries from the GTK project) The main osgPango website is here: http://osgpango.googlecode.com It won't be long before I consider it done (for me) and move back to osgWidget and start helping more with osgAnimation, so let me know soon if you're interested and need it to do something it doesn't. :) With time I hope to be able to get osgPango in the core and replace osgText, but we'll have to see. :) The advanced layout powers and pluggable rendering backends are two things it would be VERY hard to add to osgText. As far as speed is concerned, osgPango is currently just as fast as osgText for most normal usage, though obviously every time you change font families or color or size you introduce a state change. :) Placeholder code is also in place for someone to add a GLSL shader to do the multitexturing instead of the complicated osg::TexEnvCombine() object I currently use, and I'm sure we'd see some significant speed increases there as well (when effects are used or desired). ___ 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
Re: [osg-users] OpenSceneGraph-2.8.0-rc1 tagged, please test
Hi Sukender, Done: Experimental build on SUKENDER1, rev 9652 (2.8 branch), VC8sp1 express, all inclusive, CMake cache cleared, full release rebuild. See the dashboard for details. Unfortunately, it has 50 warnings. I guess most are in the wrappers? I don't build the wrappers at all... You'll need to go through and try to fix the warnings and then submit the fixes to Robert, though the wrappers are less used so I guess it's less critical if there are warnings there? 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] OpenSceneGraph-2.8.0-rc1 tagged, please test
Hi Sukender, Done: Experimental build on SUKENDER1, rev 9652 (2.8 branch), VC8sp1 express, all inclusive, CMake cache cleared, full release rebuild. See the dashboard for details. Unfortunately, it has 50 warnings. I guess most are in the wrappers? I don't build the wrappers at all... You'll need to go through and try to fix the warnings and then submit the fixes to Robert, though the wrappers are less used so I guess it's less critical if there are warnings there? I just checked the CDash page for your build. The first three should be fixed as soon as Robert can commit the changes I sent earlier (as soon as the server allows him to :-) ). The rest seem to be all in the wrappers. 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] OpenSceneGraph-2.8.0-rc1 tagged, please test
Hi, build with no warnings on OpenSuse 11.1, gcc 4.3.2 and cmake 2.6.2 I have tested some examples and everything works fine. Regards. -- Christophe Loustaunau. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.0-rc1 tagged, please test
Robert Osfield wrote:
But still we can't rest if we want to make 2.8.0 the best we can... so
please download/check out the OpenSceneGraph-2.8 branch or the
2.8.0-rc1 and do compile and runtime checks on as wide range of
platforms as you have to hand. I would also greatly value feedback on
how you own applications are performing with 2.8, if there are issues
please just report them on osg-users and we can together have a bash
at resolve them.
DCMTK, installed locally, was also not found completely by CMake,
specifically some of the include paths where missing. I slightly changed
the relevant module to reuse the DCMTK_ROOT_INCLUDE_DIR variable, which
is the first one searched for.
I also get the following warning:
/home/melis/c/osg/svn/branches-2.8/src/osgPlugins/dicom/ReaderWriterDICOM.cpp:
In member function 'virtual osgDB::ReaderWriter::ReadResult
ReaderWriterDICOM::readImage(const std::string, const
osgDB::ReaderWriter::Options*) const':
/home/melis/c/osg/svn/branches-2.8/src/osgPlugins/dicom/ReaderWriterDICOM.cpp:421:
warning: 'pixelRep' may be used uninitialized in this function
But I'm having a hard time figuring out if it is valid or not.
Paul
# - find DCMTK libraries
#
# DCMTK_INCLUDE_DIRS - Directories to include to use DCMTK
# DCMTK_LIBRARIES - Files to link against to use DCMTK
# DCMTK_FOUND - If false, don't try to use DCMTK
# DCMTK_DIR - (optional) Source directory for DCMTK
#
# DCMTK_DIR can be used to make it simpler to find the various include
# directories and compiled libraries if you've just compiled it in the
# source tree. Just set it to the root of the tree where you extracted
# the source.
#
# Written for VXL by Amitha Perera.
# Modified by Robert Osfied to enable support for install placements of DCMTK
3.5.4 versions onwards
FIND_PATH( DCMTK_ROOT_INCLUDE_DIR dcmtk/config/osconfig.h
${DCMTK_DIR}/config/include
${DCMTK_DIR}/include
/usr/local/include/
/usr/include/
/usr/local/dicom/include/
)
FIND_PATH( DCMTK_config_INCLUDE_DIR osconfig.h
${DCMTK_DIR}/config/include
${DCMTK_DIR}/include
/usr/local/include/dcmtk/config
/usr/include/dcmtk/config
/usr/local/dicom/include/dcmtk/config
)
FIND_PATH( DCMTK_ofstd_INCLUDE_DIR ofstdinc.h
${DCMTK_DIR}/ofstd/include
${DCMTK_DIR}/include/ofstd
/usr/local/include/dcmtk/ofstd
/usr/include/dcmtk/ofstd
/usr/local/dicom/include/dcmtk/ofstd
)
FIND_LIBRARY( DCMTK_ofstd_LIBRARY ofstd
${DCMTK_DIR}/ofstd/libsrc
${DCMTK_DIR}/ofstd/libsrc/Release
${DCMTK_DIR}/ofstd/libsrc/Debug
${DCMTK_DIR}/ofstd/Release
${DCMTK_DIR}/ofstd/Debug
${DCMTK_DIR}/lib
/usr/local/lib64
/usr/lib64
/usr/local/lib
/usr/lib
/usr/local/dicom/lib
)
FIND_PATH( DCMTK_dcmdata_INCLUDE_DIR dctypes.h
${DCMTK_DIR}/dcmdata/include
${DCMTK_DIR}/include/dcmdata
/usr/local/include/dcmtk/dcmdata
/usr/include/dcmtk/dcmdata
/usr/local/dicom/include/dcmtk/dcmdata
)
FIND_LIBRARY( DCMTK_dcmdata_LIBRARY dcmdata
${DCMTK_DIR}/dcmdata/libsrc
${DCMTK_DIR}/dcmdata/libsrc/Release
${DCMTK_DIR}/dcmdata/libsrc/Debug
${DCMTK_DIR}/dcmdata/Release
${DCMTK_DIR}/dcmdata/Debug
${DCMTK_DIR}/lib
/usr/local/lib64
/usr/lib64
/usr/local/lib
/usr/lib
/usr/local/dicom/lib
)
FIND_PATH( DCMTK_dcmimgle_INCLUDE_DIR dcmimage.h
${DCMTK_DIR}/dcmimgle/include
${DCMTK_DIR}/include/dcmimgle
/usr/local/include/dcmtk/dcmimgle
/usr/include/dcmtk/dcmimgle
/usr/local/dicom/include/dcmtk/dcmimgle
)
FIND_LIBRARY( DCMTK_dcmimgle_LIBRARY dcmimgle
${DCMTK_DIR}/dcmimgle/libsrc
${DCMTK_DIR}/dcmimgle/libsrc/Release
${DCMTK_DIR}/dcmimgle/libsrc/Debug
${DCMTK_DIR}/dcmimgle/Release
${DCMTK_DIR}/dcmimgle/Debug
${DCMTK_DIR}/lib
/usr/local/lib64
/usr/lib64
/usr/local/lib
/usr/lib
/usr/local/dicom/lib
)
FIND_LIBRARY(DCMTK_imagedb_LIBRARY imagedb
${DCMTK_DIR}/imagectn/libsrc/Release
${DCMTK_DIR}/imagectn/libsrc/
${DCMTK_DIR}/imagectn/libsrc/Debug
/usr/local/lib64
/usr/lib64
/usr/local/lib
/usr/lib
/usr/local/dicom/lib
)
FIND_LIBRARY(DCMTK_dcmnet_LIBRARY dcmnet
${DCMTK_DIR}/dcmnet/libsrc/Release
${DCMTK_DIR}/dcmnet/libsrc/Debug
${DCMTK_DIR}/dcmnet/libsrc/
/usr/local/lib64
/usr/lib64
/usr/local/lib
/usr/lib
/usr/local/dicom/lib
)
IF( DCMTK_config_INCLUDE_DIR
AND DCMTK_ofstd_INCLUDE_DIR
AND DCMTK_ofstd_LIBRARY
AND DCMTK_dcmdata_INCLUDE_DIR
AND DCMTK_dcmdata_LIBRARY
AND DCMTK_dcmimgle_INCLUDE_DIR
AND DCMTK_dcmimgle_LIBRARY )
SET( DCMTK_FOUND YES )
SET( DCMTK_INCLUDE_DIRS
${DCMTK_config_INCLUDE_DIR}
${DCMTK_ofstd_INCLUDE_DIR}
${DCMTK_dcmdata_INCLUDE_DIR}
${DCMTK_dcmimgle_INCLUDE_DIR}
)
SET( DCMTK_LIBRARIES
${DCMTK_dcmimgle_LIBRARY}
${DCMTK_dcmdata_LIBRARY}
${DCMTK_ofstd_LIBRARY}
${DCMTK_config_LIBRARY}
)
IF(DCMTK_imagedb_LIBRARY)
SET(
Re: [osg-users] OpenSceneGraph-2.8.0-rc1 tagged, please test
Hi JS, Yes, they're mostly in the wrappers. As I told before, I'm a bit in a hurry, so I won't be able fix them now. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Wed, 04 Feb 2009 21:57:54 +0100, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com a écrit: Hi Sukender, Done: Experimental build on SUKENDER1, rev 9652 (2.8 branch), VC8sp1 express, all inclusive, CMake cache cleared, full release rebuild. See the dashboard for details. Unfortunately, it has 50 warnings. I guess most are in the wrappers? I don't build the wrappers at all... You'll need to go through and try to fix the warnings and then submit the fixes to Robert, though the wrappers are less used so I guess it's less critical if there are warnings there? I just checked the CDash page for your build. The first three should be fixed as soon as Robert can commit the changes I sent earlier (as soon as the server allows him to :-) ). The rest seem to be all in the wrappers. J-S ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Works with 2.8 campaign :-)
Le Wed, 04 Feb 2009 18:36:36 +0100, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com a écrit: Hi Robert, Does this sound like a good idea? Definitely! :-) (when did you turn into a marketing mogul?) J-S +1 :) Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgPango (Stop Worrying Love The Bomb)
Well, I only need basic text features for now, but that really sounds interesting. Maybe in the future? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Wed, 04 Feb 2009 21:15:16 +0100, Jeremy Moles jer...@emperorlinux.com a écrit: Hello all. Before I start hacking on osgWidget again full force (in preparation for OSG-2.9 or OSG-3.0) I wanted to continue peddling my wares here and generating interest in a different (BUT RELATED) project of mine called osgPango. Basically, I'm writing osgPango to achieve the following (in order): 1. TOP quality 2D fonts in OSG on all supported platforms. 2. A sophisticated layout/markup system for complicated text. 3. An extensible rendering backend that lets users create callbacks for the actual rendering of the font character. 4. Speed, speed, and more speed. 5. Clean and intuitive API that exposes all elements of a body of text (the position of each character, etc.) Goals 1, 2, and 3 are accomplished; 4 and 5 are debatable. Lets get started with some obligatory screenshots: http://cubicool.plopbyte.net/osgPango-normal.png Here is some undecorated text (no shadows or outlines) showing one of Robert's posts from earlier this week. Notice how the text is justified to a certain width, and that it is no problem for osgPango to change font style or color midway through a sentence or word! Also notice the font quality, where no character is missing a pixel on any side and straight vertical lines are sharp and not smudged along two pixels. http://cubicool.plopbyte.net/osgPango-shadow.png Same as the above screenshot, except that the paragraph width is shortened and there are now +1, +1 drop shadows (their offset is configurable). http://cubicool.plopbyte.net/osgPango-outline.png Here we change our alignment to RIGHT and add 1px black outlines to the fonts. I'd like to get other people who need high-quality 2D fonts to start keeping an eye on osgPango so I can start seeing how folks want to use and extend it's feature set (where possible). I've tested it personally on Linux and Vista 64, but I'd need someone else to try it on Mac. (As an aside, it should use the ATSUI backend on Mac, giving some pretty nice font quality! It uses FreeType on Linux and ClearType on Windows; to get it compile on Windows I simply used the binaries from the GTK project) The main osgPango website is here: http://osgpango.googlecode.com It won't be long before I consider it done (for me) and move back to osgWidget and start helping more with osgAnimation, so let me know soon if you're interested and need it to do something it doesn't. :) With time I hope to be able to get osgPango in the core and replace osgText, but we'll have to see. :) The advanced layout powers and pluggable rendering backends are two things it would be VERY hard to add to osgText. As far as speed is concerned, osgPango is currently just as fast as osgText for most normal usage, though obviously every time you change font families or color or size you introduce a state change. :) Placeholder code is also in place for someone to add a GLSL shader to do the multitexturing instead of the complicated osg::TexEnvCombine() object I currently use, and I'm sure we'd see some significant speed increases there as well (when effects are used or desired). ___ 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] When is right time to update text on the screen
Ok I figured out by looking closer at the stats handler that a better way to do it is to implement a draw callback for the text object that uses a mutex to prevent multiple threads from accessing the text string simultaneously. Alex From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Pecoraro, Alexander N Sent: Tuesday, February 03, 2009 5:17 PM To: OpenSceneGraph Users Subject: Re: [osg-users] When is right time to update text on the screen I seem to have fixed the problem by setting the data variance on my osgText object to DYNAMIC. I'm wondering if this is the proper way to handle this situation though - because when I look at the StatsHandler for an example it appears to be modifying it's osgText nodes, but it does not set the data variance to DYNAMIC. Why does it work for the StatsHandler, but not for my code? Is it because the StatsHandler modifies its text during the event traversal and I modify my text during the update traversal? Should I be modifying it during event traversal only? Thanks. Alex From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Pecoraro, Alexander N Sent: Tuesday, February 03, 2009 4:26 PM To: OpenSceneGraph Users Subject: [osg-users] When is right time to update text on the screen Is there a proper time to make changes to an osgText object's text? I seem to be having a problem where if I update some text in an update callback function it causes a segfault when I'm running the viewer in multi-threaded mode, but not in single threaded mode. I'm guessing because the text object is modified while is it being used by the render thread. Is there something wrong with how I am doing it? Thanks. Alex ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] About OpenGL materials
Hi Gordon, (sorry, sent before I had finished typing...) No Lighting = No Material Hmmm, and any way to make it so that lighting has no effect (even though it's on) for a given object? I thought about putting a 1x1 texture with in GL_DECAL mode, but then I would need a texture for each color I want in my models (since it would even override the material color) right? What I'm getting at is I'm very flexible as to how I get the color onto my model, as long as it isn't through the vertex colors since that overrides the scribe/outline effect's color. You probably could do this with in a shader but you would have to replicate the full fixed pipeline calculation of lighting,materials, textures , fogs etc ( which you have to do anyway ) I already have shaders for most of the fixed pipeline (what I need) but these can be disabled by the user, and whatever I'm trying to display would need to look the same both with shaders on and off... So I need a solution that works for the fixed pipeline too. I'll try to think about another way... 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] 3.0 or 2.10?
Hi all -- I've seen a couple of posts now implying that the next stable release after 2.8 will be called 3.0. I wanted to open a discussion on this so that we can get some clarification. Unless the next stable release will break lots of backwards compatibility, I'd opt for calling it 2.10, then 2.12, etc. No need to change the major revision number unless we break backwards compatibility, and although there has been some discussion of that, nothing definite yet at this point as far as I know. Robert, comments? 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] 3.0 or 2.10?
I am agree with this notation. Paul Martz wrote: Hi all -- I've seen a couple of posts now implying that the next stable release after 2.8 will be called 3.0. I wanted to open a discussion on this so that we can get some clarification. Unless the next stable release will break lots of backwards compatibility, I'd opt for calling it 2.10, then 2.12, etc. No need to change the major revision number unless we break backwards compatibility, and although there has been some discussion of that, nothing definite yet at this point as far as I know. Robert, comments? 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 -- +33 (0) 6 63 20 03 56 Cedric Pinson mailto:morni...@plopbyte.net http://www.plopbyte.net ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] About OpenGL materials
Jean-Sébastien Guay wrote on Wednesday, February 04, 2009 4:43 PM: What I'm getting at is I'm very flexible as to how I get the color onto my model, as long as it isn't through the vertex colors since that overrides the scribe/outline effect's color. Couldn't you just disable color arrays when you want the scribe/outline effect (see osg::State::disableColorPointer(); would require a DrawCallback, though)? -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 3.0 or 2.10?
Hi Paul, This needs to be confirmed, but I think Robert's mind is to go to 3.0 to allow the whole community to introduce things that break backwards compatibility, as you say. You even posted a thing on the thread Ideas for OSG v3.0, where Art Tevs told about reorganizing nodekits/plugins ( http://osgforum.tevs.eu/viewtopic.php?p=5006#5006 ). Of course if nothing special breaks the compatibility, or if there is not a huge pile of new features, I think going to 2.10 should be okay. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Thu, 05 Feb 2009 00:11:04 +0100, Paul Martz pma...@skew-matrix.com a écrit: Hi all -- I've seen a couple of posts now implying that the next stable release after 2.8 will be called 3.0. I wanted to open a discussion on this so that we can get some clarification. Unless the next stable release will break lots of backwards compatibility, I'd opt for calling it 2.10, then 2.12, etc. No need to change the major revision number unless we break backwards compatibility, and although there has been some discussion of that, nothing definite yet at this point as far as I know. Robert, comments? 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] 3.0 or 2.10?
HI, I agree on that the next version will still be 2.x. Only if we really go for a completly different API (with almost no backward compatibility), then we should go to 3.x The previous thread just collected some ideas about how to manage future releases of osg 3.x The idea was to go away from current nodekit thing and to separate the real main core part. Then with the help of something like NodeKitSuite one could add additional node kits. The main core would only have the real main core of a scene graph. All other suites will just provide functionality like ViewerSuite (whcih will include osgViewer), then InteractionSuite (here one could include osgWidget, osgGA, ...), then EffectSuite (here osgParticle, ...) and so on. Cheers, art -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=5901#5901 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] About OpenGL materials
Jean-Sbastien Guay wrote: Hi Gordon, (sorry, sent before I had finished typing...) No Lighting = No Material Hi J-S, Here is a probably worthless suggestion written without a proper review of the thread. I you want a material that looks the same as the unlit colour just set the materials emissive colour to the same as the vertex colour and set all the other material colours to black. Roger ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] exporting from OSG to OpenFlight
Is there a way to export Object nodes instead of Mesh nodes when converting from OpenSceneGraph to OpenFlight? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] About OpenGL materials
This may be a naive comment but couldn't you leverage something similar to glColorMaterial() to accomplish the task? Just a thought... -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien Guay Sent: Wednesday, February 04, 2009 3:43 PM To: OpenSceneGraph Users Subject: Re: [osg-users] About OpenGL materials Hi Gordon, (sorry, sent before I had finished typing...) No Lighting = No Material Hmmm, and any way to make it so that lighting has no effect (even though it's on) for a given object? I thought about putting a 1x1 texture with in GL_DECAL mode, but then I would need a texture for each color I want in my models (since it would even override the material color) right? What I'm getting at is I'm very flexible as to how I get the color onto my model, as long as it isn't through the vertex colors since that overrides the scribe/outline effect's color. You probably could do this with in a shader but you would have to replicate the full fixed pipeline calculation of lighting,materials, textures , fogs etc ( which you have to do anyway ) I already have shaders for most of the fixed pipeline (what I need) but these can be disabled by the user, and whatever I'm trying to display would need to look the same both with shaders on and off... So I need a solution that works for the fixed pipeline too. I'll try to think about another way... 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 smime.p7s Description: S/MIME cryptographic signature ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] exporting from OSG to OpenFlight
Can you be more specific about what you are trying to do? Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com http://www.skew-matrix.com/ +1 303 859 9466 _ From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Michael Kelley Sent: Wednesday, February 04, 2009 5:17 PM To: osg-users@lists.openscenegraph.org Subject: [osg-users] exporting from OSG to OpenFlight Is there a way to export Object nodes instead of Mesh nodes when converting from OpenSceneGraph to OpenFlight? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] About OpenGL materials
Hi Bryan, Couldn't you just disable color arrays when you want the scribe/outline effect (see osg::State::disableColorPointer(); would require a DrawCallback, though)? Interesting, I didn't know you could do that, I'll look into it. Thanks for the suggestion, 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] About OpenGL materials
Hi Roger, Here is a probably worthless suggestion written without a proper review of the thread. I you want a material that looks the same as the unlit colour just set the materials emissive colour to the same as the vertex colour and set all the other material colours to black. Well, reviewing the osgFX::Scribe code, this is exactly what it does. The problem was that our own Outline effect (based on Scribe, but only renders the outside edges of the object) disabled lighting in the outline pass. Thus, it was using the raw vertex color of the object for its outline color, which is why I didn't want to use vertex colors. Re-enabling lighting for the outline pass made it use the emissive material color, and made it so that I could disable lighting on my model and use vertex colors for its own colors without affecting the color of the outline. So, I would say problem solved. Thanks also to Paul Melis who pointed me to the osgscribe example, in which I saw the same thing was being done and led me to check the lighting setting on my outline pass... 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] About OpenGL materials
Hi Shayne, This may be a naive comment but couldn't you leverage something similar to glColorMaterial() to accomplish the task? I think glColorMaterial is the opposite, i.e. it will place whatever glColor is set as (i.e. vertex colors for example) into the current material. What I (thought I) wanted was to set the material color into the vertex colors. Anyways, the problem was solved in another (more direct) way, see my previous post. 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] 3.0 or 2.10?
Hi Paul, Hi all -- I've seen a couple of posts now implying that the next stable release after 2.8 will be called 3.0. I wanted to open a discussion on this so that we can get some clarification. I don't think this is the case. Robert has only referred to 3.0 when talking about introducing an OpenGL 3.0-only pipeline, i.e. not relying on the fixed pipeline at all. This will probably not happen in the next stable release after 2.8, thus there will surely be a 2.10, 2.12, etc. before we see 3.0. At least that's how I understood it. The fact that Robert and Art have started discussions on the road to OSG 3.0 does not automatically imply that 3.0 will be the next stable version of OSG. 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] Render to Texture and per vertex colors
Hi, Joseba ok, there is now a new example called glow in the osgPPU svn. I have implemented the first version of the glow. Hence just created a slave camera and render only the thing, which I want to glow by the second camera. Then apply gaussian blur on the output of the second camera and combine it with the main camera. Then write results to the frame buffer. Take a look. I choosed the version with the slave camera, because then you doesn't need to change any object shaders. You just render the object as it is , with its complete subgraph by the slave camera and blur the result. The example isn't perfect. One should also apply some kind of stencil masking, to render only the silhuette of the glowed object (if you need so). Also a depth buffer check has to be made, because the slave camera doesn't have the depth information form the main camera. If I would find some time, I will also implement this. However just to understand how a glow effect works with osgPPU, this example should be enough ;) Best regards, art Shaitan wrote: Hi Art, It would be great to see this demo!!! Another good idea is to use another camera for the 'glow objects', this match perfectly with my pipeline, with minor changes on the shaders. Although i propossed to use OsgPPU on the app we are doing, at this time we use another postprocessing effects, so at this moment we need a quite big change on it to use osgPPU (im sure that when osgPPU gets inside osg core, we will use it). Ill try to send you the small app using osgPPU that crahses. Thanx J. -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=5908#5908 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] LWO loading problem
Hi everybody.
I have gotten a report that the LWO loader doesn't seem to work.
Investigating, I grabbed the sample LWO file posted by Marco Jez back
in november last year (attached for convenience).
Loading into osgviewer, I get an empty view. Trying osgconv, I get an
osg file full of zeroes and nans (also attached).
With SIGFPE enabled, gdb shows:
Program received signal SIGFPE, Arithmetic exception.
[Switching to Thread 0x7f9b6be43730 (LWP 10599)]
0x7f9b6756e456 in lwosg::Block::setup_texture_point
(this=0xaee3c8, p...@0x7fff73fdcca0) at
OpenSceneGraph/src/osgPlugins/lwo/Block.cpp:141
141 Q.x() *= 1/imap_.mapping.size_.x();
Current language: auto; currently c++
(gdb) p imap_.mapping
$1 = {center_ = {_v = {0, 0, 0}}, size_ = {_v = {0, 0, 0}}, rotation_
= {_v = {0, 0, 0}},
csys_ = lwosg::Texture_mapping::OBJECT}
That's clearly the source of the nans but maybe not the root of the problem.
I haven't tried to find the exact svn rev this got broken yet, maybe
somebody has a quick solution right away.
--
Thanks,
Csaba
multitextured_cube.lwo
Description: Binary data
multitextured_cube.osg
Description: Binary data
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
