You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(9) |
Jun
(6) |
Jul
(9) |
Aug
(16) |
Sep
(17) |
Oct
(50) |
Nov
(12) |
Dec
(2) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(42) |
Feb
(1) |
Mar
(27) |
Apr
(20) |
May
(3) |
Jun
(4) |
Jul
(3) |
Aug
(6) |
Sep
(7) |
Oct
(22) |
Nov
(8) |
Dec
|
2005 |
Jan
(22) |
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
(18) |
Jul
|
Aug
(66) |
Sep
(46) |
Oct
(58) |
Nov
(11) |
Dec
(7) |
2006 |
Jan
|
Feb
(2) |
Mar
(16) |
Apr
(21) |
May
(23) |
Jun
(8) |
Jul
(18) |
Aug
(72) |
Sep
(98) |
Oct
(65) |
Nov
(26) |
Dec
(38) |
2007 |
Jan
(31) |
Feb
(45) |
Mar
(62) |
Apr
(19) |
May
(21) |
Jun
(37) |
Jul
(24) |
Aug
(14) |
Sep
(29) |
Oct
(32) |
Nov
(15) |
Dec
(9) |
2008 |
Jan
(11) |
Feb
(14) |
Mar
(27) |
Apr
(5) |
May
(29) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(5) |
Oct
|
Nov
(27) |
Dec
(20) |
2009 |
Jan
(51) |
Feb
(94) |
Mar
(40) |
Apr
(3) |
May
(11) |
Jun
(34) |
Jul
(23) |
Aug
(11) |
Sep
(3) |
Oct
(10) |
Nov
(2) |
Dec
(8) |
2010 |
Jan
(16) |
Feb
(13) |
Mar
(5) |
Apr
(16) |
May
(3) |
Jun
|
Jul
|
Aug
(17) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
2011 |
Jan
(18) |
Feb
(31) |
Mar
(2) |
Apr
(6) |
May
(2) |
Jun
(5) |
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
(8) |
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(8) |
Dec
|
From: Gundel D. <ope...@we...> - 2013-11-18 14:44:42
|
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>Hi Carsten,</div> <div> </div> <div> <pre>>> SET(Boost_USE_MULTITHREADED ON ) >> IF(NOT Boost_USE_STATIC_LIBS) >> SET(Boost_USE_STATIC_LIBS OFF CACHE INTERNAL "") >> ENDIF(NOT Boost_USE_STATIC_LIBS) </pre> <div> <pre>>Do you have any experience that shows other settings still result in >correctly working OpenSG libraries? That would go a long way towards >putting my worries at ease. Thanks! </pre> <div> </div> <div> <div>The point is that OpenSG sets Boost variables. And it does it in a way a user can't do anything about it than edit the file OSGConfigurePackages.cmake. It's ok for me.</div> <div>I'm missing symmetry. The second set (see above) uses the internal cache, the first doesn't do so. So why using different approaches for Boost_USE_MULTITHREADED and Boost_USE_STATIC_LIBS? Why not put both in the internal cache and protect them by a if statement? And then add Boost_USE_STATIC_RUNTIME?</div> <div>The (non-internal) cache is fine for advanced users, as they can check the advanced settings and change them.</div> </div> <div> <div>Well, you're absolutely right, one could shoot himself in the foot with these settings. I see, it's better to obviate trouble. As OpenSG libraries are shared, the dependencies should be shared as well. Else one could break ODR (global state). But one has the perfectly fine default settings for these settings.</div> I don't advise to mix shared and static libraries. One should absolutely know the linker or be prepared for UB.</div> </div> </div></div></body></html> |
From: Gundel D. <ope...@we...> - 2013-11-18 13:49:43
|
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div> <pre>> Can you give us a better idea of what you're trying to do? > > Yours > > Dirk</pre> <div> </div> <div>We have a cluster of 10 render nodes for our CAVE wired directly to a 10GE switch. The first 7 nodes responde under 0.1s. Those preceeding broadcasts seem to induce a little latecy, so that the last 3 nodes responde in >0.1. The broadcast times out and starts over...</div> <div>If I set the timeout to 1s or 10s everything starts fine and works. The application is absolutely fine in throuput and latency. It is fun. Even in VR! The problem concerns only the startup of the application.</div> <div>I even don't see an advantage to make the timeout configurable. The timeout is the worst case and if it is exceeded the same broadcast starts over and over again. This does more harm. I can see it if the timeout is 0.1s. The latency grows insanely.</div> <div> </div> <div>What do you think?</div> </div></div></body></html> |
From: Dirk R. <dir...@gm...> - 2013-11-16 22:21:40
|
On Sat, Nov 16, 2013 at 8:10 AM, Carsten Neumann < car...@gm...> wrote: > > > hmm, while I'm not sure if it will be much fun to run the cluster over > such a network, I also don't see much harm in increasing the timeout ;) > Anybody else have an opinion on it? Thanks! > Agreed, I don't see much harm in increasing it a little bit and/or making it configurable. But the main point is why you would need it. If your network is that slow as Carsten said a ClusterWindow will not be fun to use. Are you trying to use it to display something to a an actual remote (i.e. far away) machine? In that case it would probably be better to just use the RemoteAspect that underlies the ClusterWindow to sync the scenegraphs and have a local navigation and rendering loop on the remote side. Can you give us a better idea of what you're trying to do? Yours Dirk |
From: jan p s. <js...@ig...> - 2013-11-16 18:57:07
|
hi carsten, On 11/16/13 14:10, Carsten Neumann wrote: [ snip ] > hmm, while I'm not sure if it will be much fun to run the cluster over > such a network, I also don't see much harm in increasing the timeout ;) > Anybody else have an opinion on it? Thanks! [ snip ] wie w"are es denn diesen timeout konfigurierbar zu machen und den default auf einen kompromiss zw. 0.1s und 10s zu legen? dann kann sich jeder, bei bedarf, seine eigenes grab schauffeln :) hat sich eigentlich dein visa status gekl"art (oder sogar verbessert)? cheers from the other side of the pond, j. -- jan p springer js...@ig... dcs.hull.ac.uk j.s...@hu... |
From: Carsten N. <car...@gm...> - 2013-11-16 14:21:06
|
Hello, On 11/14/2013 04:04 AM, Gundel Dunkel wrote: > I have a request for a change in CMake/OSGConfigurePackages.cmake. > The boost library selection settings are hardcoded at the moment: > SET(Boost_USE_MULTITHREADED ON ) > IF(NOT Boost_USE_STATIC_LIBS) > SET(Boost_USE_STATIC_LIBS OFF CACHE INTERNAL "") > ENDIF(NOT Boost_USE_STATIC_LIBS) > (By the way, the IF statement is redundant, because this is the default > semantics for cache variables.) > It is much better to give a user the chance to change the settings at will: > SET(Boost_USE_MULTITHREADED ON CACHE BOOL "boost built with > multithreading support") > SET(Boost_USE_STATIC_LIBS OFF CACHE BOOL "boost built as static > library") > SET(Boost_USE_STATIC_RUNTIME OFF CACHE BOOL "boost built against > static msvcrt") > Now a user can change the settings in cmake if necessary. And the > default settings are set as before. > You can set the variables as advanced if you wish using mark_as_advanced(): > mark_as_advanced(Boost_USE_MULTITHREADED Boost_USE_STATIC_LIBS > Boost_USE_STATIC_RUNTIME) > Could you please make the boost setting more user friendly? hmm, I'm not certain if that would do more than *only* improve a users chance of shooting themselves in the foot. Using static boost libs for OpenSG is untested AFAIK, the multithreading settings should be consistent with the way OpenSG is built and I'm not even sure about the implications of using a static runtime for boost in this context. So my gut feeling (without having investigated this further) is that while we could give users a choice here, it has the potential of giving a false sense of choice, i.e. in practice the only settings that actually work would be the ones we currently enforce. Do you have any experience that shows other settings still result in correctly working OpenSG libraries? That would go a long way towards putting my worries at ease. Thanks! Cheers, Carsten |
From: Carsten N. <car...@gm...> - 2013-11-16 14:11:09
|
Hello, On 11/14/2013 03:49 AM, Gundel Dunkel wrote: > there is a deficiency in > Source/System/Cluster/Window/Base/OSGClusterWindow.cpp > The member function definition "void ClusterWindow::init(GLInitFunctor)" > contains an if statement "if(serviceSock.waitReadable(0.1))". The > member function waitReadable takes a timeout for the broadcast response > in seconds. But 0.1s is quite challenging in some infrastructures. 0.1s > will try the connection over and over again and fail. 1.0s works for me. > I even don't see a harm with a timeout of 10.0 seconds. > So please change the if statement to "if(serviceSock.waitReadable(10.0))". hmm, while I'm not sure if it will be much fun to run the cluster over such a network, I also don't see much harm in increasing the timeout ;) Anybody else have an opinion on it? Thanks! Cheers, Carsten |
From: Gundel D. <ope...@we...> - 2013-11-14 09:49:56
|
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>Hi,</div> <div> </div> <div>there is a deficiency in Source/System/Cluster/Window/Base/OSGClusterWindow.cpp</div> <div>The member function definition "void ClusterWindow::init(GLInitFunctor)" contains an if statement "if(serviceSock.waitReadable(0.1))". The member function waitReadable takes a timeout for the broadcast response in seconds. But 0.1s is quite challenging in some infrastructures. 0.1s will try the connection over and over again and fail. 1.0s works for me. I even don't see a harm with a timeout of 10.0 seconds.</div> <div> </div> <div>So please change the if statement to "if(serviceSock.waitReadable(10.0))".</div> <div> </div> <div>Thank you.</div></div></body></html> |
From: Carsten N. <car...@gm...> - 2011-11-28 17:10:40
|
Hi Gerrit, On 11/27/2011 11:46 PM, Gerrit Voss wrote: > - Log ----------------------------------------------------------------- > commitdiff: http://opensg.git.sourceforge.net/git/gitweb.cgi?p=opensg/opensg;a=commitdiff;h=f888cfda28ab6088438ece86f278ad906dd4e848 > commit f888cfda28ab6088438ece86f278ad906dd4e848 > Author: gerrit<vo...@vo...> > Date: Mon Nov 28 13:44:00 2011 +0800 > > changed: make rendering backend independent of viewport->window parent link > renamed viewport/camera functions that rely on this link to computeXXX > I know it's a bike-shedding thing, but there is some precedent for calling functions like that calcXXX (e.g. Image::calcIsAlphaBinary() or Camera::calcViewRay()) [1]. Did you deliberately pick a different prefix? If not would you object if I changed it? Cheers, Carsten [1] If we keep computeXXX, we should probably make it Camera::computeViewRay(), it kinda sticks out now ;) |
From: Gerrit V. <vo...@vo...> - 2011-11-22 21:23:46
|
Hi, On 22 Nov, 2011, at 1:28, Carsten Neumann <car...@gm...> wrote: > Hello Gerrit, > > On 11/18/2011 04:23 AM, Gerrit Voss wrote: >> - Log ----------------------------------------------------------------- >> commitdiff: http://opensg.git.sourceforge.net/git/gitweb.cgi?p=opensg/opensg;a=commitdiff;h=133b1edffdd88d5ff9278776d1c6279b75e831f9 >> commit 133b1edffdd88d5ff9278776d1c6279b75e831f9 >> Author: U-FHG_IDM_NTU\vossg<vo...@to...> >> Date: Fri Nov 18 18:21:29 2011 +0800 >> >> fixed: build with separately installed support libs (report by J. Brunen) > > I think this introduces some problems with builds not using support libs. On linux (Fedora 13, x86_64) creating a fresh build dir and running cmake in it gives these warnings: > > CMake Warning at CMake/BuildFunctions.cmake:2304 (FIND_PACKAGE): > Could not find module FindLibMini.cmake or a configuration file for package > LibMini. ok, could be I missed something. I'll check as soon as I'm back home from my current travels. kind regards gerrit |
From: Timm D. <Tim...@ig...> - 2011-11-22 15:28:22
|
Hey We have an external server but with an user management for project partners only. There are community licenses for non profit & open source development: http://www.atlassian.com/software/views/community-license-request But you could try the public Sandbox(es): http://sandbox.fisheye.atlassian.com http://sandbox.onjira.com http://sandbox.onconfluence.com ... There is also a List of public fisheye installations like apache or java so you could actually see some code: http://fisheye.cenqua.com/ Sincerely Timm > -----Original Message----- > From: Dirk Reiners [mailto:dir...@gm...] > Sent: Dienstag, 22. November 2011 00:01 > To: ope...@li... > Cc: <ope...@li...> > Subject: Re: [Opensg-core] 800+ daily transactions on git repo? > > Hi Timm, > > Interesting tool. Are you using the Open Source version? If so, can you give us the access URL? I'm curious what it looks like... ;) > > Yours > > Dirk > > -- Sent from my iPhone, typos courtesy Apple^TM > > On Nov 21, 2011, at 14:32, "Timm Drevensek" <Tim...@ig...> wrote: > > > My fault > > > > It's our Atlassian Fisheye installation, scrolling for changes every ~2 minutes. > > I'll change it to around 30 minutes or so. > > > > > > Sincerely > > Timm > > > > > >> -----Original Message----- > >> From: Carsten Neumann [mailto:car...@gm...] > >> Sent: Thursday, November 17, 2011 5:31 PM > >> To: opensg-core > >> Cc: Dirk Reiners > >> Subject: [Opensg-core] 800+ daily transactions on git repo? > >> > >> Hi all, > >> > >> according to the sourceforge statistics > >> (<http://sourceforge.net/projects/opensg/stats/scm?repo=GitRepository > >> &dates=2011-09-16%20to%202011-11-16>) > >> our git repo gets about 800 anonymous read only transactions each day. > >> Popularity is nice, but this looks more like an out of control script to me... > >> Any ideas? > >> > >> Cheers, > >> Carsten > >> > >> --------------------------------------------------------------------- > >> --------- All the data continuously generated in your IT > >> infrastructure contains a definitive record of customers, application > >> performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common > sense. > >> http://p.sf.net/sfu/splunk-novd2d > >> _______________________________________________ > >> Opensg-core mailing list > >> Ope...@li... > >> https://lists.sourceforge.net/lists/listinfo/opensg-core > > > > > > ---------------------------------------------------------------------- > > -------- All the data continuously generated in your IT infrastructure > > contains a definitive record of customers, application performance, > > security threats, fraudulent activity, and more. Splunk takes this > > data and makes sense of it. IT sense. And common sense. > > http://p.sf.net/sfu/splunk-novd2d > > _______________________________________________ > > Opensg-core mailing list > > Ope...@li... > > https://lists.sourceforge.net/lists/listinfo/opensg-core > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > _______________________________________________ > Opensg-core mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensg-core |
From: Dirk R. <dir...@gm...> - 2011-11-21 23:01:25
|
Hi Timm, Interesting tool. Are you using the Open Source version? If so, can you give us the access URL? I'm curious what it looks like... ;) Yours Dirk -- Sent from my iPhone, typos courtesy Apple^TM On Nov 21, 2011, at 14:32, "Timm Drevensek" <Tim...@ig...> wrote: > My fault > > It's our Atlassian Fisheye installation, scrolling for changes every ~2 minutes. > I'll change it to around 30 minutes or so. > > > Sincerely > Timm > > >> -----Original Message----- >> From: Carsten Neumann [mailto:car...@gm...] >> Sent: Thursday, November 17, 2011 5:31 PM >> To: opensg-core >> Cc: Dirk Reiners >> Subject: [Opensg-core] 800+ daily transactions on git repo? >> >> Hi all, >> >> according to the sourceforge statistics >> (<http://sourceforge.net/projects/opensg/stats/scm?repo=GitRepository&dates=2011-09-16%20to%202011-11-16>) >> our git repo gets about 800 anonymous read only transactions each day. >> Popularity is nice, but this looks more like an out of control script to me... >> Any ideas? >> >> Cheers, >> Carsten >> >> ------------------------------------------------------------------------------ >> All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, >> security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. >> http://p.sf.net/sfu/splunk-novd2d >> _______________________________________________ >> Opensg-core mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/opensg-core > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > _______________________________________________ > Opensg-core mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensg-core |
From: Carsten N. <car...@gm...> - 2011-11-21 22:52:21
|
Hello Tim, On 11/21/2011 04:32 PM, Timm Drevensek wrote: > It's our Atlassian Fisheye installation, scrolling for changes every ~2 minutes. > I'll change it to around 30 minutes or so. it's not a big deal, after all the traffic is not going to one of our servers, but to sourceforge; so my message was mostly curiosity :) Anyway, given the commit frequency to the repo 30 minutes between checks is probably sufficient. Thanks for looking into it! Cheers, Carsten |
From: Timm D. <Tim...@ig...> - 2011-11-21 22:32:15
|
My fault It's our Atlassian Fisheye installation, scrolling for changes every ~2 minutes. I'll change it to around 30 minutes or so. Sincerely Timm > -----Original Message----- > From: Carsten Neumann [mailto:car...@gm...] > Sent: Thursday, November 17, 2011 5:31 PM > To: opensg-core > Cc: Dirk Reiners > Subject: [Opensg-core] 800+ daily transactions on git repo? > > Hi all, > > according to the sourceforge statistics > (<http://sourceforge.net/projects/opensg/stats/scm?repo=GitRepository&dates=2011-09-16%20to%202011-11-16>) > our git repo gets about 800 anonymous read only transactions each day. > Popularity is nice, but this looks more like an out of control script to me... > Any ideas? > > Cheers, > Carsten > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > _______________________________________________ > Opensg-core mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensg-core |
From: Carsten N. <car...@gm...> - 2011-11-21 17:28:58
|
Hello Gerrit, On 11/18/2011 04:23 AM, Gerrit Voss wrote: > - Log ----------------------------------------------------------------- > commitdiff: http://opensg.git.sourceforge.net/git/gitweb.cgi?p=opensg/opensg;a=commitdiff;h=133b1edffdd88d5ff9278776d1c6279b75e831f9 > commit 133b1edffdd88d5ff9278776d1c6279b75e831f9 > Author: U-FHG_IDM_NTU\vossg<vo...@to...> > Date: Fri Nov 18 18:21:29 2011 +0800 > > fixed: build with separately installed support libs (report by J. Brunen) I think this introduces some problems with builds not using support libs. On linux (Fedora 13, x86_64) creating a fresh build dir and running cmake in it gives these warnings: CMake Warning at CMake/BuildFunctions.cmake:2304 (FIND_PACKAGE): Could not find module FindLibMini.cmake or a configuration file for package LibMini. Adjust CMAKE_MODULE_PATH to find FindLibMini.cmake or set LibMini_DIR to the directory containing a CMake configuration file for LibMini. The file will have one of the following names: LibMiniConfig.cmake libmini-config.cmake Call Stack (most recent call first): CMake/ConfigurePackages.cmake:802 (OSG_FIND_PACKAGE) CMakeLists.txt:674 (OSG_CONFIGURE_LIBMINI) CMake Warning at CMake/BuildFunctions.cmake:2304 (FIND_PACKAGE): Could not find module FindOpenNurbs.cmake or a configuration file for package OpenNurbs. Adjust CMAKE_MODULE_PATH to find FindOpenNurbs.cmake or set OpenNurbs_DIR to the directory containing a CMake configuration file for OpenNurbs. The file will have one of the following names: OpenNurbsConfig.cmake opennurbs-config.cmake Call Stack (most recent call first): CMake/ConfigurePackages.cmake:584 (OSG_FIND_PACKAGE) CMakeLists.txt:684 (OSG_CONFIGURE_OPENNURBS) Should these FIND_PACKAGE calls just be changed to do FIND_PACKAGE(<name>_OpenSG ...) to use the modules in our CMake/ dir? Or are there some files missing from the commit? Cheers, Carsten |
From: Carsten N. <car...@gm...> - 2011-11-17 16:31:25
|
Hi all, according to the sourceforge statistics (<http://sourceforge.net/projects/opensg/stats/scm?repo=GitRepository&dates=2011-09-16%20to%202011-11-16>) our git repo gets about 800 anonymous read only transactions each day. Popularity is nice, but this looks more like an out of control script to me... Any ideas? Cheers, Carsten |
From: Carsten N. <car...@gm...> - 2011-07-05 16:19:20
|
Hello Gerrit, On 07/03/2011 09:45 PM, Gerrit Voß wrote: > ok, I committed your old change origin patch, ok, thanks, especially for catching this: // I don't think clear is correct here if the apps expects to tap // into the changes they will be gone (GV) //pDstCL->commitChangesAndClear(ChangedOrigin::Sync); I agree, clear is not the right thing to do here. > for the map in > shaderprogvars I fixed it so it behaves the same as the local > MT sync an rebuilds the map if the var fields are changed during > a sync. I also pushed the map down to ShaderProgramVariables and > removed the access class as ShaderProgramVariables has taken over > that part anyway so there should be no need for a separate class > anymore. ok, I had mostly kept it separate so that there is a type that can be put in a SField and synced across the cluster. > I did some basic testing and it looks ok, the values are > updated and no warnings are printed. a quick test here seems to confirm this, I also don't get the warnings any more. Thanks & cheers, Carsten |
From: Gerrit V. <vo...@vo...> - 2011-07-04 02:46:00
|
Hi, On Sun, 2011-07-03 at 08:59 +0800, Gerrit Voß wrote: > Hi, > > On Fri, 2011-07-01 at 12:35 -0500, Carsten Neumann wrote: > > Hello all, > > > > I'd like to make Node::_sfVolume a non-internal field and modify the OSB > > loader/writer to write it out in certain cases (see attached patch). > > > > If a volume is marked as static or infinite, written to OSB and read > > back in that information is lost. I see this when loading from OGRE > > .mesh files (which can contain an explicit volume in case the mesh is > > animated to contain all motions the mesh goes through) storing to OSB > > and loading that back in. > > > > Luckily the OSB format is robust enough that we don't have to bump the > > version number - old versions of OpenSG load OSBs written by ones with > > the patch applied and the other way around. > > > > Any objections/comments? > > looks ok to me, I'm just going to your old patches (changed > origin / shader var). For the shaders I have to have a deeper > look there is something odd already without you patchset which > I want to fix first. ok, I committed your old change origin patch, for the map in shaderprogvars I fixed it so it behaves the same as the local MT sync an rebuilds the map if the var fields are changed during a sync. I also pushed the map down to ShaderProgramVariables and removed the access class as ShaderProgramVariables has taken over that part anyway so there should be no need for a separate class anymore. I did some basic testing and it looks ok, the values are updated and no warnings are printed. kind regards gerrit |
From: Gerrit V. <vo...@vo...> - 2011-07-03 00:59:57
|
Hi, On Fri, 2011-07-01 at 12:35 -0500, Carsten Neumann wrote: > Hello all, > > I'd like to make Node::_sfVolume a non-internal field and modify the OSB > loader/writer to write it out in certain cases (see attached patch). > > If a volume is marked as static or infinite, written to OSB and read > back in that information is lost. I see this when loading from OGRE > .mesh files (which can contain an explicit volume in case the mesh is > animated to contain all motions the mesh goes through) storing to OSB > and loading that back in. > > Luckily the OSB format is robust enough that we don't have to bump the > version number - old versions of OpenSG load OSBs written by ones with > the patch applied and the other way around. > > Any objections/comments? looks ok to me, I'm just going to your old patches (changed origin / shader var). For the shaders I have to have a deeper look there is something odd already without you patchset which I want to fix first. kind regards gerrit |
From: Carsten N. <car...@gm...> - 2011-07-01 17:35:47
|
Hello all, I'd like to make Node::_sfVolume a non-internal field and modify the OSB loader/writer to write it out in certain cases (see attached patch). If a volume is marked as static or infinite, written to OSB and read back in that information is lost. I see this when loading from OGRE .mesh files (which can contain an explicit volume in case the mesh is animated to contain all motions the mesh goes through) storing to OSB and loading that back in. Luckily the OSB format is robust enough that we don't have to bump the version number - old versions of OpenSG load OSBs written by ones with the patch applied and the other way around. Any objections/comments? Cheers, Carsten |
From: Gerrit V. <vo...@vo...> - 2011-06-22 03:40:47
|
Hi, On Tue, 2011-06-21 at 17:42 -0500, Dirk Reiners wrote: > Hi Gerrit, > > I was trying to set up my Windows box using the CMakeFiles under /Support/, but > I can't get that to work. > > I started with ZLib, but the structure that the Support/zlib/CMakeLsits expects > is not the one found in the normal download > (http://prdownloads.sourceforge.net/libpng/zlib-1.2.5.tar.gz?download) (no > source/ dir). > > Is that an artifact of you using the php downloads originally, or is that not > how this is supposed to be used? yep, there seems to be a difference between the php downloads I started with and the sf png ones I updated too :(. I lifted the new links from the mailing list but did not really test them. Will do that ;) kind regards gerrit |
From: Dirk R. <dir...@gm...> - 2011-06-21 22:38:21
|
Hi Gerrit, I was trying to set up my Windows box using the CMakeFiles under /Support/, but I can't get that to work. I started with ZLib, but the structure that the Support/zlib/CMakeLsits expects is not the one found in the normal download (http://prdownloads.sourceforge.net/libpng/zlib-1.2.5.tar.gz?download) (no source/ dir). Is that an artifact of you using the php downloads originally, or is that not how this is supposed to be used? Thanks Dirk |
From: Carsten N. <car...@gm...> - 2011-06-20 23:11:28
|
Hello Gerrit, On 06/19/2011 05:07 AM, Gerrit Voß wrote: > On Fri, 2011-06-17 at 14:43 -0500, Carsten Neumann wrote: >> Apart from unnecessarily recomputing the values, this produces lots of >> warnings from ShaderVariableAccess::updateSVariable, because the >> variable names are not in the map on the remote side (perhaps that's a >> bug too?). > > I'll check, but until end of tomorrow (Monday) I'm extremely overloaded, > I'll try to get to it Tuesday. sure, no problem - I just prefer to bounce these things by you in case I've missed something that does not show up in our use cases ;) Even with the previous changes I still had trouble preventing the variable updates (and therefore got the warnings) and couldn't see anything that would prevent transmitting the map. The attached patch implements this (introduces a type ShaderVariableMap, defines a FieldTrait for it and adjusts uses). I still think the previous patch has value, but for my initial goal to get rid of warnings from unknown shader variables this on works better ;) What do you think? Cheers, Carsten |
From: Gerrit V. <vo...@vo...> - 2011-06-19 10:07:29
|
Hi, On Fri, 2011-06-17 at 14:43 -0500, Carsten Neumann wrote: > Hello Gerrit, all, > > the attached patch changes changedFunctors to receive the change origin > as an additional argument - so this may break applications that register > changed functors. > It also makes sure that during a ChangeList::apply or a > RemoteAspect::receiveSync the changed functions of containers are called > with ChangedOrigin::Sync instead of the normal ChangedOrigin::Commit. > > The motivation for this is that when using GPU skinned characters in a > cluster where the client renders locally as well, the shader variables > already have the correct values set, but GPUSkinningAlgorithm marks them > invalid because it receives a changed notification from the Skeleton. > Apart from unnecessarily recomputing the values, this produces lots of > warnings from ShaderVariableAccess::updateSVariable, because the > variable names are not in the map on the remote side (perhaps that's a > bug too?). I'll check, but until end of tomorrow (Monday) I'm extremely overloaded, I'll try to get to it Tuesday. kind regards gerrit |
From: Carsten N. <car...@gm...> - 2011-06-17 19:44:03
|
Hello Gerrit, all, the attached patch changes changedFunctors to receive the change origin as an additional argument - so this may break applications that register changed functors. It also makes sure that during a ChangeList::apply or a RemoteAspect::receiveSync the changed functions of containers are called with ChangedOrigin::Sync instead of the normal ChangedOrigin::Commit. The motivation for this is that when using GPU skinned characters in a cluster where the client renders locally as well, the shader variables already have the correct values set, but GPUSkinningAlgorithm marks them invalid because it receives a changed notification from the Skeleton. Apart from unnecessarily recomputing the values, this produces lots of warnings from ShaderVariableAccess::updateSVariable, because the variable names are not in the map on the remote side (perhaps that's a bug too?). Comments? Cheers, Carsten |
From: Carsten N. <car...@gm...> - 2011-05-19 00:10:09
|
Hello Gerrit, attached patch modifies QT4Window to not derive from NativeWindow (but from Window instead). It also brings the examples for rendering from the GUI thread and for rendering from a separate thread into the QGLWidget back to working condition (only tested on X11). I believe the motivation for deriving from NativeWindow was the parallel drawer that needs to be able to activate the context when needed, but the proposed solution should keep that and seems neater than attempting to capture the Qt created context with platform specific code. Comments? Cheers, Carsten |