Re: [osg-users] Creating custom wrappers for osgIntrospection
Hi Mike, http://osgscenemaker.googlepages.com http://orihalcon.jp/orihalconfw Regards, Maciej 2008/8/22 Mike Wozniewski <[EMAIL PROTECTED]> > Actually, nevermind about genwrapper. > > I've managed to use the latest svn version to create custom wrappers for my > classes (yay). Now what I would like to do, is to build a scene-graph editor > GUI to edit my class properties. > > Details: > > * I particularly like wxWidgets and gtk. > * The editor doesn't need to render the scene in the same process > (for now). All I need is a tree-view of the scene, with panels > that open when a particular node is clicked. > * I would like to be able to choose what types of nodes appear in > the tree-view. Only my custom nodes and a small subset of osg > nodes (eg, osg::Group, osg::PositionAttitudeTransform, and a > couple others) should appear. > * Must rely on osgIntrospection and osgWrappers generated by > genwrapper... I was excited about osgedit, until I realized that > it uses some other (custom) reflection mechanism. > > > Does anyone have some simple examples? Are there any libraries that use > osgWrappers & osgIntrospection to provide a GUI? > > Thanks in advance for any pointers, > -Mike > > > > Robert Osfield wrote: > >> HI Mike, >> >> I'll have to defer to the osgInttrospection/genwrapper author Marco >> Jez for low level questions about the wrappers. Hopefully he'll spot >> this this thread and comment. >> >> Robert. >> >> On Thu, Aug 21, 2008 at 4:10 PM, Mike Wozniewski <[EMAIL PROTECTED]> >> wrote: >> >> >>> Thanks Robert. >>> >>> However, I think that genwrapper is not going to work for me. My source >>> tree >>> does not look enough like OSG, and I also have some custom types in my >>> classes that genwrapper doesn't know about. >>> >>> I'm wondering if I can call introspection macros by hand? (I don't have >>> too >>> many to do). >>> >>> For example, I'd like to reflect my class asReferenced, so I've come up >>> with >>> something like this: >>> BEGIN_OBJECT_REFLECTOR(asReferenced) >>> I_BaseType(osg::Referenced); >>> I_Constructor1(IN, t_symbol *, initID, Properties::NON_EXPLICIT, >>> signature0, "", ""); >>> I_Method1(void, setParent, IN, t_symbol *, parent, >>> Properties::NON_VIRTUAL, signatureA, "", ""); >>> I_Method0(t_symbol *, getParent, Properties::NON_VIRTUAL, signatureB, >>> "", >>> ""); >>> . >>> . >>> END_REFLECTOR >>> >>> But what to put for signatures? Is there a way to automatically generate >>> these? >>> >>> Thanks again, >>> -Mike >>> >>> >>> >>> >>> Robert Osfield wrote: >>> >>> Hi Mike, I've been updating the svn version of genwrapper, so grab svn/trunk if you want the latest. I'll will update the tarball as well. Robert. On Wed, Aug 20, 2008 at 9:06 PM, Mike Wozniewski <[EMAIL PROTECTED]> wrote: > Hi, > > I have custom classes which extend OSG classes, and I'd like to create > wrapper libraries for use with osgIntrospection. Particularly, I'd like > to > use these wrappers to call my custom methods from a GUI that doesn't > need > to > know a lot about the classes. > > I've found something called GenWrapper > (http://www.openscenegraph.org/projects/osg/wiki/GenWrapper), but it > seems > to be quite old, pre-dating OSG 2.x. > > Does anyone have some sample code that creates wrapper libraries? > > Furthermore, does anyone have examples of custom classes which use > osgIntrospection? ... I'm having a hard time understanding the > reflection > mechanism in OSG. Any examples would be appreciated. > > Also, I'd like to be compatible with both Linux and OSX. > > Thanks in advance, > Mike Wozniewski > ___ > 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 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.
[osg-users] osgEXP Shader Support
Does osgEXP import osg shader programs ? or export 3D max shaders applied to a model? If not is there any plan to integrate this into osgEXP? Kind Regards Paul IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Efficient live camera rendering on textureRectangle using callback?
Hello,
i want to display a live camera stream on a texture rectangle which i
pass to a bunch of shaders.
I just want to ask if the way im doing it is the most efficient one?
The best solution would be to upload the live camera image once to the GPU
and pass the texture to the several shader..
is this accomplished by the following code?
(the picture Quads state attribute is linked to the shader)
struct DrawableUpdateCallback : public osg::Drawable::UpdateCallback
{
DrawableUpdateCallback(){};
DrawableUpdateCallback(CameraBase* camera, TextureRectangle* texture)
{
this->camera= camera;
this->texture= texture;
};
virtual void update(osg::NodeVisitor*, osg::Drawable* drawable)
{
Image* img= texture->getImage();
img->setImage(camera->getWidth(), camera->getHeight(), 1,
GL_LUMINANCE, GL_LUMINANCE, GL_UNSIGNED_BYTE, camera->getRawFrame(),
Image::NO_DELETE, 1);
img->dirty();
}
CameraBase* camera;
TextureRectangle* texture;
};
//in my class:
ref_ptr camImg= new Image();
PixelBufferObject* pbo= new PixelBufferObject(camImg.get());
camImg->setPixelBufferObject(pbo);
ref_ptr texture= new TextureRectangle(camImg.get());
StateSet* state= pictureQuad->getOrCreateStateSet();
state->setTextureAttributeAndModes(0, texture.get(),
osg::StateAttribute::ON);
pictureQuad->setUpdateCallback(new DrawableUpdateCallback(camera,
texture.get()));
cheers,
Fabian
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Creating custom wrappers for osgIntrospection
Actually, nevermind about genwrapper. I've managed to use the latest svn version to create custom wrappers for my classes (yay). Now what I would like to do, is to build a scene-graph editor GUI to edit my class properties. Details: * I particularly like wxWidgets and gtk. * The editor doesn't need to render the scene in the same process (for now). All I need is a tree-view of the scene, with panels that open when a particular node is clicked. * I would like to be able to choose what types of nodes appear in the tree-view. Only my custom nodes and a small subset of osg nodes (eg, osg::Group, osg::PositionAttitudeTransform, and a couple others) should appear. * Must rely on osgIntrospection and osgWrappers generated by genwrapper... I was excited about osgedit, until I realized that it uses some other (custom) reflection mechanism. Does anyone have some simple examples? Are there any libraries that use osgWrappers & osgIntrospection to provide a GUI? Thanks in advance for any pointers, -Mike Robert Osfield wrote: HI Mike, I'll have to defer to the osgInttrospection/genwrapper author Marco Jez for low level questions about the wrappers. Hopefully he'll spot this this thread and comment. Robert. On Thu, Aug 21, 2008 at 4:10 PM, Mike Wozniewski <[EMAIL PROTECTED]> wrote: Thanks Robert. However, I think that genwrapper is not going to work for me. My source tree does not look enough like OSG, and I also have some custom types in my classes that genwrapper doesn't know about. I'm wondering if I can call introspection macros by hand? (I don't have too many to do). For example, I'd like to reflect my class asReferenced, so I've come up with something like this: BEGIN_OBJECT_REFLECTOR(asReferenced) I_BaseType(osg::Referenced); I_Constructor1(IN, t_symbol *, initID, Properties::NON_EXPLICIT, signature0, "", ""); I_Method1(void, setParent, IN, t_symbol *, parent, Properties::NON_VIRTUAL, signatureA, "", ""); I_Method0(t_symbol *, getParent, Properties::NON_VIRTUAL, signatureB, "", ""); . . END_REFLECTOR But what to put for signatures? Is there a way to automatically generate these? Thanks again, -Mike Robert Osfield wrote: Hi Mike, I've been updating the svn version of genwrapper, so grab svn/trunk if you want the latest. I'll will update the tarball as well. Robert. On Wed, Aug 20, 2008 at 9:06 PM, Mike Wozniewski <[EMAIL PROTECTED]> wrote: Hi, I have custom classes which extend OSG classes, and I'd like to create wrapper libraries for use with osgIntrospection. Particularly, I'd like to use these wrappers to call my custom methods from a GUI that doesn't need to know a lot about the classes. I've found something called GenWrapper (http://www.openscenegraph.org/projects/osg/wiki/GenWrapper), but it seems to be quite old, pre-dating OSG 2.x. Does anyone have some sample code that creates wrapper libraries? Furthermore, does anyone have examples of custom classes which use osgIntrospection? ... I'm having a hard time understanding the reflection mechanism in OSG. Any examples would be appreciated. Also, I'd like to be compatible with both Linux and OSX. Thanks in advance, Mike Wozniewski ___ 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 list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Drawing disappears after being minimized and then restored
HI all, When I minimize and then restore a Windows form rendering OSG contents, the drawing disappears. I added a resize event in which I tried various methods and their combinations such as OsgViewer.Viewer.frame(), SimpleOpenGlControl.Invalidate(), SimpleOpenGlControl.Draw(), SimpleOpenGlControl.Refresh(), etc. None of these methods works. Can anyone give me some enlightenment? Thanks in advance. BTW, I'm using OSG in C#. Regards, Li _ Get thousands of games on your PC, your mobile phone, and the web with Windows®. http://clk.atdmt.com/MRT/go/108588800/direct/01/___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Particle system setInitialRotationalSpeedRange()
Hi Erik, I noticed the same thing about a week ago while upgrading an application from osg 1.0 to 2.4. It was on my list of things to look into. From: Erik Johnson [mailto:[EMAIL PROTECTED] Sent: Thursday, August 21, 2008 10:30 AM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Particle system setInitialRotationalSpeedRange() There is certainly a change in behavior, although I can't pinpoint the change in code yet. Setting the rotational speed with (0, 0, 1): OSG 2.2.0 - particles rotate like fans (pinwheels) OSG 2.4.0 - particles rotate like a margarita blender (cork-screw) OSG 2.6.0 - particles rotate like a margarita blender (cork-screw) I guess I'm just wondering if this is the expected behavior? And I'm surprised nobody has a problem with this. Thanks, Erik Date: Thu, 21 Aug 2008 09:26:52 +0100 From: "Robert Osfield" <[EMAIL PROTECTED]> Subject: Re: [osg-users] Particle system setInitialRotationalSpeedRange() To: "OpenSceneGraph Users" Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1 Hi Erik, osgParticle has hardly been touched between OSG-2.2 and 2.6. Use svn log to check which files have changed. Robert. On Thu, Aug 21, 2008 at 1:07 AM, Erik Johnson <[EMAIL PROTECTED]> wrote: > Hi all, > > It seems to me, back in the OSG 2.2.x time frame, that I could set the > initial rotational velocity of the RadialShooter and have the particles > "pinwheel" around their center point, while maintaining their billboard > orientation and face the Camera. Perhaps it was a rotation on the "Y" > axis. > > Nowadays with OSG 2.4/2.6, setting the rotational speed will cause the > particles to rotate relative to the world axis and not in the > camera-relative axis. > > Is this a bug? A feature? Is it still posible to "pinwheel" a particle > around? Does anyone use setInitialRotationalSpeedRange()? > > This was a cool effect which added a nice dimension to smoke plumes and > such. > > Thanks for any info! > -Erik Johnson > > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g > > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Generate MipMap bug
Hi All,
I'm in the process of upgrading 2.2 ->2.6 and came across a bug in
mipmap generation. For NPOT textures when the ResizeNonPowerOfTwoHint is
false, I'm not getting textures applied correctly.
Sample program demonstrating the bug:
#include
#include
#include
#include
int main(int, char **)
{
osg::ref_ptr redTexture = new osg::Texture2D;
osg::Image* image = new osg::Image;
static unsigned char bytes[12] = { 0xff, 0x00, 0x00, 0xff, 0xff,
0x00, 0x00, 0xff, 0xff, 0x00, 0x00, 0xff };
image->setImage(3, 1, 1, GL_RGBA8, GL_RGBA, GL_UNSIGNED_BYTE,
&bytes[0], osg::Image::NO_DELETE, 1);
redTexture->setImage(image);
redTexture->setResizeNonPowerOfTwoHint(false);
redTexture->setFilter( osg::Texture::MIN_FILTER,
osg::Texture::LINEAR_MIPMAP_LINEAR );
osg::ref_ptr geode = new osg::Geode();
osg::ref_ptr sphere1 = new
osg::ShapeDrawable(new osg::Sphere(osg::Vec3(0.0f,0.0f,0.0f),10));
geode->addDrawable(sphere1.get());
osg::ref_ptr text = new osgText::Text();
text->setText( L"Text" );
text->setAxisAlignment(osgText::Text::XZ_PLANE);
osgViewer::Viewer viewer;
viewer.setThreadingModel(osgViewer::ViewerBase::SingleThreaded);
viewer.setSceneData( geode.get() );
osg::StateSet* stateset = new osg::StateSet();
stateset->setMode(GL_LIGHTING, osg::StateAttribute::OFF);
stateset->setTextureAttributeAndModes(0, redTexture.get(),
osg::StateAttribute::ON);
geode->setStateSet( stateset );
viewer.run();
return 0;
}
The problem appears to be that in mipmapAfterTexImage, called by
applyTexImage2D_load, getTextureObject(contextID) is returning NULL.
Moving the assignment of the TextureObject to the _textureObjectBuffer
before applyTexImage2D_load is called fixes the problem. The change to
Texture2D::apply is shown below, controlled by #define MIPMAP_FIX. Other
code (in the same function even) is assigning to _textureObjectBuffer
immediately upon generation of the TextureObject so I figure this should
be a safe change.
void Texture2D::apply(State& state) const
{
//state.setReportGLErrors(true);
// get the contextID (user defined ID of 0 upwards) for the
// current OpenGL context.
const unsigned int contextID = state.getContextID();
// get the texture object for the current contextID.
TextureObject* textureObject = getTextureObject(contextID);
if (textureObject != 0)
{
textureObject->bind();
if (getTextureParameterDirty(state.getContextID()))
applyTexParameters(GL_TEXTURE_2D,state);
if (_subloadCallback.valid())
{
_subloadCallback->subload(*this,state);
}
else if (_image.valid() && getModifiedCount(contextID) !=
_image->getModifiedCount())
{
applyTexImage2D_subload(state,GL_TEXTURE_2D,_image.get(),
_textureWidth, _textureHeight,
_internalFormat, _numMipmapLevels);
// update the modified tag to show that it is up to date.
getModifiedCount(contextID) = _image->getModifiedCount();
}
else if (_readPBuffer.valid())
{
_readPBuffer->bindPBufferToTexture(GL_FRONT);
}
}
else if (_subloadCallback.valid())
{
_textureObjectBuffer[contextID] = textureObject =
generateTextureObject(contextID,GL_TEXTURE_2D);
textureObject->bind();
applyTexParameters(GL_TEXTURE_2D,state);
_subloadCallback->load(*this,state);
textureObject->setAllocated(_numMipmapLevels,_internalFormat,_textureWidth,_textureHeight,1,0);
// in theory the following line is redundent, but in practice
// have found that the first frame drawn doesn't apply the
textures
// unless a second bind is called?!!
// perhaps it is the first glBind which is not required...
//glBindTexture( GL_TEXTURE_2D, handle );
}
else if (_image.valid() && _image->data())
{
// keep the image around at least till we go out of scope.
osg::ref_ptr image = _image;
// compute the internal texture format, this set the
_internalFormat to an appropriate value.
computeInternalFormat();
// compute the dimensions of the texture.
computeRequiredTextureDimensions(state,*image,_textureWidth,
_textureHeight, _numMipmapLevels);
#define MIPMAP_FIX
#if defined MIPMAP_FIX
_textureObjectBuffer[contextID] = textureObject =
generateTextureObject(
contextID,GL_TEXTURE_2D,_numMipmapLevels,_internalFormat,_textureWidth,_textureHeight,1,0);
#else
texture
Re: [osg-users] Performance of osgdem generated databases using --terrain
Hi Robert, I finally figured out the issue I was having. I was passing in --no-mip-mapping to osgdem to compensate for the ATI compressed textures issue that existed before their drivers got updated. Removing the --no-mip-mapping argument caused the performance to be great on the machine. I still have to disable VBO on the system to avoid crashing, but other than that, things are looking really good using --terrain. Thanks again for all your help, I don't know how I would get anything done without it:) Jason On Thu, Aug 21, 2008 at 11:29 AM, Robert Osfield <[EMAIL PROTECTED]>wrote: > Hi Jason, > > It would be worth bringing up the viewer stats to look at the update, > cull, draw dispatch times. My expectation is that its draw dispatch > is stalling due to the graphics driver, but it would still be worth > checking. > > Another thing you could try would be to rebuild a osg --terrain > database, but limiting the image resolution per tile to something like > 64x64. You can do this adding --tile-image-size 64 to the command > line. The default size is 256x256 image size, a 64x64 terrain size. > > Robert. > > On Thu, Aug 21, 2008 at 3:57 PM, Jason Beverage <[EMAIL PROTECTED]> > wrote: > > Hi Robert, > > > > I noticed that anisotropy setting as well and tried commenting it out and > it > > didn't have any affect. Still large hiccups when downloading textures > using > > --terrain. Looking at the memory usage of my app in the Intel driver's > > control panel says that it has a max of 128 mb of memory, which should be > > enough. Both osgdem options (--terrian and not) keep the "used graphics > > memory" at about 126mb. > > > > Right now, it just seems that the card might not be up to the challenge. > > I'm going to try updating the drivers on the machine and see if that > helps > > at all. I think I may just have to revert back to using regular old > osgdem > > with no --terrain option for now. > > > > Thanks! > > > > Jason > > > > On Thu, Aug 21, 2008 at 4:25 AM, Robert Osfield < > [EMAIL PROTECTED]> > > wrote: > >> > >> Hi Jason, > >> > >> It does sounds like you are hitting problems with texture download. > >> When using osgTerrain the texturing should be the same as when using > >> just osg::Geometry/osg::StateSet based paged databases. The only > >> difference I can spot would be the setting of anisotropic filtering on > >> the textures, perhaps the Intel hardware is having problems with this. > >> To test this possibility out, comment out the following line of > >> src/osgTerrain/GeometryTechnique.cpp (line 690 in OSG-2.6/svntrunk): > >> > >>texture2D->setMaxAnisotropy(16.0f); > >> > >> It'd also be worth checking how texture memory you have available. > >> > >> Robert. > >> > >> > >> On Wed, Aug 20, 2008 at 10:28 PM, Jason Beverage > >> <[EMAIL PROTECTED]> wrote: > >> > Hi all, > >> > > >> > More integrated graphics woes for me today. I'm working with an Intel > >> > 945GM > >> > graphics card and trying to load a terrain database generated with > >> > --terrain. Robert, your suggestion of disabling VBO programatically > >> > worked > >> > great for getting the machine to stop crashing. For some reason, the > >> > machine only crashes if I loaded in some polygonal feature data as > well > >> > as > >> > the terrain database unless I disable VBO. > >> > > >> > The issue I'm facing now is that the performance of the terrain > database > >> > is > >> > terrible on this machine. A database generated without the --terrain > >> > option > >> > works really well, but takes a long time to build. > >> > > >> > When I move around in my application or in osgviewer, I get huge frame > >> > hiccups (up to 2 seconds sometimes) when tiles are being paged in. > The > >> > interesting thing is that this only happens if I have texturing turned > >> > on. > >> > If I hit 't' in osgviewer to disable texturing, tiles come in just > fine. > >> > I've also noticed that if I turn texturing off for just the high > >> > resolution > >> > ortho imagery on my database (layer 0) but leave on my lower > resolution > >> > map > >> > (layer 1) that thigns run smoothly. > >> > > >> > I've tried reducing the sample ratio as Robert has suggested using an > >> > osgTerrain::Terrain decorator as well, and this doesn't help the > hiccups > >> > as > >> > they seem to be related to the textures. > >> > > >> > I suspected that I was maybe hitting a texture memory limit, but I > don't > >> > understand why a database generated without the --terrain option would > >> > work > >> > well since they should be using the same imagery for the tiles. > >> > > >> > Does anyone have any more suggestions to try to get this amazing > >> > graphics > >> > card chugging along?:) > >> > > >> > Thanks for everyones help on this, > >> > > >> > Jason > >> > > >> > ___ > >> > osg-users mailing list > >> > osg-users@lists.openscenegraph.org > >> > > >> > > http://lists.openscenegraph.o
Re: [osg-users] Creating custom wrappers for osgIntrospection
HI Mike, I'll have to defer to the osgInttrospection/genwrapper author Marco Jez for low level questions about the wrappers. Hopefully he'll spot this this thread and comment. Robert. On Thu, Aug 21, 2008 at 4:10 PM, Mike Wozniewski <[EMAIL PROTECTED]> wrote: > Thanks Robert. > > However, I think that genwrapper is not going to work for me. My source tree > does not look enough like OSG, and I also have some custom types in my > classes that genwrapper doesn't know about. > > I'm wondering if I can call introspection macros by hand? (I don't have too > many to do). > > For example, I'd like to reflect my class asReferenced, so I've come up with > something like this: > BEGIN_OBJECT_REFLECTOR(asReferenced) > I_BaseType(osg::Referenced); > I_Constructor1(IN, t_symbol *, initID, Properties::NON_EXPLICIT, > signature0, "", ""); > I_Method1(void, setParent, IN, t_symbol *, parent, > Properties::NON_VIRTUAL, signatureA, "", ""); > I_Method0(t_symbol *, getParent, Properties::NON_VIRTUAL, signatureB, "", > ""); > . > . > END_REFLECTOR > > But what to put for signatures? Is there a way to automatically generate > these? > > Thanks again, > -Mike > > > > > Robert Osfield wrote: >> >> Hi Mike, >> >> I've been updating the svn version of genwrapper, so grab svn/trunk if >> you want the latest. I'll will update the tarball as well. >> >> Robert. >> >> On Wed, Aug 20, 2008 at 9:06 PM, Mike Wozniewski <[EMAIL PROTECTED]> >> wrote: >> >>> >>> Hi, >>> >>> I have custom classes which extend OSG classes, and I'd like to create >>> wrapper libraries for use with osgIntrospection. Particularly, I'd like >>> to >>> use these wrappers to call my custom methods from a GUI that doesn't need >>> to >>> know a lot about the classes. >>> >>> I've found something called GenWrapper >>> (http://www.openscenegraph.org/projects/osg/wiki/GenWrapper), but it >>> seems >>> to be quite old, pre-dating OSG 2.x. >>> >>> Does anyone have some sample code that creates wrapper libraries? >>> >>> Furthermore, does anyone have examples of custom classes which use >>> osgIntrospection? ... I'm having a hard time understanding the reflection >>> mechanism in OSG. Any examples would be appreciated. >>> >>> Also, I'd like to be compatible with both Linux and OSX. >>> >>> Thanks in advance, >>> Mike Wozniewski >>> ___ >>> 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
Re: [osg-users] Particle system setInitialRotationalSpeedRange()
There is certainly a change in behavior, although I can't pinpoint the change in code yet. Setting the rotational speed with (0, 0, 1): OSG 2.2.0 - particles rotate like fans (pinwheels) OSG 2.4.0 - particles rotate like a margarita blender (cork-screw) OSG 2.6.0 - particles rotate like a margarita blender (cork-screw) I guess I'm just wondering if this is the expected behavior? And I'm surprised nobody has a problem with this. Thanks, Erik Date: Thu, 21 Aug 2008 09:26:52 +0100 > From: "Robert Osfield" <[EMAIL PROTECTED]> > Subject: Re: [osg-users] Particle system >setInitialRotationalSpeedRange() > To: "OpenSceneGraph Users" > Message-ID: ><[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi Erik, > > osgParticle has hardly been touched between OSG-2.2 and 2.6. Use svn > log to check which files have changed. > > Robert. > > On Thu, Aug 21, 2008 at 1:07 AM, Erik Johnson <[EMAIL PROTECTED]> > wrote: > > Hi all, > > > > It seems to me, back in the OSG 2.2.x time frame, that I could set the > > initial rotational velocity of the RadialShooter and have the particles > > "pinwheel" around their center point, while maintaining their billboard > > orientation and face the Camera. Perhaps it was a rotation on the "Y" > > axis. > > > > Nowadays with OSG 2.4/2.6, setting the rotational speed will cause the > > particles to rotate relative to the world axis and not in the > > camera-relative axis. > > > > Is this a bug? A feature? Is it still posible to "pinwheel" a particle > > around? Does anyone use setInitialRotationalSpeedRange()? > > > > This was a cool effect which added a nice dimension to smoke plumes and > > such. > > > > Thanks for any info! > > -Erik Johnson > > > > > > ___ > > 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] Performance of osgdem generated databases using --terrain
Hi Jason, It would be worth bringing up the viewer stats to look at the update, cull, draw dispatch times. My expectation is that its draw dispatch is stalling due to the graphics driver, but it would still be worth checking. Another thing you could try would be to rebuild a osg --terrain database, but limiting the image resolution per tile to something like 64x64. You can do this adding --tile-image-size 64 to the command line. The default size is 256x256 image size, a 64x64 terrain size. Robert. On Thu, Aug 21, 2008 at 3:57 PM, Jason Beverage <[EMAIL PROTECTED]> wrote: > Hi Robert, > > I noticed that anisotropy setting as well and tried commenting it out and it > didn't have any affect. Still large hiccups when downloading textures using > --terrain. Looking at the memory usage of my app in the Intel driver's > control panel says that it has a max of 128 mb of memory, which should be > enough. Both osgdem options (--terrian and not) keep the "used graphics > memory" at about 126mb. > > Right now, it just seems that the card might not be up to the challenge. > I'm going to try updating the drivers on the machine and see if that helps > at all. I think I may just have to revert back to using regular old osgdem > with no --terrain option for now. > > Thanks! > > Jason > > On Thu, Aug 21, 2008 at 4:25 AM, Robert Osfield <[EMAIL PROTECTED]> > wrote: >> >> Hi Jason, >> >> It does sounds like you are hitting problems with texture download. >> When using osgTerrain the texturing should be the same as when using >> just osg::Geometry/osg::StateSet based paged databases. The only >> difference I can spot would be the setting of anisotropic filtering on >> the textures, perhaps the Intel hardware is having problems with this. >> To test this possibility out, comment out the following line of >> src/osgTerrain/GeometryTechnique.cpp (line 690 in OSG-2.6/svntrunk): >> >>texture2D->setMaxAnisotropy(16.0f); >> >> It'd also be worth checking how texture memory you have available. >> >> Robert. >> >> >> On Wed, Aug 20, 2008 at 10:28 PM, Jason Beverage >> <[EMAIL PROTECTED]> wrote: >> > Hi all, >> > >> > More integrated graphics woes for me today. I'm working with an Intel >> > 945GM >> > graphics card and trying to load a terrain database generated with >> > --terrain. Robert, your suggestion of disabling VBO programatically >> > worked >> > great for getting the machine to stop crashing. For some reason, the >> > machine only crashes if I loaded in some polygonal feature data as well >> > as >> > the terrain database unless I disable VBO. >> > >> > The issue I'm facing now is that the performance of the terrain database >> > is >> > terrible on this machine. A database generated without the --terrain >> > option >> > works really well, but takes a long time to build. >> > >> > When I move around in my application or in osgviewer, I get huge frame >> > hiccups (up to 2 seconds sometimes) when tiles are being paged in. The >> > interesting thing is that this only happens if I have texturing turned >> > on. >> > If I hit 't' in osgviewer to disable texturing, tiles come in just fine. >> > I've also noticed that if I turn texturing off for just the high >> > resolution >> > ortho imagery on my database (layer 0) but leave on my lower resolution >> > map >> > (layer 1) that thigns run smoothly. >> > >> > I've tried reducing the sample ratio as Robert has suggested using an >> > osgTerrain::Terrain decorator as well, and this doesn't help the hiccups >> > as >> > they seem to be related to the textures. >> > >> > I suspected that I was maybe hitting a texture memory limit, but I don't >> > understand why a database generated without the --terrain option would >> > work >> > well since they should be using the same imagery for the tiles. >> > >> > Does anyone have any more suggestions to try to get this amazing >> > graphics >> > card chugging along?:) >> > >> > Thanks for everyones help on this, >> > >> > Jason >> > >> > ___ >> > 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
Re: [osg-users] Creating custom wrappers for osgIntrospection
Thanks Robert. However, I think that genwrapper is not going to work for me. My source tree does not look enough like OSG, and I also have some custom types in my classes that genwrapper doesn't know about. I'm wondering if I can call introspection macros by hand? (I don't have too many to do). For example, I'd like to reflect my class asReferenced, so I've come up with something like this: BEGIN_OBJECT_REFLECTOR(asReferenced) I_BaseType(osg::Referenced); I_Constructor1(IN, t_symbol *, initID, Properties::NON_EXPLICIT, signature0, "", ""); I_Method1(void, setParent, IN, t_symbol *, parent, Properties::NON_VIRTUAL, signatureA, "", ""); I_Method0(t_symbol *, getParent, Properties::NON_VIRTUAL, signatureB, "", ""); . . END_REFLECTOR But what to put for signatures? Is there a way to automatically generate these? Thanks again, -Mike Robert Osfield wrote: Hi Mike, I've been updating the svn version of genwrapper, so grab svn/trunk if you want the latest. I'll will update the tarball as well. Robert. On Wed, Aug 20, 2008 at 9:06 PM, Mike Wozniewski <[EMAIL PROTECTED]> wrote: Hi, I have custom classes which extend OSG classes, and I'd like to create wrapper libraries for use with osgIntrospection. Particularly, I'd like to use these wrappers to call my custom methods from a GUI that doesn't need to know a lot about the classes. I've found something called GenWrapper (http://www.openscenegraph.org/projects/osg/wiki/GenWrapper), but it seems to be quite old, pre-dating OSG 2.x. Does anyone have some sample code that creates wrapper libraries? Furthermore, does anyone have examples of custom classes which use osgIntrospection? ... I'm having a hard time understanding the reflection mechanism in OSG. Any examples would be appreciated. Also, I'd like to be compatible with both Linux and OSX. Thanks in advance, Mike Wozniewski ___ 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] Performance of osgdem generated databases using --terrain
Hi Robert, I noticed that anisotropy setting as well and tried commenting it out and it didn't have any affect. Still large hiccups when downloading textures using --terrain. Looking at the memory usage of my app in the Intel driver's control panel says that it has a max of 128 mb of memory, which should be enough. Both osgdem options (--terrian and not) keep the "used graphics memory" at about 126mb. Right now, it just seems that the card might not be up to the challenge. I'm going to try updating the drivers on the machine and see if that helps at all. I think I may just have to revert back to using regular old osgdem with no --terrain option for now. Thanks! Jason On Thu, Aug 21, 2008 at 4:25 AM, Robert Osfield <[EMAIL PROTECTED]>wrote: > Hi Jason, > > It does sounds like you are hitting problems with texture download. > When using osgTerrain the texturing should be the same as when using > just osg::Geometry/osg::StateSet based paged databases. The only > difference I can spot would be the setting of anisotropic filtering on > the textures, perhaps the Intel hardware is having problems with this. > To test this possibility out, comment out the following line of > src/osgTerrain/GeometryTechnique.cpp (line 690 in OSG-2.6/svntrunk): > >texture2D->setMaxAnisotropy(16.0f); > > It'd also be worth checking how texture memory you have available. > > Robert. > > > On Wed, Aug 20, 2008 at 10:28 PM, Jason Beverage > <[EMAIL PROTECTED]> wrote: > > Hi all, > > > > More integrated graphics woes for me today. I'm working with an Intel > 945GM > > graphics card and trying to load a terrain database generated with > > --terrain. Robert, your suggestion of disabling VBO programatically > worked > > great for getting the machine to stop crashing. For some reason, the > > machine only crashes if I loaded in some polygonal feature data as well > as > > the terrain database unless I disable VBO. > > > > The issue I'm facing now is that the performance of the terrain database > is > > terrible on this machine. A database generated without the --terrain > option > > works really well, but takes a long time to build. > > > > When I move around in my application or in osgviewer, I get huge frame > > hiccups (up to 2 seconds sometimes) when tiles are being paged in. The > > interesting thing is that this only happens if I have texturing turned > on. > > If I hit 't' in osgviewer to disable texturing, tiles come in just fine. > > I've also noticed that if I turn texturing off for just the high > resolution > > ortho imagery on my database (layer 0) but leave on my lower resolution > map > > (layer 1) that thigns run smoothly. > > > > I've tried reducing the sample ratio as Robert has suggested using an > > osgTerrain::Terrain decorator as well, and this doesn't help the hiccups > as > > they seem to be related to the textures. > > > > I suspected that I was maybe hitting a texture memory limit, but I don't > > understand why a database generated without the --terrain option would > work > > well since they should be using the same imagery for the tiles. > > > > Does anyone have any more suggestions to try to get this amazing graphics > > card chugging along?:) > > > > Thanks for everyones help on this, > > > > Jason > > > > ___ > > 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] problem with recycled context id's and OPTIMIZE_TEXTURE_SETTINGS
Hi Brett,
I've just grokked what is going on - the optimize texture settings is
setting the UnrefImageDataApply to true on scene graph, which is great
for keeping memory usage down, but... it does mean that if you later
what to recompile the texture such as when you create a new viewer,
then image won't be available to download - hence your white texture.
This isn't an bug OSG, nothing is going wrong, everything is occurring
what you'd expect to occur given the optimization. The problem is
your app applying an optimization that is inappropriate for your
viewer usage model. If you want to dynamically create viewers and
share scene graphs between then then you'll have to avoid using the
OPTIMIZE_TEXTURE_SETTINGS pass (of in particular its setting of
Texture::setUnrefImageDataAfterApply.
Robert.
On Thu, Aug 21, 2008 at 3:06 PM, brettwiesner <[EMAIL PROTECTED]> wrote:
> Hi Robert,
>
> I finally got around to getting the 2.6.0 build and tested it out again.
> Unfortunatly, the OPTIMIZE_TEXTURE_SETTINGS
> flag still causes problems.
>
> As stated below, the problem is if you optimize your scene graph using the
> OPTIMIZE_TEXTURE_SETTINGS setting, then recycle the context id, textures are
> missing.
>
> Thanks,
> Brett
>
> Robert Osfield wrote:
>>
>> Hi Brett,
>>
>> We've done work since 2.4.0 to address this issue, could you please
>> try 2.5.5 or the svn/trunk.
>>
>> Cheers,
>> Robert.
>>
>> On Thu, Jul 17, 2008 at 9:31 PM, Brett Wiesner <[EMAIL PROTECTED]>
>> wrote:
>>
>>>
>>> Hi,
>>>
>>> Problem:
>>> Using OSG 2.4.0 I have built an app that dynamically creates composite
>>> viewers that have one of more views. The scene graph is kept around as a
>>> ref
>>> pointer during the course of multiple viewers. When I delete a composite
>>> viewer and create another one and then use the original root node of the
>>> scene graph, textures are gone (ie, everythings white).
>>>
>>> I've tracked the problem down to this. If you optimize your scene graph
>>> using the OPTIMIZE_TEXTURE_SETTINGS setting, then recycle the context id,
>>> textures are missing.
>>>
>>> I'm honestly not sure what the optimizer option OPTIMIZE_TEXTURE_SETTINGS
>>> does but I can reproduce the bug.
>>>
>>> I've included sample code below to reproduce the bug.
>>>
>>> Thanks,
>>> Brett
>>>
>>>
>>> // This method reads in a flt file and writes it out optimized using the
>>> "troublesome" flag.
>>> writeOutModelAsIveOptimized()
>>> {
>>>std::string modelPath = testDataDir();
>>>modelPath += "testTree\\Test_tree.flt";
>>>
>>>std::string modelPathOut = testDataDir();
>>>modelPathOut += "testTree\\Test_tree_optimized.ive";
>>>
>>>// create a scene graph (and keep it around).
>>>osg::ref_ptr modelNode = osgDB::readNodeFile(modelPath);
>>>osgUtil::Optimizer op;
>>>
>>>
>>> op.optimize(modelNode.get(),osgUtil::Optimizer::OPTIMIZE_TEXTURE_SETTINGS);
>>>
>>>osgDB::writeNodeFile(*modelNode.get(), modelPathOut);
>>> }
>>>
>>> // This method reads in a flt file and writes it out unoptimized. Please
>>> substitute any flt file you have.
>>> writeOutModelAsIve()
>>> {
>>>std::string modelPath = testDataDir();
>>>modelPath += "testTree\\Test_tree.flt";
>>>
>>>std::string modelPathOut = testDataDir();
>>>modelPathOut += "testTree\\Test_tree_unoptimized.ive";
>>>
>>>// create a scene graph (and keep it around).
>>>osg::ref_ptr modelNode = osgDB::readNodeFile(modelPath);
>>> osgDB::writeNodeFile(*modelNode.get(), modelPathOut);
>>> }
>>>
>>>
>>> // This method creates a scene graph and keeps it around after the
>>> destruction of a viewer.
>>> // Then it creates a viewer and loads the model. You try this with both
>>> the
>>> unoptimized ive and the
>>> // optimized one. It runs the viewer waits for you to look at the model
>>> and
>>> then hit esc to quit.
>>> // Then it destroys the viewer, and creates another one using the same
>>> scene
>>> graph.
>>> // You'll notice that the scene no longer has textures.
>>> TEST(test_osgKeepSceneGraphAround)
>>> {
>>>std::string modelPath = testDataDir();
>>>modelPath += "testTree\\Test_tree_optimized.ive";
>>>
>>>// create a scene graph (and keep it around).
>>>osg::ref_ptr modelNode = osgDB::readNodeFile(modelPath);
>>>
>>>// create viewer1 and set the scene graph data.
>>>osgViewer::Viewer* viewer1 = new osgViewer::Viewer;
>>>viewer1->setUpViewOnSingleScreen(0);
>>>viewer1->setSceneData(modelNode.get());
>>>viewer1->setCameraManipulator(new osgGA::TrackballManipulator());
>>>
>>>// render
>>>viewer1->realize();
>>>while(!viewer1->done())
>>>{
>>> viewer1->frame();
>>>}
>>>
>>>// delete viewer1.
>>>delete viewer1;
>>>viewer1 = 0;
>>>
>>>// create viewer2 and set the scene graph data.
>>>osgViewer::Viewer* viewer2 = new osgViewer::Viewer;
>>>viewer2->setUpViewOnSingleScreen(0);
>>>viewer2->setSceneData(modelNode.get());
>>>viewer2->setCameraManipulator(new osgGA:
Re: [osg-users] Update callbacks occur in between calls to glBegin andglEnd?
OK, that makes sense. The error is saying it's invalid to call glGetInt
in between a glbegin and glend. I took this for face value and thought
it was weird because I shouldn't be inside glbegin and glend in the
update traversal. But what the error means is really, the graphics
context isn't current so you can't make these calls. That makes sense.
Too bad the error message isn't very helpful.
Thanks guys.
Tomlinson, Gordon wrote:
Hi
I think the GL error is because your doing a GL call in the update
process/thread and not the draw process/threads (You need a valid GL
context which is typically owned by the draw process/threads)
Gordon
__
Gordon Tomlinson
Email : gtomlinson @ overwatch.textron.com
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
brettwiesner
Sent: Thursday, August 21, 2008 10:01 AM
To: OpenSceneGraph Users
Cc: [EMAIL PROTECTED]
Subject: [osg-users] Update callbacks occur in between calls to glBegin
andglEnd?
Hi,
I was wondering if update callbacks are suppose to occur in between
calls to glBegin and glEnd? I think this test code demonstrates that
they do.
I'm using a glGet command (in this case glGetIntegerv) and checking for
it's error code. From the open GL docs:
"GL_INVALID_OPERATION is generated if glGet is executed between the
execution of glBegin and the corresponding execution of glEnd."
I'm making that call inside the update callback and getting that error,
suggesting that the update callback occurs somewhere in between a
glBegin and glEnd. Is this correct?
Thanks,
Brett
class TestUpdateCallback : public osg::NodeCallback
{
public:
void operator()(osg::Node* node, osg::NodeVisitor* nv)
{
// Clear any previous error.
GLenum eError = glGetError();
// Make the call that will generate a new error.
int maxUnits;
glGetIntegerv(GL_MAX_TEXTURE_UNITS,&maxUnits);
// Check the error
eError = glGetError();
if(eError == GL_INVALID_OPERATION)
{
std::cout << "TestUpdateCallback: This update callback
occurs in between glBegin and glEnd." << std::endl;
}
// Continue traverse.
traverse(node,nv);
}
};
main()
{
std::string modelPath = testDataDir();
modelPath += "cow.osg";
osg::ref_ptr modelNode =
osgDB::readNodeFile(modelPath);
modelNode->setUpdateCallback(new TestUpdateCallback);
osg::ref_ptr viewer = new osgViewer::Viewer;
viewer->setUpViewOnSingleScreen(0);
viewer->setSceneData(modelNode.get());
viewer->setCameraManipulator(new osgGA::TrackballManipulator());
viewer->run();
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g
___
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] Update callbacks occur in between calls to glBegin andglEnd?
brettwiesner wrote on Thursday, August 21, 2008 9:01 AM: > Hi, > > I was wondering if update callbacks are suppose to occur in between > calls to glBegin and glEnd? I think this test code demonstrates that > they do. > > I'm using a glGet command (in this case glGetIntegerv) and checking for > it's error code. From the open GL docs: > > "GL_INVALID_OPERATION is generated if glGet is executed between the > execution of glBegin and the corresponding execution of glEnd." > > I'm making that call inside the update callback and getting that error, > suggesting that the update callback occurs somewhere in between a > glBegin and glEnd. Is this correct? More likely it is because you don't have a valid OpenGL context during the update call. If I understand correctly, running the OSG viewer single-threaded will cause the update traversal to have a valid context, but it would be better to simply do OpenGL calls from a draw or cull callback. -- Bryan Thrall FlightSafety International [EMAIL PROTECTED] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Update callbacks occur in between calls to glBegin andglEnd?
Hi
I think the GL error is because your doing a GL call in the update
process/thread and not the draw process/threads (You need a valid GL
context which is typically owned by the draw process/threads)
Gordon
__
Gordon Tomlinson
Email : gtomlinson @ overwatch.textron.com
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
brettwiesner
Sent: Thursday, August 21, 2008 10:01 AM
To: OpenSceneGraph Users
Cc: [EMAIL PROTECTED]
Subject: [osg-users] Update callbacks occur in between calls to glBegin
andglEnd?
Hi,
I was wondering if update callbacks are suppose to occur in between
calls to glBegin and glEnd? I think this test code demonstrates that
they do.
I'm using a glGet command (in this case glGetIntegerv) and checking for
it's error code. From the open GL docs:
"GL_INVALID_OPERATION is generated if glGet is executed between the
execution of glBegin and the corresponding execution of glEnd."
I'm making that call inside the update callback and getting that error,
suggesting that the update callback occurs somewhere in between a
glBegin and glEnd. Is this correct?
Thanks,
Brett
class TestUpdateCallback : public osg::NodeCallback
{
public:
void operator()(osg::Node* node, osg::NodeVisitor* nv)
{
// Clear any previous error.
GLenum eError = glGetError();
// Make the call that will generate a new error.
int maxUnits;
glGetIntegerv(GL_MAX_TEXTURE_UNITS,&maxUnits);
// Check the error
eError = glGetError();
if(eError == GL_INVALID_OPERATION)
{
std::cout << "TestUpdateCallback: This update callback
occurs in between glBegin and glEnd." << std::endl;
}
// Continue traverse.
traverse(node,nv);
}
};
main()
{
std::string modelPath = testDataDir();
modelPath += "cow.osg";
osg::ref_ptr modelNode =
osgDB::readNodeFile(modelPath);
modelNode->setUpdateCallback(new TestUpdateCallback);
osg::ref_ptr viewer = new osgViewer::Viewer;
viewer->setUpViewOnSingleScreen(0);
viewer->setSceneData(modelNode.get());
viewer->setCameraManipulator(new osgGA::TrackballManipulator());
viewer->run();
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problem with recycled context id's and OPTIMIZE_TEXTURE_SETTINGS
Hi Robert,
I finally got around to getting the 2.6.0 build and tested it out again.
Unfortunatly, the OPTIMIZE_TEXTURE_SETTINGS
flag still causes problems.
As stated below, the problem is if you optimize your scene graph using
the OPTIMIZE_TEXTURE_SETTINGS setting, then recycle the context id,
textures are missing.
Thanks,
Brett
Robert Osfield wrote:
Hi Brett,
We've done work since 2.4.0 to address this issue, could you please
try 2.5.5 or the svn/trunk.
Cheers,
Robert.
On Thu, Jul 17, 2008 at 9:31 PM, Brett Wiesner <[EMAIL PROTECTED]> wrote:
Hi,
Problem:
Using OSG 2.4.0 I have built an app that dynamically creates composite
viewers that have one of more views. The scene graph is kept around as a ref
pointer during the course of multiple viewers. When I delete a composite
viewer and create another one and then use the original root node of the
scene graph, textures are gone (ie, everythings white).
I've tracked the problem down to this. If you optimize your scene graph
using the OPTIMIZE_TEXTURE_SETTINGS setting, then recycle the context id,
textures are missing.
I'm honestly not sure what the optimizer option OPTIMIZE_TEXTURE_SETTINGS
does but I can reproduce the bug.
I've included sample code below to reproduce the bug.
Thanks,
Brett
// This method reads in a flt file and writes it out optimized using the
"troublesome" flag.
writeOutModelAsIveOptimized()
{
std::string modelPath = testDataDir();
modelPath += "testTree\\Test_tree.flt";
std::string modelPathOut = testDataDir();
modelPathOut += "testTree\\Test_tree_optimized.ive";
// create a scene graph (and keep it around).
osg::ref_ptr modelNode = osgDB::readNodeFile(modelPath);
osgUtil::Optimizer op;
op.optimize(modelNode.get(),osgUtil::Optimizer::OPTIMIZE_TEXTURE_SETTINGS);
osgDB::writeNodeFile(*modelNode.get(), modelPathOut);
}
// This method reads in a flt file and writes it out unoptimized. Please
substitute any flt file you have.
writeOutModelAsIve()
{
std::string modelPath = testDataDir();
modelPath += "testTree\\Test_tree.flt";
std::string modelPathOut = testDataDir();
modelPathOut += "testTree\\Test_tree_unoptimized.ive";
// create a scene graph (and keep it around).
osg::ref_ptr modelNode = osgDB::readNodeFile(modelPath);
osgDB::writeNodeFile(*modelNode.get(), modelPathOut);
}
// This method creates a scene graph and keeps it around after the
destruction of a viewer.
// Then it creates a viewer and loads the model. You try this with both the
unoptimized ive and the
// optimized one. It runs the viewer waits for you to look at the model and
then hit esc to quit.
// Then it destroys the viewer, and creates another one using the same scene
graph.
// You'll notice that the scene no longer has textures.
TEST(test_osgKeepSceneGraphAround)
{
std::string modelPath = testDataDir();
modelPath += "testTree\\Test_tree_optimized.ive";
// create a scene graph (and keep it around).
osg::ref_ptr modelNode = osgDB::readNodeFile(modelPath);
// create viewer1 and set the scene graph data.
osgViewer::Viewer* viewer1 = new osgViewer::Viewer;
viewer1->setUpViewOnSingleScreen(0);
viewer1->setSceneData(modelNode.get());
viewer1->setCameraManipulator(new osgGA::TrackballManipulator());
// render
viewer1->realize();
while(!viewer1->done())
{
viewer1->frame();
}
// delete viewer1.
delete viewer1;
viewer1 = 0;
// create viewer2 and set the scene graph data.
osgViewer::Viewer* viewer2 = new osgViewer::Viewer;
viewer2->setUpViewOnSingleScreen(0);
viewer2->setSceneData(modelNode.get());
viewer2->setCameraManipulator(new osgGA::TrackballManipulator());
// render
viewer2->realize();
while(!viewer2->done())
{
viewer2->frame();
}
// delete viewer2.
delete viewer2;
viewer2 = 0;
}
___
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] Update callbacks occur in between calls to glBegin and glEnd?
Hi,
I was wondering if update callbacks are suppose to occur in between
calls to glBegin and glEnd? I think this test code demonstrates that
they do.
I'm using a glGet command (in this case glGetIntegerv) and checking for
it's error code. From the open GL docs:
"GL_INVALID_OPERATION is generated if glGet is executed between the
execution of glBegin and the corresponding execution of glEnd."
I'm making that call inside the update callback and getting that error,
suggesting that the update callback occurs somewhere in between a
glBegin and glEnd. Is this correct?
Thanks,
Brett
class TestUpdateCallback : public osg::NodeCallback
{
public:
void operator()(osg::Node* node, osg::NodeVisitor* nv)
{
// Clear any previous error.
GLenum eError = glGetError();
// Make the call that will generate a new error.
int maxUnits;
glGetIntegerv(GL_MAX_TEXTURE_UNITS,&maxUnits);
// Check the error
eError = glGetError();
if(eError == GL_INVALID_OPERATION)
{
std::cout << "TestUpdateCallback: This update callback
occurs in between glBegin and glEnd." << std::endl;
}
// Continue traverse.
traverse(node,nv);
}
};
main()
{
std::string modelPath = testDataDir();
modelPath += "cow.osg";
osg::ref_ptr modelNode = osgDB::readNodeFile(modelPath);
modelNode->setUpdateCallback(new TestUpdateCallback);
osg::ref_ptr viewer = new osgViewer::Viewer;
viewer->setUpViewOnSingleScreen(0);
viewer->setSceneData(modelNode.get());
viewer->setCameraManipulator(new osgGA::TrackballManipulator());
viewer->run();
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] FLT writer and PositionAttitudeTransform
Paul, The attached file demonstrates the bug with PositionAttitudeTransform if you convert it to FLT. View it in wireframe to see the problem. John From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Wednesday, August 20, 2008 10:03 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] FLT writer and PositionAttitudeTransform Sounds like a bug. You can fix it yourself and submit a change, or post a .osg file that can be ran through osgconv to repro the issue. I'll add it to my queue, or maybe someone else will chip in and fix it. I do recall PAT was someone difficult to support during FLT export. -Paul From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Argentieri, John-P63223 Sent: Wednesday, August 20, 2008 3:00 PM To: [EMAIL PROTECTED] Subject: [osg-users] FLT writer and PositionAttitudeTransform All, I've built a little cube and placed it on the surface of a big square using PositionAttitudeTransform. No surprise that this works great during runtime in OSG 2.6. Then, I make a call to osgDB::writeNodeFile and save it as both IVE and FLT. In the IVE file, it looks just like it did during runtime. BUT, in the FLT file, it looks like it breaks the order of rotate/translate operations and flops the little cube way off the surface of the big square. Any thoughts? Thanks, John Argentieri Software Engineer GENERAL DYNAMICS C4 Systems (407) 281-5568 [EMAIL PROTECTED] "This email message is for the sole use of the intended recipient(s) and may contain GDC4S confidential or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not an intended recipient, please contact the sender by reply email and destroy all copies of the original message." Test.osg Description: Test.osg ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DAE to OSG/IVE conversion problem when vertex areshared (OSG 2.4)
Hi Fabien, The best way to go about supporting shared arrays in .ive is to implement a similar scheme that is currently used for Nodes, Drawables, StateSet and StateAttributes in the .ive. The scheme involves writing out an id with the array, and then later places where that array is used the id is written out in its place. A map within the plugin is used to keep track of id's and associated objects for both reading and writing. In implementing such a scheme for arrays one will need to make sure that backwards compatibility is achieved by versioning the new code carefully. Robert. On Thu, Aug 21, 2008 at 10:53 AM, Fabien Dachicourt <[EMAIL PROTECTED]> wrote: > Hi Robert, > Thank you for your answer, > > If shared vertex array are not common, it seems not necessary to support > them in IVE, > but in such case, maybe the DAE driver should not load meshes as shared > vertex array. > > Maybe the best option is to update writers not supporting shared array : > Now, in those writers, for all geometries sharing an array, a deep copy of > the shared array is made for each geometry. > In writers not supporting shared arrays, geometries could keep only array > elements which are needed, rather than copying all the array. > > According to you, what is the best option ? > > Fabien > > - Original Message - From: "Robert Osfield" > <[EMAIL PROTECTED]> > To: "OpenSceneGraph Users" > Sent: Tuesday, August 12, 2008 9:07 PM > Subject: Re: [osg-users] DAE to OSG/IVE conversion problem when vertex > areshared (OSG 2.4) > > >> Hi Fabien, >> >> I suspect there is a couple of issues here. First up .ive doesn't >> support sharing of vertex arrays, it's not a particular common need >> which is probably why no one else has highlighted this requirement or >> step forward to implement. Adding won't be particularly difficult as >> sharing of Nodes, Drawables and State is already supported, but it'll >> require a increment of the ive version internal number/and careful >> handling of backwards compatibility. Same applies to .osg. Feel free >> to dive in and help implement it. >> >> The other issue is that your .dae model is just 3Mb while the output >> .ive is 250Mb, this screams to me that you have shared arrays in >> separate geometry, whereas your model really should be setup as a >> small number of geometry without shared arrays. I haven't had a >> chance to look at your model - I have a full inbox so am just skimming >> right now, but I'd suggest you have a look at how many primitives are >> in each geometry. >> >> Robert. >> >> On Mon, Aug 11, 2008 at 11:48 AM, Fabien Dachicourt <[EMAIL PROTECTED]> >> wrote: >>> >>> Hi all, >>> Using osgconv on some DAE models to procude IVE files sometimes really >>> increase the vertex count (and file size) >>> I'm not talking about texture problem, but about geometry and vertex. >>> >>> It seems the problem appear when vertex arrays are shared in the DAE >>> model >>> (in a mesh entity) between several geomerties using distinct materials. >>> When the DAE file is loaded in OSG, it seems ok, it looks like everything >>> remains shared. >>> But when we write the node (to IVE or OSG for instance, but it seems it >>> appears in other formats too), the shared vertex array seems duplicated >>> for >>> each geometry, including useless vertex : it dramatically increase the >>> object size (from 3 Mb to 250 Mb in my example). >>> >>> Using "osgconv --simplify 1", we remove useless vertex and the problem is >>> almost solved. >>> >>> Regarding this problem, I'm wondering if there is something to improve in >>> OGS : >>> - To support shared vertex arrays (and normals/textures arrays..) between >>> geodes in OSG or IVE format >>> - To remove any useless array element when writing nodes >>> >>> See this example, >>> http://spaceyes.nerim.net/sample/sample_dae.zip >>> >>> Thanks in advance for your answers, >>> Fabien >>> ___ >>> 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
Re: [osg-users] DAE to OSG/IVE conversion problem when vertex areshared (OSG 2.4)
Hi Robert, Thank you for your answer, If shared vertex array are not common, it seems not necessary to support them in IVE, but in such case, maybe the DAE driver should not load meshes as shared vertex array. Maybe the best option is to update writers not supporting shared array : Now, in those writers, for all geometries sharing an array, a deep copy of the shared array is made for each geometry. In writers not supporting shared arrays, geometries could keep only array elements which are needed, rather than copying all the array. According to you, what is the best option ? Fabien - Original Message - From: "Robert Osfield" <[EMAIL PROTECTED]> To: "OpenSceneGraph Users" Sent: Tuesday, August 12, 2008 9:07 PM Subject: Re: [osg-users] DAE to OSG/IVE conversion problem when vertex areshared (OSG 2.4) Hi Fabien, I suspect there is a couple of issues here. First up .ive doesn't support sharing of vertex arrays, it's not a particular common need which is probably why no one else has highlighted this requirement or step forward to implement. Adding won't be particularly difficult as sharing of Nodes, Drawables and State is already supported, but it'll require a increment of the ive version internal number/and careful handling of backwards compatibility. Same applies to .osg. Feel free to dive in and help implement it. The other issue is that your .dae model is just 3Mb while the output .ive is 250Mb, this screams to me that you have shared arrays in separate geometry, whereas your model really should be setup as a small number of geometry without shared arrays. I haven't had a chance to look at your model - I have a full inbox so am just skimming right now, but I'd suggest you have a look at how many primitives are in each geometry. Robert. On Mon, Aug 11, 2008 at 11:48 AM, Fabien Dachicourt <[EMAIL PROTECTED]> wrote: Hi all, Using osgconv on some DAE models to procude IVE files sometimes really increase the vertex count (and file size) I'm not talking about texture problem, but about geometry and vertex. It seems the problem appear when vertex arrays are shared in the DAE model (in a mesh entity) between several geomerties using distinct materials. When the DAE file is loaded in OSG, it seems ok, it looks like everything remains shared. But when we write the node (to IVE or OSG for instance, but it seems it appears in other formats too), the shared vertex array seems duplicated for each geometry, including useless vertex : it dramatically increase the object size (from 3 Mb to 250 Mb in my example). Using "osgconv --simplify 1", we remove useless vertex and the problem is almost solved. Regarding this problem, I'm wondering if there is something to improve in OGS : - To support shared vertex arrays (and normals/textures arrays..) between geodes in OSG or IVE format - To remove any useless array element when writing nodes See this example, http://spaceyes.nerim.net/sample/sample_dae.zip Thanks in advance for your answers, Fabien ___ 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] createGraphicContext pbuffer not working for me
Hi Philip,
I'm not a windows users so can't directly help, but can provide a few
things to look into.
First up, check that your hardware supports pbuffers.
Second up I very very strongly recommend upgrading to OSG-2.6, the API
changes between 2.0 and 2.6 are quite modest - most of the time you
should be able to just do a rebuild of your code. The benefit of this
upgrade is a lots of lots of bug fixes, and lots of performance
improvements and better features.
Once you've upgraded it also make it much easier for others to help
out as you'll be working from the same base, so problems that you have
will be reproducible by others.
Finally, you don't mention anything about the hardware and drivers you
are using - this has a huge baring on the capabilities of your system
and the effect it'll have on functionality/bugs (i.e. driver bugs).
Robert.
On Thu, Aug 21, 2008 at 5:59 AM, Tessier, Philip <[EMAIL PROTECTED]> wrote:
> All,
>
> I submitted the following (as "Off-screen rendering") some time ago (and
> received helpful replies - Thank you), but I have yet to get this working
> correctly. I have been digging into how this works, and I hopefully can ask
> my question so as to illicit whatever bit of knowledge I am lacking...
>
> In order to capture an image to an off-screen buffer, I'm using the following
> (which has been carved down for clarity):
>osg::ref_ptr traits = new
> osg::GraphicsContext::Traits;
>...
>traits->pbuffer = true;
>osg::GraphicsContext* _gc=
> osg::GraphicsContext::createGraphicsContext(traits.get());
>
> But, this fails every time. I'm using Win32.
>
> I came across
> http://www.openscenegraph.org/projects/osg/wiki/Community/Tasks/osgViewer
> tonight, (last updated 6th June 2007), which includes, as future work,
> "Support for pbuffers under Win32, X11 and Carbon."
>
> I'm currently using OSG 2.0. Was pbuffer support present in Win32
> implementation in OSG 2.0?
>
> Thanks,
> Phil
>
> Philip A. Tessier
> Northrop Grumman IT
> [EMAIL PROTECTED]
>
>
> Previous thread follows:
>
> From: osg-users-bounces lists.openscenegraph.org [mailto:[EMAIL
> PROTECTED] On Behalf Of Rafa Gaitan
> Sent: Sunday, April 27, 2008 4:53 PM
> To: [EMAIL PROTECTED]; OpenSceneGraph Users
>
> Subject: Re: [osg-users] Off-screen rendering
>
> Hi Philip and xbee
>
> We have this code and is working for us:
>
>osg::ref_ptr traits = new
> osg::GraphicsContext::Traits;
>traits->x =x;
>traits->y = y;
>traits->width = width;
>traits->height = height;
>traits->windowDecoration = false;
>traits->doubleBuffer = false;
>traits->sharedContext = 0;
>traits->pbuffer = true;
>
>osg::GraphicsContext* _gc=
> osg::GraphicsContext::createGraphicsContext(traits.get());
>
>if (!_gc)
>{
>osg::notify(osg::NOTICE)<<"Failed to create pbuffer, failing back to
> normal graphics window."<
>traits->pbuffer = false;
>_gc = osg::GraphicsContext::createGraphicsContext(traits.get());
>}
>v->getCamera()->setGraphicsContext(_gc);
>v->getCamera()->setViewport(new osg::Viewport(x,y,width,height));
>
> v is an osgViewer::Viewer.
>
> Hope this helps.
>
>
>
> On Sun, Apr 27, 2008 at 7:49 PM, xbee
> wrote:
>
> Tessier, Philip a écrit :
>
>> My attempt to use createGraphicsContext() to create an off-screen
>> rendering context is failing. (It's returning NULL.)
>>
>> I'm using Win32.
>>
>> What am I missing?
>>
>> I have added the following to my code:
>> osg::GraphicsContext * GetOffscreenGraphicsContext(
>> unsigned a_tex_width,
>> unsigned a_tex_height
>> )
>> {
>> osg::ref_ptr traits=new
>> osg::GraphicsContext::Traits;
>>
>> traits->width = a_tex_width;
>> traits->height = a_tex_height;
>> //traits->doubleBuffer = true;
>> traits->pbuffer = true;
>>
>> osg::ref_ptr
>> gc=osg::GraphicsContext::createGraphicsContext(traits.get());
>> // TODO: Above returning NULL!
>>
>> return gc.get();
>> }
>>
>> with the following to hook it in:
>> // Setup camera for off-screen rendering.
>> osg::ref_ptr gc=
>> GetOffscreenGraphicsContext( tex_width, tex_height);
>> camera->setGraphicsContext(gc.get());
>>
>> Thanks,
>> Phil
>>
>
> ___
> 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] Particle system setInitialRotationalSpeedRange()
Hi Erik, osgParticle has hardly been touched between OSG-2.2 and 2.6. Use svn log to check which files have changed. Robert. On Thu, Aug 21, 2008 at 1:07 AM, Erik Johnson <[EMAIL PROTECTED]> wrote: > Hi all, > > It seems to me, back in the OSG 2.2.x time frame, that I could set the > initial rotational velocity of the RadialShooter and have the particles > "pinwheel" around their center point, while maintaining their billboard > orientation and face the Camera. Perhaps it was a rotation on the "Y" > axis. > > Nowadays with OSG 2.4/2.6, setting the rotational speed will cause the > particles to rotate relative to the world axis and not in the > camera-relative axis. > > Is this a bug? A feature? Is it still posible to "pinwheel" a particle > around? Does anyone use setInitialRotationalSpeedRange()? > > This was a cool effect which added a nice dimension to smoke plumes and > such. > > Thanks for any info! > -Erik Johnson > > > ___ > 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] Performance of osgdem generated databases using --terrain
Hi Jason, It does sounds like you are hitting problems with texture download. When using osgTerrain the texturing should be the same as when using just osg::Geometry/osg::StateSet based paged databases. The only difference I can spot would be the setting of anisotropic filtering on the textures, perhaps the Intel hardware is having problems with this. To test this possibility out, comment out the following line of src/osgTerrain/GeometryTechnique.cpp (line 690 in OSG-2.6/svntrunk): texture2D->setMaxAnisotropy(16.0f); It'd also be worth checking how texture memory you have available. Robert. On Wed, Aug 20, 2008 at 10:28 PM, Jason Beverage <[EMAIL PROTECTED]> wrote: > Hi all, > > More integrated graphics woes for me today. I'm working with an Intel 945GM > graphics card and trying to load a terrain database generated with > --terrain. Robert, your suggestion of disabling VBO programatically worked > great for getting the machine to stop crashing. For some reason, the > machine only crashes if I loaded in some polygonal feature data as well as > the terrain database unless I disable VBO. > > The issue I'm facing now is that the performance of the terrain database is > terrible on this machine. A database generated without the --terrain option > works really well, but takes a long time to build. > > When I move around in my application or in osgviewer, I get huge frame > hiccups (up to 2 seconds sometimes) when tiles are being paged in. The > interesting thing is that this only happens if I have texturing turned on. > If I hit 't' in osgviewer to disable texturing, tiles come in just fine. > I've also noticed that if I turn texturing off for just the high resolution > ortho imagery on my database (layer 0) but leave on my lower resolution map > (layer 1) that thigns run smoothly. > > I've tried reducing the sample ratio as Robert has suggested using an > osgTerrain::Terrain decorator as well, and this doesn't help the hiccups as > they seem to be related to the textures. > > I suspected that I was maybe hitting a texture memory limit, but I don't > understand why a database generated without the --terrain option would work > well since they should be using the same imagery for the tiles. > > Does anyone have any more suggestions to try to get this amazing graphics > card chugging along?:) > > Thanks for everyones help on this, > > Jason > > ___ > 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] Creating custom wrappers for osgIntrospection
Hi Mike, I've been updating the svn version of genwrapper, so grab svn/trunk if you want the latest. I'll will update the tarball as well. Robert. On Wed, Aug 20, 2008 at 9:06 PM, Mike Wozniewski <[EMAIL PROTECTED]> wrote: > Hi, > > I have custom classes which extend OSG classes, and I'd like to create > wrapper libraries for use with osgIntrospection. Particularly, I'd like to > use these wrappers to call my custom methods from a GUI that doesn't need to > know a lot about the classes. > > I've found something called GenWrapper > (http://www.openscenegraph.org/projects/osg/wiki/GenWrapper), but it seems > to be quite old, pre-dating OSG 2.x. > > Does anyone have some sample code that creates wrapper libraries? > > Furthermore, does anyone have examples of custom classes which use > osgIntrospection? ... I'm having a hard time understanding the reflection > mechanism in OSG. Any examples would be appreciated. > > Also, I'd like to be compatible with both Linux and OSX. > > Thanks in advance, > Mike Wozniewski > ___ > 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
