Menu
▾
▴
diverse-devel — For discussion among developers and users
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
(10) |
Oct
(12) |
Nov
(27) |
Dec
(20) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(7) |
Feb
(6) |
Mar
(4) |
Apr
(2) |
May
(3) |
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
(32) |
Oct
(9) |
Nov
(1) |
Dec
(1) |
| 2006 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(2) |
Jun
(1) |
Jul
(8) |
Aug
(3) |
Sep
(2) |
Oct
(4) |
Nov
(3) |
Dec
(2) |
| 2007 |
Jan
(8) |
Feb
(12) |
Mar
(4) |
Apr
(3) |
May
(11) |
Jun
(12) |
Jul
(12) |
Aug
(24) |
Sep
(5) |
Oct
(10) |
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
(1) |
Mar
|
Apr
(5) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <div...@un...> - 2006-07-08 01:56:57
|
|
From: John K. <ke...@be...> - 2006-07-03 16:55:39
|
Hi, Can someone at OpenTech take a look and see why our web pages are still down? Specifically, the link from diverse.sourceforge.net says the site diverse.sf.net is offline. Thanks, -John |
|
From: Daniel L. <dla...@op...> - 2006-07-03 16:26:35
|
John, It would be possible to parse the augments in dtkManager and then have them removed so that others don't see the arguments. Your environment variable approach is an interesting one. In CoVE (Collaborative VE / VEWL) we are providing support for both command line and environment variable approaches when ever possible. One down side to environment variables is that they do not necessarily get parsed by the shell first, where as command line arguments get expanded by the shell. There are work-arounds via smart scripts that dynamically set the environment variables. We would like to have CoVE work with DOSG as an augment and not require a special dosg-fly executable. As always we continue to stick to the DIVERSE mantra of "works-by- default" and are striving to make sure that sane defaults are in place. Dan On Jul 3, 2006, at 12:07 PM, John Kelso wrote: > Hi, > > Years ago we discussed the command-line issue, similar to what you're > doing now. > > We finally decided to keep it simple and use envvars to pass > arguments to > DSOs. Messy and low tech, but also easy to use and implement. > > We sort of had a convention- XXX_YYY_ZZZ whwre XXX was DTK or DPF, > YYY was > the augment name, adn ZZZ was specific to the augment. Nothing > enforced > the convention, but it seemed a decent ideda. > > Anyway, at least this is how I remember it. > > I don't know why you want or need command-line arguments, but the cure > might be worse than the disease, if you catch my meaning. > > I strongly hope that whatever you come up with "will work by > default" and > not require any substantial changes to each application, not that > we have > that many. > > Is it possible for the dtkManager to be passed the command line > arguments > as one of its constructor methods, and to strip out the arguments of > interest to the augments, modifying argc and argv, leaving the rest > of the > arguments intact? If so, then the applications could just create the > dtkmanager object, then parse as usual. > > -John > > On Mon, 3 Jul 2006, Daniel Larimer wrote: > >> I was contemplating adding support for a argument such as >> >> --augment-args[ DtkAugmentName argv list here ] >> >> but this is a much bigger change. One potential problem we may >> have is that dosg-fly treats all *extra* arguments as model files to >> load and will exit if it doesn't find a model. >> >> At a minimum I may need to add support to dosg-fly to know how to >> ignore certain arguments. >> >> Dan >> >> >> On Jul 3, 2006, at 11:42 AM, John Kelso wrote: >> >>> OK by me as long as it builds. >>> >>> Any plans on how to keep applications and DSOs from tripping over >>> each >>> other's command line arguments? >>> >>> Thanks, >>> >>> -John >>> >>> On Mon, 3 Jul 2006, Daniel Larimer wrote: >>> >>>> All, >>>> I have a patch to dtkManager and DGL that will allow the argc and >>>> argv to be passed to the dtkManager constructor and then >>>> accessed by >>>> any augment via dtkManager::argc() and dtkManager::argv() >>>> >>>> This is needed because not all operating systems support proc and >>>> most developers don't know how to get argc/argv from proc. >>>> >>>> To make this change in DGL will make DGL dependent upon the latest >>>> subversion version of DTK and so I have with held the patch from >>>> DGL/ >>>> DTK. >>>> >>>> If you see no problems with this then I will check it in. >>>> >>>> Dan >>>> >>>> Using Tomcat but need to do more? Need to support web services, >>>> security? >>>> Get stuff done quickly with pre-integrated technology to make your >>>> job easier >>>> Download IBM WebSphere Application Server v.1.0.1 based on Apache >>>> Geronimo >>>> http://sel.as-us.falkag.net/sel? >>>> cmd=lnk&kid=120709&bid=263057&dat=121642 >>>> _______________________________________________ >>>> diverse-devel mailing list >>>> div...@li... >>>> https://lists.sourceforge.net/lists/listinfo/diverse-devel >>>> >>> >>> >>> Using Tomcat but need to do more? Need to support web services, >>> security? >>> Get stuff done quickly with pre-integrated technology to make your >>> job easier >>> Download IBM WebSphere Application Server v.1.0.1 based on Apache >>> Geronimo >>> http://sel.as-us.falkag.net/sel? >>> cmd=lnk&kid=120709&bid=263057&dat=121642 >>> _______________________________________________ >>> diverse-devel mailing list >>> div...@li... >>> https://lists.sourceforge.net/lists/listinfo/diverse-devel >> > > > Using Tomcat but need to do more? Need to support web services, > security? > Get stuff done quickly with pre-integrated technology to make your > job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel? > cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > diverse-devel mailing list > div...@li... > https://lists.sourceforge.net/lists/listinfo/diverse-devel |
|
From: John K. <ke...@be...> - 2006-07-03 16:07:56
|
Hi, Years ago we discussed the command-line issue, similar to what you're doing now. We finally decided to keep it simple and use envvars to pass arguments to DSOs. Messy and low tech, but also easy to use and implement. We sort of had a convention- XXX_YYY_ZZZ whwre XXX was DTK or DPF, YYY was the augment name, adn ZZZ was specific to the augment. Nothing enforced the convention, but it seemed a decent ideda. Anyway, at least this is how I remember it. I don't know why you want or need command-line arguments, but the cure might be worse than the disease, if you catch my meaning. I strongly hope that whatever you come up with "will work by default" and not require any substantial changes to each application, not that we have that many. Is it possible for the dtkManager to be passed the command line arguments as one of its constructor methods, and to strip out the arguments of interest to the augments, modifying argc and argv, leaving the rest of the arguments intact? If so, then the applications could just create the dtkmanager object, then parse as usual. -John On Mon, 3 Jul 2006, Daniel Larimer wrote: > I was contemplating adding support for a argument such as > > --augment-args[ DtkAugmentName argv list here ] > > but this is a much bigger change. One potential problem we may > have is that dosg-fly treats all *extra* arguments as model files to > load and will exit if it doesn't find a model. > > At a minimum I may need to add support to dosg-fly to know how to > ignore certain arguments. > > Dan > > > On Jul 3, 2006, at 11:42 AM, John Kelso wrote: > > > OK by me as long as it builds. > > > > Any plans on how to keep applications and DSOs from tripping over each > > other's command line arguments? > > > > Thanks, > > > > -John > > > > On Mon, 3 Jul 2006, Daniel Larimer wrote: > > > >> All, > >> I have a patch to dtkManager and DGL that will allow the argc and > >> argv to be passed to the dtkManager constructor and then accessed by > >> any augment via dtkManager::argc() and dtkManager::argv() > >> > >> This is needed because not all operating systems support proc and > >> most developers don't know how to get argc/argv from proc. > >> > >> To make this change in DGL will make DGL dependent upon the latest > >> subversion version of DTK and so I have with held the patch from DGL/ > >> DTK. > >> > >> If you see no problems with this then I will check it in. > >> > >> Dan > >> > >> Using Tomcat but need to do more? Need to support web services, > >> security? > >> Get stuff done quickly with pre-integrated technology to make your > >> job easier > >> Download IBM WebSphere Application Server v.1.0.1 based on Apache > >> Geronimo > >> http://sel.as-us.falkag.net/sel? > >> cmd=lnk&kid=120709&bid=263057&dat=121642 > >> _______________________________________________ > >> diverse-devel mailing list > >> div...@li... > >> https://lists.sourceforge.net/lists/listinfo/diverse-devel > >> > > > > > > Using Tomcat but need to do more? Need to support web services, > > security? > > Get stuff done quickly with pre-integrated technology to make your > > job easier > > Download IBM WebSphere Application Server v.1.0.1 based on Apache > > Geronimo > > http://sel.as-us.falkag.net/sel? > > cmd=lnk&kid=120709&bid=263057&dat=121642 > > _______________________________________________ > > diverse-devel mailing list > > div...@li... > > https://lists.sourceforge.net/lists/listinfo/diverse-devel > |
|
From: Daniel L. <dla...@op...> - 2006-07-03 15:50:45
|
I was contemplating adding support for a argument such as --augment-args[ DtkAugmentName argv list here ] but this is a much bigger change. One potential problem we may have is that dosg-fly treats all *extra* arguments as model files to load and will exit if it doesn't find a model. At a minimum I may need to add support to dosg-fly to know how to ignore certain arguments. Dan On Jul 3, 2006, at 11:42 AM, John Kelso wrote: > OK by me as long as it builds. > > Any plans on how to keep applications and DSOs from tripping over each > other's command line arguments? > > Thanks, > > -John > > On Mon, 3 Jul 2006, Daniel Larimer wrote: > >> All, >> I have a patch to dtkManager and DGL that will allow the argc and >> argv to be passed to the dtkManager constructor and then accessed by >> any augment via dtkManager::argc() and dtkManager::argv() >> >> This is needed because not all operating systems support proc and >> most developers don't know how to get argc/argv from proc. >> >> To make this change in DGL will make DGL dependent upon the latest >> subversion version of DTK and so I have with held the patch from DGL/ >> DTK. >> >> If you see no problems with this then I will check it in. >> >> Dan >> >> Using Tomcat but need to do more? Need to support web services, >> security? >> Get stuff done quickly with pre-integrated technology to make your >> job easier >> Download IBM WebSphere Application Server v.1.0.1 based on Apache >> Geronimo >> http://sel.as-us.falkag.net/sel? >> cmd=lnk&kid=120709&bid=263057&dat=121642 >> _______________________________________________ >> diverse-devel mailing list >> div...@li... >> https://lists.sourceforge.net/lists/listinfo/diverse-devel >> > > > Using Tomcat but need to do more? Need to support web services, > security? > Get stuff done quickly with pre-integrated technology to make your > job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel? > cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > diverse-devel mailing list > div...@li... > https://lists.sourceforge.net/lists/listinfo/diverse-devel |
|
From: John K. <ke...@be...> - 2006-07-03 15:43:00
|
OK by me as long as it builds. Any plans on how to keep applications and DSOs from tripping over each other's command line arguments? Thanks, -John On Mon, 3 Jul 2006, Daniel Larimer wrote: > All, > I have a patch to dtkManager and DGL that will allow the argc and > argv to be passed to the dtkManager constructor and then accessed by > any augment via dtkManager::argc() and dtkManager::argv() > > This is needed because not all operating systems support proc and > most developers don't know how to get argc/argv from proc. > > To make this change in DGL will make DGL dependent upon the latest > subversion version of DTK and so I have with held the patch from DGL/ > DTK. > > If you see no problems with this then I will check it in. > > Dan > > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > diverse-devel mailing list > div...@li... > https://lists.sourceforge.net/lists/listinfo/diverse-devel > |
|
From: Daniel L. <dla...@op...> - 2006-07-03 14:40:20
|
All, I have a patch to dtkManager and DGL that will allow the argc and argv to be passed to the dtkManager constructor and then accessed by any augment via dtkManager::argc() and dtkManager::argv() This is needed because not all operating systems support proc and most developers don't know how to get argc/argv from proc. To make this change in DGL will make DGL dependent upon the latest subversion version of DTK and so I have with held the patch from DGL/ DTK. If you see no problems with this then I will check it in. Dan |
|
From: Steve S. <st...@ni...> - 2006-05-19 22:56:30
|
Thanks for the reply. Something was preveting Xvfb from running. While trying to debug it, I made a mistake that complicated the problem. Once we figured out my mistake, the original issue disappeared and we got things working again. -Steve On Fri, 19 May 2006, Daniel Larimer wrote: > Steve, > This looks like a problem with the port that Xvfb is attempting to > bind to. This could be caused by Xvfb already running or another > program already bound to that port. > > Try: > > killall -9 Xvfb > > wait a minute (just to make sure the OS has a chance to reclaim the > port) > > Xvfb :99 -ac -screen 0 1024x1024x24 > > Dan > > On May 19, 2006, at 3:27 PM, Steve Satterfield wrote: > > > Hi Guys, > > > > I would normally ask John, but he is away this week. We had a > > system crash > > on our Prism and now after re-boot our VEWL stopped working. I suppect > > there is some sort of file left laying around that needs to be > > cleaned up. > > I have cleaned out DIVESE shared memory. > > I removed /tmp/.X99-lock. > > > > This version of VEWL uses Xvfb. If I try to run Xvbf directly I get > > the > > following: > > > > rainbow:~: Xvfb :99 -ac -screen 0 1024x1024x24 > > _XSERVTransSocketCreateListener: failed to bind listener > > _XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed > > _XSERVTransMakeAllCOTSServerListeners: failed to create listener > > for local > > Could not init font path element /usr/X11R6/lib/X11/fonts/TTF/, > > removing from list! > > Could not init font path element /usr/X11R6/lib/X11/fonts/CID/, > > removing from list! > > > > > > Do these messages give you any ides on what I should look for? > > > > > > Thanks, > > Steve > > > > > > ------------------------------------------------------- > > Using Tomcat but need to do more? Need to support web services, > > security? > > Get stuff done quickly with pre-integrated technology to make your > > job easier > > Download IBM WebSphere Application Server v.1.0.1 based on Apache > > Geronimo > > http://sel.as-us.falkag.net/sel? > > cmd=lnk&kid=120709&bid=263057&dat=121642 > > _______________________________________________ > > diverse-devel mailing list > > div...@li... > > https://lists.sourceforge.net/lists/listinfo/diverse-devel > > > |
|
From: Steve S. <st...@ni...> - 2006-05-19 19:27:51
|
Hi Guys, I would normally ask John, but he is away this week. We had a system crash on our Prism and now after re-boot our VEWL stopped working. I suppect there is some sort of file left laying around that needs to be cleaned up. I have cleaned out DIVESE shared memory. I removed /tmp/.X99-lock. This version of VEWL uses Xvfb. If I try to run Xvbf directly I get the following: rainbow:~: Xvfb :99 -ac -screen 0 1024x1024x24 _XSERVTransSocketCreateListener: failed to bind listener _XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed _XSERVTransMakeAllCOTSServerListeners: failed to create listener for local Could not init font path element /usr/X11R6/lib/X11/fonts/TTF/, removing from list! Could not init font path element /usr/X11R6/lib/X11/fonts/CID/, removing from list! Do these messages give you any ides on what I should look for? Thanks, Steve |
|
From: <jac...@po...> - 2006-03-15 18:56:39
|
Hi, I recently launched a new website (http://vroot.org/) which is intended to the "VR Community": people who work/study in the field of Virtual Reality or are really interested by it. The main objectives of VRoot.org are: - To provide an open place where to find and share news/comments related to Virtual Reality. - To provide a collaborative space where to find, document and maintain Virtual Reality Resources. - To promote personal/academic/communitarian/research/artistic Virtual Reality projects of the VR Community. The last point is about promoting all kind of VR project (which is true), but in fact we are especially interested in promoting open source and academic research projects. We would be pleased to hear about specific projects of Master/PhD students. Since I presume most of you are VR developers, I would be pleased to give you permission privileges if you are interested in contributing with us. Just send me an email if it's the case. In hoping I did not shock you by the fact this mail is not specifically about Diverse. Notice for Diverse developers: I'm interested in hearing news about the main events surrounding Diverse development. I can even give you permission privileges (so you could do it by yourself) if you're interested. Don't hesitate to contact me for any questions/propositions about VRoot.org. Regards, Jacques-Andre Boulay |
|
From: Patrick S. <psh...@vt...> - 2005-12-02 19:21:59
|
New releases of DTK and DGL are available -
DTK-2.4.15 - fixes/removes unnecessary dependency from MS VC6 projects
DGL-2.4.3 - renames vtCaveDisplay* DSOs
adds mono support through vtCaveMono* DSOs
|
|
From: Patrick S. <psh...@vt...> - 2005-11-18 21:50:42
|
New releases of DTK, DPF, DGL, and DADS are now available to the public.
These packages contain bug fixes, some incremental feature updates, and
some additional support.
DTK-2.4.14 Linux (32, 64, and 32 bit under 64), IRIX (32 and 64 bit),
Mac OS X 10.4, Cygwin, Windows
DPF-2.4.2 Linux (32, 64, and 32 bit under 64), IRIX (32 and 64 bit)
DGL-2.4.2 Linux (32, 64, and 32 bit under 64), IRIX (32 and 64 bit),
Mac OS X 10.4
DADS-1.3.0 Linux (32, 64, and 32 bit under 64), IRIX (32 and 64 bit),
Mac OS X 10.4
|
|
From: Doug M. <mc...@ia...> - 2005-10-15 18:16:04
|
On Oct 15, 2005, at 12:55 PM, an...@vt... wrote: > Hi Doug, > > Glad to hear you are interested in trying DIVERSE. As far as I > know DGL will > allow all of OSG to be supported. If you find something that you need > DIVERSE to do that it isn't doing let me know and I'll see if I can > make it > work for you. > > We have a vastly different method of handling input devices than what > VRJuggler does. In a nutshell we have a server running that manages > different services. One of these services would manage getting > input from a > certain device (such as an IS900 device). This service would then > filter the > input data if it needs to be filtered and would then put the data > into shared > memory. Once the data is in shared memory the data can be read by any > DIVERSE application running on the machine, and can be easily > shared across > the network with other machines. These services are normally hard > coded in a > C++ program that we call a DSO. > > DIVERSE gets most of its functionality through a plugin system. > These plugins > (we call them DSOs in most cases, services in others, but that is an > implementation detail), get loaded at runtime and provide > capabilities to the > DIVERSE process that is currently running. This is how we provide > navigation, displays, and input devices. Environmental variables > are what we > currently use to tell DIVERSE what plugins to load when running an > application. Inside of the application you can dynamically manage the > plugins if you want to. > > If you want, could you tell me the scenario that you are wanting to > use > DIVERSE for? It would be helpful for me to know what you are > wanting to > accomplish. Here is an example of what I mean: I have a 4 wall > cave powered > by 4 linux machines and am using an is900 tracker and wand. I want > to use > DIVERSE to view a building I modeled with OSG. > We run on systems from desktops to passive one wall systems to active 6 wall systems. I believe I just need to give DIVERSE a try on our systems and figure a few things out. We currently have an application written that uses vtk and other apis for scientific vis and other CAD related applications. > Thank you again for your interest in DIVERSE. > > Sincerely, > > Andrew A. Ray > On Saturday 15 October 2005 12:33 pm, Doug McCorkle wrote: > >> Your response is what I was hoping for. We will give it a try on our >> cluster. >> >> Another question, does the OSG support allow usage of all of OSG >> scenegraph capability? I imagine it does but wanted to make sure. >> >> Also, I am quite familiar with vrjuggler and its configuration tools >> for external input devices. Does diverse have a similar tool or is >> there another mechanism for configuration of hardware and input >> devices? Thanks again for the patience in answering my questions. >> >> Doug >> >> On Oct 15, 2005, at 12:09 PM, an...@vt... wrote: >> >>> Hi Doug, >>> >>> Good questions. We need to work on our website. >>> >>> DIVERSE does support OSG. The DGL component has a simple OSG >>> scenegraph that >>> you can use. >>> >>> DIVERSE works on Mac OS X platorms (except for DPF). Windows >>> support is still >>> under development. Parts of DIVERSE are windows friendly (DTK , >>> DGL). >>> However, on Windows it requires more work to make things work >>> properly than >>> on Linux. >>> >>> The DADS cluster support is ready for outside usage and I have >>> heard that it >>> is being installed at another site now. >>> >>> Let me know if you have any other questions, and feel free to >>> give us >>> feedback. We know DIVERSE isn't perfect, but it does some things >>> very well >>> in our humble opinion. >>> >>> Sincerely, >>> >>> Andrew A. Ray >>> >>> On Saturday 15 October 2005 11:39 am, Doug McCorkle wrote: >>> >>>> Hello, >>>> I have a few questions regarding what diverse currently >>>> supports. >>>> First, does diverse support OSG currently? It appears that in some >>>> places on the web site that support is still coming but then in >>>> others >>>> it looks like it is already there. Second, does diverse support the >>>> win32 and mac os 10.X platforms? Third, is the DADS cluster support >>>> still beta or is that ready for outside use? Thanks for the info. >>>> >>>> Doug >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------- >>>> This SF.Net email is sponsored by: >>>> Power Architecture Resource Center: Free content, downloads, >>>> discussions, >>>> and more. http://solutions.newsforge.com/ibmarch.tmpl >>>> _______________________________________________ >>>> diverse-devel mailing list >>>> div...@li... >>>> https://lists.sourceforge.net/lists/listinfo/diverse-devel >>>> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: >> Power Architecture Resource Center: Free content, downloads, >> discussions, >> and more. http://solutions.newsforge.com/ibmarch.tmpl >> _______________________________________________ >> diverse-devel mailing list >> div...@li... >> https://lists.sourceforge.net/lists/listinfo/diverse-devel >> > > |
|
From: <an...@vt...> - 2005-10-15 18:07:19
|
Hi Doug, Glad to hear you are interested in trying DIVERSE. As far as I know DGL will allow all of OSG to be supported. If you find something that you need DIVERSE to do that it isn't doing let me know and I'll see if I can make it work for you. We have a vastly different method of handling input devices than what VRJuggler does. In a nutshell we have a server running that manages different services. One of these services would manage getting input from a certain device (such as an IS900 device). This service would then filter the input data if it needs to be filtered and would then put the data into shared memory. Once the data is in shared memory the data can be read by any DIVERSE application running on the machine, and can be easily shared across the network with other machines. These services are normally hard coded in a C++ program that we call a DSO. DIVERSE gets most of its functionality through a plugin system. These plugins (we call them DSOs in most cases, services in others, but that is an implementation detail), get loaded at runtime and provide capabilities to the DIVERSE process that is currently running. This is how we provide navigation, displays, and input devices. Environmental variables are what we currently use to tell DIVERSE what plugins to load when running an application. Inside of the application you can dynamically manage the plugins if you want to. If you want, could you tell me the scenario that you are wanting to use DIVERSE for? It would be helpful for me to know what you are wanting to accomplish. Here is an example of what I mean: I have a 4 wall cave powered by 4 linux machines and am using an is900 tracker and wand. I want to use DIVERSE to view a building I modeled with OSG. Thank you again for your interest in DIVERSE. Sincerely, Andrew A. Ray On Saturday 15 October 2005 12:33 pm, Doug McCorkle wrote: > Your response is what I was hoping for. We will give it a try on our > cluster. > > Another question, does the OSG support allow usage of all of OSG > scenegraph capability? I imagine it does but wanted to make sure. > > Also, I am quite familiar with vrjuggler and its configuration tools > for external input devices. Does diverse have a similar tool or is > there another mechanism for configuration of hardware and input > devices? Thanks again for the patience in answering my questions. > > Doug > > On Oct 15, 2005, at 12:09 PM, an...@vt... wrote: > > Hi Doug, > > > > Good questions. We need to work on our website. > > > > DIVERSE does support OSG. The DGL component has a simple OSG > > scenegraph that > > you can use. > > > > DIVERSE works on Mac OS X platorms (except for DPF). Windows > > support is still > > under development. Parts of DIVERSE are windows friendly (DTK , DGL). > > However, on Windows it requires more work to make things work > > properly than > > on Linux. > > > > The DADS cluster support is ready for outside usage and I have > > heard that it > > is being installed at another site now. > > > > Let me know if you have any other questions, and feel free to give us > > feedback. We know DIVERSE isn't perfect, but it does some things > > very well > > in our humble opinion. > > > > Sincerely, > > > > Andrew A. Ray > > > > On Saturday 15 October 2005 11:39 am, Doug McCorkle wrote: > >> Hello, > >> I have a few questions regarding what diverse currently > >> supports. > >> First, does diverse support OSG currently? It appears that in some > >> places on the web site that support is still coming but then in > >> others > >> it looks like it is already there. Second, does diverse support the > >> win32 and mac os 10.X platforms? Third, is the DADS cluster support > >> still beta or is that ready for outside use? Thanks for the info. > >> > >> Doug > >> > >> > >> > >> > >> ------------------------------------------------------- > >> This SF.Net email is sponsored by: > >> Power Architecture Resource Center: Free content, downloads, > >> discussions, > >> and more. http://solutions.newsforge.com/ibmarch.tmpl > >> _______________________________________________ > >> diverse-devel mailing list > >> div...@li... > >> https://lists.sourceforge.net/lists/listinfo/diverse-devel > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > diverse-devel mailing list > div...@li... > https://lists.sourceforge.net/lists/listinfo/diverse-devel |
|
From: Doug M. <mc...@ia...> - 2005-10-15 17:33:25
|
Your response is what I was hoping for. We will give it a try on our cluster. Another question, does the OSG support allow usage of all of OSG scenegraph capability? I imagine it does but wanted to make sure. Also, I am quite familiar with vrjuggler and its configuration tools for external input devices. Does diverse have a similar tool or is there another mechanism for configuration of hardware and input devices? Thanks again for the patience in answering my questions. Doug On Oct 15, 2005, at 12:09 PM, an...@vt... wrote: > Hi Doug, > > Good questions. We need to work on our website. > > DIVERSE does support OSG. The DGL component has a simple OSG > scenegraph that > you can use. > > DIVERSE works on Mac OS X platorms (except for DPF). Windows > support is still > under development. Parts of DIVERSE are windows friendly (DTK , DGL). > However, on Windows it requires more work to make things work > properly than > on Linux. > > The DADS cluster support is ready for outside usage and I have > heard that it > is being installed at another site now. > > Let me know if you have any other questions, and feel free to give us > feedback. We know DIVERSE isn't perfect, but it does some things > very well > in our humble opinion. > > Sincerely, > > Andrew A. Ray > On Saturday 15 October 2005 11:39 am, Doug McCorkle wrote: > >> Hello, >> I have a few questions regarding what diverse currently >> supports. >> First, does diverse support OSG currently? It appears that in some >> places on the web site that support is still coming but then in >> others >> it looks like it is already there. Second, does diverse support the >> win32 and mac os 10.X platforms? Third, is the DADS cluster support >> still beta or is that ready for outside use? Thanks for the info. >> >> Doug >> >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: >> Power Architecture Resource Center: Free content, downloads, >> discussions, >> and more. http://solutions.newsforge.com/ibmarch.tmpl >> _______________________________________________ >> diverse-devel mailing list >> div...@li... >> https://lists.sourceforge.net/lists/listinfo/diverse-devel >> > > |
|
From: <an...@vt...> - 2005-10-15 17:21:25
|
Hi Doug, Good questions. We need to work on our website. DIVERSE does support OSG. The DGL component has a simple OSG scenegraph that you can use. DIVERSE works on Mac OS X platorms (except for DPF). Windows support is still under development. Parts of DIVERSE are windows friendly (DTK , DGL). However, on Windows it requires more work to make things work properly than on Linux. The DADS cluster support is ready for outside usage and I have heard that it is being installed at another site now. Let me know if you have any other questions, and feel free to give us feedback. We know DIVERSE isn't perfect, but it does some things very well in our humble opinion. Sincerely, Andrew A. Ray On Saturday 15 October 2005 11:39 am, Doug McCorkle wrote: > Hello, > I have a few questions regarding what diverse currently supports. > First, does diverse support OSG currently? It appears that in some > places on the web site that support is still coming but then in others > it looks like it is already there. Second, does diverse support the > win32 and mac os 10.X platforms? Third, is the DADS cluster support > still beta or is that ready for outside use? Thanks for the info. > > Doug > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > diverse-devel mailing list > div...@li... > https://lists.sourceforge.net/lists/listinfo/diverse-devel |
|
From: Doug M. <mc...@ia...> - 2005-10-15 16:39:29
|
Hello,
I have a few questions regarding what diverse currently supports.
First, does diverse support OSG currently? It appears that in some
places on the web site that support is still coming but then in others
it looks like it is already there. Second, does diverse support the
win32 and mac os 10.X platforms? Third, is the DADS cluster support
still beta or is that ready for outside use? Thanks for the info.
Doug
|
|
From: Patrick S. <psh...@vt...> - 2005-10-13 19:15:23
|
To all, OpenSceneGraph (as of 0.9.9) now uses AGL by default when building on Mac OS X. To build properly, export USE_AGL=no before building Producer and OpenSceneGraph. The INSTALL document with DGL has been updated. Pat |
|
From: Steve S. <st...@ni...> - 2005-10-11 21:18:26
|
Birds of a Feather at VIS 2005 -
DIVERSE - Flexible Open Source Software for Immersive Visualization
Thursday, October 27, 6:15-7:45PM
Hilton Minneapolis, Directors Row 4
DIVERSE is a cross-platform, open source, API for developing Virtual
Environment (VE) applications that can run almost anywhere from laptops to
multi-screen immersive environments. It has a highly flexible design which
emphasizes reuse and reconfiguration of tools over recoding.
DIVERSE provides:
* a common user interface to interactive graphics and/or VE programs.
Using DIVERSE the same program can be run on a CAVE(TM),
ImmersaDesk(TM), HMD, desktop and laptop without modification.
* a common API to VE oriented hardware such as trackers, wands,
joysticks, and motion bases.
* a "remote shared memory" facility that allows data from hardware or
computation to be asynchronously shared between both local and
remote processes
DIVERSE is being used for scientific visualization, architectural and
interior design walk-throughs, medical education and user interface design
studies and other applications in both immersive and desktop environments.
For information about DIVERSE see the web page- http://diverse.sourceforge.net
For information about the VIS 2005 BOF contact:
Steve Satterfield: st...@ni...
John Kelso: ke...@ni...
-Steve
|
|
From: John K. <ke...@be...> - 2005-10-04 17:06:28
|
Hi, I think a default build of n32 is OK. It needs to be able to build with 64 too. You're right- Performer no longer supplies o32 binaries, so no need to support that bintype. When I start to install on our Prism, I'll use the tarballs from sourceforge, to be sure I'm using the same code as everyone else. -John On Tue, 4 Oct 2005, Patrick Shinpaugh wrote: > Does anyone foresee problems making the default build for DPF on IRIX > -n32? Right now it has no default and therefor builds partially n32 and > partially o32 which results in an error halfway through if --enable-n32 > or --enable-64 was not specified as configure options. I believe > Performer is only n32 and n64 so o32 is unnecessary. > > If there are any comments or concerns please let me know ASAP > > > |
|
From: Patrick S. <psh...@vt...> - 2005-10-04 16:42:25
|
Does anyone foresee problems making the default build for DPF on IRIX -n32? Right now it has no default and therefor builds partially n32 and partially o32 which results in an error halfway through if --enable-n32 or --enable-64 was not specified as configure options. I believe Performer is only n32 and n64 so o32 is unnecessary. If there are any comments or concerns please let me know ASAP -- Patrick Shinpaugh Virginia Tech UVAG System Administrator/Programmer 540-231-2054 |
|
From: Patrick S. <psh...@vt...> - 2005-09-21 21:50:20
|
Added DTK_CLUSTER_TIMEOUT to allow configurable navWrite timeout
if the default of 20 seconds is not sufficient for larger
models.
Updated build and install to use GNU Autotools
Testing will begin tomorrow for latest dtk, dpf (hopefully), and dads
packages
--
Patrick Shinpaugh
Virginia Tech
UVAG System Administrator/Programmer
540-231-2054
|
|
From: Daniel L. <dla...@op...> - 2005-09-21 12:53:48
|
All,
Bugzilla allows us to vote on bugs. Each user gets a certain
number of votes (1000) and you can place up to 10 votes per bug. You
can change your vote at any time to redistribute your votes to newer
or more important bugs.
I suggest we use this feature to vote on the priority of bugs,
enhancements, or policies.
Dan
|
|
From: John K. <ke...@be...> - 2005-09-20 13:16:33
|
I'm not sure when NIST will get it installed on their IRIX machines either. I'll let you know when it happens. I'm not expecting any problems- Performer upgrades generally don't break DIVERSE. Not even going from 2.X to 3.X. Thanks, -John On Tue, 20 Sep 2005, Patrick Shinpaugh wrote: > I did not get a chance to test it on IRIX - only Linux. I tried both > dpf-2.3.2 and dpf-2.4.1 and both worked as expected. > > Pat > > |
|
From: Patrick S. <psh...@vt...> - 2005-09-20 13:11:20
|
I did not get a chance to test it on IRIX - only Linux. I tried both dpf-2.3.2 and dpf-2.4.1 and both worked as expected. Pat On Tue, 2005-09-20 at 09:06, John Kelso wrote: > Thanks Pat- I was about to give this a try. What version of dpf? > > Did you do it for both Linux & Irix? > > -John > > On Tue, 20 Sep 2005, Patrick Shinpaugh wrote: > > > I have found no issues with Performer 3.2.1 working with DIVERSE. > > > > > > On Tue, 2005-09-20 at 08:04, John Kelso wrote: > > > Hi, > > > > > > I built diverse with 3.2.0 a while back without any problems. I don't > > > expect any problems with 3.2.1 either, but will probably not get to it for > > > a couple of days. If you try it before I do, please let the group know if > > > you had any problems. > > > > > > Thanks, > > > > > > -John > > > > > > > > > On Tue, 20 Sep 2005, Raymond Wadie wrote: > > > > > > > > > > > Hi there > > > > How is everybody :) > > > > OpenGL Performer 3.2.1 is now available > > > > I was asking if it is ok to use it, or I should wait until somebody > > > > verify that it works fine with diverse? > > > > Thanks in advance > > > > > > > > Ray > > > > -----Original Message----- > > > > From: own...@pe... > > > > [mailto:own...@pe...] On Behalf Of Allan > > > > Schaffer > > > > Sent: Monday, September 19, 2005 6:26 PM > > > > To: info-performer Mailing List > > > > Subject: [info-performer] Announcement: OpenGL Performer 3.2.1 now > > > > available > > > > > > > > Hello Performers, > > > > > > > > SGI is very pleased to announce, OpenGL Performer 3.2.1 is now released! > > > > > > > > The web downloads for 64-bit Linux, 32-bit Linux, IRIX, and Windows OS > > > > platforms are all available. Please visit the Performer web site: > > > > > > > > <http://www.sgi.com/software/performer/> > > > > > > > > The Demo Edition of Performer 3.2.1 is available as a free web > > > > download. An SGI Supportfolio membership is required to access the > > > > download site. If you don't already have an SGI Supportfolio account > > > > you can sign up for free. > > > > > > > > Here's some of what's new for Performer 3.2.1. Check it out: > > > > > > > > Changes in OpenGL Performer 3.2.1 > > > > > > > > o Support for SGI ProPack 4 Service Pack 2. (SCR 936282) > > > > Performer now supports the SGI ProPack 4 Service Pack 2 > > > > operating system release for Silicon Graphics Prism. > > > > > > > > o Support for Microsoft Visual Studio 7. (SCR 929852) > > > > Performer now supports the Visual Studio 7 (.NET) > > > > compiler on Windows. > > > > > > > > o Performer City demo now included. (SCR 929989) > > > > The modern "Performer City" demonstration application is > > > > now bundled with OpenGL Performer. > > > > IRIX: /usr/sbin/pfCity > > > > Linux: /usr/X11R6/bin/pfCity > > > > Windows: %PFROOT%/bin/pfCity > > > > > > > > o New "sgi-performer-clipdemos" rpm on Linux. (SCR 902282) > > > > Sample cliptexture data is now shipped with OpenGL Performer > > > > for Linux in the sgi-performer-clipdemos RPM file. > > > > See: /usr/share/Performer/data/clipdata > > > > > > > > o 914835: Missing pfStats tokens. Headers and handlers for > > > > PFFSTATSVAL_PFTIMES_{NUMFRAMES_COMPUTE, APPSTAMP_COMPUTE, > > > > PROC_COMPUTE, MISSES_COMPUTE, HIST_ALL_COMPUTE} were missing. > > > > This has been fixed. > > > > > > > > o 920517: GeoArray stride information missing in PFB output. > > > > Added support for saving/storing pfGeoArray pfVertexAttr > > > > information in cases where stride information != (size of > > > > data type * # elements needed to represent type). > > > > > > > > o 924143: Prism/IA64 - C++ samples crash in pfMemory::ref(). > > > > Several samples and tools failed on 64-bit Prism systems > > > > with a stack trace leading to pfMemory::ref(). This was due > > > > to using 'new pfMemory' for array allocation. This has been > > > > fixed. > > > > > > > > o 924685: Manpages give error msg on SuSE Linux. "man pfNode" > > > > would give this error on SuSE Linux (32-bit and 64-bit): > > > > man: warning: /usr/man/man3/pfNode.3pf.c.gz: ignoring > > > > bogus filename > > > > man: warning: /usr/man/man3/pfNode.3pf.C++.gz: ignoring > > > > bogus filename > > > > No manual entry for pfNode. > > > > This has been fixed. > > > > > > > > o 927024: perfly powerwall modes require pipe or > > > > compositor list. perfly powerwall mode would hang if > > > > a pipe list was not specified. This has been fixed. > > > > > > > > o 927184: Onyx4: Fill stats cause perfly crash. Hangs > > > > and crashes could occur when enabling perfly 'Fill stats' > > > > on Onyx4. This has been fixed. > > > > > > > > o 928429: Performer does not reset attach address after > > > > usinit(). Arenas created by the user after calling pfConfig > > > > may fail with 'resource busy' errors. This has been fixed. > > > > > > > > o 929057: some pfdb header files missing on Windows. > > > > pfcsb.h, pfiv.h, pflsb.h, pfmedit.h, and pfptu.h were > > > > missing from <Performer/pfdb> on Windows. This has been > > > > fixed. > > > > > > > > o 929361: Performer 3.2 MP hangs on startup in pfGetTime(). > > > > When first starting perfly in any multi-process mode on an > > > > SMP linux system (2.6 kernel), the process will hang just > > > > after displaying the "OpenGL Performer" text. This has been > > > > fixed. > > > > > > > > o 935755: Onyx4: performer town textures have black spots. > > > > This has been fixed. > > > > > > > > o 936906: GL_LUMINANCE problems with emulated cliptextures. > > > > Cliptexture files specifying a 16-bit luminance format (such > > > > as the hl.L16.ct sample) were not supported when using > > > > cliptexture emulation. This has been fixed. > > > > > > > > o 936963: Problems in automatic clipsize shrinking. > > > > Calculations to automatically shrink a given cliptexture if > > > > it is too large to fit in texture memory were incorrect when > > > > using cliptexture emulation. This has been fixed. > > > > > > > > o 937271: undefined GL_FUNC_REVERSE_SUBTRACT_EXT in bump > > > > sample. Several EXT_blend_minmax, EXT_blend_subtract, and > > > > EXT_blend_logic_op tokens were missing or used incorrectly. > > > > This has been fixed. > > > > > > > > o 937327: pfuSelectFBConfig.c not installed on linux. The > > > > new pfuSelectFBConfig.c file was missing. This has been > > > > fixed. > > > > > > > > o 937657: windows version can't find license. After > > > > installing Performer for the first time, the user may be > > > > prompted by FlexLM for the location of a license. This has > > > > been fixed. > > > > > > > > Problems fixed in OpenGL Performer 3.2 rev E > > > > > > > > OpenGL Performer 3.2 rev E was a platform-specific release > > > > for Silicon Graphics Prism only. All 3.2 rev E fixes are now > > > > included in the all-platform OpenGL Performer 3.2.1 release. > > > > > > > > o 909953: Performance drop with latest nvidia drivers. The > > > > default visual was 8x multisampled. This has been corrected. > > > > > > > > o 919800, 912651, 924251: Support for Cliptexture Emulation. > > > > Cliptexture emulation is now functional on Silicon Graphics > > > > Prism and Silicon Graphics Onyx4 UltimateVision. > > > > > > > > o 914183: pfdBuildTopologyTravese() and > > > > pfTopo::buildTopology() failure. This has been corrected. > > > > > > > > o 921088: Support for SecondaryColor, FogCoords & > > > > VertexWeight. GeoArray support for these data types has > > > > been added. > > > > > > > > o 927186: perfly collision detections don't work in fly mode > > > > on Prism. This has been corrected. > > > > > > > > o 929514: pfGeoArrays don't handle odd strides. This has > > > > been corrected. > > > > > > > > o 930580: Perfly crash with large GeoArray pfb file. This > > > > has been corrected. > > > > > > > > o 930594: .gopt pseudoloader causes infinte loop. This has > > > > been corrected. > > > > > > > > o 931507: pfQuerySys calls in libpfdu slow file loading. > > > > This has been corrected. Note that applications containing > > > > repeated calls to pfQuerySys(PFQSYS_GL, &q) may also see > > > > delays. > > > > > > > > o 932929: 12-pipe support on Silicon Graphics Prism. OpenGL > > > > Performer now supports up to 12 pipes on Prism. > > > > > > > > o 932931: 4-compositor support on Silicon Graphics Prism. > > > > OpenGL Performer now supports up to 4 compositors on Prism. > > > > > > > > o 932934: Support for multiple X servers. OpenGL Performer > > > > now supports Silicon Graphics Prism systems configured with > > > > multiple X servers. > > > > > > > > o 932936: Multipipe GLSL. OpenGL Performer now supports > > > > OpenGL 2.0 GLSL in multi-pipe configurations > > > > > > > > o 933277: Non-power of 2 textures load incorrectly in > > > > Performer applications. NPOT textures are now partially > > > > supported. > > > > > > > > o 933387: perfly compositor options & pfCompositor man page. > > > > perfly's compositor options have been added to the perfly > > > > man page; and the missing pfCompositor man page is now > > > > included in the OpenGL Performer distribution. > > > > > > > > o 933727: Performer crashes when building topology for trim > > > > curves & shadow trim curves. This has been corrected. > > > > > > > > o 933777: Some transparent objects not rendered correctly on > > > > Silicon Graphics Prism. This has been corrected. > > > > > > > > o 934166: perfly GUI crashes. On Silicon Graphics Prism, if > > > > perfly is run in a multi-process mode with the GUI disabled, > > > > then the user presses F1 to bring up the GUI, the > > > > application crashes. This has been corrected. > > > > > > > > Problems fixed in OpenGL Performer 3.2 rev D > > > > > > > > OpenGL Performer 3.2 rev D was a platform-specific release > > > > for Silicon Graphics Prism only. All 3.2 rev D fixes are now > > > > included in the all-platform OpenGL Performer 3.2.1 release. > > > > > > > > o 925641: perfly crash on Prism depending on values assigned > > > > to PFSHAREDSIZE. Increased default PFSHAREDSIZE to 512MB. > > > > > > > > o 928974: pfGeoArray::tryVAOCache() is not multiprocess > > > > safe. This has been fixed. > > > > > > > > o 928975: Error in pfQueue::getNum(). This has been fixed. > > > > > > > > o 929848: Multipipe GLSL support in performer. GLSL support > > > > on Prism was only functional on a single pipe. This has > > > > been fixed. > > > > > > > > o 929850: OpenGL Multipipe interferes with OpenGL Performer. > > > > Performance may suffer if OpenGL Performer is used while the > > > > session is in OpenGL Multipipe mode. Prominent warnings > > > > have been added. > > > > > > > > o 929853: Additional Silicon Graphics Prism product line > > > > models are now recognized. > > > > > > > > o 929951: Performer fails when run under OMP. This has been > > > > fixed. > > > > > > > > o 931057: performer .gopt loader crash. Certain datasets > > > > could cause the .gopt Pseudo-Loader to crash. This has been > > > > fixed. > > > > > > > > o 931290: Perfly exits with segmentation fault. perfly would > > > > sometimes crash on systems with a hardware compositor > > > > attached. This has been fixed. > > > > > > > > o 932007: Use of hardware swap barriers now disabled by > > > > default with compositor. The use of swapbarrier > > > > functionality can sometimes cause a deadlock on Prism > > > > systems. Performer now disables this functionality by > > > > default, further changing the behavior from 3.2 rev C. To > > > > enable the previous behavior the user may set the > > > > environment variable PFCOMP_DO_SWAPBARRIERS to 1. > > > > > > > > > > > > Problems fixed in OpenGL Performer 3.2 rev C > > > > > > > > OpenGL Performer 3.2 rev C was a platform-specific release > > > > for Silicon Graphics Prism only. All 3.2 rev C fixes are now > > > > included in the all-platform OpenGL Performer 3.2.1 release. > > > > > > > > o 927225: Enable PF_SEMA_BEFORE_SWAP and PFU_LOAD_WIN_CURSOR > > > > workarounds for swapbarrier deadlock by default. Set either > > > > variable to 0 to revert to its pre-workaround behavior. > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > SF.Net email is sponsored by: > > > Tame your development challenges with Apache's Geronimo App Server. Download > > > it for free - -and be entered to win a 42" plasma tv or your very own > > > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > > > _______________________________________________ > > > diverse-devel mailing list > > > div...@li... > > > https://lists.sourceforge.net/lists/listinfo/diverse-devel > > -- Patrick Shinpaugh Virginia Tech UVAG System Administrator/Programmer 540-231-2054 |
145 messages has been excluded from this view by a project administrator.