Content-type: text/plain; charset=us-ascii
This is a Mailman mailing list bounce action notice:
List: Opensg-users
Member: [EMAIL PROTECTED]
Action: Subscription disabled.
Reason: Excessive or fatal bounces.
You can reenable their subscription by visiting the membership
management page at
https://lists.sourceforge.net/lists/admin/opensg-users/members and
setting their options accordingly
The triggering bounce notice is attached below.
Questions? Contact the Mailman site administrator at
[EMAIL PROTECTED]
This is a MIME-encapsulated message.
--F1BFC3392F.1115840077/sc8-sf-spam1.sourceforge.net
Content-Description: Notification
Content-Type: text/plain
This is the Postfix program at host sc8-sf-spam1.sourceforge.net.
I'm sorry to have to inform you that the message returned
below could not be delivered to one or more destinations.
For further assistance, please send mail to <postmaster>
If you do so, please include this problem report. You can
delete your own text from the message returned below.
The Postfix program
<[EMAIL PROTECTED]>: host europa.cg.cs.tu-bs.de[134.169.37.4] said: 550
Rejected because of SPAM (in reply to end of DATA command)
--F1BFC3392F.1115840077/sc8-sf-spam1.sourceforge.net
Content-Description: Delivery error report
Content-Type: message/delivery-status
Reporting-MTA: dns; sc8-sf-spam1.sourceforge.net
Arrival-Date: Wed, 11 May 2005 12:32:32 -0700 (PDT)
Final-Recipient: rfc822; [EMAIL PROTECTED]
Action: failed
Status: 5.0.0
Diagnostic-Code: X-Postfix; host europa.cg.cs.tu-bs.de[134.169.37.4] said: 550
Rejected because of SPAM (in reply to end of DATA command)
--F1BFC3392F.1115840077/sc8-sf-spam1.sourceforge.net
Content-Description: Undelivered Message
Content-Type: message/rfc822
Received: from projects.sourceforge.net (sc8-sf-list2-b.sourceforge.net
[10.3.1.8])
by sc8-sf-spam1.sourceforge.net (Postfix) with ESMTP
id F1BFC3392F; Wed, 11 May 2005 12:32:32 -0700 (PDT)
Date: Wed, 11 May 2005 12:30:17 -0700
From: [EMAIL PROTECTED]
Subject: Opensg-users digest, Vol 1 #1043 - 9 msgs
X-Mailer: Mailman v2.0.9-sf.net
MIME-version: 1.0
Content-type: text/plain
To: [email protected]
Sender: [EMAIL PROTECTED]
Errors-To: [EMAIL PROTECTED]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
Reply-To: [email protected]
X-Reply-To: [email protected]
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/opensg-users>,
<mailto:[EMAIL PROTECTED]>
List-Id: <opensg-users.lists.sourceforge.net>
List-Post: <mailto:[email protected]>
List-Help: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/opensg-users>,
<mailto:[EMAIL PROTECTED]>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=opensg-users>
Message-Id: <[EMAIL PROTECTED]>
Send Opensg-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/opensg-users
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Opensg-users digest..."
Today's Topics:
1. Re: got an mfc application running opensg ([EMAIL PROTECTED])
2. Re: Opensg-users digest, Vol 1 #1042 - 9 msgs (Marc Hartmann)
3. Function objects ... possible bug / behaviour (Marcus Lindblom)
4. List problems? (Dirk Reiners)
5. Re: Screenshot! (Dirk Reiners)
6. Re: Aspects consuming memory (Johan Grafstrom)
7. List problems, especially gmail (Dirk Reiners)
8. Re: got an mfc application running opensg (Andreas Zieringer)
9. Re: Aspects consuming memory (Dirk Reiners)
--__--__--
Message: 1
Date: Wed, 11 May 2005 10:38:26 +0200 (MEST)
From: [EMAIL PROTECTED]
To: [email protected]
Subject: Re: [Opensg-users] got an mfc application running opensg
Reply-To: [email protected]
Hi Tariq,
I've got some time at the weekend. If you send me your sources I could take
a look at them for finding the error. My own MFC integration has some other
dependcies making it difficult to separate the OpenSG part.
Greets,
Patrik
--
+++ Lassen Sie Ihren Gedanken freien Lauf... z.B. per FreeSMS +++
GMX bietet bis zu 100 FreeSMS/Monat: http://www.gmx.net/de/go/mail
--__--__--
Message: 2
Date: Wed, 11 May 2005 12:00:16 +0200
From: "Marc Hartmann" <[EMAIL PROTECTED]>
To: [email protected]
Organization: http://freemail.web.de/
Subject: [Opensg-users] Re: Opensg-users digest, Vol 1 #1042 - 9 msgs
Reply-To: [email protected]
This is MIME
-----SKER1115805617--
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Hi Marcus,
nice. Go on.
Greetings
Marc
> Message: 7
> Date: Tue, 10 May 2005 17:02:16 +0200
> From: Marcus Lindblom <[EMAIL PROTECTED]>
> To: [email protected]
> Subject: [Opensg-users] Screenshot!
> Reply-To: [email protected]
>
> Hi all,
>
> Here's a shot of my shader in action: http://yar.nu/macke/screenshot.png
>
> Enjoy,
> /Marcus
>
-----SKER1115805617--
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIIFlgYJKoZIhvcNAQcCoIIFhzCCBYMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3
DQEHAaCCA/IwggPuMIIC1qADAgECAgQCrJa+MA0GCSqGSIb3DQEBBAUAMIGgMQsw
CQYDVQQGEwJERTESMBAGA1UEChMJV0VCLkRFIEFHMRUwEwYDVQQLEwxUcnVzdCBD
ZW50ZXIxGjAYBgNVBAcTEUQtNzYyMjcgS2FybHNydWhlMS0wKwYDVQQDEyRXRUIu
REUgVHJ1c3RDZW50ZXIgRU1haWwtWmVydGlmaWthdGUxGzAZBgkqhkiG9w0BCQEW
DHRydXN0QHdlYi5kZTAeFw0wNDA3MDgyMjQ4NTVaFw0wNTA3MDgyMjQ4NTVaMHIx
CzAJBgNVBAYTAkRFMRQwEgYDVQQIEwtEZXV0c2NobGFuZDEWMBQGA1UEBxMNMjAw
OTkgSGFtYnVyZzEWMBQGA1UEAxMNTWFyYyBIYXJ0bWFubjEdMBsGCSqGSIb3DQEJ
ARYObWFyYy43MUB3ZWIuZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAK7V
6koX+moSlabiGFDworBHs3YoHxCsHggt6JOikqZ5temPfn0BuPnsFyWcOepJQ8up
c0aIXwdPwwWUCO2ZQd/evXC+LX745aZ5mLZOiNDEMf3OU2sOeESS8TwpQHLGofrx
LRxnVC0/hxBzxDmtfm4e3O+VyrZoxBTva4sO7/l3AgMBAAGjgeAwgd0wLAYJYIZI
AYb4QgEEBB8WHWh0dHBzOi8vdHJ1c3Qud2ViLmRlL3J2Q0EvP3M9MCMGCWCGSAGG
+EIBAgQWFhRodHRwczovL3RydXN0LndlYi5kZTAWBglghkgBhvhCAQMECRYHL3J2
Lz9zPTAWBglghkgBhvhCAQcECRYHL3JuLz9zPTAaBglghkgBhvhCAQgEDRYLL0hp
bGZlL0FHQi8wKQYJYIZIAYb4QgENBBwWGkZyZWVtYWlsIEVtYWlsIGNlcnRpZmlj
YXRlMBEGCWCGSAGG+EIBAQQEAwIAsDANBgkqhkiG9w0BAQQFAAOCAQEAdOpU9aP1
UVB1EoAlPyuo/a6OpjZ7Z9DE53Occj3PcSMEzam0FPfg5DVrx3hsZenmrYxRuUkh
QscfcfWX2dPc++gBF/h6y7hDkLzYm4U+CLG6UKl/0OhJs4OPib3cLCatuOs7lw9t
vcupT+d0GVZXO+D6dwcaONHLIyZrfCI8gdFukchbibsATXFTrheo0TmsD6nzlrKB
Bv7HUaU/oXE9uIZ3K6bqUEBA1+nXMgM36LqayHSIhdwVwM+3j7A3NQQntcmbIxNY
zVCNMs7oDrkplvtKpaHFkOF01kElT1kvahtPHkVm2Mf018Jl/K58vX07ccnSeaHq
qXU/OqSHzW2FgzGCAWwwggFoAgEBMIGpMIGgMQswCQYDVQQGEwJERTESMBAGA1UE
ChMJV0VCLkRFIEFHMRUwEwYDVQQLEwxUcnVzdCBDZW50ZXIxGjAYBgNVBAcTEUQt
NzYyMjcgS2FybHNydWhlMS0wKwYDVQQDEyRXRUIuREUgVHJ1c3RDZW50ZXIgRU1h
aWwtWmVydGlmaWthdGUxGzAZBgkqhkiG9w0BCQEWDHRydXN0QHdlYi5kZQIEAqyW
vjAJBgUrDgMCGgUAMA0GCSqGSIb3DQEBAQUABIGAPo6rUgTvt/tsPv3scH6cOA8v
Disb63S/i0laZhyxAR43Hp++7Ydx5R+dfD2lGK9/LATp9TwIEhfCUvgGeM63Vs9j
flj2o4gN/fcKq87BCWH3+z+mth90YfEjqB7svuFzoAC+buyyv3MtQBpYwckEGbe9
kUeoO2B6JSMopFtM6TihGjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB
-----SKER1115805617----
--__--__--
Message: 3
Date: Wed, 11 May 2005 16:03:18 +0200
From: Marcus Lindblom <[EMAIL PROTECTED]>
To: [email protected]
Subject: [Opensg-users] Function objects ... possible bug / behaviour
Reply-To: [email protected]
Hi all,
Just a heads-up, no real bug-report per se.
I was mucking about with the function objects and graph traversal, and
found that encapsulation boost function objects in the traversefunctors
sometimes do not work at all. (The stored object didn't cast back
properly when it was invocation time, i.e. some copy/conversion did not
work as expected). I merely did some refactoring that should have no
effect on this (it worked ok for quite some time) and it stopped working.
I can't really say exactly what I did (too many changes) but obviously
there was something that caused the conversion to fail.
I didn't have time to track this down, as it was faster to copy-paste
the osg::traverse-code, make it templated and have that use generic
function objects. That solved my problem. (I could probably write one
that uses boost::function this making the traverse code non-template to
minimize code-bloat, but so far this hasn't been a problem).
I suspect the way objects are stored (memcpy to char & stuff) in
OpenSG's functors are the cause for this, and there was some
undocumented restriction that I fell upon (using a pointer pointing back
to the function object itself perhaps, that would defeat this scheme).
A fix would be to not copy data with memcpy but to leave it in memory
via a ptr to a base class instead (defining a virtual operator()(...))
with the template-invocation implementing it.
Anyway, just wanted to let you know.. it could happen to you! ;)
(unless it's been fixed?)
Best regards
/Marcus
FYI: This is still vanilla OpenSG 1.4.
--__--__--
Message: 4
From: Dirk Reiners <[EMAIL PROTECTED]>
To: users <[email protected]>
Date: Wed, 11 May 2005 10:36:22 -0500
Subject: [Opensg-users] List problems?
Reply-To: [email protected]
Hi folks,
I've been having a little trouble sending stuff to the list lately, and
I know at least one other person who's message didn't go through.
If anybody else has problems, please send me a private mail so I can
take a closer look. If you got rejection messages, please include those
in your mail.
Thanks
Dirk
--
-- Dirk Reiners OpenSG Forum [EMAIL PROTECTED]
-- The OpenSG Open Source Scenegraph: http://www.opensg.org
-- Join the list at http://lists.sf.net/lists/listinfo/opensg-users
--__--__--
Message: 5
Subject: Re: [Opensg-users] Screenshot!
From: Dirk Reiners <[EMAIL PROTECTED]>
To: users <[email protected]>
Date: Wed, 11 May 2005 10:40:16 -0500
Reply-To: [email protected]
Hi Marcus,
On Tue, 2005-05-10 at 17:02 +0200, Marcus Lindblom wrote:
> Hi all,
>
> Here's a shot of my shader in action: http://yar.nu/macke/screenshot.png
hey, that looks pretty neat! Is this for a specific project or just for
fun?
Dirk
--
-- Dirk Reiners OpenSG Forum [EMAIL PROTECTED]
-- The OpenSG Open Source Scenegraph: http://www.opensg.org
-- Join the list at http://lists.sf.net/lists/listinfo/opensg-users
--__--__--
Message: 6
Date: Wed, 11 May 2005 18:24:31 +0200
From: Johan Grafstrom <[EMAIL PROTECTED]>
To: [email protected]
Subject: Re: [Opensg-users] Aspects consuming memory
Reply-To: [email protected]
This is a multi-part message in MIME format.
--------------000305020900060901030701
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: Quoted-Printable
Hi!
Thanks for your quick reply and sorry for the delayed reply on your=20
reply. We have been busy removing a few other bugs from our application.
The problem with the doubled memory consumption remains though. We made=20
a short test program to provoke the behavior, based on the multithread=20
example in the Tutorial. The program is attached to this mail.
Display lists is turned off, as you suggested, setting the prototype=20
before creating the torus.
The behavior of the test program is similar to our application. What=20
happens is:
* Thread 1 (main) - osgInit ... etc
* T1 - create Thread 2
* T1 - glut calls display and stops on barrier
* T2 - turn off display lists and create a torus that takes about
40 MB (very smooth :-)
* T2 - enter animation loop
* T2 - enter barrier
* T1 - calls applyAndClear for the first time, consuming another 40 MB
The major difference from the tutorial example should be that the scene=20
isn't created in the rendering thread. We must do this in our=20
application because scene loading and manipulating is handled by the=20
non-rendering GUI-thread.
The environment:
* Windows XP with latest updates.
* Binary distribution OpenSG 1.4 with MS STL
* Visual Studio .Net 2003
The doubled memory consumption is not supposed to take place if
I understand your reply correctly. Is this due to a bug in OpenSG or in=20
our usage of the API?
Best regards,
Johan Grafstr=F6m, Fredrik Andersson
Dirk Reiners wrote:
> Hi Johan,
>=20
> On Mon, 2005-05-02 at 18:54 +0200, Johan Grafstrom wrote:
>=20
>>We are using OpenSG to visualize a large model on Windows. The model
>>takes about 1 GB of memory. The model may take a while to render
>>(depending of how much of it is currently visible). To keep the user
>>interface responsive, rendering is therefor done in a separate thread.
>>
>>The GUI-thread reads and writes the scenegraph, so we need the two
>>aspects. However since there is a lot of data in the scenegraph, we
>>cannot simply double its size. When the second thread starts (and the
>>first changeList->applyAndClear() is called) the program locks for a
>>while and the memory usage doubles, usually crashing due to memory (or
>>rather, address space) overflow.
>=20
>=20
> I don't think that's related to the aspects, see below.
>=20
>=20
>>What happens is probably:
>>
>>* The nodes and cores are created with aspects when scenegraph is read
>> from file. The data fields is initially empty.
>>
>>* During reading, the geometry data (vertices etc) is assigned to the
>> current aspect data fields of the the nodes. The fields is added to
>> the changelist.
>>
>>* When applyAndClear is called the first time all geometry data is
>> copied to fill the aspect of the second thread, thus consuming lots
>> of memory.
>=20
>=20
> Unless there is a bug that shouldn't happen. The applyAndClear() for
> MultiFields only creates a new reference to the same data, so no new
> memory should be allocated.
>=20
>=20
>>Some possible solutions to the problem:
>>
>>A Using only one aspect and make sure only one thread at a time can
>> access the scenegraph. We will need to be able to interrupt the
>> rendering in order to keep the application responsive (eg by calling
>> renderAction->setTravMask(0))
>=20
>=20
> Well, you can run mutiple threads and a single aspect, as long as you'r=
e
> careful about changing things synchronized.
> =20
>=20
>>B Change OpenSG so that number of aspects may be set per
>> FieldContainer or FieldContainerType. Ensuring that the geometry
>> nodes (and their data) data (which is static in our application)
>> has only one aspect would solve our problem.
>=20
>=20
> That would be a pretty serious issue. Right now the ChangeList manager
> can just copy the data around, but what is it supposed to do, if there
> is no copy of the node in the aspect it's supposed to copy to?
>=20
>=20
>>Alternative B would be the "nicest" solution of these, if it is'nt too
>>much work.
>=20
>=20
> I don't see that happening, it's a very big change with lots of
> undefined problems in my mind right now.
>=20
>=20
>>Questions:
>>
>>* Are there some other, better, solutions?
>=20
>=20
> As I said, unless there is a bug this is not really the problem.
>=20
> My guess is that the memory is consumed during the first rendering
> (could you confirm that by putting a pause after the sync and before th=
e
> first render?). By default OpenSG uses Display Lists to speed up
> rendering, and those take about the same amount of memory as the
> geometry (somewhat more, actually). So unless you've switched them off,
> that's going to be an issue. You can switch them off individually using
> geocore->setDlistCache(false); or globally by calling
>=20
> FieldContainerPtr pProto =3D Geometry::getClassType().getPrototype(=
);
>=20
> GeometryPtr pGeoProto =3D GeometryPtr::dcast(pProto);
>=20
> if(pGeoProto !=3D NullFC)
> {
> pGeoProto->setDlistCache(false);
> }
>=20
> before you start loading.
>=20
> Please try that, it should at least relieve the memory pressure.
>=20
>=20
>>* Otherwise, how difficult would it be to fix B above, e g by making
>> getNumAspects() a method of FieldContainer or FieldContainerType? If
>> we did, would you accept it into the OpenSG project?
>=20
>=20
> I'd be hard pressed to do that, as it will involve serious changes
> throughout the whole system to make this work reliably. I really hope
> the abovementioned changes fix your problem. ;)
>=20
>=20
>>Sorry if the mail got uneccessarily lengthy...
>=20
>=20
> No problem, I prefer longer and detailed mails to the "My program
> doesn't work. How do I fix it?" ones.
>=20
> Yours
>=20
> Dirk
>=20
>=20
--------------000305020900060901030701
Content-Type: text/plain;
name="01hello.vcproj"
Content-Disposition: inline;
filename="01hello.vcproj"
Content-Transfer-Encoding: 7Bit
<?xml version="1.0" encoding="Windows-1252"?>
<VisualStudioProject
ProjectType="Visual C++"
Version="7.10"
Name="Viewer"
ProjectGUID="{3D356E7A-0629-488C-B9E3-2C8C8D02A84F}"
RootNamespace="Viewer"
Keyword="ManagedCProj">
<Platforms>
<Platform
Name="Win32"/>
</Platforms>
<Configurations>
<Configuration
Name="Debug|Win32"
OutputDirectory="$(SolutionDir)$(ConfigurationName)"
IntermediateDirectory="$(ConfigurationName)"
ConfigurationType="1"
CharacterSet="2"
ManagedExtensions="TRUE">
<Tool
Name="VCCLCompilerTool"
Optimization="0"
AdditionalIncludeDirectories="include;"$(OSG_HOME)\include""
PreprocessorDefinitions="WIN32;_DEBUG;WINVER=0x0400;_WIN32_WINDOWS=0x0410;_WIN32_WINNT=0x0400;OSG_BUILD_DLL;_OSG_HAVE_CONFIGURED_H_;QT_DLL;QT_PLUGIN;QT_THREAD_SUPPORT;OSG_WITH_GLUT;_WINDOWS;UNICODE;_GNU_SOURCE;QT_CLEAN_NAMESPACE;QT_ACCESSIBILITY_SUPPORT;QT_TABLET_SUPPORT;QT_NO_STL;_WINDLL"
MinimalRebuild="FALSE"
BasicRuntimeChecks="0"
RuntimeLibrary="1"
WarningLevel="3"
DebugInformationFormat="3"/>
<Tool
Name="VCCustomBuildTool"/>
<Tool
Name="VCLinkerTool"
AdditionalDependencies="OSGBaseD.lib
OSGSystemD.lib OSGWindowGlutD.lib"
OutputFile="$(OutDir)\$(ProjectName).exe"
LinkIncremental="2"
AdditionalLibraryDirectories="$(OSG_HOME)\lib"
GenerateDebugInformation="TRUE"
AssemblyDebug="1"/>
<Tool
Name="VCMIDLTool"/>
<Tool
Name="VCPostBuildEventTool"/>
<Tool
Name="VCPreBuildEventTool"/>
<Tool
Name="VCPreLinkEventTool"/>
<Tool
Name="VCResourceCompilerTool"/>
<Tool
Name="VCWebServiceProxyGeneratorTool"/>
<Tool
Name="VCXMLDataGeneratorTool"/>
<Tool
Name="VCWebDeploymentTool"/>
<Tool
Name="VCManagedWrapperGeneratorTool"/>
<Tool
Name="VCAuxiliaryManagedWrapperGeneratorTool"/>
</Configuration>
<Configuration
Name="Release|Win32"
OutputDirectory="$(SolutionDir)$(ConfigurationName)"
IntermediateDirectory="$(ConfigurationName)"
ConfigurationType="1"
CharacterSet="2"
ManagedExtensions="TRUE">
<Tool
Name="VCCLCompilerTool"
PreprocessorDefinitions="WIN32;NDEBUG"
MinimalRebuild="FALSE"
RuntimeLibrary="0"
WarningLevel="3"
DebugInformationFormat="3"/>
<Tool
Name="VCCustomBuildTool"/>
<Tool
Name="VCLinkerTool"
OutputFile="$(OutDir)\$(ProjectName).exe"
LinkIncremental="1"
GenerateDebugInformation="TRUE"/>
<Tool
Name="VCMIDLTool"/>
<Tool
Name="VCPostBuildEventTool"/>
<Tool
Name="VCPreBuildEventTool"/>
<Tool
Name="VCPreLinkEventTool"/>
<Tool
Name="VCResourceCompilerTool"/>
<Tool
Name="VCWebServiceProxyGeneratorTool"/>
<Tool
Name="VCXMLDataGeneratorTool"/>
<Tool
Name="VCWebDeploymentTool"/>
<Tool
Name="VCManagedWrapperGeneratorTool"/>
<Tool
Name="VCAuxiliaryManagedWrapperGeneratorTool"/>
</Configuration>
</Configurations>
<References>
</References>
<Files>
<Filter
Name="Source Files"
Filter="cpp;c;cxx;def;odl;idl;hpj;bat;asm;asmx"
UniqueIdentifier="{4FC737F1-C7A5-4376-A066-2A32D752A2FF}">
<File
RelativePath=".\13multithreading2.cpp">
</File>
</Filter>
<Filter
Name="Header Files"
Filter="h;hpp;hxx;hm;inl;inc;xsd"
UniqueIdentifier="{93995380-89BD-4b04-88EB-625FBE52EBFB}">
</Filter>
<Filter
Name="Resource Files"
Filter="rc;ico;cur;bmp;dlg;rc2;rct;bin;rgs;gif;jpg;jpeg;jpe;resx"
UniqueIdentifier="{67DA6AB6-F800-4c08-8B7A-83BB121AAD01}">
</Filter>
</Files>
<Globals>
</Globals>
</VisualStudioProject>
--------------000305020900060901030701
Content-Type: text/plain;
name="13multithreading2.cpp"
Content-Disposition: inline;
filename="13multithreading2.cpp"
Content-Transfer-Encoding: 7Bit
// all needed include files
#include <OpenSG/OSGGLUT.h>
#include <OpenSG/OSGConfig.h>
#include <OpenSG/OSGSimpleGeometry.h>
#include <OpenSG/OSGGLUTWindow.h>
#include <OpenSG/OSGSimpleSceneManager.h>
#include <OpenSG/OSGThreadManager.h>
OSG_USING_NAMESPACE
using namespace std;
SimpleSceneManager *mgr;
NodePtr scene;
//we will store the transformation globally - this
//is not necessary, but comfortable
TransformPtr trans;
Thread* animationThread;
Barrier *syncBarrier;
int setupGLUT( int *argc, char *argv[] );
NodePtr createScenegraph(){
// the scene must be created here
NodePtr n = makeTorus(.5,2,1024,1024);
//add a simple Transformation
trans = Transform::create();
beginEditCP(trans);
Matrix m;
m.setIdentity();
trans->setMatrix(m);
endEditCP(trans);
NodePtr transNode = Node::create();
beginEditCP(transNode);
transNode->setCore(trans);
transNode->addChild(n);
endEditCP(transNode);
return transNode;
}
//this function will run in a thread and simply will
//rotate the cube by setting a new transformation matrix
void rotate(void *args) {
// we won't stop calculating new matrices....
// NEW STUFF
// Disable displaylist on new geometry
FieldContainerPtr pProto = Geometry::getClassType().getPrototype();
GeometryPtr pGeoProto = GeometryPtr::dcast(pProto);
if(pGeoProto != NullFC) {
pGeoProto->setDlistCache(false);
}
// this consumes about 40 MB
scene = createScenegraph();
mgr->setRoot(scene);
mgr->showAll();
// END NEW STUFF
while(true) {
Real32 time = glutGet(GLUT_ELAPSED_TIME);
Matrix m;
m.setIdentity();
m.setRotate(Quaternion(Vec3f(0,1,0), time/1000));
beginEditCP(trans);
trans->setMatrix(m);
endEditCP(trans);
// nothing unusual until here
//well that's new...
//wait until two threads are cought in the
//same barrier
syncBarrier->enter(2);
//just the same again
syncBarrier->enter(2);
}
}
int main(int argc, char **argv)
{
ChangeList::setReadWriteDefault();
osgInit(argc,argv);
int winid = setupGLUT(&argc, argv);
GLUTWindowPtr gwin = GLUTWindow::create();
gwin->setId(winid);
gwin->init();
// in the tutorial example, the scengraph was created in the
// main/render thread.
// scene = createScenegraph();
syncBarrier = Barrier::get("Barrier");
mgr = new SimpleSceneManager;
mgr->setWindow(gwin );
//create the thread that will run generation of new matrices
animationThread = dynamic_cast<Thread *>(ThreadManager::the()
->getThread("anim"));
//do it...
animationThread->runFunction(rotate, 1, NULL);
glutMainLoop();
return 0;
}
void reshape(int w, int h)
{
mgr->resize(w, h);
glutPostRedisplay();
}
void display(void)
{
// we wait here until the animation thread enters
//the first barrier
syncBarrier->enter(2);
// now we sync data
// First time this is run, it consumes another 40 MB !!
animationThread->getChangeList()->applyAndClear();
// and again
syncBarrier->enter(2);
// now render...
mgr->redraw();
}
void mouse(int button, int state, int x, int y)
{
if (state)
mgr->mouseButtonRelease(button, x, y);
else
mgr->mouseButtonPress(button, x, y);
glutPostRedisplay();
}
void motion(int x, int y)
{
mgr->mouseMove(x, y);
glutPostRedisplay();
}
int setupGLUT(int *argc, char *argv[])
{
glutInit(argc, argv);
glutInitDisplayMode(GLUT_RGB | GLUT_DEPTH | GLUT_DOUBLE);
int winid = glutCreateWindow("OpenSG First Application");
glutDisplayFunc(display);
glutMouseFunc(mouse);
glutMotionFunc(motion);
glutReshapeFunc(reshape);
glutIdleFunc(display);
return winid;
}
--------------000305020900060901030701--
--__--__--
Message: 7
From: Dirk Reiners <[EMAIL PROTECTED]>
To: users <[email protected]>
Date: Wed, 11 May 2005 11:28:29 -0500
Subject: [Opensg-users] List problems, especially gmail
Reply-To: [email protected]
Hi folks,
apparently SourceForge has problems with their mailing lists. Messages
may not go through but time out instead. For some reason this seem to
affect gmail users more than others, but it's not totally limited to
gmail. So if you have a choice, a non-gmail account might have a better
chance of getting through. No guarantees, but worth a try.
Dirk
--
-- Dirk Reiners OpenSG Forum [EMAIL PROTECTED]
-- The OpenSG Open Source Scenegraph: http://www.opensg.org
-- Join the list at http://lists.sf.net/lists/listinfo/opensg-users
--__--__--
Message: 8
Date: Wed, 11 May 2005 11:21:44 +0200
From: Andreas Zieringer <[EMAIL PROTECTED]>
To: [email protected]
Subject: Re: [Opensg-users] got an mfc application running opensg
Reply-To: [email protected]
Hi Tariq,
I added a MFC example application to OpenSG/Examples. Just set the
environment variable OPENSG_BUILD_DIR to your installed OpenSG directory
and execute the OpenSGDemo.vcproj file.
Many thanks to Aitor Moreno for providing this code.
Andreas
> Hi everyone,
>
> I have tried alot to integrate opensg into an mfc application but
> yet not reached any solution. If any one of you have a working mfc
> application with WIN32window or PassiveWindow used ,than please send me
> its code and executable, it will be a great help for me.
>
> Regards
>
> Tariq
>
> ------------------------------------------------------------------------
> Yahoo! Mail
> Stay connected, organized, and protected. Take the tour
> <http://tour.mail.yahoo.com/mailtour.html>
--__--__--
Message: 9
Subject: Re: [Opensg-users] Aspects consuming memory
From: Dirk Reiners <[EMAIL PROTECTED]>
To: users <[email protected]>
Date: Wed, 11 May 2005 14:28:42 -0500
Reply-To: [email protected]
Hi Johan,
On Wed, 2005-05-11 at 18:24 +0200, Johan Grafstrom wrote:
> Hi!
>
> Thanks for your quick reply and sorry for the delayed reply on your
> reply. We have been busy removing a few other bugs from our application.
As long as they're bugs in your app and not in OpenSG I'm not
worried. ;)
> The problem with the doubled memory consumption remains though. We made
> a short test program to provoke the behavior, based on the multithread
> example in the Tutorial. The program is attached to this mail.
Thanks for the example, I could reproduce the effect. You're right, it
actually makes a copy.
Gerrit, looking at it the problem is that void MField<FieldTypeT,
fieldNameSpace>::setValues(const Self &obj); is called instead of void
MField<FieldTypeT, fieldNameSpace>::setValues(const StorageTypeParent
&value); as void MField<FieldTypeT, fieldNameSpace>::syncWith(Self
&source); just calls setValues(source);.
Is that on purpose? Can you fix that? Does that still happen in your new
FC code?
Thanks
Dirk
--
-- Dirk Reiners OpenSG Forum [EMAIL PROTECTED]
-- The OpenSG Open Source Scenegraph: http://www.opensg.org
-- Join the list at http://lists.sf.net/lists/listinfo/opensg-users
--__--__--
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
End of Opensg-users Digest
--F1BFC3392F.1115840077/sc8-sf-spam1.sourceforge.net--
