I have added the following (copied from SimpleSceneManager init) to my
modified OpenSGApp.h:
...
#include
#include
#include
#include
...
OSG::SimpleStatisticsForegroundPtr sf =
OSG::SimpleStatisticsForeground::create();
beginEditCP(sf);
sf->setSize(25);
sf->setColor(OSG::Color4f
Hi,
On Tue, 2006-08-29 at 15:04 -0500, Allen Bierbaum wrote:
> What is the "attachment handling" interface in OSG::Image used for?
>
> See OSGImage.h
>
> /*-*/
> /*! \name attachment
> handling
Hi Allen,
On Tue, 2006-08-29 at 15:04 -0500, Allen Bierbaum wrote:
> What is the "attachment handling" interface in OSG::Image used for?
>
> See OSGImage.h
>
> /*-*/
> /*! \name attachment
> handling
Hi Allen,
On Tue, 2006-08-29 at 13:54 -0500, Allen Bierbaum wrote:
>
> Sounds a little like a chicken and the egg problem. You want the source
> files clean so when a developer goes there that already knows what they
> want they can get to it quickly. But at the same time you want goo
What is the "attachment handling" interface in OSG::Image used for?
See OSGImage.h
/*-*/
/*! \name attachment
handling*/
/*!
\{
Hi Alan,
On Tue, 2006-08-29 at 14:43 -0500, Alan Austin wrote:
> I've been building OpenSG on unix/windows using scons because it is
> so much easier and seems to work better, but there is no system to build
> the documentation with scons. Is this planned to be included?
Not for 1
I've been building OpenSG on unix/windows using scons because it is
so much easier and seems to work better, but there is no system to build
the documentation with scons. Is this planned to be included?
-Alan
--
Alan Austin Cell
Dirk Reiners wrote:
> Hi All,
>
>next round of doc comments. ;) Hope fully getting close to being done.
>
>On Tue, 2006-08-29 at 08:44 +0200, Haykel BEN JEMIA wrote:
>
>
>>>- I've thought about the best place to document the member vars.
>>>
>>>
>>They
>>
>>
>>>don't have a natur
Hi Alexandra,
On Tue, 2006-08-29 at 16:38 +0100, Alexandra Ribeiro wrote:
> I am developing a project that needs at the moment the collision
> detection implementation, and I saw that maybe BoxVolume class would
> be an answer to my problem.
>
> What I am trying to do is to create a Box
Hello,
one more suggestion for the documentation (sorry for beeing so late). It just came to my mind. For what I understood there where discussions on test sources/programs which could serve as examples but are hidden among the sources.
In the documentation of VTK (The Visualization Toolkit, www.vt
Dirk Reiners wrote:
> Hi All,
[ snip ]
> On Tue, 2006-08-29 at 13:06 +0200, jan p. springer wrote:
>> one possible solution is to split into several doxygen runs. for
>> avango the
>> (outdated) result is here:
>>
>> http://www.avango.org/documentation/doxygen/index.html
>>
>> we defined d
Hi All,
next round of doc comments. ;) Hope fully getting close to being done.
On Tue, 2006-08-29 at 08:44 +0200, Haykel BEN JEMIA wrote:
> > - I've thought about the best place to document the member vars.
> They
> > don't have a natural representation in the source file, so it's
> eith
Hi all,
I am developing a project that needs at the moment the collision
detection implementation, and I saw that maybe BoxVolume class would be an answer
to my problem.
What I am trying to do is to create a BoxVolume to each of
my scene objects and then add that BoxVolume as an Attach
Hi,
On Tue, 2006-08-29 at 09:01 -0500, Dirk Reiners wrote:
> Hi All,
>
> On Mon, 2006-08-28 at 12:01 +0200, Patric Schmitz wrote:
> >
> > Okay, I ivestigated it a bit further myself, and found out that the
> > macro is normally defined in stdcomp.h of the Cstd standard library.
> > STLpor
Hi All,
On Mon, 2006-08-28 at 12:01 +0200, Patric Schmitz wrote:
>
> Okay, I ivestigated it a bit further myself, and found out that the
> macro is normally defined in stdcomp.h of the Cstd standard library.
> STLport seems not to define this macro at all. So I provisionally
> changed th
Hi Peppe,
I fixed the missing D in the debug lib names. I compiled all tutorials
and they work fine for me. Did you really rename the debug libs?
Renaming the opt build libs would create such a error message.
Andreas
> Hi Andreas,
> I compiled all...the release version works well, but the dbg
Dirk Reiners wrote:
> Hi all,
>
>ok, here's my version, and my comments to the other versions. I also put
>them up at www.dirkreiners.com/doc_challenge , to compare the results.
>To create those I turned the INLINE_SOURCES, REFERENCED_BY_RELATION and
>REFERENCES_RELATION options off compared
On 8/29/06, Allen Bierbaum <[EMAIL PROTECTED]> wrote:
[snip]
>
> >>Related to this, I think we should setup a mailing list for
> >>notifications of all ticket adds and changes. That would be much easier
> >>then visiting the tickets everyday. :)
> >>
> >>
> >
> >Does Trac support that? I couldn'
[snip]
>>>How do you do that? Can you include other pages into a united page?
>>>
>>>
>>>
>>>
>>I think so.
>>
>>
>
>Not yet, I think. So far you can only do single pages, but there seems
>to be some development on this plugin. But currently I'm moving away
>from that anyway, see my oth
Dirk Reiners said the following on 08/29/06 07:04:
[ snip ]
>> If only doxygen were multi-threaded. :)
>
> I spent some time on the weekend looking into that. Profiling doxygen
> turned out to be a bigger problem than expected (valgrind segfaults...),
> and looking at the code: making that MT-safe
Hello Andreas,
> I fixed it after some test I will check it in. The OSGScanParseSkel.h
> includes the FlexLexer.h file. Now deriving from the osg vrml loader,
> this includes again the FlexLexer.h and this results in some
> unresolved
> symbols.
Ok, good, forget my last eMail.
Bye,
Patrick
Hello Matthias,
does compiling the lexer and parser files succeed? I realized this
morning that compiling with old versions of bison failed silently
without stopping the (make) build process - maybe it is the same for
scons. I already fixed that in the CVS a few minutes ago.
Bye,
Patrick
Hi,
I fixed it after some test I will check it in. The OSGScanParseSkel.h
includes the FlexLexer.h file. Now deriving from the osg vrml loader,
this includes again the FlexLexer.h and this results in some unresolved
symbols.
Andreas
> Hello Patrick,
>
> we are using the scons system for Open
Hi Andreas,
I compiled all...the release version works well, but the dbg version of
the libs has some problems. First of all the compilation creates the
nomefile.lib and nomefile.dll and not the nomefileD.lib and
nomefileD.dll, so I had link errors because the nomefileD.lib are not
present in m
Hello Patrick,
we are using the scons system for OpenSG as well as for our own
software, so everything should be updated. Andreas mentioned that it
could be due to inlining things in flexlexer.h which is included from
OSGScanParseSkel.h
Regards
Matthias
On Tuesday 29 August 2006 12:02, Patr
Hello Matthias,
which build system are you using? I did not update the lexer and
parser files for the Visual Studio project files. I also did not
check the scons build system. When using make, did you call "make
distclean" (dependencies are not handled automatically on windows)?
Bye,
Patri
Hello Patrick,
at first kudos for reducing the size of code and lib, I alwasy wondered
why the system lib was bigger than Qt ;-) But I guess its still not
alright, there are some missing symbols on windows, building our
software gives these errors during linking:
vrVRMLLoader.obj : error LNK20
27 matches
Mail list logo