Re: [osg-users] osgEarth - terrain on demand
Hi Jason, On Sat, Jan 24, 2009 at 4:09 PM, Jason Beverage jasonbever...@gmail.com wrote: If you run osgearth_seed on the simple_caching.earth file does it also segfault or does it only segfault when you don't have a cache defined? When I run : osgearth_seed tests/simple_caching.earth I get a long series of output of the form: Processing 1332 Processing 13320 Processing 13321 Processing 13322 Processing 13323 Processing 1333 Then a Segmentation fault. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] What is the ideal default value for LIB_POSTFIX under Linux?
Hi Linux users, I've been building 64bit linux for quite a few years now, and we've always installed 64bit libries in /usr/local/lib64, which is consistent with the usual 64bit unix way of doing things. This would be fine and dandy if the linux distribution included by default the /usr/local/lib64 on their standard library search paths, but alas all the ones I've used haven't, so to get the OSG to run one has to explicitly add the /usr/local/lib64 in. I had hoped that this little deficiency in the linux distributions would be fixed given a bit of time, but alas this doesn't seem to have to come to pass. I would much prefer the OSG to install and run without any tweaks, so I am thinking about whether we should keep the default of 64 library post fix for linux 64bit builds. Thoughts? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg2.4 for VS Express 2008
http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/VisualStudio On Sat, Jan 24, 2009 at 5:24 PM, Amit Kalhapure akalhap...@yahoo.com wrote: Can anyone plz tell me, how to install and use OSG 2.4 or higher version in VS Express 2008.I am not able to install even by reading tutorials. Can anyone plz explain it to me in simple way Thank you.. ___ 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] osgWidget Design Though (Input Events)
Hi Jeremy,
I don't know if this can be the ideal solution for you, but I can say what I
did in my engine. I got both states class and event class. I guess events
only are useful to osgWidgets, so I'll ignore states here (but they behave
quite the same).
All nodes that need to read/intercept an event derive from
ControlEventHandler, and defines:
virtual bool handleEvent(blah blah blah) =0;
For instance, for a HUD/button/anything that waits for a key to be pushed:
virtual bool handleEvent(blah blah blah) {
if (it is my event) {
do something;
return true;
}
return false;
}
The return value (true or false) simply says if the event is consumed or not.
A consumed event will not be passed to other elements.
Of course, I got a special manipulator that stores ControlEventHandlers, and
processes them all when it receives an event (derives from
osgGA::GUIEventHandler), by implementing a custom
virtual bool handle (const osgGA::GUIEventAdapter ea,
osgGA::GUIActionAdapter aa);
This is the main problem I guess: you have to use a special manipulator. Maybe
standard manipulators could have a kind of functionality-extention by the way
of callbacks or such?
Please note that for the mouse, my implementation only sends coordinates, but
changing this to a mouseOver event would be quite simple I guess. You could
provide a mehtod in your widgets that says if a mouse coordinate is over it or
not.
Hope it helps!
If you need some more info, you can mail me, mail the list, or look at the PVLE
documentation:
http://pvle.sourceforge.net/Doc/Html/classControlEventHandler.html (Abstract
class for handling events)
http://pvle.sourceforge.net/Doc/Html/classControlEvent.html (Event class)
or:
http://pvle.sourceforge.net/Doc/Html (doc root)
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
Le Thu, 22 Jan 2009 20:23:15 +0100, Jeremy Moles jer...@emperorlinux.com a
écrit:
In osgWidget's current design, Widgets are notified of events such as
mouseOver by a single ViewerEventHandler object that traverses a given
root node and determines (or tries to :)) what kind of thing is going
on. When I originally wrote this part of osgWidget, such was the limit
of my knowldege...
However, I would like to move to a more divorced system, in which each
Drawable (Widget) or Node (Window) can use special UpdateCallback and
NodeCallback objects so that they can simply subscribe to the events
they're interested in.
What I'm looking for are some ideas as to how I could best accomplish
this.
One possibility is that I could keep the osgWidget::ViewerEventHandlers
that I currently have (MouseHandler, KeyboarHandler, etc.) except than
instead of having them call the mouseOver methods on the Widgets
directly they would simply set various state variables (mouse position,
etc.) that the user could later query in their on NodeCallback or
UpdateCallback functions.
Does this make sense? Is this even a worthy endeavor? I get a lot of
questions about how osgWidget marries the WindowManager+Event
mechanism and the widgets it manages, so I'm looking for ways to break
that up. The general idea is that I really want to use the OSG update
traversal more, since right now I basically just have one object (the
various ViewerEventHandlers) doing EVERYTHING on every object during
their own update phase.
___
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] Development plan for imminent stable OSG-2.8
Hi Sukender, On Sun, Jan 25, 2009 at 12:52 PM, Sukender suky0...@free.fr wrote: That's a nice idea, and I may help for building/testing... But binaries may take much disk space, especially if dev releases are uploaded, and SVN is meant to keep all revisions (even if real deleting is still possible, yet not very clean, I think). Won't this make your hard disks explode? :) IMHO, a simple FTP/SFTP/SCP/HTTPS/Whatever upload would be enough. You would then be able to do some cleanup when needed. Anyway, when writing access will be possible, I'd be glad to help (when possible!). I feel that binary releases for dev release is not appropriate, only stable releases need binaries. The current webserver has support for ftp and webdav which is a possible route. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] What is the ideal default value for LIB_POSTFIX under Linux?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Robert, Robert Osfield wrote: Yes this is what I mean, and I agree /usr/local/lib64 should be where such 64bit libraries should be installed. Almost all of other 3rd party libraries that I've built on my machine install into /usr/local/lib rather than /usr/local/lib64, I presume out of not knowing/caring about the /usr/local/lib64 convention for 64 bit libs, or it's a pragmatic decision based on problems with Linux distro's not including /usr/local/lib64 in there default search path. It is mostly ignorance, most open source developers do not think about making their project truly cross-platform and portable and assume it will be built on i586 and Linux only (or whatever their development machine runs) :( A sad truth - I had to fix my share of broken libs that assumed that sizeof(int) == 4, installed libs in lib instead of lib64 (and overwrote libs for the 32bit binaries) and such. The issue above is straight in the same vein. Making the OSG compile, install and run out of the box with mods very much my concern. Linux is one of most commonly used platforms so making things as seamless as possible is important. If this means being pragmatic about things then I'm prepared to be. I am a long time Linux developer and user too, and perpetuation of such kludges causes no end of trouble. Fighting brokenness with brokenness is a bad idea - then the issue will never get fixed because major software X relies on a bug Y and would break if it is fixed, so the kludge is carried on ... The LSB filesystem standard is there for a reason. The out-of-the-box experience is of little concern for me - OSG is not an end-user product but something used by developers who should know about library search path. Breaking a standard practice for a little convenience is a bad trade-off in my book. Do you still remember how it is on Windows? Every application drops files wherever it wants - in Windows, Windows\System32, overwriting other files, etc, resulting in issues like DLL hell. I would hate seeing something like that on Linux (or other Unix platforms). If you want to provide out-of-the-box working solution, I would really go for pre-built packages, at least for the stable releases. For development releases I do not think this is at all an issue. This does sound a possible solution, but.. it would require building of the packages and then installing, which is a two stage process rather than a single stage. It also requires CPack to support rpms and debians to be mature enough to do this. The build system could offer an option to invoke rpm or dpkg to install the packages after they are built. That is not really a big issue. I am not familiar with CPack, but in essence what you need is a SPEC file for RPM (which can be static - it doesn't really change unless you add/remove files and the file list could be perhaps generated by cmake) and then invoke rpmbuild -b foo.spec to assemble the package. It could be invoked as a custom command after the target is built. Perhaps another solution would be to have Cmake's install scripts add /usr/local/lib64 (or whatever the path is) to /etc/ld.so.conf automatically if it's not already there. That is also an option, however, modifying system-wide config files (especially an important one like ld.so.conf) is generally a bad idea for a 3rd-party app. One bug in a script somewhere and your system is unusable. Also, only root can modify these files, so it would have to handle the case when the installation is done into a user-writable directory, not system-wide. I would leave modification of such files to rpm/dpkg or similar tools. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJfIeXn11XseNj94gRAhaCAJ43dW8bnzLX8h7WZNcItY1YzTVSAQCgl6lF 6fG2J3jND/Q+tLUP++1WRdg= =Y/LV -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] What is the ideal default value for LIB_POSTFIX under Linux?
Hi Jan, On Sun, Jan 25, 2009 at 3:39 PM, Jan Ciger jan.ci...@gmail.com wrote: The out-of-the-box experience is of little concern for me - OSG is not an end-user product but something used by developers who should know about library search path. Breaking a standard practice for a little convenience is a bad trade-off in my book. The standard practice under Linux has not been to install in /usr/local/lib64 under Linux, and it's not standard practice of the distro's to include /usr/local/lib64 in search paths. While I believe /usr/local/lib64 is a better standard to assume, and is what the OSG uses right now, it is out of step with the most common practice. As for what is standard under linux, even my /usr/lib64 is totally empty under Kubuntu, let alone /usr/local/lib64. I believe Kubuntu does fit with the LSB. Do you have any links to LSB docs that say that 64bit libs must be in /usr/loca/lib64 and /usr/lib64? Out of the box experience *is* important to me, as a project lead I have to take in consideration more than my own personal needs. First up a good out of the box experience gives developers a better first experience with the OSG and secondly it means that we have less to document, keeping out documentation focused on things that are particular to the OSG rather than general build topics. Right now out use of /usr/local/lib64 is out of step with what the distro's support out of the box, so we have to document this deviation and end users have to do an extra step in their set up - even if we feel what we are doing is the rightous way to do it, it does dump extra work on others. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] What is the ideal default value for LIB_POSTFIX under Linux?
As for what is standard under linux, even my /usr/lib64 is totally empty under Kubuntu, let alone /usr/local/lib64. I believe Kubuntu does fit with the LSB. Correction, Kubuntu does use /usr/local/lib64, my earlier quick search that suggested it was empty was wrong due to a typo... it's /usr/local/lib64 that is empty save for OSG related libs. What I have under Kubuntu in /usr is : drwxr-xr-x 152 root root 91168 2009-01-24 09:49 lib drwxr-xr-x 34 root root 15880 2009-01-07 16:23 lib32 lrwxrwxrwx 1 root root 3 2008-12-02 12:57 lib64 - lib So lib64 is a symbolic link to /usr/local/lib. Some more info: cat /etc/ld.so.conf include /etc/ld.so.conf.d/*.conf cat /etc/ld.so.conf.d/libc.conf # libc default configuration /usr/local/lib I have just done some browsing on the Linux Standard Base website and couldn't spot anything pertaining to conventions for /usr/local/lib or /usr/local/lib64. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] What is the ideal default value for LIB_POSTFIX under Linux?
As another possible solution to the path issue might be to provide an addition config file for /etc/ld.so.conf.d/, the file is simply: # openscenegraph /usr/local install configuration /usr/local/lib64 I've attached one such file, this is automatically picked up by the /etc/ld.so.conf file that uses: include /etc/ld.so.conf.d/*.conf Another hack would be to do: echo /usr/local/lib64 /usr/ld.so.conf Then run ldconfig to get the lib paths to be updated. One could add this to the install quite easily for /usr/local/lib64 installs under Linux, the merits of this idea I'll happy to debate. Is it better than installing in /usr/local/lib? Is installing via rpm or debian possible instead? Robert. openscenegraph.conf Description: Binary data ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] What is the ideal default value for LIB_POSTFIX under Linux?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Osfield wrote: As for what is standard under linux, even my /usr/lib64 is totally empty under Kubuntu, let alone /usr/local/lib64. I believe Kubuntu does fit with the LSB. Not really, Ubuntu is known to take various shortcuts in the name of convenience. Correction, Kubuntu does use /usr/local/lib64, my earlier quick search that suggested it was empty was wrong due to a typo... it's /usr/local/lib64 that is empty save for OSG related libs. What I have under Kubuntu in /usr is : drwxr-xr-x 152 root root 91168 2009-01-24 09:49 lib drwxr-xr-x 34 root root 15880 2009-01-07 16:23 lib32 lrwxrwxrwx 1 root root 3 2008-12-02 12:57 lib64 - lib So lib64 is a symbolic link to /usr/local/lib. Some more info: cat /etc/ld.so.conf include /etc/ld.so.conf.d/*.conf cat /etc/ld.so.conf.d/libc.conf # libc default configuration /usr/local/lib This then means that whatever you put into /usr/local/lib64 should be found, because it is on the path thanks to the symlink. However, that is non-standard and breaks things if you want both 32 and 64 bits binaries to be used on the same system (quite common - not all software is available in 64bit versions or they are buggy, especially the proprietary software). See here (a mail from LSB guy to Debian developers about this issue): http://lists.debian.org/debian-amd64/2004/07/msg00039.html I have just done some browsing on the Linux Standard Base website and couldn't spot anything pertaining to conventions for /usr/local/lib or /usr/local/lib64. No, but the convention is for all lib directories, /usr/local is special only in that that it is intended for user-installed libraries. Actually the description is in the Filesystem Hierarchy Standard (FHS), not LSB - sorry, my bad: http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLTQUALGTALTERNATEFORMATLIBRARI To quote the relevant parts: /usr/libqual : Alternate format libraries (optional) Purpose /usr/libqual performs the same role as /usr/lib for an alternate binary format, except that the symbolic links /usr/libqual/sendmail and /usr/libqual/X11 are not required. And: Specific Options If directories /libqual or /usr/libqual exist, the equivalent directories must also exist in /usr/local. If [K]Ubuntu doesn't have them, it is not really standard compliant. This seems to be however taken over from Debian, judging from the mail above. So the rule is that on i[3456]86 you are installing into /lib, /usr/lib or /usr/local/lib, on ia64 or amd64 you are installing into /lib64, /usr/lib64 and /usr/local/lib64 The FHS text is a bit ambiguous and could be interpreted that foo/lib contains the libs for your main architecture and foo/libXX for alternates, so you could also have /lib and /lib32 on a 64-bit system running 32-bit binaries. However, I didn't see a Linux distro actually doing this yet. IRIX has it this way, if I recall correctly. Regarding the convenience - I am not against convenience in principle, but breaking the standards to kludge around a non-compliant system is not good. If you want a really simple solution, add a command to the installer that will drop an appropriate file to /etc/ld.so.conf.d directory. That is probably the least evil option. Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJfKsRn11XseNj94gRAg5yAKCqsQhIsQo0E0NpbjwNVaSZv7WPRQCeIVNR hH2b4ajndg+mB3hVCPl0EyY= =Zne0 -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgEarth - terrain on demand
Hi Robert and Jan, I just committed a fix to osgearth that removes the segfault at the end of the seeding. Works fine for me now in Ubuntu. Thanks! Jason On Sun, Jan 25, 2009 at 7:06 AM, Jan Ciger jan.ci...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jason Beverage wrote: Hi Jan and Robert, If you run osgearth_seed on the simple_caching.earth file does it also segfault or does it only segfault when you don't have a cache defined? If I define the cache, it tries to compute something and then segfaults at the end. Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJfFW2n11XseNj94gRAt9wAJ9iajQ4CSlT3Ti2oNH1N6pdeaqbkQCePMlU NSCVMotvYnuX3i8Au8+s0ig= =7tl0 -END PGP SIGNATURE- ___ 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
