Re: [osg-users] [osgPlugins] build osg 3.5.4 plugin lua error, on vs 2010

[René Molenaar]

Yes,
the additional memcpy, is the old code,
(just in case i added updated/fixed version).

gr.
René


2016-10-05 13:57 GMT+02:00 Robert Osfield <robert.osfi...@gmail.com>:

> Hi Rene,
>
> Thanks for the fix.  I've just compared to master version of lstring.c
> against your modification version and there are two difference, first
> the declaration of the start_of_string local variable at the top of
> the function while resolves the compile issue, and second a memcpy
> addition prior to the assingment to start_of_string.  This second
> addition looks like it's been pulled in from the 3.4 branch.
>
> Robert,
>
> On 5 October 2016 at 12:27, René Molenaar <megamillerz...@gmail.com>
> wrote:
> > Hi all,
> >
> > i ran into the same problem (when compiling in vs2012), see this
> changeset:
> > https://github.com/openscenegraph/OpenSceneGraph/commit/
> e64e70870d51873621be4f90f1301640d882704d
> >
> > char* start_of_string;
> >
> > this is caused by the fact that the file is c code, not c++ and the new
> > variable needs to be declared at the start of the block.
> >
> > (updated file is attached)
> >
> > groetjes,
> > René
> >
> >
> > 2016-08-08 9:11 GMT+02:00 nguyen duy nam <osgfo...@tevs.eu>:
> >>
> >> Hi, help me
> >> log error
> >>  All outputs are up-to-date.
> >> 3>  lstring.c
> >>
> >> 3>..\..\..\..\..\sources\openscenegraph3.5.0\src\
> osgPlugins\lua\lua-5.2.3\src\lstring.c(107):
> >> error C2143: syntax error : missing ';' before 'type'
> >>
> >> 3>..\..\..\..\..\sources\openscenegraph3.5.0\src\
> osgPlugins\lua\lua-5.2.3\src\lstring.c(108):
> >> error C2065: 'start_of_string' : undeclared identifier
> >>
> >> 3>..\..\..\..\..\sources\openscenegraph3.5.0\src\
> osgPlugins\lua\lua-5.2.3\src\lstring.c(108):
> >> warning C4022: 'memcpy' : pointer mismatch for actual parameter 1
> >>
> >> 3>..\..\..\..\..\sources\openscenegraph3.5.0\src\
> osgPlugins\lua\lua-5.2.3\src\lstring.c(109):
> >> error C2065: 'start_of_string' : undeclared identifier
> >>
> >> 3>..\..\..\..\..\sources\openscenegraph3.5.0\src\
> osgPlugins\lua\lua-5.2.3\src\lstring.c(109):
> >> error C2109: subscript requires array or pointer type
> >>
> >> 3>..\..\..\..\..\sources\openscenegraph3.5.0\src\
> osgPlugins\lua\lua-5.2.3\src\lstring.c(117):
> >> error C2143: syntax error : missing '{' before '*'
> >>
> >> 3>..\..\..\..\..\sources\openscenegraph3.5.0\src\
> osgPlugins\lua\lua-5.2.3\src\lstring.c(118):
> >> warning C4431: missing type specifier - int assumed. Note: C no longer
> >> supports default-int
> >>
> >> 3>..\..\..\..\..\sources\openscenegraph3.5.0\src\
> osgPlugins\lua\lua-5.2.3\src\lstring.c(127):
> >> warning C4133: 'return' : incompatible types - from 'TString *' to 'int
> *'
> >>
> >> 3>..\..\..\..\..\sources\openscenegraph3.5.0\src\
> osgPlugins\lua\lua-5.2.3\src\lstring.c(150):
> >> warning C4133: 'return' : incompatible types - from 'int *' to 'TString
> *'
> >> 3>
> >> ...
> >> anyone show me, how to fix.
> >> Thank you!
> >>
> >> Cheers,
> >> nguyen
> >>
> >> --
> >> Read this topic online here:
> >> http://forum.openscenegraph.org/viewtopic.php?p=68301#68301
> >>
> >>
> >>
> >>
> >>
> >> ___
> >> osg-users mailing list
> >> osg-users@lists.openscenegraph.org
> >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-
> openscenegraph.org
> >
> >
> >
> > ___
> > osg-users mailing list
> > osg-users@lists.openscenegraph.org
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-
> openscenegraph.org
> >
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
/*
** $Id: lstring.c,v 2.26.1.1 2013/04/12 18:48:47 roberto Exp $
** String table (keeps all strings handled by Lua)
** See Copyright Notice in lua.h
*/


#include 

#define lstring_c
#define LUA_CORE

#include "lua.h"

#include "lmem.h"
#include "lobject.h"
#include "lstate.h"
#include "lstring.h"


/*
** Lua will use at most ~(2^LUAI_HASHLIMIT) bytes from a string to
** compute its hash
*/
#if !defined(LUAI_HASH

Re: [osg-users] [osgPlugins] build osg 3.5.4 plugin lua error, on vs 2010

[René Molenaar]

Hi all,

i ran into the same problem (when compiling in vs2012), see this changeset:
https://github.com/openscenegraph/OpenSceneGraph/commit/e64e70870d51873621be4f90f1301640d882704d

char* start_of_string;

this is caused by the fact that the file is c code, not c++ and the new
variable needs to be declared at the start of the block.

(updated file is attached)

groetjes,
René


2016-08-08 9:11 GMT+02:00 nguyen duy nam :

> Hi, help me
> log error
>  All outputs are up-to-date.
> 3>  lstring.c
> 3>..\..\..\..\..\sources\openscenegraph3.5.0\src\
> osgPlugins\lua\lua-5.2.3\src\lstring.c(107): error C2143: syntax error :
> missing ';' before 'type'
> 3>..\..\..\..\..\sources\openscenegraph3.5.0\src\
> osgPlugins\lua\lua-5.2.3\src\lstring.c(108): error C2065:
> 'start_of_string' : undeclared identifier
> 3>..\..\..\..\..\sources\openscenegraph3.5.0\src\
> osgPlugins\lua\lua-5.2.3\src\lstring.c(108): warning C4022: 'memcpy' :
> pointer mismatch for actual parameter 1
> 3>..\..\..\..\..\sources\openscenegraph3.5.0\src\
> osgPlugins\lua\lua-5.2.3\src\lstring.c(109): error C2065:
> 'start_of_string' : undeclared identifier
> 3>..\..\..\..\..\sources\openscenegraph3.5.0\src\
> osgPlugins\lua\lua-5.2.3\src\lstring.c(109): error C2109: subscript
> requires array or pointer type
> 3>..\..\..\..\..\sources\openscenegraph3.5.0\src\
> osgPlugins\lua\lua-5.2.3\src\lstring.c(117): error C2143: syntax error :
> missing '{' before '*'
> 3>..\..\..\..\..\sources\openscenegraph3.5.0\src\
> osgPlugins\lua\lua-5.2.3\src\lstring.c(118): warning C4431: missing type
> specifier - int assumed. Note: C no longer supports default-int
> 3>..\..\..\..\..\sources\openscenegraph3.5.0\src\
> osgPlugins\lua\lua-5.2.3\src\lstring.c(127): warning C4133: 'return' :
> incompatible types - from 'TString *' to 'int *'
> 3>..\..\..\..\..\sources\openscenegraph3.5.0\src\
> osgPlugins\lua\lua-5.2.3\src\lstring.c(150): warning C4133: 'return' :
> incompatible types - from 'int *' to 'TString *'
> 3>
> ...
> anyone show me, how to fix.
> Thank you!
>
> Cheers,
> nguyen
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=68301#68301
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
/*
** $Id: lstring.c,v 2.26.1.1 2013/04/12 18:48:47 roberto Exp $
** String table (keeps all strings handled by Lua)
** See Copyright Notice in lua.h
*/


#include 

#define lstring_c
#define LUA_CORE

#include "lua.h"

#include "lmem.h"
#include "lobject.h"
#include "lstate.h"
#include "lstring.h"


/*
** Lua will use at most ~(2^LUAI_HASHLIMIT) bytes from a string to
** compute its hash
*/
#if !defined(LUAI_HASHLIMIT)
#define LUAI_HASHLIMIT		5
#endif


/*
** equality for long strings
*/
int luaS_eqlngstr (TString *a, TString *b) {
  size_t len = a->tsv.len;
  lua_assert(a->tsv.tt == LUA_TLNGSTR && b->tsv.tt == LUA_TLNGSTR);
  return (a == b) ||  /* same instance or... */
((len == b->tsv.len) &&  /* equal length and ... */
 (memcmp(getstr(a), getstr(b), len) == 0));  /* equal contents */
}


/*
** equality for strings
*/
int luaS_eqstr (TString *a, TString *b) {
  return (a->tsv.tt == b->tsv.tt) &&
 (a->tsv.tt == LUA_TSHRSTR ? eqshrstr(a, b) : luaS_eqlngstr(a, b));
}


unsigned int luaS_hash (const char *str, size_t l, unsigned int seed) {
  unsigned int h = seed ^ cast(unsigned int, l);
  size_t l1;
  size_t step = (l >> LUAI_HASHLIMIT) + 1;
  for (l1 = l; l1 >= step; l1 -= step)
h = h ^ ((h<<5) + (h>>2) + cast_byte(str[l1 - 1]));
  return h;
}


/*
** resizes the string table
*/
void luaS_resize (lua_State *L, int newsize) {
  int i;
  stringtable *tb = (L)->strt;
  /* cannot resize while GC is traversing strings */
  luaC_runtilstate(L, ~bitmask(GCSsweepstring));
  if (newsize > tb->size) {
luaM_reallocvector(L, tb->hash, tb->size, newsize, GCObject *);
for (i = tb->size; i < newsize; i++) tb->hash[i] = NULL;
  }
  /* rehash */
  for (i=0; isize; i++) {
GCObject *p = tb->hash[i];
tb->hash[i] = NULL;
while (p) {  /* for each node in the list */
  GCObject *next = gch(p)->next;  /* save next */
  unsigned int h = lmod(gco2ts(p)->hash, newsize);  /* new position */
  gch(p)->next = tb->hash[h];  /* chain it */
  tb->hash[h] = p;
  resetoldbit(p);  /* see MOVE OLD rule */
  p = next;
}
  }
  if (newsize < tb->size) {
/* shrinking slice must be empty */
lua_assert(tb->hash[newsize] == NULL && tb->hash[tb->size - 1] == NULL);
luaM_reallocvector(L, tb->hash, tb->size, newsize, GCObject *);
  }
  tb->size = newsize;
}


/*
** creates a new string object
*/
static TString *createstrobj (lua_State *L, const char *str, size_t l,
  int tag, unsigned int h, GCObject **list) {
  TString *ts;
  size_t totalsize;  /* total size of TString object */
  char* 

[osg-users] division by zero in _delta_frame_time / (_ga_t0-getTime() - _ga_t1-getTime()) caused by event synchronization

[René Molenaar]

Hi all,

i have a small bug report in the manipulators after updating from 3.01 to
3.1.3.
after some searching, i found a division by 0.

double throwScale =  (_thrown  _ga_t0.valid()  _ga_t1.valid()) ?
_delta_frame_time / (_ga_t0-getTime() - _ga_t1-getTime()) : 1.0;

I suspect the changes in the eventQueue (  time reset to the next valid
time )
cause the _ga_t0 and _ga_t1 to be equal, causing a divide by zero.

(also note i'am running in ON_DEMAND mode).

the problem occurs after 'throwing' with a manipulator, this causes NaN in
matrices.

one way to reproduce the problem is running the osgviewer like this:

set OSG_NOTIFY_LEVEL=DEBUG
osgviewerd cow.osg --window 40 40 500 500 --run-on-demand
--run-max-frame-rate 10

and throw and scroll simultaneously with the mouse several times and
very quickly. ( lower framerate helps with reproduction )

you will eventually get:
CullVisitor::apply(Geode) detected NaN,
etc

gr.

René
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Render a lot of labels

[René Molenaar]

Hi,

u can use a custom drawable and ftgl (freetype gl) for this.
http://sourceforge.net/projects/ftgl/

René

 On Nov 28, 2012 11:09 PM, Andrew Cunningham andr...@mac.com wrote:

 Hi,
 I render the letters of the alphabet into pre-built bitmaps at various
 points sizes.

 Andrew

 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=51274#51274





 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [osgPPU] Blur artifacts in HDR effect

[René Molenaar]

I don't think there are other textures involved to add MSAA to..

 two other blur units before the UnitInResampleOut could help yes,

also notice that the radius should be about 2.5 - 3 times sigma to make sure
the entire kernel is used instead of cutoff by the radius.

grtz,

René

2011/11/24 Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com

 Hello René,


  maybe multisampling can reduce the problem.


 The screenshot was with 4x MSAA active (in the camera-attach(...) call of
 the HDR code, where we bind a texture to the main scene camera which is
 then passed to the first unit in the osgPPU pipeline).

 Perhaps you're suggesting I enable MSAA for one of the other stages in the
 pipeline? How would I do that?


  also you can add an additional gausian blur to the image before
 resampling to reduce the artifacts.


 Again using the same separable blur (x and y passes)? So I would add two
 other units before the UnitInResampleOut?

 Thanks for your suggestions,


 J-S
 --
 __**
 Jean-Sebastien Guay
 jean-sebastien.guay@cm-labs.**comjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/

 http://whitestar02.dyndns-web.**com/http://whitestar02.dyndns-web.com/
 __**_
 osg-users mailing list
 osg-users@lists.**openscenegraph.org osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.**org/listinfo.cgi/osg-users-**
 openscenegraph.orghttp://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [osgPPU] Blur artifacts in HDR effect

[René Molenaar]

the radius determines the pixel for which the sigma is used.
once you are on the edges of the kernel (gauss curve approaches 0),
you can stop blurring.

this will be around 2.5 - 3 times sigma.

the correct sigma depends on the effect intended,
try different sigmas ranging from 2-15 and radius = 2.5 * sigma
(maybe you can attach a slider to interactively determine the best value.)

René



2011/11/24 Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com

 Hello René,


  also notice that the radius should be about 2.5 - 3 times sigma to make
 sure
 the entire kernel is used instead of cutoff by the radius.


 The default values in the osgPPU hdr example are sigma = 4.0 and radius =
 7.0, however I have not seen a difference between radius = 7.0, 15.0 and
 200.0... So there I wonder if the values are getting to the shaders
 correctly.

 What values would you suggest I use for good results?

 Thanks,


 J-S
 --
 __**
 Jean-Sebastien Guay
 jean-sebastien.guay@cm-labs.**comjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/

 http://whitestar02.dyndns-web.**com/http://whitestar02.dyndns-web.com/
 __**_
 osg-users mailing list
 osg-users@lists.**openscenegraph.org osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.**org/listinfo.cgi/osg-users-**
 openscenegraph.orghttp://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [osgPPU] Blur artifacts in HDR effect

[René Molenaar]

Hi,

maybe multisampling can reduce the problem.
using osgPPU hdr I noticed small details with high frequency (distant
lights) appearing and disappearing.

mutlisampling reduced these artifacts.
(It did however cause a one frame delay, which isn't very noticable until
you use a request redraw viewer,
or screencaptures)

also you can add an additional gausian blur to the image before resampling
to reduce the artifacts.

grtz,

René Molenaar



2011/11/23 Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com

 Hello all,

 I am using the osgPPU HDR effect, and I noticed some undesirable artifacts
 probably caused by the blur effect, or the resample of the original pass
 (before the blur). Using the default resample settings (resample by 0.25 in
 each direction) I get the result in the attached screenshot. Look at the
 edges of the black cables, there are regular artifacts along their length,
 they are supposed to be a smooth edge.

 If I change the resample to 0.5 or 1.0 in each direction, I don't get
 these artifacts, but of course then the glare effect is less interesting :-)

 I also saw these parameters which are related to the blur (their name
 implies it at least) but changing them doesn't seem to make a significant
 difference.

  float mHDRBlurSigma = 4.0;
  float mHDRBlurRadius = 7.0;

 Can anyone give me a hint as to what could help this situation? Perhaps
 OpenGL is already filtering the resampled unit and then the blur uses that
 badly-filtered image as input? Or perhaps the blur shaders have some error
 in them?

 Thanks in advance,

 J-S
 --
 __**
 Jean-Sebastien Guay
 jean-sebastien.guay@cm-labs.**comjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/

 http://whitestar02.dyndns-web.**com/http://whitestar02.dyndns-web.com/

 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgPPU swig wrapped and viewport issues

[René Molenaar]

Hi,

I'am experiencing some issues with osgPPU, (some might have been addressed
before on the list):

* I use an ON_DEMAND scheme and osgPPU always has a one frame lag. (i am
using a simple setup similar to examples like osgppu_viewer)
* My Camera had some hud camera childs doing a POST_RENDER, these huds are
no longer visible.

and the previously mentioned issues
* auto compute near far breaks my manipulators
* viewports need a 0,0 origin

I am using osgPPU to add camera effects like bloom and vignetting,
the results are nice and the performance is good,
now i need to resolve these issues to finalize the implementation.

Any ideas if i can resolve this in my application, or are these issues to be
solved in osgPPU or osg?

Grtz,

René

Op 22 augustus 2011 15:42 schreef René Molenaar
megamillerz...@gmail.comhet volgende:

 Hi,

 I recently started some experimenting with osgPPU.
 The first results are very nice and promising!! (osgppu rocks ;-))

 I added osgswig wrappers to the osgswig project to do some testing, and i
 experienced a few glitches.

 1. there were some manipulation glitches, these were caused by our camera
 setting COMPUTE_NEAR_FAR_USING_BOUNDING_VOLUMES on. Turning this off
 resolved the issue.

 2. i had some resize problems, after searching on the forum. I found a
 solution, by adding some additional explicit resize calls ( for example in
 an event handler ):

  osgPPU::Camera::resizeViewport(0,0, ea.getWindowWidth(), 
 ea.getWindowHeight(), viewer-getCamera()); 
 viewer-getProcessor()-onViewportChange();

 this does work when the x and y of the viewport are 0, 0 but i see wrong
 results if x and y are increased ( purple bars appear ).

 3. an additional frame() call was needed after the scene is loaded and
 before the postprocessor is attached, otherwise i would see only a black
 screen.

 Grtz,

 René


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] osgPPU swig wrapped and viewport issues

[René Molenaar]

Hi,

I recently started some experimenting with osgPPU.
The first results are very nice and promising!! (osgppu rocks ;-))

I added osgswig wrappers to the osgswig project to do some testing, and i
experienced a few glitches.

1. there were some manipulation glitches, these were caused by our camera
setting COMPUTE_NEAR_FAR_USING_BOUNDING_VOLUMES on. Turning this off
resolved the issue.

2. i had some resize problems, after searching on the forum. I found a
solution, by adding some additional explicit resize calls ( for example in
an event handler ):

 osgPPU::Camera::resizeViewport(0,0, ea.getWindowWidth(),
ea.getWindowHeight(), viewer-getCamera());
viewer-getProcessor()-onViewportChange();

this does work when the x and y of the viewport are 0, 0 but i see wrong
results if x and y are increased ( purple bars appear ).

3. an additional frame() call was needed after the scene is loaded and
before the postprocessor is attached, otherwise i would see only a black
screen.

Grtz,

René
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Delighted to announce OpenSceneGraph-3.0.0!

[René Molenaar]

Very nice,

we are defiantly going to enjoy OpenSceneGraph 3.0

Thank you,

René

2011/6/29 Torben Dannhauer tor...@dannhauer.info

 Dear Robert,

 thank you for your effort! I hope you will enjoy the trip with you family!

 Thanks also to the community, OSg 3.0 will be great!

 Best wishes,

 Torben

 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=41007#41007





 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenSceneGraph-2.9.16 dev release tagged

[René Molenaar]

Nice! I will check it out!

grtz,

René


2011/6/9 Robert Osfield robert.osfi...@gmail.com

 Hi All,

 I have just tagged the 2.9.16 dev release.

 OpenSceneGraph-2.9.16, released on 9th June 2011, key deliverables in
 this dev release are:
   new osg::Object user object data support with an
 osg::UserDataContainer? and templated osg::ValueObject? and
 automatical serialization.
   two new Android examples for GLES1 and GLES2 respectively.
   Merged pending submissions that fixed a range of bugs and minor
 feature additions.

 source package : OpenSceneGraph-2.9.16.zip

 svn tag: svn co

 http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.9.16
 OpenSceneGraph

 Thanks to all that have contributed code, fixes and testing.  Just one
 week left till feature freeze for 3.0 yehawww ;-)

 Robert.
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] PixelBufferWin32 memory leak and resize functionality

[René Molenaar]

Hi osg-users,

In the application I'am working on we use PixelBufferWin32. I found there
was a large memory leak and noticed incorrect shader result after destroying
and creating a new pbuffer-enabled viewer.
( I adapted the pbuffertest code posted a while ago to create and destroy
multiple pbuffers to see that this caused the leakage) :

traits-pbuffer = true //leaks
v.s.
traits-pbuffer = false//doesn't leak

After some experimenting I decided to reuse the existing pbuffer to solve
the problems. However this did not work if the pbuffer needed a different
size. So I created a resize function in the
PixelBufferWin32 class. This function does something like this (short
version):

//create new pbuffer
newhwnd =wgle-wglCreatePbufferARB(_hdc, _format, width, height,
bAttribList[0]);
newhdc = wgle-wglGetPbufferDCARB(newhwnd);
newhglrc = wglCreateContext(newhdc);
// delete the old context and pbuffer
wglMakeCurrent(_hdc,0);
if ( !wglDeleteContext(_hglrc) ) {}
if ( !wgle-wglReleasePbufferDCARB(_hwnd, _hdc) ) {}
if ( !wgle-wglDestroyPbufferARB(_hwnd) ) {}
_hwnd = newhwnd;
_hdc = newhdc;
_hglrc = newhglrc;

This solved the problems, now I could reuse and resize pbuffers. The
difference with this function and creating and destroying the entire
PixelBufferWin32 is that there is no TempWindow involved.
It is the TempWindow class that was causing the memory leak. There is a
comment in the code of this class:

PixelBufferWin32.cpp:

319:// mew 2005-05-09 commented out due to crashes.
320:// possible causes are unsafe destructor ordering, or context
already
321:// deleted by window deletion; see:
322://
http://openscenegraph.org/pipermail/osg-users/2005-May/052753.html
323://wglDeleteContext(_context);
324:_context = 0;

after uncommenting the wglDeleteContext(_context) call the memory leak was
gone.
I could not read the original post and now I am not sure how to procede. If
we want a resize function in the PixelBufferWin32 class I can submit this?
Can the wglDeleteContext(_context)
be uncommented without causing the original crashes? Other suggestions?

Thanks!

René
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Cannot debug osg/dotnet application on windows after update from 2.9.7

[René Molenaar]

Hi all,

This week I updated OpenSceneGraph to 2.9.9 and got the following problem in
an osg/dotnet application, windows 7, vs2008sp1:

The Program can't start because MSVCP90D.dll is missing from your computer.
Try reinstalling the program to fix this problem.

This happens after trying to load a file with an osgDB plugin.

when linking with osg 2.9.7 this problem does not occur. So I tranced down
the changes in osg and found the following change
in src\OpenThreads\win32\CMakeLists.txt

  From Alok Priyadashi, The attached patch fixes
  - compile errors on windows when compiled with UNICODE flag
  - warnings for duplicate WIN32_LEAN_AND_MEAN. I think this should
  better fixed by adding WIN32_LEAN_AND_MEAN to vcproj preprocessor
  list.

  ADD_DEFINITIONS(-DWIN32_LEAN_AND_MEAN)
  ADD_DEFINITIONS(-D_WIN32_WINNT=0x0400)

reverting this change resolved the problem for me.

with the _WIN32_WINNT definition a particular version of Windows is
targeted, in this case this causes a problem finding the right version of
the debug dlls in the dotnet application ... (bleh...)

The problem does not occur in the c++ examples/applications.

cheers,

René
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenSceneGaph 2.9.8 dev release tagged :-)

[René Molenaar]

Nice,

I am building and testing the release.
looks good.

René


2010/6/21 Michael Gronager grona...@ndgf.org

 Hi Robert,

 Congratz with this, but perhaps you should update the date (applies for
 2.9.7 as well):

 * OpenSceneGraph-2.9.8, released on 18th June 2009, key

 I guess it should be 2010...

 Apart from that it builds fairly ok on a OSX, though I am a bit puzzled
 about the lack of ability to build frameworks from Xcode - should I stick
 with the Makefiles ?

 Cheers,

 Michael (joining the list again for a 3D hobby project with my son...)



 On 18/06/2010, at 18:42, Robert Osfield wrote:

  Hi All,
 
  I have just tagged the OpenSceneGraph-2.9.8 dev release.  Thanks to
  all those who've contributed to development these four months since
  the last dev release, and all those that have been testing/debugging
  over the last day.  I've put a  quick summary of changes up on
 
 
 http://www.openscenegraph.org/projects/osg/wiki/Downloads/DeveloperReleases
 
  Which reads:
 
 * OpenSceneGraph-2.9.8, released on 18th June 2009, key
  deliverables in this dev release are:
   o Revamped 3ds plugin that supports and reading and writing,
  and now uses a latest lib3ds source code.
   o New osgDB serializers and associated .osgt (text), .osgb
  (binary) and .osgx (xml) file formats that are extensible, and
  deprecate the old .osg and .ive formats.
   o Revamp of osgGA CameraManipulators
   o New osgQT library for integrating QT and OpenSceneGraph
   o Range of improvements to the FBX plugin
   o Rewrite of osg::observer_ptr and osg::Observer, with
  introduce of new ObserverNodePath class, for addressing threading
  issues with old implementation.
   o A range of improvements to DatabasePager to improve
  performance, reduced memory usage, and address crashes/deadlocks.
   o Fixes to memory usage in TerraPage (.txp) plugin.
   o Improvements to the Graphviz .dot plugin and added support
  for dot diagrams to !Present3D application.
   o Improvements to COLLADA .dae plugin, including adding
  support for animation using osgAnimation.
   o Support for static linking of OpenGL ES 2.0.
   o Improvements to Inventor and VRML plugins.
   o Support for automatic boundary equalization in osgTerrain
  databases (requires databases to built with updated
  VirtualPlanetBuilder to take advantage of it.)
   o New OSG_INFO/OSG_NOTICE/OSG_WARN/OSG_DEBUG macro's that
  add a condition infront of the underlying osg::notify(..) call they
  provide to avoid executing stream code when messages were being
  discarded, and also done in a way that compilers can optimize the
  notification code out completely when notification is completely
  disabled via the new cmake GOSG_NOTIFY_DISABLE variable. Under Windows
  this new feature avoids a hitting a contended global mutex that
  Microsoft uses in it ostream implementation and results in a
  noticeable improvement in speed. All platforms will benefit from lower
  overheads as well, but not quite as dramatic as under windows.
   o Many general bug fixes and minor feature
  improvements/optimizations.
 
 source package : OpenSceneGraph-2.9.8.zip
 svn tag: svn co
 
 http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.9.8
  OpenSceneGraph
 
  Cheers,
  Robert.
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
 
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

 Michael Gronager, PhD
 NDGF Director
 Nordic Data Grid Facility
 NORDUnet A/S
 Kastruplundgade 22, 1
 2770 Kastrup
 Phone: +45 32 46 25 00
 Fax: +45 45 76 23 66
 Mobile: +45 31 62 14 01
 E-mail: grona...@ndgf.org


 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] clipnode

[René Molenaar]

Hi Sunil,

There is one thing missing.
The clipped subgraph needs to have the clipping mode enabled in its
StateSet,
try (for example) to add this line of code before viewer.run():

dumptruck-setStateSet(clipnode-getStateSet());

now all the clipplanes are on, and your example works.

Your welcome,

René



2010/5/7 Sunil S Nandihalli sunil.nandiha...@gmail.com

 Hello everybody,
  in the 06_clipnode example...

   //Group:model
 // . .
 //..
 //   .  .
 //Subgraph:dumptruck   Transform:pat
 //.
 //.
 // ClipNode

 How is the clipnode supposed to influence the dumptruck.. Am I missing
 something here. this is the thirdblock of the code in the example ... Here
 is how I interpretted and coded it

   osg::ClipNode* n = new osg::ClipNode;
   n-createClipBox(osg::BoundingBox(-2.5,-2.5,-2.5,2.5,2.5,2.5));

   osg::PositionAttitudeTransform* pat = new
 osg::PositionAttitudeTransform;
   pat-setPosition(osg::Vec3(0,0,0));
   osg::Group* model = new osg::Group;
   model-addChild(dumptruck);
   model-addChild(pat);
   pat-addChild(n);
   viewer.setSceneData(model);

   The complete code (example program) is pasted in

 http://pastebin.com/Hs6Q1Wb3

 I got the first block to work .. I was trying to get the 3rd block to work
 .. but was not very successfull. How is it supposed to clip the dumptruck?
 as indicated above.. dumptruck is not a child of the ClipNode.. can anybody
 explain?

 Thanks in advance..
 Sunil


 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] ANN: PAK Scene Editor for OSG

[René Molenaar]

Nice work,

i will take a look!

cheers,

René

2010/4/27 Peter Kilpatrick p...@icon.co.za

 Hello,
 I'd like to announce the first release of  PAK Scene Editor for OSG.

 Features:
 - Add models to a scene.
 - Drag nodes.
 - Edit light and material properties.

 Release details:
 - OSG 2.8.0
 - Qt 4.5.0
 - Visual C++ 8.0
 - Tested on Windows XP

 License: proprietary no charge

 Download from www.icon.co.za/~pak

 Cheers,
 Peter


 --
 This message has been scanned for viruses and
 dangerous content by Pinpoint, and is
 believed to be clean.

 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] 2.8.3 release likely, need community assistance

[René Molenaar]

I was referring to the osgManipulators nodekit. The website is still
stuttering..

I just checked the revision log, and there were a view since the first 2.8.2
tag:

r10429, r10431, r10434, r10436, r10443, r10523 and r10794 (most are small
revisions)

The changes do make the usage of manipulators more accessable to 'quick'
usage,
and more in line with the rest of the nodekits (thanks robert).
and also fix a possible crash on certain platforms (r10794).

I do admit it is a little late in the process ;-)

make 2.8.3 equal to the trunk?

haha, yeah, my guess is that the trunk has much more larger updates, then
the refactoring
of this nodekit, but i see what you mean.

about the collada dom,
the dilemma is this: the usage of the plugin will increase if it is build
out of the box.
leaving it out because there is only a small portion using it, doesn't..

Maybe there should be a seperate link/zip file with binaries/precompiled
libraries on the dependencies page.
or the knowledgebase. It also seems that the collada-dom will introduce
dependecies of its own (wereas png and freetype don't).

Have a good day!

René


2010/3/21 Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com

 Hi René,


 Maybe the DOM 2.2 binaries could go into the 3rdparty folder or repository?
  that way the plugin becomes 'out of the box' like png and freetype
 or do we want a limited set of 3rdparty binaries?


 I think we'd have to survey to see how many people use it, because it's a
 pretty big dependency (over 12MB for the dynamic version, and over 70MB for
 the static version! and that's just for VC9sp1). If only a small portion of
 users use it... The png and freetype libs are pretty much required to do
 anything useful with OSG...


 About the 2.8.3 release:
 I recently updated sources to use the new manipulators in 2.9.7 .
 Is there a stable release to be expected that include these (nice!)
 improvements?

 I wouldn't mind these changes in 2.8.3 but other users of the old
 manipulator code will have to change some code.


 It's pretty easy to add #if OSG_VERSION_GREATER_THAN in your code so that
 it works for both versions of OSG. That's what I did when I tested if our
 framework worked with OSG 2.9.7 (in particular for the changes in
 osgManipulator).

 At some point Paul will have to draw a line, or else why not merge all the
 changes and make 2.8.3 equal to the trunk? Anyways, there should be a 2.10
 release eventually, right? :-)


 J-S
 --
 __
 Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] 2.8.3 release likely, need community assistance

[René Molenaar]

Maybe the DOM 2.2 binaries could go into the 3rdparty folder or repository?
 that way the plugin becomes 'out of the box' like png and freetype
or do we want a limited set of 3rdparty binaries?

About the 2.8.3 release:
I recently updated sources to use the new manipulators in 2.9.7 .
Is there a stable release to be expected that include these (nice!)
improvements?

I wouldn't mind these changes in 2.8.3 but other users of the old
manipulator code
will have to change some code.

Groetjes,

René



2010/3/20 Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com

 Hi Chris,


Yes, but building the DAE plugin at all is complicated. Have you done it
 before?


 That was my impression until last Friday, too. I was proven wrong by doing
 it. It was literally a 3 step process.

 1. Get the DOM 2.2 zip file from sourceforge
 2. Open the solution file in there and build all configurations
 3. Point CMake at the DOM directory and optionally check the USE_STATIC_DOM
 flag, generate and then compile the plugin

 (sure that last step is more than one atomic operation, but running CMake
 to configure and generate build files and then using those to build OSG is
 pretty routine :-) )

 Were you talking about other platforms? I don't see why it should be harder
 on Linux, given for almost any other dependency it's actually simpler on
 Linux thanks to package managers on almost any distribution.


 J-S
 --
 __
 Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] using osg 2.9.7 and manipulators

[René Molenaar]

Hi Robert and other osg-users,

I have been using (and testing) osg 2.9.7 in our applications. This version
was used also for the re-factored manipulators.
Here is some feedback.

I had to change some code here and there, for the manipulators and for quad
elements with primitive indices.

We are using windows 32 and 64 bit (Visual Studio 2005) and linux 32 and 64
bit (gcc Ubuntu 4.4.1-4ubuntu9).

manipulator feedback:
The re-factored manipulators do make the implementation simpler. I made some
subclasses for customization ( and a more model/view like approach ).
There are only a few small remarks regarding the manipulators. The line
segment intersectors don't intersect with the cylinders when
viewed from the side. I used a polytope intersector instead and had to
reimplement the entire handle function in the subclass. There are also a lot
of notifications:

osgManipulator::computeNodePathToRoot(,) taking first parent path, ignoring
others.

is this because the scene is visualized in multiple viewers?

anyway, thanks for the rework on the manipulators and on osg 2.9.7,

have a good day,

René
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] linking error when i use osgdb_dae

[René Molenaar]

Just for the record:

If this occurs, you did not link the collada plugin to the correct boost
libs.

1. go to your osg build dir
2. run ccmake or cmake-gui
3. check: COLLADA_BOOST_FILESYSTEM_LIBRARY and COLLADA_BOOST_SYSTEM_LIBRARY
4. make sure they point to the correct boost libs (not the mingw libs
provided by the collada libs) (if you don't have these libs, install them)
5. recompile

p.s. this error only surfaces at run-time, not at the configure or build
time..

Now i have a question.
I was playing with the plugin and was wondering:
If I use osgconv to write a .dae file, what happens to the (embedded)
textures. Can they be embedded in the dae file or written out separately by
the writer?

René


2009/9/18 Martin Großer grosser.mar...@gmx.de

 Hello,

 a new day and a new problem. I would like try to load a dae-File. I install
 the collada-dom like the description on the osg website.
 After this I build osg new. But when I start the osgviewer with the collada
 file I get the following message:

 Warning: dynamic library
 '/home/grosser/OpenSceneGraph-2.8.2/install/lib64/osgPlugins-2.8.2/osgdb_dae.so'
 exists, but an error occurred while trying to open it:
 /usr/local/lib/libcollada14dom.so: undefined symbol:
 _ZN5boost6system19get_system_categoryEv
 Warning: Could not find plugin to read objects from file cube.dae.
 osgviewer: No data loaded

 The boost libs are in /usr/lib64 and the collada libs are in
 /usr/local/lib.

 My LD_LIBRARY_PATH is:


 LD_LIBRARY_PATH=/usr/lib64:/usr/local/lib:/home/grosser/OpenSceneGraph-2.8.2/install/lib64

 What is my mistake?

 Cheers,

 Martin
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] quads deprecated, resulting in triangles in wireframe mode

[René Molenaar]

Hello osg-users,

I noticed that the latest developers release (2.9.6) translates quads to
triangles.
Very large models need to be chopped into smaller pieces for this
translation to work,
but in most cases it goes unnoticed.. until, you switch to wireframe.
Now we see the triangles. For example:

boxGeode-addDrawable(new osg::ShapeDrawable(new osg::Box(center, lx, ly,
lz)));

now renders triangles instead of quads ..

Is there an easy way to render the wireframe mode 'as-if' quads are used?

cheers,

René
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] quads deprecated, resulting in triangles in wireframe mode

[René Molenaar]

Thanks Paul,

It seems to me that I would need a similar convenience routine that creates
GL_LINE_... primitives for arbitrary geometry.
The thing is a lot of fe-models still use quads, end-users expect to see
quads for their fe-models.

René


2010/2/1 Paul Martz pma...@skew-matrix.com

 René Molenaar wrote:

 I noticed that the latest developers release (2.9.6) translates quads to
 triangles.
 Very large models need to be chopped into smaller pieces for this
 translation to work,
 but in most cases it goes unnoticed.. until, you switch to wireframe.
 Now we see the triangles. For example:

 boxGeode-addDrawable(new osg::ShapeDrawable(new osg::Box(center, lx, ly,
 lz)));

 now renders triangles instead of quads ..

 Is there an easy way to render the wireframe mode 'as-if' quads are used?


 You could make a wireframe box using GL_LINE_LOOP and GL_LINE_STRIP
 primitives. osgWorks (osgworks.googlecode.com) has a convenience routine
 for this; see osgwTools/Shapes.cpp/.h.
   -Paul




 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] quads deprecated, resulting in triangles in wireframe mode

[René Molenaar]

Thank you,

I will experiment with the latter option (as the first one is currently
already working with osg 2.8.2).

I bet this question will be repeated in the future.. ;-)

cheers,

René

2010/2/1 Paul Martz pma...@skew-matrix.com

 René Molenaar wrote:

 Thanks Paul,

 It seems to me that I would need a similar convenience routine that
 creates GL_LINE_... primitives for arbitrary geometry.
 The thing is a lot of fe-models still use quads, end-users expect to see
 quads for their fe-models.


 In general, then, I'd advise you to stick to GL1/2 and use GL_QUADS
 PrimitiveSets in Geometry-type Drawables, and GL_LINE polygon mode.

 Or, knowing that all modern graphics hardware draws a quad as two
 triangles, the other way to handle this would be to keep two representations
 of your model, one for fill, and one for line. They could easily share the
 same vertex data, so this should not consume a substantial amount of
 resources.

 So you have many options available to you.

   -Paul

 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Python port of osgviewerQT

[René Molenaar]

There is an example script osgviewerQt4.py in the osgswig project.
(using a combination of osgswig and PyQt4)

see http://code.google.com/p/osgswig/

Succes,

Rene




2009/11/5 christophe chappet christophe.chap...@gmail.com


 chappet wrote:
  Hi,
 
  Is there someboby that has ported the osgviewerQT into Python ?
 
 http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/examples/osgviewerQT/osgviewerQT.cpp
 
  I have a problem with the multiple inheritance.
 
  Thank you!
 
  Cheers,
  christophe


 I have attached my python port of the osgviewerQT file but the ViewerQT
 class declaration is not correct and generates the following error :

 Traceback (most recent call last):
  File F:\dev\workspace\PYGMT\src\PyGMT\GMT3D\AdapterWidget.py, line 91,
 in module
viewerWindow = ViewerQT()
  File F:\dev\workspace\PYGMT\src\PyGMT\GMT3D\AdapterWidget.py, line 71,
 in __init__

  self.getCamera().setViewport(osg.Viewport(0,0,self.width(),self.height()))
  File c:\Python25\lib\site-packages\osg-2.2.0-msw\osg.py, line 3564, in
 getCamera
def getCamera(*args): return _osg.View_getCamera(*args)
 NotImplementedError: Wrong number of arguments for overloaded function
 'View_getCamera'.
  Possible C/C++ prototypes are:
getCamera()
getCamera()

 I hope it helps.

 Cheers,
 christophe

 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=19227#19227




 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Problems building examples (UNCLASSIFIED)

[René Molenaar]

Which version of cmake are you using? I believe recent versions have updated
FindQt modules.
You might want to build qt again with the font libs installed, the configure
step can have different
results.

Rene



2009/7/15 Robert Osfield robert.osfi...@gmail.com

 Hi Lee,

 On Tue, Jul 14, 2009 at 8:22 PM, Butler, Lee Mr CIV USA
 USAMClee.but...@us.army.mil wrote:
/home/butler/src/Qt/qtsdk-2009.03/qt/lib/libQtGui.so: undefined
  reference to FcFreeTypeQueryFace This indicates that it is not linking
 with
  the fontconfig library I specified.
  Any hints at getting this to link right would be most welcome.

 I'm afraid I'm no Qt expert so will have to defer to others on this issue.

  FLTK:
  Linking osgviewerFLTK doesn't pick up the -lXft -lXinerama flags needed
 to
  link.  The default FLTK 1.3 configuration includes Xft and Xinerama
 support
  at this point.  A CMakeList.txt entry for FLTK_XFT_LIBRARY and
  FLTK_XINERAMA_LIBRARY would allow proper linking.

 Could you post this change to osg-submissions so I can review it.


  Linux:
  Clearly RedHat 5 is *not* the linux of choice for OSG.  The real question
  is:  Which distro *is* the preferred one?

 There isn't a preferred choice, it should work across a wide range of
 distributions.  Good support for any particular distro is really down
 to the community to ensure that it works as it's not practical for
 engineers like myself to manage dozens of different OS variants. Even
 if you use the same OS variant there are still variables such as
 optional dependencies like Qt and FLTK that can be thrown into the mix
 that make your particular build system unique.  The upshot of this is
 that to see good support of your chosen build combination then you
 need to be prepared to step forward and help ensure that the wrinkles
 are all smoothed out.

 The alternative to need members of community be proactive would be to
 restrict the list of supported OS variants to ones that I can support,
 which right now would be... Kubuntu 9.04, while this is fine OS
 variant for dev work, it won't be a perfect fit for everyone.  I see
 this as the beauty of open source - you aren't restricted to arbitrary
 choices that I or other core developers make - you have the ability to
 tune the software to work well on your own platform of choice ;-)

 Robert.
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgManipulator.AntiSquish

[René Molenaar]

I reconfirm this same issue in 2.8.1

The solution is simple (AntiSquish.cpp line 149) :

// Position
if (_usePosition)
unsquished.postMult(_position);
else
unsquished.postMult(_pivot);

should be

// Position
if (_usePosition)
unsquished.postMultTranslate(_position);
else
unsquished.postMultTranslate(_pivot);

if needed i can attach a complete file.

have a good one,

Rene

2009/2/23 Robert Osfield robert.osfi...@gmail.com

 Hi Jonathan,

 This is correct place to report bugs.  I've just ran osgmanipulaor and
 see the that tabs rendering is indeed wrong.  I have briefly looked at
 the svn logs and haven't spotted the cause of this regression yet.
 It's end of day here so I'll look into this tomorrow.

 Robert.

 On Mon, Feb 23, 2009 at 5:21 PM, Lewis, Jonathan
 jle...@integrity-apps.com wrote:
  Hi,
 
  The behavior of osgManipulator::AntiSquish seems to have changed between
  releases 2.6.1 and 2.8.0.  I'm not sure what is happening differently in
 the
  matrix math, but you can see the result on the TabBoxDragger by firing up
  the standard osgManipulator example.  The dragger's corner tabs are no
  longer in the corners.
 
  As a test I replaced the v2.8 AntiSquish node with the v2.6.1 AntiSquish
 in
  the TabPlaneDragger, and things looked right again.
 
  Btw, is this the right place to put a bug report like this?
 
  Thanks,
  -Jonathan Lewis
 
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
 
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgManipulator.AntiSquish

[René Molenaar]

Sure,

here is the complete modified file osgManipulator/AntiSquish.cpp
from OpenSceneGraph-2.8.1

The bug is as described above:
The dragger's corner tabs are no longer in the corners.

this fix places the cornertabs back in the corners.
(the manipulator does not make sense otherwise).

Grtz,

René


2009/6/8 Robert Osfield robert.osfi...@gmail.com

 HI Rene,

 Could you post the whole modified file, thanks,
 Robert.

 2009/6/8 René Molenaar megamillerz...@gmail.com:
  I reconfirm this same issue in 2.8.1
 
  The solution is simple (AntiSquish.cpp line 149) :
 
  // Position
  if (_usePosition)
  unsquished.postMult(_position);
  else
  unsquished.postMult(_pivot);
 
  should be
 
  // Position
  if (_usePosition)
  unsquished.postMultTranslate(_position);
  else
  unsquished.postMultTranslate(_pivot);
 
  if needed i can attach a complete file.
 
  have a good one,
 
  Rene
 
  2009/2/23 Robert Osfield robert.osfi...@gmail.com
 
  Hi Jonathan,
 
  This is correct place to report bugs.  I've just ran osgmanipulaor and
  see the that tabs rendering is indeed wrong.  I have briefly looked at
  the svn logs and haven't spotted the cause of this regression yet.
  It's end of day here so I'll look into this tomorrow.
 
  Robert.
 
  On Mon, Feb 23, 2009 at 5:21 PM, Lewis, Jonathan
  jle...@integrity-apps.com wrote:
   Hi,
  
   The behavior of osgManipulator::AntiSquish seems to have changed
 between
   releases 2.6.1 and 2.8.0.  I'm not sure what is happening differently
 in
   the
   matrix math, but you can see the result on the TabBoxDragger by firing
   up
   the standard osgManipulator example.  The dragger's corner tabs are no
   longer in the corners.
  
   As a test I replaced the v2.8 AntiSquish node with the v2.6.1
 AntiSquish
   in
   the TabPlaneDragger, and things looked right again.
  
   Btw, is this the right place to put a bug report like this?
  
   Thanks,
   -Jonathan Lewis
  
   ___
   osg-users mailing list
   osg-users@lists.openscenegraph.org
  
  
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
  
  
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
 
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
 
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
 
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield
 *
 * This library is open source and may be redistributed and/or modified under
 * the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or
 * (at your option) any later version.  The full license is in LICENSE file
 * included with this distribution, and on the openscenegraph.org website.
 *
 * This library is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * OpenSceneGraph Public License for more details.
*/
//osgManipulator - Copyright (C) 2007 Fugro-Jason B.V.

#include osgManipulator/AntiSquish

using namespace osgManipulator;

namespace
{
class AntiSquishCallback: public osg::NodeCallback
{
public:
AntiSquishCallback(AntiSquish* asq) : osg::NodeCallback(), _antiSquish(asq) {}
virtual ~AntiSquishCallback() {};

virtual void operator() (osg::Node*, osg::NodeVisitor* nv)
{
// Get the node path.
osg::NodePath np = nv-getNodePath();

// Remove the last node which is the anti squish node itself.
np.pop_back(); 

// Get the accumulated modeling matrix.
osg::Matrix localToWorld = osg::computeLocalToWorld(np);

// compute the unsquished matrix.
bool flag = false;
osg::Matrix _unsquishedMatrix = _antiSquish-computeUnSquishedMatrix(localToWorld, flag);
if (flag)
_antiSquish-setMatrix(_unsquishedMatrix);
}

protected:
AntiSquish* _antiSquish;
};

}

AntiSquish::AntiSquish() : _usePivot(true), _usePosition(false)
{
_asqCallback = new AntiSquishCallback(this);
setUpdateCallback(_asqCallback);
}

AntiSquish::AntiSquish(const osg::Vec3d pivot) : _pivot(pivot), _usePivot(true), _usePosition(false)
{
_asqCallback = new AntiSquishCallback(this);
setUpdateCallback(_asqCallback);
}

AntiSquish::AntiSquish(const osg::Vec3d pivot, const osg::Vec3d pos)
: _pivot

Re: [osg-users] Picking and ignoring clipped parts of models?

[René Molenaar]

i'am doing something simular, and use the hit.getWorldIntersectPoint(),
I have a function: bool isPointInSceneClipped, which looks like this for me:

//transform the point to rotated box coordinates
osg::NodePath nodePath;
nodePath.push_back(m_Impl-m_SceneClipBox.m_ClipBoxTransform.get());
osg::Matrix l_mat = osg::computeWorldToLocal(nodePath);

osg::Vec3 vpoint(hitpoint[0], hitpoint[1], hitpoint[2]);
vpoint = vpoint*l_mat;

//points outside the box are clipped, points in the box are not clipped
return !(vpoint.x()  m_Impl-m_SceneClipBox.m_SceneClipInfo.m_vMin[0]

 vpoint.x()  m_Impl-m_SceneClipBox.m_SceneClipInfo.m_vMax[0]

 vpoint.y()  m_Impl-m_SceneClipBox.m_SceneClipInfo.m_vMin[1]

 vpoint.y()  m_Impl-m_SceneClipBox.m_SceneClipInfo.m_vMax[1]

 vpoint.z()  m_Impl-m_SceneClipBox.m_SceneClipInfo.m_vMin[2]

 vpoint.z()  m_Impl-m_SceneClipBox.m_SceneClipInfo.m_vMax[2]
);


the m_SceneClipBox class contains the transformation and the dimensions of
my clipbox.
the worldpoint is translated to a local coordinate, and this is tested
against the (local) clipbox dimensions.

to answer your question:
  how do i get a clipNodes clipBox? so i can check if the
WorldIntersectPoint is within it?
  -
  store your clipbox dimensions when you specify them, translate
your WorldIntersectPoint to it's (rotated/scaled) coordsystem
  so you can check that point.

Hope this is of some help,

Rene

2009/5/21 Paul Griffiths gaffe...@gmail.com

 i found out i can simple use:

 if (clipBox.contains(hitr-getWorldIntersectPoint()))


 how do i get a clipNodes clipBox? so i can check if the WorldIntersectPoint
 is within it?

 Any ideas?

 --
 Read this topic online here:
 http://forum.openscenegraph.org/viewtopic.php?p=12708#12708





 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Development of Qt support as part of osgViewer

[René Molenaar]

Hi Robert,

I have tried a few different 're-invent' paths with different ups and downs.
We use qt 3.3.8 and osg 2.8.0, here is some of my experience.

QGLWidget provides functions like:
  grabFrameBuffer
  renderText

a previous implementation of our software (with Producer) used these
functions. So I
subclassed from QGLWidget to keep this functionality.

When creating a new traits with inheritedWindowData, on windows the event
will not
be form QT, but from windows itself. On Linux you will need to adapt the
event
(using an AdapterWidget). Unfortionately some graphics drivers had problems
creating a valid context (Intel..). So I replaced the code using
GraphicsWindowEmbedded and
always using an AdapterWidget.

Special attention was needed for scroll event and for modifier adaptation.
For example scrolling
in a treeview caused the viewer to zoom and a treeview to scroll
simultaneously (only on widows,
on linux the focus is stolen).

It was nice to see your 'on demand' update scheme. For a viewer in a GUI it
is not always very nice to be continously drawing.
We also got some users with a single processor (which would be drawing with
100% cpu usage). So I made use of your new code.

There are more little details/point of attention that are needed for the
QT/OSG integration (how to setup multiple views/ shared context etc?).

We currently use QT 3.3.8 and not 4.5, so our integration is 'out-dated'.
But we do have the plan to start using 4.5 soon.
I agree with your analysis of the situation and that it would be good to
adress this issue.
Our implementation currently suffices, but since i have some experience I am
interested in this development.

Have you seen David Guthries implementation (posted a few days ago), it uses
windowsystemwrapper to integrate osg/qt?

Have a good one,

Rene Molenaar


2009/5/11 Robert Osfield robert.osfi...@gmail.com

 Hi All,

 There has been lots of support questions relating to Qt integration
 with the OSG over the past year, and especially in the last few
 months.  This a good in terms of see a cross platform GUI toolkit
 becoming more widely spread, bad in terms of the difficulties that
 users still have.  Part of the difficulties is down to Qt being a
 little bit awkward to integrate with making it not entirely straight
 forward, and while we have an example, it's just a guide so lots of
 users are having to go re-invent the wheel each time.  So it'd be good
 to try and address this issue by providing a better Qt/OSG widget for
 users to adopt directly.

 One of the design facets of osgViewer library is that it's designed to
 work with multiple windowing toolkits, with four models of integration
 possible:

 1) GraphicsWindowEmbedded - provides very basic single threaded,
 single context window integration suitable for use with simple apps
 that use SDL/GLUT.

  2) GraphicsWindow core osgViewer implementations (i.e.
 GraphisWindowWin32/X11/Carbon/Cocoa) - full OpenGL + multi-context,
 threadeding and pbuffer capabilities exposed.  You'll find these
 implementation interfaces in include/osgViewer/api/Win32, X11, Carbon
 and Cocoa.

  3) GraphicsWindow subclass (i.e GraphicsWindowWx) - 3rd party
 implementation of a GraphicsWindow, potential for full capabilities if
 all parts of GraphicsWindow are correctly implemented.  For pbuffer
 support one will have to add PixelBuffer implementation as well.

 4)  GraphicsWindow window inheritance - windowing toolkit provides the
 window, while GraphicsWindowWin32/X11/Carbon/Cocoa provide the actual
 OpenGL context implementation.


 Now Item 1) is really just for very simple apps, and is often adopted
 by end users because it's really easy to use, but almost always starts
 limiting you as your project goes on.  I wouldn't recommend 1 for
 anything by GLUT/SDL style apps.

 Items 2 is great for sim and games that don't need any GUI.  You can
 get the full capabilities of the OSG with very little effort on your
 part.   If you want a traditional 2D GUI though then it won't help
 you.

 Item 3 is possible, but rarely do 3rd party window toolkits do OpenGL
 really well, often they won't expose the full capabilities of OpenGL
 or support pbuffers.  It also often requires the most work in
 implementation.

 Item 4 is possible, but a little bit awkward, but potentially can give
 users the best of both worlds - full OpenGL/OSG capabilities and the
 2D GUI.

 --

 So where does that leave the Qt side?  We'll my preference would be to
 work together to get a GraphicsWindowQt and/or a window inheritance
 implemented in a full and flexible way that users could just reuse the
 implementation provided in a new include/osgViewer/api/Qt collection
 of headers.  I would suggest the implementation should be done
 entirely in the headers to avoid the need for linking the osgViewer
 library itself to Qt.

 Now I've tinkered with Qt, but I'm not Qt expert, to get a really good
 implementation we'll need members of the community to pitch in with
 helping 

Re: [osg-users] OpenSceneGraph always opening in fullscreen on Intel integrated graphics.

[René Molenaar]

We have had similar complaints with a qt3.3.8 integrated viewer.In our case
a composite viewer with four views with splitters in between.

I found one 'workaround' which is:
 go to the advanced display settings, advanced, troubleshoot and ...
disable hardware acceleration ... .. pff...

but the Intel graphics drivers sometimes don't provide this menu.
If I check the log (with set OSG_NOTIFY_LEVEL=DEBUG) i see:

GraphicsContext::registerGraphicsContext 07391228
close(1)07391228
close(0)07391228
GraphicsContext::unregisterGraphicsContext 07391228
Viewer::startThreading() - starting threading
Viewer::startThreading() - contexts.size()=0


while I should see:

GraphicsContext::registerGraphicsContext 0x95187f8
Relaxing traits
GraphicsContext::createNewContextID() creating contextID=0
Updating the MaxNumberOfGraphicsContexts to 1
Viewer::startThreading() - starting threading
Viewer::startThreading() - contexts.size()=1

Any suggestions are very welcome.

Rene

2009/4/27 Jesper D. Thomsen j...@anybodytech.com

  Hi, I'm not currently using multisampling in the window, as we have an
 option in the application where we can switch to an older OpenGL renderer
 for the viewport, and this older implementation doesn't like multisampling.
 I'm however not having any problems with OpenGL state, as I don't use any
 direct OpenGL in the cases where I'm having the fullscreen problem.
 I just dug up an old computer with integrated Intel 82865G graphics (which
 supports OpenGL 1.3), and that computer works fine with windowed
 OpenSceneGraph use (even with standard Windows XP graphics drivers).

 regards,


 Jesper D. Thomsen

 **

  --
 *From:* osg-users-boun...@lists.openscenegraph.org [
 osg-users-boun...@lists.openscenegraph.org] On Behalf Of Ümit Uzun [
 umituzu...@gmail.com]
 *Sent:* Monday, April 27, 2009 11:14 AM
 *To:* OpenSceneGraph Users
 *Subject:* Re: [osg-users] OpenSceneGraph always opening in fullscreen on
 Intel integrated graphics.

   Hi Jesper;

 As I can see from attached codes you didn't used traits-samples = (any int
 value); but you may be set multisampling in your code from using

 osg::DisplaySettings* ds = new osg::DisplaySettings();
 ds-setNumMultiSamples( 4 );

 or osgUtil namespaces function(I have forgotten the name of this
 function.).

 If you try to anti aliasing operation by using MultiSampling, this could be
 cause full screen problem which I had had kind of that before and solved by
 removing multisampling operation.

 HTH.Regards.

 2009/4/27 Jesper D. Thomsen j...@anybodytech.com

  Hi all (again), and thanks for your help in the past.

 We have now shipped an application using OpenSceneGraph for the 3D
 viewports of a model. We are now receiving a couple of bug-reports (2 so
 far) from users running the application on laptops with Intel integrated
 graphics (GMA 950 and 3100). We are using OpenSceneGraph in an MFC window in
 the application, but whenever these two users open the viewport window (and
 thus starting the OpenSceneGraph part of the application), the
 OpenSceneGraph viewer starts in fullscreen (no menus or windows bar
 visible), which of course means that they have to use the task manager to
 quit the application.

 Both users are using Windows XP pro. The OSG version used is 2.6.1,
 compiled with Visual Studio 2005 SP1 under Vista. The application is using
 MFC, and the OpenSceneGraph viewport is based on the MFCViewer example. The
 code for creating the viewer can be found below. Does anybody know why OSG
 suddenly will be forced to work in fullscreen, and is it generally because
 of some specific lack of OpenGL support?

 Any help will be much appreciated.

 --- Code: --

 void
 cOSG::InitCameraConfig(void)

 {

 // Local Variable to hold window size data

 RECT rect;

 // Create the viewer for this window

 mViewer =
 new osgViewer::Viewer();

 mViewer-setThreadingModel(osgViewer::Viewer::SingleThreaded);

 // Get the current window size

 ::GetWindowRect(m_hWnd, rect);

 // Init the GraphicsContext Traits

 osg::ref_ptrosg::GraphicsContext::Traits traits =
 new osg::GraphicsContext::Traits;

 // Init the Windata Variable that holds the handle for the Window to
 display OSG in.

 osg::ref_ptrosg::Referenced windata =
 new osgViewer::GraphicsWindowWin32::WindowData(m_hWnd);

 // Setup the traits parameters

 traits-x = 0;

 traits-y = 0;

 traits-width = rect.right - rect.left;

 traits-height = rect.bottom - rect.top;

 traits-windowDecoration =
 false;

 traits-doubleBuffer =
 true;

 traits-sharedContext = 0;

 traits-setInheritedWindowPixelFormat =
 true;

 traits-inheritedWindowData = windata;

 // Create the Graphics Context

 osg::GraphicsContext* gc =
 osg::GraphicsContext::createGraphicsContext(traits.get());

 // Init a new Camera (Master for this View)

 camera = mViewer-getCamera();

 // Assign Graphics Context to the Camera

 camera-setGraphicsContext(gc);

 // Set the viewport for the Camera

 camera-setViewport(
 

Re: [osg-users] Red, Green and Blue, now I've tried two!

[René Molenaar]

Thanks Robert,

Customers are the kings, right. So it is not uncommon that people expect
your software to run on a laptop with Intel onboard graphics.
Also nice to hear about the ATI fix.

I also experienced the problems of developing on particular hardware. For
example I got complaints about single processor machines using 99% cpu when
running the latest version of our application. The previous version did not
do any continousUpdate, but now it does, causing the processor to be used
continously...

Having the hardware available would help predicting these issues people
might experience.

Thanks for the input,

Rene



2009/4/9 Robert Osfield robert.osfi...@gmail.com

 Hi All,

 Wow no comment on my trying out ATI under linux...  hell freezing over
 moment seems to have gone unnoticed...

 Still lets have another bash at waking your up...

 With the addition of a ATI card here I now have coverage of ATI (Red),
 NVidia (Green) but as yet no Intel (Blue) parts.  The later will require
 buying a motherboard that has Intel onboard graphics, or patience as I'd
 have to wait for Larabee to come out...


 Yesterday a new motherboard arrived in the post that I purchased with the
 intent of testing out Intel integrated graphics.  The board is an ASUS
 P5Q-EM with G45 chipset and Intel GMA X4500HD.  This board replaces my heavy
 duty triple 16xPCI Express motherboard that hosted my first Quad core
 processor, while the new card only has a single 16xPCI Express slot, it is
 for the most part capable of handling all the memory, devices and the quad
 core that I need for my second dev station.

 My initial attempt at using the Kubuntu 9.04 beta Live CD and the onboard
 graphics was a failure as intel graphics drivers that it came with screwed
 up all desktop rendering leaving me with just a black or a pinstripped
 desktop.  Throwing in a NVidia graphics card and then re-running the the
 Live CD worked fine so using this I was able to install Kubuntu 9.04 beta
 and once the OS was installed an update pulled in improved Intel drivers, or
 at least that what I was hoping...

 So hoping for the best I pulled out the NVidia grpahics card and configured
 the bios to use the onboard graphics, then rebooted and waited with bated
 breath... would it work... would it fail

 Less than a miniute later Kunbuntu booted to the desktop no problems,
 enabling desktop effects even worked - these use OpenGL compositing.  So far
 so good, the open source Intel drivers were providing a better out of the
 box experience than the ATI propritary drivers w.r.t KDE and desktop effects
 as the my ATI machine still is really flaky w.r.t initializing desktop
 effects.  Performance with the composited desktop is also very good, can't
 really tell the difference between NVidia, ATI and Intel when just using the
 desktop - they all just work smoothly.

 Next up it was time to get the OSG compiling, once the mesa glx and glu
 headers/libs were installed everything built without a hitch.  Running
 through the examples almost everyting works, even the shaders.  Fill
 rate/shader performance is actually far better than I expected, and the
 onboard graphics can handle the glsl_mandelbrot.osg dataset very well.

 Things aren't prefect though.   No Texture3D support, so volume rendering
 support fails.  There is also no PBuffer support.  No texture compression
 support either so standard VPB generated models just result in white
 models.  The vertex throughput is also very poor, even small models like
 cow.osg just return max frame rates of 200fps while I normally get many
 thousand of fps on ATI and NVidia.  Big town models also really slow when
 lots of objects/geometry are in the scene.  I kinda suspect that the drivers
 aren't well optimized for the vertex load.

 However, we are just talking about onboard graphics from Intel here... I
 wasn't expecting a high performance graphics monster, what it is a pretty
 capable machine for light graphics loads, and is really efficient on power.
 My big tripple SLI motherboard + Quad core + high end graphics card would
 suck over 200W even at iddle, now it just sips away with 88W on iddle.
 Considering the machine is still pretty powerful machine with first gen
 (65nm) Quad core processer this is pretty impressive, it's finally lower
 enough for me not to worry about my kids surfing the web on a high end
 machine and burning a hole in the household budget or monster carbon
 footprint.

 The other side to note is that finally I have machines with all three major
 graphics vendors represented so I can do testing of the OSG across a better
 spread of desktop hardware,  For the last decade I have pretty well
 exlusively been developing using NVidia graphics, simple because they've
 always has the best OpenGL drivers.  My testing this week has shown that
 NVidia still do have the best OpenGL drivers, but that both ATI and Intel
 are now doing a pretty decent job - neither are perfect but they are now
 finally 

Re: [osg-users] Light Manager

[René Molenaar]

Hi Sajjad,


There are asType functions is osg::Node,
this has better performance then dynamic_cast ...

for example you can do:

osg::ref_ptrosg::Switch switch = group-asSwitch();

Now you are using a virtual table to get the right type:

if the object is a Switch you will get the this-pointer of the Switch
if it is not you will get 0.

Usually there are always better ways then dynamic_cast, especially
if you are the owner of the code.

Good Luck,

Rene



2009/4/9 ami guru dosto.wa...@gmail.com

 Hello Forum,


 I have a LightManager class that tracks the number of lights(OpenGL Lights)
 that have been created.

 Inside the class the have the following member


   osg::ref_ptrosg::Group  groupOfLights;
   vectorosg::ref_ptrosg::LightSourcelights;

 the member groupOfLights contain the LightSource as child.


 In the application i want to select different light (spot,point or diffuse)
 with key press event and only one light is enabled during an instant OR i
 may enable several lights.


 In that case i believe that i have to do dynamic casting to cast Group to
 Switch.

 In other better way to do that ?



 Regards
 Sajjad

 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osg+QT MODKEY How to

[René Molenaar]

Hi,

i use the following code to get the modifiers in.
call this in your mousePressEvent.
(and don't forget to convert the keyrelease, like other non-text
key-releases)


/**
 * Check the current event for modifiers
 *
 * @brief  Mouse Press Event
 * @param event Mouse event to be placed in the event queue
 */
#if USE_QT4
void AdapterWidget::adaptModifiers( QInputEvent* event )
{
int modkey = event-modifiers()  (Qt::ShiftModifier |
Qt::ControlModifier | Qt::AltModifier);
unsigned int modkeyosg = 0;
if (modkey  Qt::ShiftModifier)modkeyosg |=
osgGA::GUIEventAdapter::MODKEY_SHIFT;
if (modkey  Qt::ControlModifier)  modkeyosg |=
osgGA::GUIEventAdapter::MODKEY_CTRL;
if (modkey  Qt::AltModifier)  modkeyosg |=
osgGA::GUIEventAdapter::MODKEY_ALT;
m_gw-getEventQueue()-getCurrentEventState()-setModKeyMask( modkeyosg
);
}
#else
void AdapterWidget::adaptModifiers( QMouseEvent* event )
{
int modkey = event-stateAfter()  (Qt::ShiftButton | Qt::ControlButton
| Qt::AltButton);
unsigned int modkeyosg = 0;
if (modkey  Qt::ShiftButton)modkeyosg |=
osgGA::GUIEventAdapter::MODKEY_SHIFT;
if (modkey  Qt::ControlButton)  modkeyosg |=
osgGA::GUIEventAdapter::MODKEY_CTRL;
if (modkey  Qt::AltButton)  modkeyosg |=
osgGA::GUIEventAdapter::MODKEY_ALT;
m_gw-getEventQueue()-getCurrentEventState()-setModKeyMask( modkeyosg
);
}
#endif

Rene

2009/3/9 Fabien Lavignotte fabien.lavigno...@vegatechnologies.fr

 The osgViewerQt example does not take into account modifier key. So, the
 OSG modifier mask is always zero.
 I have changed the conversion between Qt event and OSG event to handle
 modifier properly.
 Here is my code. You can adapt this code in your widget. Let me know if
 you need some help.
 Fabien

 /*! Helper function which converts a Qt mouse button code into a osg
 mouse button code */
 inline void convertMouseEvent( osgGA::EventQueue* eventQueue,
 QMouseEvent* eventQt, osgGA::GUIEventAdapter::EventType eventType )
 {
 eventQueue-getCurrentEventState()-setX( eventQt-x() );
 eventQueue-getCurrentEventState()-setY( eventQt-y() );
 int button = 0;
 switch( eventQt-button() )
 {
 case Qt::LeftButton :
 button = osgGA::GUIEventAdapter::LEFT_MOUSE_BUTTON;
 break;
 case Qt::MidButton :
 button = osgGA::GUIEventAdapter::MIDDLE_MOUSE_BUTTON;
 break;
 case Qt::RightButton :
 button = osgGA::GUIEventAdapter::RIGHT_MOUSE_BUTTON;
 break;
 }
 if ( eventQt-type() == QEvent::MouseButtonPress )
 eventQueue-getCurrentEventState()-setButtonMask( button |
 eventQueue-getCurrentEventState()-getButtonMask());
 else
 eventQueue-getCurrentEventState()-setButtonMask( ~button 
 eventQueue-getCurrentEventState()-getButtonMask());
 unsigned int modKeyMask = 0;
 if( eventQt-modifiers()  Qt::ShiftModifier)
 {
 modKeyMask |= osgGA::GUIEventAdapter::MODKEY_SHIFT;
 }
 if( eventQt-modifiers()  Qt::ControlModifier)
 {
 modKeyMask |= osgGA::GUIEventAdapter::MODKEY_CTRL;
 }
 if( eventQt-modifiers()  Qt::AltModifier)
 {
 modKeyMask |= osgGA::GUIEventAdapter::MODKEY_ALT;
 }
 osgGA::GUIEventAdapter* event = eventQueue-createEvent();
 event-setEventType(eventType);
 event-setTime(eventQueue-getTime());
 event-setModKeyMask(modKeyMask);
 event-setButton(button);
 eventQueue-addEvent(event);
 }

 /*! overwrites the mouse pressed handler */

 void Viewer::mousePressEvent( QMouseEvent* event )
 {
GLWidget::mousePressEvent(event);
if ( _graphicsWindow.valid() )
{
convertMouseEvent( _graphicsWindow-getEventQueue(),
 event, osgGA::GUIEventAdapter::PUSH );
}
 }

 /*! overwrites the mouse released handler */
 void Viewer::mouseReleaseEvent( QMouseEvent* event )
 {
GLWidget::mousePressEvent(event);
if ( _graphicsWindow.valid() )
{
convertMouseEvent( _graphicsWindow-getEventQueue(),
 event, osgGA::GUIEventAdapter::RELEASE );
}
 }


 

 From: osg-users-boun...@lists.openscenegraph.org
 [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Dieter
 Pfeffer
 Sent: lundi 9 mars 2009 09:34
 To: OpenSceneGraph Users
 Subject: Re: [osg-users] osg+QT MODKEY How to


 Hi Legeo

 I had a similar problem - using osg, qt4 and the AdapterWidget example.

 In AdapterWidget::keypressEvent (...)
 osgGA::GUIEventAdapter::KeySymbol) * (event-text().toAscii().data()
 returns 0 in the call
 _gw-getEventQueue()-keyPress( (... ) )  for keys like:

 Qt::Key_up ... Have a look at the Qt documentation Qt::Key.

 I have managed it with:

 int c = *event-text().toAscii().data();

 if ( c == 0)

 {

 switch (event-key())

 {

 case Qt::Key_PageDown:

 _gw-getEventQueue()-keyPress(
 osgGA::GUIEventAdapter::KeySymbol::KEY_Page_Down );

 break;

 case Qt::Key_PageUp:

 _gw-getEventQueue()-keyPress(
 osgGA::GUIEventAdapter::KeySymbol::KEY_Page_Up );

 break;

 case Qt::Key_Up:

 _gw-getEventQueue()-keyPress( osgGA::GUIEventAdapter::KEY_Up);

 break;

 }

 }
 else
 _gw-getEventQueue()-keyPress( 

Re: [osg-users] Displaying a scene in the background of a QGraphicsView

[René Molenaar]

If the cow shows and the cessna does not, it is probably an optimization
step, like small feature culling.

2008/11/5 Yvon Halbwachs [EMAIL PROTECTED]

 Hi everybody,

 I managed to use osg in a Qt QGraphicsView with the information that Eric
 Zeremba and Rene Molenaar posted some weeks ago. I still have some troubles
 though... Things work fine when I display the cow.osg scene from the
 OpenSceneGraph example files, but nothing is displayed when I use
 cessna.osg. The only way to display it is to enable display lists (it is
 set to false by default).

 Anybody has a clue about what's going on?

 Yvon



 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Event Adapter getXNormalized doesn't return normalized value

[René Molenaar]

Today I experienced the same problem (with scrolling in a composite viewer).
I got the normalized coordinates in terms of the previous view.
I solved it by first checking if the coordinate is between -1.0  and 1.0,
the second event was in terms of the correct camera.

Maybe the 'switch' to the second camera is not yet completed when you get
your
fisrt event.



2008/8/29 Mike Greene [EMAIL PROTECTED]

 I have a OSG 2.3.7 application with an OSG viewer and two slave cameras.
 The first camera is a normal drive type view. The other is rotated 90
 degrees so that it looks down on a terrain.
 I am using a pick event adapter with code gleaned from on of the OSG
 examples. The pick works fine on the first camera. When I switch to the
 other camera (which I have set up via a keyboard command to encompass the
 same viewport as the first), the event adapter function ea.getXnormalized
 does not return a normalized value - it returns something on the order of
 -13.0  from my second camera. Is this correct?


 Mike Greene
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Qt4, OSG and HUD

[René Molenaar]

I compiled and run the examples, it might become useful. Thanks!
I did notice a similar problem with the other two versions (AdapterWidget
and QOSGWidget),
after you resize your height to zero pixels, the scene is missing...
I worked around this by having the resize function set always a minimum of
one pixel,
it seems like a bug in osg.

Rene

2008/8/19 René Molenaar [EMAIL PROTECTED]

 Nice,

 i will check it out, i just read the article too.
 thanks!

 Rene

 2008/8/18 Johan Nouvel [EMAIL PROTECTED]

 Hi Eric,

 Thanks for the example.

 We are using OSG in QT application with some GUI over the OSG 3D rendering
 widget. QT version is 4.3.X but we want to move to QT 4.4.X.

 With your code, I will spare time. Thanks.

 Johan.

 Eric ZAREMBA a écrit :

 Hi all,


 Since Qt 4.4, we are able to mix OpenGL and Qt in a way which provides
 more possibility than the osgViewerQT do by using QGraphics framework,
 especially for HUD display.

 I joint the example I write to do this.

  ...


 I hope this could be usefull for someone.

 Eric Z.



 

 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org



 --
 Johan Nouvel, RD Project Manager
 http://www.archivideo.com
 tel : +33 (0)2 99 86 30 20
 ARCHIVIDEO, 40 rue des Veyettes, 35000 RENNES, FRANCE
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org



___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgviewerQT shows garbage when viewer is destroyed and re-created

[René Molenaar]

Qt 4.4 includes a QGraphicsView class, this class can be used to perform
OpenGL drawing,
instead of using the QGLWidget. This might open up some new possibilities
for
embedding osg in the QGraphicsView. I will take a look at the possibilities.

Rene



2008/8/17 René Molenaar [EMAIL PROTECTED]

 (i use qt 4.4.1 and osg 2.6, and adapted vierwerqt example sources)

 The QOSGWidget works for me on linux.

 On windows I got the pixelformat error but,
 I got the QOSGWidget to work, and the --CompositeViewer version, by adding
 the traits-setInheritedWindowPixelFormat = true; line.

 I don't see any problems running a second time or multiple times.
 I don't have any windows decorations by default, but these can also be set
 on.

 (it helps to set
 viewerWindow-setGeometry(50,50,640,480); instead of
 viewerWindow-setGeometry(0,0,640,480);)
 to prevent the decorations from being outside the screen.
 )

 I did have problems when making the window heigth 0, but this was solved by
 making the resize always a minumum of one pixel.

 But i do get some errors in the console:
 QWidget::repaint: Recursive repaint detected

 and after closing:
 Windows Error #6: [Screen #0]
 GraphicsWindowWin32::makeCurrentImplementation() - Unable to set current
 OpenGL rendering context. Reason: De ingang is ongeldig.
 Windows Error #1400: [Screen #0]
 GraphicsWindowWin32::unregisterWindowProcedure() - Unable to unregister
 window procedure. Reason: Ongeldige vensteringang.

 I am still not sure what solution to use, as the ViewerQT version does its
 job, never had window problems with the AdapterWidget, but the performance
 of the QOSGWidget seems better.

 I also use a qtimer that triggers the update, but I want to start a new
 (singleshot) timer only after the frame is drawn, to make sure every frame
 is drawn before the timer issues a new frame.  Large models seemed to have a
 problem with the original code. would there be a better solution for the
 update?

 Rene Molenaar


 2008/5/7 Mathieu Champlon [EMAIL PROTECTED]

 Hi Robert,

 I quickly hacked the --QOSGWidget mode in order to work around the
 invalid pixel format error (forcing traits-setInheritedWindowPixelFormat
 = true;) and the result is the same : trashed scene on the second run.
 I tried adding the piece of code you suggested but it does not change
 anything.

 By the way the crash you were experiencing running with --QOSGWidget is
 actually due to osg::ArgumentParser modifying argv, thus on the second run
 argc remains unchanged but all arguments have actually been eaten up from
 argv.
 I am now using this code to run the application twice :
 int main( int argc, char **argv )
 {
   char** tmp = (char**)malloc( argc * sizeof( char*) );
   memcpy( tmp, argv, argc * sizeof( char* ) );
   run( argc, argv );
   run( argc, tmp );
 }

 MAT.


 Robert Osfield wrote:

 Hi Mathieu,

 The error with -QOSGWidget looks to be a bug in this code, but its a
 totally different path that the default path which uses
 GraphicsWindowEmbedded to adapt the Viewer.  QOSGWidget is the most
 flexible path for integration and long term I'd like this to be the
 default route under Qt.  My own time is rather stretched out so I
 can't address all these things at once.

 The issues you are seeing with the default path is very unlikely to be
 related to transparency, most likely is issues with display lists or
 texture objects being reused inappropriately.  In theory the viewer
 should be release OpenGL objects when the context is destroyed, but
 with GraphicsWindowEmbedded not all the standard functionality for
 managing OpenGL objects is available, so perhaps this step is not
 being executed appropriately.

 One thing you could try is a

viewer-getSceneData()-releaseGLObjects();
osg::GLObjects::discardAllDeletedGLObjects(0);

 In between the viewer allocations.

 Robert.




 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org



___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgviewerQT shows garbage when viewer is destroyed and re-created

[René Molenaar]

(i use qt 4.4.1 and osg 2.6, and adapted vierwerqt example sources)

The QOSGWidget works for me on linux.

On windows I got the pixelformat error but,
I got the QOSGWidget to work, and the --CompositeViewer version, by adding
the traits-setInheritedWindowPixelFormat = true; line.

I don't see any problems running a second time or multiple times.
I don't have any windows decorations by default, but these can also be set
on.

(it helps to set
viewerWindow-setGeometry(50,50,640,480); instead of
viewerWindow-setGeometry(0,0,640,480);)
to prevent the decorations from being outside the screen.
)

I did have problems when making the window heigth 0, but this was solved by
making the resize always a minumum of one pixel.

But i do get some errors in the console:
QWidget::repaint: Recursive repaint detected

and after closing:
Windows Error #6: [Screen #0]
GraphicsWindowWin32::makeCurrentImplementation() - Unable to set current
OpenGL rendering context. Reason: De ingang is ongeldig.
Windows Error #1400: [Screen #0]
GraphicsWindowWin32::unregisterWindowProcedure() - Unable to unregister
window procedure. Reason: Ongeldige vensteringang.

I am still not sure what solution to use, as the ViewerQT version does its
job, never had window problems with the AdapterWidget, but the performance
of the QOSGWidget seems better.

I also use a qtimer that triggers the update, but I want to start a new
(singleshot) timer only after the frame is drawn, to make sure every frame
is drawn before the timer issues a new frame.  Large models seemed to have a
problem with the original code. would there be a better solution for the
update?

Rene Molenaar


2008/5/7 Mathieu Champlon [EMAIL PROTECTED]

 Hi Robert,

 I quickly hacked the --QOSGWidget mode in order to work around the invalid
 pixel format error (forcing traits-setInheritedWindowPixelFormat = true;)
 and the result is the same : trashed scene on the second run.
 I tried adding the piece of code you suggested but it does not change
 anything.

 By the way the crash you were experiencing running with --QOSGWidget is
 actually due to osg::ArgumentParser modifying argv, thus on the second run
 argc remains unchanged but all arguments have actually been eaten up from
 argv.
 I am now using this code to run the application twice :
 int main( int argc, char **argv )
 {
   char** tmp = (char**)malloc( argc * sizeof( char*) );
   memcpy( tmp, argv, argc * sizeof( char* ) );
   run( argc, argv );
   run( argc, tmp );
 }

 MAT.


 Robert Osfield wrote:

 Hi Mathieu,

 The error with -QOSGWidget looks to be a bug in this code, but its a
 totally different path that the default path which uses
 GraphicsWindowEmbedded to adapt the Viewer.  QOSGWidget is the most
 flexible path for integration and long term I'd like this to be the
 default route under Qt.  My own time is rather stretched out so I
 can't address all these things at once.

 The issues you are seeing with the default path is very unlikely to be
 related to transparency, most likely is issues with display lists or
 texture objects being reused inappropriately.  In theory the viewer
 should be release OpenGL objects when the context is destroyed, but
 with GraphicsWindowEmbedded not all the standard functionality for
 managing OpenGL objects is available, so perhaps this step is not
 being executed appropriately.

 One thing you could try is a

viewer-getSceneData()-releaseGLObjects();
osg::GLObjects::discardAllDeletedGLObjects(0);

 In between the viewer allocations.

 Robert.




 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] CMake error

[René Molenaar]

dont ust the /src dir, just use:
 C:\svn\Delta3D\dt_dep_src\OpenSceneGraph-2.2.0\

That should be the solution..

Good luck,

René


2008/2/20, Brian [EMAIL PROTECTED]:

 I've finally gotten the approval to start looking at OSG 2.2, however I'm
 having issues with CMake not being able to find include files.  Here is the
 error message that I'm getting.


 ---
 Error
 ---
 CMake Error: Cannot find source file /include/OpenThreads/Barrier

 Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
 .hxx .in .txx

 (Press  Cancel to suppress any further messages.)
 ---
 OK   Cancel
 ---


 How can I resolve this?  I'm using CMake 2.4 - patch 8.

 Here are my CMake dialog values.  I'm building for Visual Studio .Net 2003

 Where is the source code:  C:\svn\Delta3D\dt_dep_src\OpenSceneGraph-
 2.2.0\src
 Where to build the binaries:  C:\svn\Delta3D\dt_dep_src\OpenSceneGraph-
 2.2.0\src

 Cache Values for CMake

 CMAKE_BACKWARDS_COMPATIBILITY 2.4
 CMAKE_INSTALL_PREFIX c:/OpenSceneGraph-2.2.0
 DYNAMIC_OPENTHREADS ON
 EXECUTABLE_OUTPUT_PATH C:\svn\Delta3D\dt_dep_src\OpenSceneGraph-2.2.0\bin
 LIBRARY_OUTPUT_PATH C:\svn\Delta3D\dt_dep_src\OpenSceneGraph-2.2.0\lib


 I appreciate the help and have looked at the instructions on the OSG Wiki
 first.  I haven't seen any reference to this particular problem.

 Thanks,
 Brian


 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] ANN: osgPython (SWIG) 2.2.0

[René Molenaar]

I read this in the swig manual:

If you need to cast a pointer or change its value, consider writing some
helper functions instead.
see: http://www.swig.org/Doc1.3/Python.html

%inline %{

/* C++-style cast */
Foo *BarToFoo(Bar *b) {
   return dynamic_castFoo*(b);
}

%}


You can also create the member function node.asGeode() in a similar way with
swig. This is a safe and handy method. There might be other options... this
way you would need to use swig, and can't use the binary version.

René



2008/2/13, Luigi Calori [EMAIL PROTECTED]:

 René Molenaar wrote:

  Swig wrappers for OpenSceneGraph Python and Perl
 
  These files are part of: The VRmeer Library - Delft University of
  Technology
 
  The files are based on osgswig (http://code.google.com/p/osgswig/)
  with some additions and CMake files.
 
 Thanks for the post, I' ll try them as soon as possible, I' m currently
 try to learn python and osgswig using the binary version under windows XP
 I stumbled upon a problem:

 I would like to parse the one scene, so willing to use  something like:


 node = osgDB.readNodeFile('cow.osg')

 while node.className() == 'Group':
 print node.className()
 node = node.asGroup().getChild(0)
 print node.className()

 The problem arise when getChild() returns a Geode.
 There is no  --- node.asGeode()  method so I have no idea of how to
 get the handle of a Geode in the scene.

 Sorry for my dumbness, any help really appreciated,

 Luigi
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] ANN: osgPython (SWIG) 2.2.0

[René Molenaar]

I checked and it worked with the word trunk removed,
so try to checkout http://osgswig.googlecode.com/svn/

svn checkout http://osgswig.googlecode.com/svn/ osg-swig-read-only

René


2008/2/12, Jeremy Moles [EMAIL PROTECTED]:

 Just as a head up, it doesn't look like the project was created using
 the standard trunk/tags/branches layout, so the link that the Google
 Source tab provides is wrong...

 On Tue, 2008-02-12 at 19:07 +0100, René Molenaar wrote:
  Swig wrappers for OpenSceneGraph Python and Perl
 
  These files are part of: The VRmeer Library - Delft University of
  Technology
 
  The files are based on osgswig (http://code.google.com/p/osgswig/)
  with some additions and CMake files.
 
  (I currenlty use swigwin 1.3.29 and the current svn trunk of osg but
  other platform and versions are also being used. There is only one
  example, all our other examples make heavy use of
  The VRmeer Library and the vrmswig library.)
 
  You can also just copy the needed cmake files and place them in the
  right
  directories of the online version. To use cmake to build your project.
 
  Good Luck.
 
  Rene Molenaar
 
 
  2008/2/12, Luigi Calori [EMAIL PROTECTED]:
  I would also be interested in Cmake osgswig building
  I, as a novice in both python and Lua, would greatly
  appreciate any
  script example usage.
 
  I' m trying to use the binary version of osgSwig, it seems
  working well
  but some further python example would really help
 
  Is this the right place to ask question regarding osgswig?
 
  thanks in advance and compliments for the work
 
 
  Luigi
 
  René Molenaar wrote:
 
   I just separated an osgswig cmake project from our larger
  Library.
  
   Tomorrow I can try to build some of your version of the
  wrappers in
   this structure.
   (our version has changed a version of yours here and there).
  
   You can add me to the Project members of the google code
  page?
   I saw another member on there, I worked with him to create
  our current
   version.
   He makes great use of osgPython in combination with IPython
  gtk and
   the rest
   of our Library.
  
   Cheers,
  
   René
  
  
   2008/2/12, Hartmut Seichter [EMAIL PROTECTED]
   mailto:[EMAIL PROTECTED]:
  
  
   Hi there,
  
   I updated the SWIG based python bindings.
  
   http://code.google.com/p/osgswig/
  
   Please test and break it.
  
   Some, hopefully, clarifying words about licensing:
  
   The generating scripts are under the MIT license. The
  modules directly
   derived from OpenSceneGraph are following the OSGPL v0.0
  or the
   appropriate licenses.
  
   The HITLabNZ (http://www.hitlabnz.org) is promoting the
  GPL version of
   osgART 1.1, ARToolKit for OpenSceneGraph, with this
  release. If
   you are
   using this module you also agree to follow the licensing
  terms of the
   GPLv2.
  
   Shameless plug :)
  
   If you need a commercial license for osgART or features
  beyond marker
   based tracking please contact ARToolworks Inc.
   (http://www.artoolworks.com/)
  
   Cheers,
   Hartmut
   ___
   osg-users mailing list
   osg-users@lists.openscenegraph.org
   mailto:osg-users@lists.openscenegraph.org
  
 
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
  
  
 
 
  
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
  
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
  
  
 
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
 
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
 
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing

Re: [osg-users] ANN: osgPython (SWIG) 2.2.0

[René Molenaar]

I just separated an osgswig cmake project from our larger Library.

Tomorrow I can try to build some of your version of the wrappers in this
structure.
(our version has changed a version of yours here and there).

You can add me to the Project members of the google code page?
I saw another member on there, I worked with him to create our current
version.
He makes great use of osgPython in combination with IPython gtk and the rest

of our Library.

Cheers,

René


2008/2/12, Hartmut Seichter [EMAIL PROTECTED]:


 Hi there,

 I updated the SWIG based python bindings.

 http://code.google.com/p/osgswig/

 Please test and break it.

 Some, hopefully, clarifying words about licensing:

 The generating scripts are under the MIT license. The modules directly
 derived from OpenSceneGraph are following the OSGPL v0.0 or the
 appropriate licenses.

 The HITLabNZ (http://www.hitlabnz.org) is promoting the GPL version of
 osgART 1.1, ARToolKit for OpenSceneGraph, with this release. If you are
 using this module you also agree to follow the licensing terms of the
 GPLv2.

 Shameless plug :)

 If you need a commercial license for osgART or features beyond marker
 based tracking please contact ARToolworks Inc. (
 http://www.artoolworks.com/)

 Cheers,
 Hartmut
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org