Re: [osg-users] VBO and vertex attribute data
Hello Janna, If you use a shader program you'll have to bind the attributes to the program: const std::string name=v_tangent program-addBindAttribLocation(name, index); Then in the vertex shader you can access the attribute via: attribute vec3 v_tangent; hth Sebastian Hi, I am working on optimizing existing code for height field. I've enabled VBO for height field geometry which seems to make draw time faster however it seems can not retrieve vertex attribute data in the vertex shader anymore. Is there a special way of using VBO with geometry which has additional vertex attribute data set up? Data is set up on vertex attribute array with the index 15. Thank you! Cheers, Janna -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=50382#50382 ___ 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] dynamic multithreading problem
Hi,
I think the problem maybe located in my custom Drawable class. It draws text
geometry instead of textured quads (like in osgText::Test). It basicaly works
like Group with multiple transforms and geodes with character geometry. But I
really need it to be Drawable (structure of transform will be memory consuming
and I can attach it to Geode in the same way as I attach regular osgText::Text).
How it works:
My custom Drawable calls draw method of every character geometry in it, some
characters have program in their stateset so I have to call
state.apply(character_goemetry.getStateSet()); and that's where it crashes. Is
it legal to call state.apply in drawImplementation method ?
It crashes while drawing my custom Drawable in function drawImplementation()
while rendering its content like this:
Code:
// for each glyph in CustomTextDrawable
for (int i = 0; i itr-glyph-getNumDrawables(); ++i)
{
osg::Drawable* drawable = itr-glyph-getDrawable(i);
state.apply(drawable-getStateSet());
itr-glyph-getDrawable(i)-draw(renderInfo);
}
Stack trace:
Code:
msvcr90.dll!_crt_debugger_hook(int _Reserved=6676656) Line 65 C
msvcr90.dll!_invoke_watson(const wchar_t * pszExpression=0x, const
wchar_t * pszFunction=0x, const wchar_t * pszFile=0x, unsigned
int nLine=0, unsigned int pReserved=0) Line 230 + 0x7 bytes C++
msvcr90.dll!_invalid_parameter_noinfo() Line 125 + 0xc bytes C++
osg80-osgrd.dll!std::_Treestd::_Tset_traitsosg::Program::PerContextProgram
const *,std::lessosg::Program::PerContextProgram const
*,std::allocatorosg::Program::PerContextProgram const *,0
::const_iterator::_Inc() Line 391 + 0x2 bytes C++
osg80-osgrd.dll!std::_Distance2std::_Treestd::_Tset_traitsosg::Program::PerContextProgram
const *,std::lessosg::Program::PerContextProgram const
*,std::allocatorosg::Program::PerContextProgram const *,0
::const_iterator,unsigned
int(std::_Treestd::_Tset_traitsosg::Program::PerContextProgram const
*,std::lessosg::Program::PerContextProgram const
*,std::allocatorosg::Program::PerContextProgram const *,0 ::const_iterator
_First=0x {_program=??? _extensions={...} _glProgramHandle=??? ...},
std::_Treestd::_Tset_traitsosg::Program::PerContextProgram const
*,std::lessosg::Program::PerContextProgram const
*,std::allocatorosg::Program::PerContextProgram const *,0 ::const_iterator
_Last=0x0a4ecc80 {_program=??? _extensions=??? _glProgramHandle=??? ...},
unsigned int _Off=5, std::bidirectional_iterator_tag __formal={...}) Line
1859 + 0xb bytes C++
osg80-osgrd.dll!std::_Treestd::_Tset_traitsosg::Program::PerContextProgram
const *,std::lessosg::Program::PerContextProgram const
*,std::allocatorosg::Program::PerContextProgram const *,0 ::count(const
osg::Program::PerContextProgram * const _Keyval=) Line 999 C++
osg80-osgrd.dll!osg::State::setLastAppliedProgramObject(const
osg::Program::PerContextProgram * program=0x006367c8) Line 1257 + 0x17 bytes
C++
osg80-osgrd.dll!osg::Program::apply(osg::State state={...}) Line 460 + 0x8
bytes C++
osg80-osgrd.dll!osg::State::applyAttribute(const osg::StateAttribute *
attribute=0x00624350, osg::State::AttributeStack as={...}) Line 1598 C++
osg80-osgrd.dll!osg::State::applyAttributeList(std::mapstd::pairenum
osg::StateAttribute::Type,unsigned
int,osg::State::AttributeStack,std::lessstd::pairenum
osg::StateAttribute::Type,unsigned int
,std::allocatorstd::pairstd::pairenum osg::StateAttribute::Type,unsigned
int const ,osg::State::AttributeStack
attributeMap=[10](((MATERIAL,0),{changed=false
last_applied_attribute=0x088a6708 last_applied_shadercomponent=0x
...}),((LIGHT,0),{changed=false last_applied_attribute=0x00654f60
last_applied_shadercomponent=0x ...}),((POINT,0),{changed=false
last_applied_attribute=0x097a9bd0 last_applied_shadercomponent=0x
...}),...,...), const std::mapstd::pairenum
osg::StateAttribute::Type,unsigned
int,std::pairosg::ref_ptrosg::StateAttribute,unsigned
int,std::lessstd::pairenum osg::StateAttribute::Type,unsigned int
,std::allocatorstd::pairstd::pairenum osg::StateAttribute::Type,unsigned
int const ,std::pairosg::ref_ptrosg::State
Attribute,unsigned int
attributeList=[1](((PROGRAM,0),({_ptr=0x00624350 },0 Line 2298 + 0xb bytes
C++
osg80-osgrd.dll!osg::State::apply(const osg::StateSet * dstate=0x059685c0)
Line 512C++
MyApp.exe!MyApp::CustomTextDrawable::drawImplementation(osg::RenderInfo
renderInfo={...}) Line 87C++
osg80-osgrd.dll!osg::Drawable::draw(osg::RenderInfo renderInfo={...}) Line
914 + 0xa bytes C++
osg80-osgUtilrd.dll!osgUtil::RenderBin::drawImplementation(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x0a344880) Line 460 C++
osg80-osgUtilrd.dll!osgUtil::RenderBin::drawImplementation(osg::RenderInfo
renderInfo={...}, osgUtil::RenderLeaf * previous=0x0a344880) Line 509 + 0x37
bytes C++
Re: [osg-users] glslDevil
Hi, On Tuesday, October 02, 2012 14:01:59 Chris Hanson wrote: Does anyone here on the list know any of the folks involved in the glslDevil project: http://www.vis.uni-stuttgart.de/glsldevil/ This seems to be one of the few prospects for a cross-platform (Linux and Windows anyway) GLSL source-level debugging tool. It was not released as open-source, but is a free download, and seems like it is getting neglected now. I'd like to contact the creators and see about open-sourcing it and maybe updating it a bit. Is anyone else interested in helping? Do we have any other Germans, especially academics who might help me contact and talk to uni-stuttgart? I have some interest in the project from an American university who might help keep the project alive. May be you can take a look at apitrace. The sources are available at git://github.com/apitrace/apitrace.git and that is and stays open source. Greetings Mathias ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] glslDevil
May be you can take a look at apitrace. The sources are available at git://github.com/apitrace/apitrace.git and that is and stays open source. Thanks. To me, APItrace looks functionally similar to gDebugger. GLSLdevil is a whole different class of GLSL debugging. Greetings Mathias ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://www.alphapixel.com/ Training • Consulting • Contracting 3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 • GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL Digital Imaging • GIS • GPS • Telemetry • Cryptography • Digital Audio • LIDAR • Kinect • Embedded • Mobile • iPhone/iPad/iOS • Android ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] bumpmapping and tangentspacegenerator, generating tangents
Dear OSG users, I am trying to develop bump mapping using opengl es 2.0 and openscenegraph. I can't use osgFX because of opengl es 2.0. I have to apply a bump map to an obj that has the map embedded in the MTL. The mtl is like this: newmtl Nuovo Kd 0.80 0.80 0.80 illum 2 Ns 50.781250 map_bump PINKGRA2_NRM.JPG map_Kd PINKGRA2.JPG I read the obj using the options string: osg::ref_ptrosgDB::ReaderWriter::Options options = new osgDB::ReaderWriter::Options; options-setOptionString(DIFFUSE=0 BUMP=1); To generate the tagents I use tangentspacegenerator. osg::ref_ptr osgUtil::TangentSpaceGenerator tsg = new osgUtil::TangentSpaceGenerator; tsg-generate( geo , 1); However this is not working!!! The application crashes with a bad access! Instead, if I use tsg-generate( geo, 0) then it is working! However in this case I think it is using the diffuse map to generate the tangents, which I think is bad! The tangent space generator is created and applied inside a nodevisitor. I am almost sure everything is bound correctly. #define NORMAL_ATTR_UNIT 2 #define TANGENT_ATTR_UNIT 9 #define NORMAL_TEX_UNIT 1 #define TEX_UNIT 0 _programBumpMapping-addBindAttribLocation( a_tangent, TANGENT_ATTR_UNIT ); _programBumpMapping-addBindAttribLocation( a_normal, NORMAL_ATTR_UNIT ); ssRoot-setAttributeAndModes( _programBumpMapping, osg::StateAttribute::ON ); ssRoot-addUniform(new osg::Uniform(osg::Uniform::SAMPLER_2D, u_TextureMap, TEX_UNIT)); ssRoot-addUniform(new osg::Uniform(osg::Uniform::SAMPLER_2D, u_NormalMap, NORMAL_TEX_UNIT)); Can you please help me to understand why with 0 works and with 1 I have a bad access? Kind Regards, John -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=50387#50387 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VBO and vertex attribute data
This is being done and as I mention it works fine unless I try to use vertex buffer object. so lets say code like this works: Code: geometry-setVertexAttribArray(s_attributeIndex, m_vertexAttributes.get()); geometry-setVertexAttribBinding(s_attributeIndex, osg::Geometry::BIND_PER_VERTEX); geometry-setVertexAttribNormalize(s_attributeIndex, GL_FALSE); but I can not access custom attribute in the shader anymore with the code like this: Code: geometry-setUseVertexBufferObjects(true); geometry-setVertexAttribArray(s_attributeIndex, m_vertexAttributes.get()); geometry-setVertexAttribBinding(s_attributeIndex, osg::Geometry::BIND_PER_VERTEX); geometry-setVertexAttribNormalize(s_attributeIndex, GL_FALSE); s_attributeIndex is 15. Cheers, Janna -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=50388#50388 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenGL 3.2 support in OS X 10.7 (Lion)
Robert, Paul, et. al: Has any further discussion or work gone into adding proper VAO support to OSG? I'm interested in contributing if I can, mostly because I'd like to see full 3.2 support for OS X. Craig On Mon, Mar 5, 2012 at 8:22 AM, Robert Osfield robert.osfi...@gmail.com wrote: Hi David, On 4 March 2012 20:55, David Garcia da...@aimsun.com wrote: Yes, I think so too. Unfortunately Apple decides that a VAO is required. I can fill a radar and ask in the developer forums but, for now, what is the best solution? The think that we should implement proper VAO support. I'm not familiar with this new feature yet, but would guess that it should probably sit in osg::Array and osg::BufferData. I'm open to suggestions. 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] VBO and vertex attribute data
Hi, I've tried to use gl_MultiTexCoord1 and do geometry-setTexCoordArray(1, secondTexCoords); instead of custom vertex attributes to pass my data and it seems to be working. Does anyone know if there is some kind of problem with using custom vertex attributes ( using methods like setVertexAttribArray ) and VBOs? Cheers, Janna -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=50390#50390 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenGL 3.2 support in OS X 10.7 (Lion)
Hi Craig -- as far as I know, no one is using vertex array objects with OSG. I am using OSG built for GL3 in an external OpenGL 3/4 project, but for file loading only, not for rendering. (The external project requires OSG built for GL3 in order to avoid including both gl.h and gl3.h in the same source.) I'm using OSG svn trunk HEAD for this, and it works great on both Windows and OSX (not yet tested on Linux). But the external project does the rendering, not OSG, so my work here doesn't help you with OSG's current lack of VAO support. I think it'd be great to have VAO support in OSG. You might want to post some design ideas here for discussion, and review by Robert (as it would involve changes to core OSG). -Paul On 10/3/2012 9:45 AM, Craig Bosma wrote: Robert, Paul, et. al: Has any further discussion or work gone into adding proper VAO support to OSG? I'm interested in contributing if I can, mostly because I'd like to see full 3.2 support for OS X. Craig On Mon, Mar 5, 2012 at 8:22 AM, Robert Osfieldrobert.osfi...@gmail.com wrote: Hi David, On 4 March 2012 20:55, David Garciada...@aimsun.com wrote: Yes, I think so too. Unfortunately Apple decides that a VAO is required. I can fill a radar and ask in the developer forums but, for now, what is the best solution? The think that we should implement proper VAO support. I'm not familiar with this new feature yet, but would guess that it should probably sit in osg::Array and osg::BufferData. I'm open to suggestions. 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 mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Bug in Qt thread integration
Hi, Thanks for the replies and suggestions. I think I might not have explained the issue as well as I thought, so I'll try again. QThread::currentThread does return a value with static type QThread*. However, it might not point to a QThread instance, but an instance of a subclass of QThread. The problem is that OpenThreads assumes that the return value can be cast to a pointer to a specific subclass of QThread that OpenThreads defines, QtThreadPrivateData, like this: Code: QtThreadPrivateData* pd = static_castQtThreadPrivateData*(QThread::currentThread()); This is a problem because if the current thread is a different subclass of QThread, this cast is invalid so when the new pointer (pd) is used, it causes a seg fault or random behavior. We have observed in our application that this does in fact sometimes occur. Specifically, QThread::currentThread can return a QAdoptedThread*, which is legal since QAdoptedThread is a subclass of QThread. I hope this clarifies things. Thank you! Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=50392#50392 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgPPU::Processor and other root's children traversing order
Hello. I am working on osgPPU but there are some things i haven't completely understood yet. I add 2 children in root's group. A cow model and the osgPPU::Processor. In processor i have added 1 child which outputs the depth buffer and under that child i have added 1 child which outputs to frame buffer. I have noticed that the order of root-addChild(loadedModel); root-addChild(ppu); doesnt matter and i am wondering why. UnitCameraAttachmentBypass needs the depth buffer which is taken from camera. But if ppu is rendered first (as first child) there will be no depth buffer to output to frame buffer (through UnitCameraAttachmentBypass's child, which is UnitOut). Why is this happening ? do i miss something? The scene graph is the following root ppu UnitCameraAttachmentBypass (outputs Depth) UnitOut loadedModel Thank you for your time. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgPPU::Processor and other root's children traversing order
Hiiirc ppu stuff does it things at a renderbin 100. Cheers. 03.10.2012, 23:42, "Peterakos" hay...@gmail.com:Hello.I am working on osgPPU but there are some things i haven't completely understood yet.I add 2 children in root's group.A cow model and the osgPPU::Processor.In processor i have added 1 child which outputs the depth buffer and under that child i have added 1 child which outputs to frame buffer.I have noticed that the order of root-addChild(loadedModel);root-addChild(ppu);doesnt matter and i am wondering why.UnitCameraAttachmentBypass needs the depth buffer which is taken from camera. But if ppu is rendered first (as first child) there will be no depth buffer to output to frame buffer (through UnitCameraAttachmentBypass's child, which is UnitOut).Why is this happening ? do i miss something?The scene graph is the followingroot ppu UnitCameraAttachmentBypass (outputs Depth) UnitOut loadedModelThank you for your time.,___osg-users mailing listosg-users@lists.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
[osg-users] Backward compatibility with custom serializers
Hi, I recently added serialization support for a custom osg::Object derived class in my application. I saved the object to a osgt and osgb file and attempted to load it into an older version of my application, which didn't have serialization support for my custom object yet. Loading the osgt file gives me the following warning message: InputStream::readObject(): Unsupported wrapper class MyLibrary::MyObject This is expected. However, when I attempt to load the osgb file I get the following output then my application crashes: InputStream::readObject(): Unsupported wrapper class MyLibrary::MyObject InputStream::readObject(): Unsupported wrapper class Before I spend time looking into this, I was wondering if it is expected for the binary loader to crash on unsupported objects? I'm working with osg 2.9.12, if that makes a difference. Cheers, Farshid ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osg::PPU , Texture unit associated with depth buffer
Hello In osgppu_ssao project in simple.h file, there are the following lines: shader-add(originalDepthTexture, osg::Uniform::SAMPLER_2D); shader-set(originalDepthTexture, 1); Where is the depth texture associated with texture unit 1 ? i couldnt find it anywhere. thnx. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
