http://blog.gmane.org/gmane.comp.graphics.opensg.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.graphics.opensg.devel/132 <pre>Hi all, according to the sourceforge statistics (&lt;http://sourceforge.net/projects/opensg/stats/scm?repo=GitRepository&amp;dates=2011-09-16%20to%202011-11-16&gt;) 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 </pre> Carsten Neumann 2011-11-17T16:31:16 http://comments.gmane.org/gmane.comp.graphics.opensg.devel/128 <pre>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 diff --git a/Source/Base/FieldContainer/Node/OSGNode.cpp b/Source/Base/FieldContainer/Node/OSGNode.cpp index f132e40..c505e50 100644 --- a/Source/Base/FieldContainer/Node/OSGNode.cpp +++ b/Source/Base/FieldContainer/Node/OSGNode.cpp &lt; at &gt;&lt; at &gt; -106,7 +106,7 &lt; at &gt;&lt; at &gt; void Node::classDescInserter(TypeObject &amp;oType) "volume", </pre> Carsten Neumann 2011-07-01T17:35:39 http://comments.gmane.org/gmane.comp.graphics.opensg.devel/126 <pre> 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 ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev </pre> Dirk Reiners 2011-06-21T22:42:03 http://comments.gmane.org/gmane.comp.graphics.opensg.devel/123 <pre>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 diff --git a/Source/Base/Base/OSGContainerForwards.h b/Source/Base/Base/OSGContainerForwards.h</pre> Carsten Neumann 2011-06-17T19:43:51 http://comments.gmane.org/gmane.comp.graphics.opensg.devel/122 <pre>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 From: Carsten Neumann &lt;carstenneumann-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f&lt; at &gt;public.gmane.org&gt; Date: Wed, 18 May 2011 19:02:17 -0500 Subject: [PATCH] changed: derive QT4Window from Window (not NativeWindow) : rename OSGQ4GLWidget -&gt; OSGQT4GLWidget fixed : single/multi thread Qt render example --- Source/WindowSystem/QT4/OSGQ4GLWidget_qt.cpp | 125 ----------- Source/WindowSystem/QT4/OSGQ4GLWidget_qt.h | 134</pre> Carsten Neumann 2011-05-19T00:09:58 http://comments.gmane.org/gmane.comp.graphics.opensg.devel/116 <pre> Hi All, on the OSG list there is some discussion about embedding OSG ina web page, and this just came through: Message: 2 Date: Thu, 07 Apr 2011 15:27:54 -0400 From: Peter Amstutz &lt;peter.amstutz-Tm69T9whmJaaMJb+Lgu22Q&lt; at &gt;public.gmane.org&gt; To: OpenSceneGraph Users &lt;osg-users-ZwoEplunGu0hajLcUbyfC12AsgEQdTeF&lt; at &gt;public.gmane.org&gt; Subject: Re: [osg-users] OSG plugin for browsers Message-ID: &lt;4D9E103A.9060901-Tm69T9whmJaaMJb+Lgu22Q&lt; at &gt;public.gmane.org&gt; Content-Type: text/plain; charset=ISO-8859-1 On 4/7/2011 5:30 AM, Thibault Genessay wrote: &gt; &gt; Other people have thought of alternatives to display 3D content: &gt; &gt; - osgjs - which re-implements the OSG in Javascript. Although the API &gt; &gt; is very close to the C++ one, it is not a way to embed an OSG app in a &gt; &gt; browser &gt; &gt; - webGL. If I am not mistaken, this leaves out the OSG entirely, and &gt; &gt; only aims at displaying 3D models. Kind of a new VRML thing. &gt; &gt; Just to clarify, WebGL consists of Javascript bindings for OpenGL, which are used by osgjs for rendering</pre> Dirk Reiners 2011-04-08T15:22:13 http://comments.gmane.org/gmane.comp.graphics.opensg.devel/114 <pre> Hi, I will be there so if anybody wants to talk about OpenSG, where it is going, where problems are, what we should change, what we should fix, what we did wrong, what we should address, ... Just drop me a line ;) kind regards gerrit </pre> Gerrit Voß 2011-03-15T04:14:48 http://comments.gmane.org/gmane.comp.graphics.opensg.devel/113 <pre>Hello all, just as an FYI I've set up a post-receive hook for the git repo on sourceforge to sent commit mails, the script is the one recommended by sf here: &lt;https://sourceforge.net/apps/trac/sourceforge/wiki/Git#Commitemailhooksetup&gt; and lives in /home/scm_git/o/op/opensg/opensg/hooks when using a sf shell - in case you feel like tuning it or there are problems and you need to disable it (just remove the post-receive symlink to the actual script). Cheers, Carsten ------------------------------------------------------------------------------ Free Software Download: Index, Search &amp; Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev </pre> Carsten Neumann 2011-03-03T16:53:14 http://comments.gmane.org/gmane.comp.graphics.opensg.devel/110 <pre> Dear all, as the sf cvs is back (with log mails ;)) I pushed the github commits back to sf so both repositories are identical again. If nobody wants me to keep him around I will remove the github tree and go back to let the cvs repository be the master. As I don't know how many people have adjusted their build scripts I'll leave the tree until early next week. kind regards gerrit </pre> Gerrit Voß 2011-02-26T00:46:57 http://comments.gmane.org/gmane.comp.graphics.opensg.devel/76 <pre>I would like to submit a patch that adds support for separate doxygen documentation for each OpenSG library similar to the discussion here&lt;http://www.opensg.org/wiki/Dev/Documentation&gt; . I added support for building separate doxygen documentation for each OpenSG library. The separate documentation trees reference the documentation of dependent libraries. New build targets are made for building the documentation of a library, e.g. to make the OSGDrawable library documentation use: make OSGDrawableDoc. This will build the dependent library docs first. The new cmake option OSG_GENERATE_SEPARATE_LIB_DOC can be used to turn the building of separate doxygen documentation on or off. By default it is off. I also added cmake configuration for installing doxygen documentation. If the new cmake option OSG_INSTALL_DOXYDOC is on then the doxygen documentation will be installed to &lt;INSTALL_PREFIX&gt;/share/OpenSG/documentation. By default OSG_INSTALL_DOXYDOC is off. The following is a link to an example build of th</pre> David Kabala 2011-01-21T00:05:45 http://comments.gmane.org/gmane.comp.graphics.opensg.devel/68 <pre> Hi, as this came up internally, can somebody give me a hint as to the status and where I can get started to look at it. It seems more sooner than later that I will need some form of (at least basic) script support. So I would like to have another structured go at it ;) kind regards gerrit </pre> Gerrit Voß 2011-01-11T07:49:36 http://comments.gmane.org/gmane.comp.graphics.opensg.devel/64 <pre>Hello all, I've a patch set (attached) that adds support for reading containers (not just nodes) to the SceneFileHandler and all SceneFileTypes in trunk (there was some talk about this a while back). I've taken the opportunity to also do some cleanup on the SFHandler/SFType interface, the most notable change is that the handler now gets passed down to the SFType. The motivation here is that currently it is not possible to safely load more than one file in parallel [1], because there is only one SFH and loaders access the singleton whenever they need to pull in additional files (changing e.g. the state of the PathHandler). If we allow the SFH to be cloned, each clone can operate in parallel with the others, as long as the loaders only operate on the instance passed to them. Of course for convenience a global instance remains accessible with SceneFileHandler::the(). Some things that I'd also like to add (so not in the patch yet): - For the parallel load to also work for images, I want to give th</pre> Carsten Neumann 2011-01-07T23:19:44 http://comments.gmane.org/gmane.comp.graphics.opensg.devel/63 <pre>Hello all, there is a planned network outage today in the building that houses the OpenSG web and subversion server. It is scheduled from 6PM - 12AM CDT. Apologies for the short notice. Cheers, Carsten ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev </pre> Carsten Neumann 2010-09-20T22:21:58 http://comments.gmane.org/gmane.comp.graphics.opensg.devel/56 <pre>Hello Gerrit, we are having one more problem with our app. The setup is like this: editor: Aspect 0: multiple threads implementing the editor logic Aspect 1: one thread sending changes to our cave cave: Aspect 0: one thread rendering Aspect 1: one thread receiving changes The cave part crashes under certain (reproducible) circumstances in AttachmentContainer::resolveLinks on the unlinkParent call. It looks like the attachment is already gone. Looking through the ref counting for the attachments I've noticed that there is the isMTLocal() check and depending on that a recorded or unrecorded ref change is made. I don't think that is correct, since the attachment map essentially behaves like a field and we never record the ref count changes made by a field, so I believe these should all be unrecorded. Indeed the attached patch fixes our problem. What do you think? The isMTLocal() change was done in r1357, maybe the commit message "record attachment refcounts if container is a bundle to fix multi as</pre> Carsten Neumann 2010-08-18T21:07:23 http://comments.gmane.org/gmane.comp.graphics.opensg.devel/47 <pre>Hello all, we've run into a problem with our app that runs multiple threads on one aspect when connecting it to a cluster server. Consider the following scenario: Thread A: - changes field F0 in container C in FC::registerChangedContainer _pContainerChanges points to an entry in the CL of Thread A. - commitChanges(); Thread B: - changes field F1 in container C because of the commitChanges _bvChanges == 0x00 so FC::registerChangedContainer runs, but only puts an uncommitted change for F1 into the CL of Thread B. - commitChanges(); The change to F1 will not be transmitted over the cluster, because it is lost after the commitChanges clears the uncommitedChanges list of the CL of Thread B. Attached is a patch that changes the behaviour of FC::registerChangedContainer() to only skip creation of a new CL entry if _pContainerChanges points into the current thread's CL. Comments? Other ideas to solve this? Cheers, Carsten -----------------------------------------------------------------------------</pre> Carsten Neumann 2010-08-13T22:40:43 http://comments.gmane.org/gmane.comp.graphics.opensg.devel/46 <pre>Hello Gerrit, I'm trying to find out what is causing our application to crash when I connect it to a render server and afterwards move the camera to bring an animated character into view (everything works fine if I connect after the character was already in view on the client). This is on Fedora 10, x86_64, OpenSG r2474. The problem seems to be related to ShaderProgramVariables/ShaderExecutable{,Var}Chunks, because the server prints messages about changes for unknown FC from RemoteAspect::receiveSync. Earlier in the logs (attached) these FC are created (in response to a CREATE message), but seem to die at the end of RemoteAspect::receiveSync. It is (sort of) possible to reproduce the problem with a slightly modified testClusterClient (attached) and unchanged testClusterServer [1]. As long as there is a call to Thread::getCurrentChangelist()-&gt;clear() in display() the program works, but the server complains about unknown FC. This makes sense because the CL entries for the creation of ShaderExe</pre> Carsten Neumann 2010-08-13T22:27:02 http://comments.gmane.org/gmane.comp.graphics.opensg.devel/43 <pre>Hello, any objections to installing the attached patch? The static_cast in Thread::getCurrent() is actually wrong if the current thread is an ExternalThread. There is some (low IMHO) potential to break applications, but doing the illegal cast is probably worse long term. Comments? Cheers, Carsten ------------------------------------------------------------------------------ </pre> Carsten Neumann 2010-05-07T02:42:55 http://comments.gmane.org/gmane.comp.graphics.opensg.devel/37 <pre>Hello Gerrit, I've been looking a bit at the details of Material and State (originally while analysing Micheal Raab's cluster problem [1]). One thing I've stumbled over is the ChunkBlock, which seems to behave very similar to State (i.e. different types of StateChunks end up at indices determined by their type). What is the difference between the two? I've also been wondering if it would make sense to make State not a FieldContainer - it mostly seems to be used as a cache for chunks in internal parts and especially in Material the multi buffering from being a FC is wasted because every aspect creates its very own State object. Any objections if I give this a try or reasons why this is a bad idea? Thanks, Carsten [1] see thread "OpenSG1.8 - Destroying Materials in ClusterMode" on opensg-users. ------------------------------------------------------------------------------ </pre> Carsten Neumann 2010-04-23T16:01:04 http://comments.gmane.org/gmane.comp.graphics.opensg.devel/32 <pre>Hello all, attached patch series changes the way we create RenderTreeNodes from doing it inside RenderPartition::dropFunctor to TreeBuilderBase::add (or derived). This seems a cleaner interface as the RPart now does not have to care what the different TreeBuilder actually store in the RTNode. It also allows moving occlusion culling specific data into OCRenderTreeNode that is only used by the OcclusionCullingTreeBuilder, reducing the size of the base RTNode. Comments? [1] Cheers, Carsten [1] I'll commit this at the end of the week if nobody objects. ------------------------------------------------------------------------------ </pre> Carsten Neumann 2010-04-20T19:37:20 http://comments.gmane.org/gmane.comp.graphics.opensg.devel/31 <pre>------------------------------------------------------------------------------ Download Intel&amp;#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev</pre> David Kabala 2010-04-13T16:39:02 http://comments.gmane.org/gmane.comp.graphics.opensg.devel/28 <pre> Hi, does anybody has a problem if we retire the OSG::Path / OSG::Dir stuff and switch to boost::filesystem instead ??. The only drawback I see is that we always have to link against a boost library. Comments ?? kind regards gerrit ------------------------------------------------------------------------------ Download Intel&amp;#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev </pre> Gerrit Voß 2010-04-09T07:07:04 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.graphics.opensg.devel