The OpenSG Scenegraph

Andreas Zieringer wrote:

> 
> 
> cvs -d:pserver:amz@... login
> cvs -d:pserver:amz@... co Fhs

Sorry just ignore it that shouldn't go to this address ...

Andreas

Hi Andreas!

> > > Did you have a look at the DrawFunctorCore in the Contrib directory?
> > > It works quite well.
> >
> > Yes, Dirk told me the same. But how can I use it? I downloaded it. But
> > I get errors.
> >
> > Linking...
> > virtual09VSFIRE.obj : error LNK2019: unresolved external symbol
> > "__declspec(dllimport) public: static class osg::FCPtr<class
> > osg::FCPtr<class osg::FCPtr<class osg::FCPtr<class
> > osg::AttachmentContainerPtr,class osg::NodeCore>,class
> > osg::Drawable>,class osg::MaterialDrawable>,class
> > osg::DrawFunctorCore> __cdecl osg::DrawFunctorCoreBase::create(void)"
> > 
> (__imp_?create@...) 
> referenced in function _main
> > .\Debug/template.exe : fatal error LNK1120: 1 unresolved externals
> >
> > I think I must build the lib. How can I include this files into my
> > openSG?
>
>You have to build OpenSG yourself.

I do this.

>I don't think it is possible to build
>the contrib-lib using a daily snapshot (would be a nice feature :-) ).
>Also, you have to enable the build of the draw functor core by renaming
>Source/Contrib/DrawFunctorCore/common.libs.in.disabled to
>common.libs.in.

Yes, that I read in README ;-) and have done it. But how can I compile it 
with VS7 on Win2000?

I tried to make a new project in VS7 with the contrib files but I get erros:

\DrawFunctorCore\OSGDrawFunctorCoreBase.cpp(67) : warning C4273: 
'osg::VolumeUpdateFieldMask' : inconsistent dll linkage
\DrawFunctorCore\OSGDrawFunctorCoreBase.cpp(67) : error C2491: 
'osg::DrawFunctorCoreBase::VolumeUpdateFieldMask' : definition of dllimport 
static data member not allowed
\DrawFunctorCore\OSGDrawFunctorCoreBase.cpp(70) : warning C4273: 
'osg::DrawFieldMask' : inconsistent dll linkage
\DrawFunctorCore\OSGDrawFunctorCoreBase.cpp(70) : error C2491: 
'osg::DrawFunctorCoreBase::DrawFieldMask' : definition of dllimport static 
data member not allowed
\DrawFunctorCore\OSGDrawFunctorCoreBase.cpp(73) : warning C4273: 
'osg::MTInfluenceMask' : inconsistent dll linkage
\DrawFunctorCore\OSGDrawFunctorCoreBase.cpp(73) : error C2491: 
'osg::DrawFunctorCoreBase::MTInfluenceMask' : definition of dllimport 
static data member not allowed
\DrawFunctorCore\OSGDrawFunctorCoreBase.cpp(88) : warning C4273: 
'osg::_desc' : inconsistent dll linkage
\DrawFunctorCore\OSGDrawFunctorCoreBase.cpp(88) : error C2491: 
'osg::DrawFunctorCoreBase::_desc' : definition of dllimport static data 
member not allowed
\DrawFunctorCore\OSGDrawFunctorCoreBase.cpp(109) : warning C4273: 
'osg::_type' : inconsistent dll linkage
\DrawFunctorCore\OSGDrawFunctorCoreBase.cpp(109) : error C2491: 
'osg::DrawFunctorCoreBase::_type' : definition of dllimport static data 
member not allowed

=> OSGDrawFunctorCoreBase.cpp =>

const OSG::BitVector  DrawFunctorCoreBase::VolumeUpdateFieldMask =
     (TypeTraits<BitVector>::One << DrawFunctorCoreBase::VolumeUpdateFieldId);

const OSG::BitVector  DrawFunctorCoreBase::DrawFieldMask =
     (TypeTraits<BitVector>::One << DrawFunctorCoreBase::DrawFieldId);

const OSG::BitVector DrawFunctorCoreBase::MTInfluenceMask =
     (Inherited::MTInfluenceMask) |
     (static_cast<BitVector>(0x0) << Inherited::NextFieldId);

Sorry, I'm so stupid ;-)
Thank you for help!

         Tobias


         Tobias M. Pigulla
ICQ:    16 77 47 25
eMail:  tpigulla@...

Hi Tobias,

On Mon, 2003-08-25 at 13:48, Tobias Pigulla wrote:
> > > 
> > > Linking...
> > > virtual09VSFIRE.obj : error LNK2019: unresolved external symbol
> > > "__declspec(dllimport) public: static class osg::FCPtr<class
> > > osg::FCPtr<class osg::FCPtr<class osg::FCPtr<class
> > > osg::AttachmentContainerPtr,class osg::NodeCore>,class
> > > osg::Drawable>,class osg::MaterialDrawable>,class
> > > osg::DrawFunctorCore> __cdecl
> > osg::DrawFunctorCoreBase::create(void)"
> > >
> > (__imp_?create@...) referenced in function _main
> > > .\Debug/template.exe : fatal error LNK1120: 1 unresolved externals
> 
> Yes, that I read in README ;-) and have done it. But how can I compile
> it with VS7 on Win2000?
> 
> I tried to make a new project in VS7 with the contrib files but I get
> erros:
> 
> \DrawFunctorCore\OSGDrawFunctorCoreBase.cpp(67) : warning C4273:
> 'osg::VolumeUpdateFieldMask' : inconsistent dll linkage
> \DrawFunctorCore\OSGDrawFunctorCoreBase.cpp(67) : error C2491:
> 'osg::DrawFunctorCoreBase::VolumeUpdateFieldMask' : definition of
> dllimport static data member not allowed
> 
> => OSGDrawFunctorCoreBase.cpp =>
> 
> const OSG::BitVector  DrawFunctorCoreBase::VolumeUpdateFieldMask = 
>     (TypeTraits<BitVector>::One <<
> DrawFunctorCoreBase::VolumeUpdateFieldId);
> 
> const OSG::BitVector  DrawFunctorCoreBase::DrawFieldMask = 
>     (TypeTraits<BitVector>::One << DrawFunctorCoreBase::DrawFieldId);
> 
> const OSG::BitVector DrawFunctorCoreBase::MTInfluenceMask = 
>     (Inherited::MTInfluenceMask) | 
>     (static_cast<BitVector>(0x0) << Inherited::NextFieldId); 
> 
> Sorry, I'm so stupid ;-)

Naa, you're not. It's just that compiling OpenSG structures with VS is a
bit tricky. Well, compiling dlls with VS is a bit tricky, it's not
really limited to OpenSG.

The problem is that for real MS code two different headers are used. One
to compile the lib (which marks every symbol that should be visible with
"__declspec(dllexport)") and one that defines the outside interface (and
marks every symbol that should be useable with "__declspec(dllimport)"),
which is used by the users. Doesn't make a lot of sense, but that's the
idea. So if you want to use the same header for both uses you have to
use dllexport when compiling the library, and dllimport when using it. 

OpenSG, like many other systems, just defines a macro called
OSG_xxxLIB_DLLMAPPING to be either dllimport or dllexport, depending on
what is needed. This macro is library-dependent and defined in the
OSGxxxDef.h headers, and controlled by the OSG_BUILD_DLL macro. 

So to include some OpenSG library code into an application, you should
define the OSG_xxxLIB_DLLMAPPING and OSG_xxxLIB_DLLTMPLMAPPING to
nothing, for your case define OSG_CONTRIBLIB_DLLMAPPING and
OSG_CONTRIBLIB_DLLTMPLMAPPING in the VS compiler options. This will turn
the OpenSG library source into standard source and should please the VS
compiler enough to make it work.  Note that if you want to add into
another dll, you need to define it according to the rules given above.
In that case it's probably easier to add OSGxxxDef.h header and define
OSG_BUILD_DLL.

Hope it helps

	Dirk

-- 
--
-- Dirk Reiners               OpenSG Forum               dirk@... 
-- The OpenSG Open Source Scenegraph:              http://www.opensg.org
-- Announcements:     http://lists.sf.net/lists/listinfo/opensg-announce

Hi Andreas,

On Mon, 2003-08-25 at 10:23, Andreas Kopecki wrote:
> 
> You have to build OpenSG yourself. I don't think it is possible to build
> the contrib-lib using a daily snapshot (would be a nice feature :-) ).

Hmm, not sure what you're thinking of here. What would you like to do?

The problem with most of the Contrib stuff is that it depends on
external libraries, which need to be added to the Makefiles to make it
compile, so there needs to be a configure or something similar that can
create the correct pathes.

	Dirk
-- 
--
-- Dirk Reiners               OpenSG Forum               dirk@... 
-- The OpenSG Open Source Scenegraph:              http://www.opensg.org
-- Announcements:     http://lists.sf.net/lists/listinfo/opensg-announce

Hi Dirk!

On Wed, 2003-08-27 at 13:25, Dirk Reiners wrote:
> On Mon, 2003-08-25 at 10:23, Andreas Kopecki wrote:
> > 
> > You have to build OpenSG yourself. I don't think it is possible to build
> > the contrib-lib using a daily snapshot (would be a nice feature :-) ).
> 
> Hmm, not sure what you're thinking of here. What would you like to do?

It was just a thought... to have a simple makefile you can use if you
want (parts of) the contrib-lib without having the complete build system
(which is not included in the daily snaps), or at least a guildeline
which defines, etc. you need to do it by hand.

-- 
Andreas Kopecki                High Performance Computing Center (HLRS)
                               Visualization Department
Tel. ++49-711-6855789          Allmandring 30a, D-70550 Stuttgart

kopecki@...                                      http://www.hlrs.de/
-------------------------------------------------------------------------

Hi Dirk,

> > > >
> > > > Linking...
> > > > virtual09VSFIRE.obj : error LNK2019: unresolved external symbol
> > > > "__declspec(dllimport) public: static class osg::FCPtr<class
> > > > osg::FCPtr<class osg::FCPtr<class osg::FCPtr<class
> > > > osg::AttachmentContainerPtr,class osg::NodeCore>,class
> > > > osg::Drawable>,class osg::MaterialDrawable>,class
> > > > osg::DrawFunctorCore> __cdecl
> > > osg::DrawFunctorCoreBase::create(void)"
> > > >
> > > 
> (__imp_?create@...) 
> referenced in function _main
> > > > .\Debug/template.exe : fatal error LNK1120: 1 unresolved externals
> >
> > Yes, that I read in README ;-) and have done it. But how can I compile
> > it with VS7 on Win2000?
> >
> > I tried to make a new project in VS7 with the contrib files but I get
> > erros:
> >
> > \DrawFunctorCore\OSGDrawFunctorCoreBase.cpp(67) : warning C4273:
> > 'osg::VolumeUpdateFieldMask' : inconsistent dll linkage
> > \DrawFunctorCore\OSGDrawFunctorCoreBase.cpp(67) : error C2491:
> > 'osg::DrawFunctorCoreBase::VolumeUpdateFieldMask' : definition of
> > dllimport static data member not allowed
> >
> > => OSGDrawFunctorCoreBase.cpp =>
> >
> > const OSG::BitVector  DrawFunctorCoreBase::VolumeUpdateFieldMask =
> >     (TypeTraits<BitVector>::One <<
> > DrawFunctorCoreBase::VolumeUpdateFieldId);
> >
> > const OSG::BitVector  DrawFunctorCoreBase::DrawFieldMask =
> >     (TypeTraits<BitVector>::One << DrawFunctorCoreBase::DrawFieldId);
> >
> > const OSG::BitVector DrawFunctorCoreBase::MTInfluenceMask =
> >     (Inherited::MTInfluenceMask) |
> >     (static_cast<BitVector>(0x0) << Inherited::NextFieldId);
> >
> > Sorry, I'm so stupid ;-)
>
>Naa, you're not. It's just that compiling OpenSG structures with VS is a
>bit tricky. Well, compiling dlls with VS is a bit tricky, it's not
>really limited to OpenSG.
>
>The problem is that for real MS code two different headers are used. One
>to compile the lib (which marks every symbol that should be visible with
>"__declspec(dllexport)") and one that defines the outside interface (and
>marks every symbol that should be useable with "__declspec(dllimport)"),
>which is used by the users. Doesn't make a lot of sense, but that's the
>idea. So if you want to use the same header for both uses you have to
>use dllexport when compiling the library, and dllimport when using it.
>
>OpenSG, like many other systems, just defines a macro called
>OSG_xxxLIB_DLLMAPPING to be either dllimport or dllexport, depending on
>what is needed. This macro is library-dependent and defined in the
>OSGxxxDef.h headers, and controlled by the OSG_BUILD_DLL macro.
>
>So to include some OpenSG library code into an application, you should
>define the OSG_xxxLIB_DLLMAPPING and OSG_xxxLIB_DLLTMPLMAPPING to
>nothing, for your case define OSG_CONTRIBLIB_DLLMAPPING and
>OSG_CONTRIBLIB_DLLTMPLMAPPING in the VS compiler options. This will turn
>the OpenSG library source into standard source and should please the VS
>compiler enough to make it work.  Note that if you want to add into
>another dll, you need to define it according to the rules given above.
>In that case it's probably easier to add OSGxxxDef.h header and define
>OSG_BUILD_DLL.
>
>Hope it helps

No sorry, me and my colleagues don't know how/where to set define 
OSG_CONTRIBLIB_DLLMAPPING and
OSG_CONTRIBLIB_DLLTMPLMAPPING in the VS compiler options in VS.NET

Thanks for help again!!

         Newbe Tobias

p.s.: In OSG_ContribDef.h in line 51
#   ifdef OSG_COMPILESYSTEMLIB
is wrong or? Must be
#   ifdef OSG_COMPILECONTRIBLIB
?!


         Tobias M. Pigulla
Mobil:  91 23 21 593
ICQ:    16 77 47 25
MSN:    tpigulla@...
Yahoo:  tpigulla
eMail:  tpigulla@...
URL:       http://www.tpigulla.charmelion.de/

Tobias Pigulla wrote:

> Hi Dirk,
> 
>> > > >
>> > > > Linking...
>> > > > virtual09VSFIRE.obj : error LNK2019: unresolved external symbol
>> > > > "__declspec(dllimport) public: static class osg::FCPtr<class
>> > > > osg::FCPtr<class osg::FCPtr<class osg::FCPtr<class
>> > > > osg::AttachmentContainerPtr,class osg::NodeCore>,class
>> > > > osg::Drawable>,class osg::MaterialDrawable>,class
>> > > > osg::DrawFunctorCore> __cdecl
>> > > osg::DrawFunctorCoreBase::create(void)"
>> > > >
>> > > 
>> (__imp_?create@...) 
>> referenced in function _main
>> > > > .\Debug/template.exe : fatal error LNK1120: 1 unresolved externals
>> >
>> > Yes, that I read in README ;-) and have done it. But how can I compile
>> > it with VS7 on Win2000?
>> >
>> > I tried to make a new project in VS7 with the contrib files but I get
>> > erros:
>> >
>> > \DrawFunctorCore\OSGDrawFunctorCoreBase.cpp(67) : warning C4273:
>> > 'osg::VolumeUpdateFieldMask' : inconsistent dll linkage
>> > \DrawFunctorCore\OSGDrawFunctorCoreBase.cpp(67) : error C2491:
>> > 'osg::DrawFunctorCoreBase::VolumeUpdateFieldMask' : definition of
>> > dllimport static data member not allowed
>> >
>> > => OSGDrawFunctorCoreBase.cpp =>
>> >
>> > const OSG::BitVector  DrawFunctorCoreBase::VolumeUpdateFieldMask =
>> >     (TypeTraits<BitVector>::One <<
>> > DrawFunctorCoreBase::VolumeUpdateFieldId);
>> >
>> > const OSG::BitVector  DrawFunctorCoreBase::DrawFieldMask =
>> >     (TypeTraits<BitVector>::One << DrawFunctorCoreBase::DrawFieldId);
>> >
>> > const OSG::BitVector DrawFunctorCoreBase::MTInfluenceMask =
>> >     (Inherited::MTInfluenceMask) |
>> >     (static_cast<BitVector>(0x0) << Inherited::NextFieldId);
>> >
>> > Sorry, I'm so stupid ;-)
>>
>> Naa, you're not. It's just that compiling OpenSG structures with VS is a
>> bit tricky. Well, compiling dlls with VS is a bit tricky, it's not
>> really limited to OpenSG.
>>
>> The problem is that for real MS code two different headers are used. One
>> to compile the lib (which marks every symbol that should be visible with
>> "__declspec(dllexport)") and one that defines the outside interface (and
>> marks every symbol that should be useable with "__declspec(dllimport)"),
>> which is used by the users. Doesn't make a lot of sense, but that's the
>> idea. So if you want to use the same header for both uses you have to
>> use dllexport when compiling the library, and dllimport when using it.
>>
>> OpenSG, like many other systems, just defines a macro called
>> OSG_xxxLIB_DLLMAPPING to be either dllimport or dllexport, depending on
>> what is needed. This macro is library-dependent and defined in the
>> OSGxxxDef.h headers, and controlled by the OSG_BUILD_DLL macro.
>>
>> So to include some OpenSG library code into an application, you should
>> define the OSG_xxxLIB_DLLMAPPING and OSG_xxxLIB_DLLTMPLMAPPING to
>> nothing, for your case define OSG_CONTRIBLIB_DLLMAPPING and
>> OSG_CONTRIBLIB_DLLTMPLMAPPING in the VS compiler options. This will turn
>> the OpenSG library source into standard source and should please the VS
>> compiler enough to make it work.  Note that if you want to add into
>> another dll, you need to define it according to the rules given above.
>> In that case it's probably easier to add OSGxxxDef.h header and define
>> OSG_BUILD_DLL.
>>
>> Hope it helps
> 
> 
> No sorry, me and my colleagues don't know how/where to set define 
> OSG_CONTRIBLIB_DLLMAPPING and
> OSG_CONTRIBLIB_DLLTMPLMAPPING in the VS compiler options in VS.NET
> 

Hi,

open the "Property Pages" dialog and select in the tree view C/C++ -> 
Command Line and add the following line to "Additional Options":
-Zm1000 /D "OSG_COMPILECONTRIBLIB"

> Thanks for help again!!
> 
>         Newbe Tobias
> 
> p.s.: In OSG_ContribDef.h in line 51
> #   ifdef OSG_COMPILESYSTEMLIB
> is wrong or? Must be
> #   ifdef OSG_COMPILECONTRIBLIB
> ?!

Yep you are right I already fixed this but the anonymous cvs is a bit 
slow :-(

Andreas

Hello list

On Win2k, vs.net 2002, OpenSG with stl_port, voodoo3 with OpenGL of 
DozerXP-Driver:

Tutorials 1-6 behave as wanted but the rest crushes without error messages. 
Means Win has to be restarted by reset button...
It is possible that my system is a little bit untidy, cause I tested every 
single version combination to run OpenSG. I already modified the 
environment variables to fit the present setup (seems as if this brought 
tutorials 3-5 to work, as they also did not want in the beginning). Do you 
still know something to try?

There are some warnings but on another system it worked with them:

d:\OpenSG\include\OpenSG\OSGFieldDataType.h(380) : warning C4806: '==' : 
unsafe operation: no value of type 'bool' promoted to type 'int' can equal 
the given constant
        d:\OpenSG\include\OpenSG\OSGFieldDataType.h(421) : see reference to 
class template instantiation 'osg::FieldTraitsRecurseMapper<FieldTypeT,>' 
being compiled
d:\OpenSG\include\OpenSG\OSGFieldDataType.h(434) : warning C4806: '==' : 
unsafe operation: no value of type 'bool' promoted to type 'int' can equal 
the given constant
        d:\OpenSG\include\OpenSG\OSGFieldDataType.h(474) : see reference to 
class template instantiation 'osg::FieldTraitsRecurseMapper1<FieldTypeT,>' 
being compiled
d:\OpenSG\include\OpenSG\OSGFieldDataType.h(488) : warning C4806: '==' : 
unsafe operation: no value of type 'bool' promoted to type 'int' can equal 
the given constant
        d:\OpenSG\include\OpenSG\OSGFieldDataType.h(528) : see reference to 
class template instantiation 'osg::FieldTraitsRecurseMapper2<FieldTypeT,>' 
being compiled


Thank you,

-- 
Pascal Sproedt

On Tue, 26 Aug 2003 21:18:24 +0200, Pascal Sproedt <pascalsproedt@...> 
wrote:

> Hello list
>
> On Win2k, vs.net 2002, OpenSG with stl_port, voodoo3 with OpenGL of 
> DozerXP-Driver:
>
> Tutorials 1-6 behave as wanted but the rest crushes without error 
> messages. Means Win has to be restarted by reset button...
> It is possible that my system is a little bit untidy, cause I tested 
> every single version combination to run OpenSG. I already modified the 
> environment variables to fit the present setup (seems as if this brought 
> tutorials 3-5 to work, as they also did not want in the beginning). Do 
> you still know something to try?
>
> There are some warnings but on another system it worked with them:
>
> d:\OpenSG\include\OpenSG\OSGFieldDataType.h(380) : warning C4806: '==' : 
> unsafe operation: no value of type 'bool' promoted to type 'int' can 
> equal the given constant
> d:\OpenSG\include\OpenSG\OSGFieldDataType.h(421) : see reference to class 
> template instantiation 'osg::FieldTraitsRecurseMapper<FieldTypeT,>' being 
> compiled
> d:\OpenSG\include\OpenSG\OSGFieldDataType.h(434) : warning C4806: '==' : 
> unsafe operation: no value of type 'bool' promoted to type 'int' can 
> equal the given constant
> d:\OpenSG\include\OpenSG\OSGFieldDataType.h(474) : see reference to class 
> template instantiation 'osg::FieldTraitsRecurseMapper1<FieldTypeT,>' 
> being compiled
> d:\OpenSG\include\OpenSG\OSGFieldDataType.h(488) : warning C4806: '==' : 
> unsafe operation: no value of type 'bool' promoted to type 'int' can 
> equal the given constant
> d:\OpenSG\include\OpenSG\OSGFieldDataType.h(528) : see reference to class 
> template instantiation 'osg::FieldTraitsRecurseMapper2<FieldTypeT,>' 
> being compiled
>
>
> Thank you,
>

Hello again

I found some error messages put out by the toutorials which work. Is there 
something like a DBG library I have to link?

'02move.exe': Loaded 'D:\STUDDY\studienarbeit- 
CG\openSG\OpenSG\Tutorials\Debug\02move.exe', Symbols loaded.
'02move.exe': Loaded 'C:\WINNT\system32\NTDLL.DLL', Cannot find or open a 
required DBG file.
'02move.exe': Loaded 'C:\WINNT\system32\msvcp70d.dll', Symbols loaded.
'02move.exe': Loaded 'C:\WINNT\system32\msvcr70d.dll', Symbols loaded.
'02move.exe': Loaded 'C:\WINNT\system32\KERNEL32.DLL', Cannot find or open 
a required DBG file.
'02move.exe': Loaded 'D:\STUDDY\studienarbeit- 
CG\openSG\OpenSG\lib\OSGBaseD.dll', No symbols loaded.
'02move.exe': Loaded 'D:\STUDDY\studienarbeit- 
CG\openSG\OpenSG\lib\stlport_vc745.dll', No symbols loaded.
'02move.exe': Loaded 'C:\WINNT\system32\msvcp70.dll', Symbols loaded.
'02move.exe': Loaded 'C:\WINNT\system32\msvcr70.dll', Symbols loaded.
'02move.exe': Loaded 'C:\WINNT\system32\winmm.dll', Cannot find or open a 
required DBG file.
'02move.exe': Loaded 'C:\WINNT\system32\USER32.DLL', Cannot find or open a 
required DBG file.
'02move.exe': Loaded 'C:\WINNT\system32\GDI32.DLL', Cannot find or open a 
required DBG file.
'02move.exe': Loaded 'C:\WINNT\system32\ADVAPI32.DLL', Cannot find or open 
a required DBG file.
'02move.exe': Loaded 'C:\WINNT\system32\rpcrt4.dll', Cannot find or open a 
required DBG file.
'02move.exe': Loaded 'C:\WINNT\system32\wsock32.dll', Cannot find or open a 
required DBG file.
'02move.exe': Loaded 'C:\WINNT\system32\ws2_32.dll', Cannot find or open a 
required DBG file.
'02move.exe': Loaded 'C:\WINNT\system32\msvcrt.dll', No symbols loaded.
'02move.exe': Loaded 'C:\WINNT\system32\ws2help.dll', Cannot find or open a 
required DBG file.
'02move.exe': Loaded 'D:\STUDDY\studienarbeit- 
CG\openSG\OpenSG\lib\OSGSystemD.dll', No symbols loaded.
'02move.exe': Loaded 'C:\WINNT\system32\OPENGL32.DLL', Cannot find or open 
a required DBG file.
'02move.exe': Loaded 'C:\WINNT\system32\glu32.dll', Cannot find or open a 
required DBG file.
'02move.exe': Loaded 'C:\WINNT\system32\ddraw.dll', No symbols loaded.
'02move.exe': Loaded 'C:\WINNT\system32\dciman32.dll', Cannot find or open 
a required DBG file.
'02move.exe': Loaded 'D:\STUDDY\studienarbeit- 
CG\openSG\OpenSG\lib\OSGWindowGLUTD.dll', No symbols loaded.
'02move.exe': Loaded 'C:\WINNT\system32\glut32.dll', No symbols loaded.
'02move.exe': Loaded 'C:\Programme\Winamp\Plugins\gen_bktb.dll', No symbols 
loaded.
'02move.exe': Loaded 'C:\WINNT\system32\SHELL32.DLL', Cannot find or open a 
required DBG file.
'02move.exe': Loaded 'C:\WINNT\system32\shlwapi.dll', No symbols loaded.
'02move.exe': Loaded 'C:\WINNT\system32\comctl32.dll', Cannot find or open 
a required DBG file.
'02move.exe': Loaded 'C:\WINNT\system32\COMDLG32.DLL', Cannot find or open 
a required DBG file.
'02move.exe': Loaded 'C:\WINNT\system32\3dfxOGL.dll', Cannot find or open a 
required DBG file.
'02move.exe': Loaded 'C:\WINNT\system32\glide3x.dll', No symbols loaded.
'02move.exe': Loaded 'C:\WINNT\system32\mcd32.dll', Cannot find or open a 
required DBG file.
'02move.exe': Unloaded 'C:\WINNT\system32\mcd32.dll'
'02move.exe': Loaded 'C:\WINNT\system32\SSSensor.dll', No symbols loaded.

Thank you,
-- 
Pascal Sproedt

Hi Polina,

On Tue, 2003-08-26 at 20:44, Polina Kondratieva wrote:
> Hi everybody,
> 
> I have some problems with TextureGrabForeground. I need to render the scene
> into the texture and got an advice to use TextureGrabForeground for this
> purpose. But I need not to write the texture to the file, I need it to apply 
> as a texture to another objects on the scene. I found some examples how to 
> use GrabForeground, unfortunately I cannot understand how does one of them 
> work.
> 
> The situation is not clear for the second example which uses
> TextureGrabForeground (testWindowGLUTTGF.cpp). It seems to me that the QUAD 
> with material (textureChunk used to keep the texture from the Foreground is
> attached to this material) somehow placed into the foreground of the viewport.
> The root for the viewport is set to the transformed QUAD NodePtr. We see the
> torus on the screen and it looks like we see it through the pink
> semi-transparent QUAD. And we do not see the QUAD itself (I guess, because
> the torus is at the top of scene graph attached to the SimpleManager and the
> QUAD lies exactly on the camera screen and does not attached to the 
> SimpleManager but to the second viewport). The function 'draw' of 
> TextureGrabForeground makes the copy of the viewport into the memory and is 
> called automatically (as it seems to me) when function 'draw' of Window class 
> is called.
> 
> But how does all it really work I have no idea! And how can I
> take the texture grabbed from the foreground?
> 
> For some reasons tex->getImage() (tex is TextureChunk) and also 
> tg->getTexture()->getImage() (where tg is TextureGrabForeground) give just 
> the black image with the size equal to the current viewport size.
> 
> 
> Could anybody help me?

the idea behind the TextureGrabForeground is is that the viewport it's
assigned to is directly copied into a texture on the graphics card,
without having to go to main memory (which would be a significant speed
hit), that's why the textures you get are black. To sensibly use it you
need to open a new Viewport using the Camera and Scene you want to use,
size it to be the size of your texture, and add the TGF to it. After the
Viewport is rendered the TGF will copy its contents into the texture,
and you can then use the same texture in another scene. 

Right now the TGF is hardcoded to grab into GL_TEXTURE2D, so it won't
help you for the CubeTexture. I'll add that and send you an example.

Yours

	Dirk


-- 
--
-- Dirk Reiners               OpenSG Forum               dirk@... 
-- The OpenSG Open Source Scenegraph:              http://www.opensg.org
-- Announcements:     http://lists.sf.net/lists/listinfo/opensg-announce

Hi Pascal,

On Tue, 2003-08-26 at 21:18, Pascal Sproedt wrote:
> Hello list
> 
> On Win2k, vs.net 2002, OpenSG with stl_port, voodoo3 with OpenGL of 
> DozerXP-Driver:
> 
> Tutorials 1-6 behave as wanted but the rest crushes without error messages. 
> Means Win has to be restarted by reset button...

that sounds more like graphics driver problems, as I've never had OpenSG
crash bad enough to kill the system (ok, some multi-thread apps can do
that, but the tutorials are not).

> It is possible that my system is a little bit untidy, cause I tested every 
> single version combination to run OpenSG. I already modified the 
> environment variables to fit the present setup (seems as if this brought 
> tutorials 3-5 to work, as they also did not want in the beginning). Do you 
> still know something to try?

Having multiple version of anything on Windows demands great care to use
the same version for compiling, linking and running the program. Are you
sure you do that with your OpenSG versions?

> There are some warnings but on another system it worked with them:
> 
> d:\OpenSG\include\OpenSG\OSGFieldDataType.h(380) : warning C4806: '==' : 
> unsafe operation: no value of type 'bool' promoted to type 'int' can equal 
> the given constant
>         d:\OpenSG\include\OpenSG\OSGFieldDataType.h(421) : see reference to 
> class template instantiation 'osg::FieldTraitsRecurseMapper<FieldTypeT,>' 
> being compiled
> d:\OpenSG\include\OpenSG\OSGFieldDataType.h(434) : warning C4806: '==' : 
> unsafe operation: no value of type 'bool' promoted to type 'int' can equal 
> the given constant
>         d:\OpenSG\include\OpenSG\OSGFieldDataType.h(474) : see reference to 
> class template instantiation 'osg::FieldTraitsRecurseMapper1<FieldTypeT,>' 
> being compiled
> d:\OpenSG\include\OpenSG\OSGFieldDataType.h(488) : warning C4806: '==' : 
> unsafe operation: no value of type 'bool' promoted to type 'int' can equal 
> the given constant
>         d:\OpenSG\include\OpenSG\OSGFieldDataType.h(528) : see reference to 
> class template instantiation 'osg::FieldTraitsRecurseMapper2<FieldTypeT,>' 
> being compiled

These are harmless.

Have you tried running another graphics card? The Voodoos are seriously
ancient, and I'm actually surprised there are Windows XP drivers at all.
And given that old GeForces or TNTs are very cheap, it would probably
make sense to upgrade.

Hope it helps

	Dirk

-- 
--
-- Dirk Reiners               OpenSG Forum               dirk@... 
-- The OpenSG Open Source Scenegraph:              http://www.opensg.org
-- Announcements:     http://lists.sf.net/lists/listinfo/opensg-announce

On 27 Aug 2003 18:45:14 +0200, Dirk Reiners <reiners@...> wrote:

>
> 	Hi Pascal,
>
> On Tue, 2003-08-26 at 21:18, Pascal Sproedt wrote:
>> Hello list
>>
>> On Win2k, vs.net 2002, OpenSG with stl_port, voodoo3 with OpenGL of 
>> DozerXP-Driver:
>>
>> Tutorials 1-6 behave as wanted but the rest crushes without error 
>> messages. Means Win has to be restarted by reset button...
>
> that sounds more like graphics driver problems, as I've never had OpenSG
> crash bad enough to kill the system (ok, some multi-thread apps can do
> that, but the tutorials are not).
>
>> It is possible that my system is a little bit untidy, cause I tested 
>> every single version combination to run OpenSG. I already modified the 
>> environment variables to fit the present setup (seems as if this brought 
>> tutorials 3-5 to work, as they also did not want in the beginning). Do 
>> you still know something to try?
>
> Having multiple version of anything on Windows demands great care to use
> the same version for compiling, linking and running the program. Are you
> sure you do that with your OpenSG versions?
>
> Have you tried running another graphics card? The Voodoos are seriously
> ancient, and I'm actually surprised there are Windows XP drivers at all.
> And given that old GeForces or TNTs are very cheap, it would probably
> make sense to upgrade.

Hm, at the moment there is only one istallation of OpenSG and VS.NET 
respectively and the environment variables should be right. I do not think 
that it is a problem of the graphics card though it is old indeed, as it 
worked with VS6 and ic7.1. Unfortunately the evaluation period for the 
compiler is over :]

Anyway, thanks a lot,
-- 
Pascal Sproedt

On Wed, 2003-08-27 at 19:13, Pascal Sproedt wrote:
> 
> Hm, at the moment there is only one istallation of OpenSG and VS.NET 
> respectively and the environment variables should be right. I do not think 
> that it is a problem of the graphics card though it is old indeed, as it 
> worked with VS6 and ic7.1. Unfortunately the evaluation period for the 
> compiler is over :]
> 
> Anyway, thanks a lot,

OK, I wasn't aware of the fact that it worked before. So everything
worked with VS6/Icc7.1, and when you tried it again with VS.NET it
crashes? 

I still suspect the graphics driver being the one actually crashing the
system. Could you try disabling it and using the software OpenGL
instead? There might be some problem that get invalid data to the OpenGL
driver, which might crash it. 

Yours

	Dirk

-- 
--
-- Dirk Reiners               OpenSG Forum               dirk@... 
-- The OpenSG Open Source Scenegraph:              http://www.opensg.org
-- Announcements:     http://lists.sf.net/lists/listinfo/opensg-announce

Hi Polina,

I couldn't quite finish what I wanted to do, but I hope it's enough to
help get you along. 

I attached some new sources to this mail for a fixed
TextureGrabForeground and -Background, as well as for the
MatrixCameraDecorator. Copy them to OpenSG/Source/System/Window and
recompile your SystemLib. 

Also attached is an example that uses the above classes to generate a
CubeMap. The map images themselves look ok, but the reflection is crap,
and I didn't have the time to fix it.

The idea is to add 6 new viewports, one for each CubeMap face. Each of
these renders one face of the CubeMap, using a Camera that is attached
to the object that should be mapped. The different directions are
created using a little CameraDecorator that rotates the viewing
direction for each face. The results are grabbed into the faces of  a
CubeMap using a TextureGrabForeground. For debugging the viewports are
put on top of the main port, for actual use you would put them below it,
so that they are not visible in the final image.

Hope it helps

	Dirk

-- 
--
-- Dirk Reiners               OpenSG Forum               dirk@... 
-- The OpenSG Open Source Scenegraph:              http://www.opensg.org
-- Announcements:     http://lists.sf.net/lists/listinfo/opensg-announce

Akos Balazs wrote:

> Hi guys,
> 
> It didn't get through on Monday so I'm resending, the list seems to
> work again...
> 
> Akos
> 
> ---------- Forwarded message ----------
> Date: Mon, 25 Aug 2003 21:15:39 +0200 (CEST)
> From: Akos Balazs <edhellon@...>
> To: opensg-users@...
> Subject: OSGQGLWidget
> 
> Hi guys,
> 
> Just a quick question: I remember that recently there has been some issues
> with OSGQGLWidget (it didn't compile after a certain snapshot or something
> like that). Has that been resolved? Or if not, does anyone know a working
> (and simple :) solution for integrating an OpenSG-rendering window into a
> Qt application?
> 
> I have to write a somewhat spiffed-up version of the 'testClusterClient'
> program for controlling our powerwall and I thought about doing the UI in
> Qt. However, should anyone have better ideas or whatever, I'm open to
> suggestions.  :-)
> 
> Thanks,
> 	Akos

Hi,

there a several ways doing this. OSGQGLWidget creates its own opengl 
context and it is thread safe so you can open multiple windows und 
render with multiple threads. If you don't need this you can try a 
passive window this won't create a new opengl context just uses the 
context from the QGLWidget (This works with all kinds of GUI's)
I also wrote my own QT based cluster server and client with a passive 
window. This works really fine. For a code example just look in 
WindowSystems/QT/testPassiveQT.cpp

Andreas

Hi Jochen,

On Tue, 2003-08-26 at 15:13, Jochen Winzen wrote:
> Hi Dirk, hi everyone!
>  
> I have some problems with an OpenGL visualization program i wanted to
> change to use OpenSG. At the moment the most severe problem is a
> numerical one. Since my program renders a really large scene (a solar
> system) matrix-/vector calculations with float precision are not
> sufficient. In OpenGL i used double versions (glLoadMatrixd etc.) and
> everything was ok. 

Hm, I was under the impression that all chips and OpenGL libs use floats
internally, so it's a little surprising that it helps.

> But now i just tried to build the scene in OpenSG and see a "wobble"
> in geometry since the transformations become too inaccurate. 

> The other problem is that my dynamic LOD algorithm creates/deletes
> many nodes on the fly (peak rate: up to 200 nodes = 20k triangles per
> frame). Rendering performance is as good as pure OpenGL but the
> automatic memory handling seems to collect the changes for some
> seconds and then the garbage collector starts running (with the effect
> of 2 seconds program interruption).

I would suspect the display list building to be the problem. Per default
OpenSG geometries are cached into display lists, and that can take some
time. Can you try to switch it off for your dynamic objects by calling
geo->setDlistCache(false); and see if that helps? Performancewise the
hit depends on your graphics card and system, on a fast system with a
current card the difference is pretty small.

> Now my questions:
> 1. Is there a way to force OpenSG to use double precision in all
> transformation computations?

Nope, not directly. You would have to add a DoubleTransform node, that
keeps a double precision transformation, and rewrite the RenderAction to
use double precision matrices internally.

> 2. Can view frustum culling be disabled since i already use it in the
> underlying LOD algo?

Sure: renderaction->setFrustumCulling(false);

> 3. Is there a way to influence memory handling in OpenSG?

Not directly, but I suspect the problem is the display lists, not the
memory.

> 4. OpenSG plus has some extensions for dynamic LOD and large scenes
> are in development. When will they be part of OpenSG and could this
> help to successfully change this program to OpenSG? 

By the end of the year, as that is when the project ends. Double
precision models weren't intended here, so that won't be part of it,
though.

Hope it helps

	Dirk

-- 
--
-- Dirk Reiners               OpenSG Forum               dirk@... 
-- The OpenSG Open Source Scenegraph:              http://www.opensg.org
-- Announcements:     http://lists.sf.net/lists/listinfo/opensg-announce