Re: [osg-users] Projective Multi-Texturing
On Tue, Oct 23, 2012 at 8:40 PM, Jason Daly jd...@ist.ucf.edu wrote: How can TexGen and a shader help here? Would it allow me to calculate the UV coordinates for a given photo (camera position etc.) and the mesh? The more I think about it, the more I think you'll want to use a shader for this. The basis for your technique will be the EYE_LINEAR TexGen mode that old-fashioned projective texturing used, so you'll probably want to read up on that. There's some sample code written in pure OpenGL here: http://www.sgi.com/products/software/opengl/examples/glut/advanced/source/projtex.c The equation used for EYE_LINEAR TexGen is given in the OpenGL spec. You can also find it in the man page for glTexGen, available here: http://www.opengl.org/sdk/docs/man2/xhtml/glTexGen.xml Thanks for the hints. From browsing the documentation it seems though that this would also texture non-visible triangles (i.e backfacing triangles)? This however would lead to messy texturing, since I have photos from around the mesh. Once you're familiar with that technique, you'll probably be able to come up with a specific technique that works better for your situation. Another benefit of using shaders is that you'll be able to do any blending, exposure compensation, etc. that you might be needing to do really easily as part of the texturing process. I think I'd need a starter sample for how to use EYE_LINEAR in combination with a shader. You might not need to segment the mesh. If you don't segment the mesh, it means that you'll have to have all of your photo textures active at the same time. Most modern graphics cards can handle at least 8, decent mid range gaming cards can handle as many as 64, and the high-end enthusiast cards can even hit 128. If you're photo count is less than this number for your hardware, you'll probably be OK. You'll just need to encode which photo or photos are important for each vertex, so you can look them up in the shader, you'd do this as a vertex attribute. Since ReconstructMe itself requires a decent graphics card we are ok with that approach. I assume that there won't be more than 64 fotos per mesh and I assume that a vertex would never be textured from more than 3 fotos. Your photo texture samplers will be one set of uniforms, and you'll need another set to encode the photo position and orientation, as these will be needed to calculate the texture coordinates. You won't need to pass texture coordinates as vertex attributes, because you'll be generating them in the vertex shader. As long as you don't have more than a few photos per vertex, you shouldn't have any issues with the limited number of vertex attributes that can be passed between shader stages. That sounds interesting. You don't have an example at hands? A rather related problem is the export of meshes. Using the shader approach, how would one deliver such a textured mesh? Wouldn't it make more sense to pre-calucate the UV coordinates for each vertex/foto infront (incl. visibility detection) and pass this to the shader (possible?), so that I could decide on file export (based on the format chosen) to either - split the mesh if the format does not support multiple texture layers (.ply/.obj maybe). - don't split the mesh if the format supports multiple layers (.fbx) Thanks for your time, Christoph ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] custom vertex attribut, using BIND_OVERALL
Hi all
I want to pass a custom vertex attribute (lets say a material code) to my
vertex shader.
For the moment I use BIND_PER_VERTEX:
Code:
int l_SMC = 1027; // some material code
for (unsigned int i=0; ia_geode.getNumDrawables(); ++i)
{
osg::Geometry* l_Geom = a_geode.getDrawable(i)-asGeometry();
if (l_Geom)
{
osg::Array* l_VertexArray = l_Geom-getVertexArray();
if (l_VertexArray)
{
unsigned int vertex_count = l_VertexArray-getNumElements();
osg::IntArray* l_Array = new osg::IntArray;
for (int v=0; vvertex_count; v++)
{
l_Array-push_back(l_SMC);
}
l_Geom-setVertexAttribArray(6, l_Array);
l_Geom-setVertexAttribNormalize(6, false);
l_Geom-setVertexAttribBinding(6, osg::Geometry::BIND_PER_VERTEX);
}
}
}
Since the material code is unique within geometries, so actually I would need
to transfer it only once per Geometry. If I change to BIND_OVERALL, the data is
no longer transferred, or at least my shader cannot detect it anymore. I
thought i should maybe reduce the VertexAttribArray (l_Array) to one single
entry, but this doesn't work either.
What is the correct way of passing general or common data, on a per geometry
(and not vertex) basis?
Regards
Daniel
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=50745#50745
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] custom vertex attribut, using BIND_OVERALL
Hi all
I want to pass a custom vertex attribute (lets say a material code) to my
vertex shader.
For the moment I use BIND_PER_VERTEX:
[code]
int l_SMC = 1027; // some material code
for (unsigned int i=0; ia_geode.getNumDrawables(); ++i)
{
osg::Geometry* l_Geom = a_geode.getDrawable(i)-asGeometry();
if (l_Geom)
{
osg::Array* l_VertexArray = l_Geom-getVertexArray();
if (l_VertexArray)
{
unsigned int vertex_count = l_VertexArray-getNumElements();
osg::IntArray* l_Array = new osg::IntArray;
for (int v=0; vvertex_count; v++)
{
l_Array-push_back(l_SMC);
}
l_Geom-setVertexAttribArray(6, l_Array);
l_Geom-setVertexAttribNormalize(6, false);
l_Geom-setVertexAttribBinding(6, osg::Geometry::BIND_PER_VERTEX);
}
}
}
[/code]
Since the material code is unique within geometries, so actually I would need
to transfer it only once per Geometry. If I change to BIND_OVERALL, the data is
no longer transferred, or at least my shader cannot detect it anymore. I
thought i should maybe reduce the VertexAttribArray (l_Array) to one single
entry, but this doesn't work either.
What is the correct way of passing general or common data, on a per geometry
(and not vertex) basis?
Regards
Daniel
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] custom vertex attribut, using BIND_OVERALL
Hi wouldnt it be better to use uniform in this case? Cheers. 24.10.2012, 13:28, "Daniel Schmid" daniel.sch...@swiss-simtec.ch:Hi all I want to pass a custom vertex attribute (lets say a material code) to my vertex shader. For the moment I use BIND_PER_VERTEX: [code]int l_SMC = 1027; // some material code for (unsigned int i=0; ia_geode.getNumDrawables(); ++i){ osg::Geometry* l_Geom = a_geode.getDrawable(i)-asGeometry(); if (l_Geom) { osg::Array* l_VertexArray = l_Geom-getVertexArray(); if (l_VertexArray) { unsigned int vertex_count = l_VertexArray-getNumElements(); osg::IntArray* l_Array = new osg::IntArray; for (int v=0; vvertex_count; v++) { l_Array-push_back(l_SMC); } l_Geom-setVertexAttribArray(6, l_Array); l_Geom-setVertexAttribNormalize(6, false); l_Geom-setVertexAttribBinding(6, osg::Geometry::BIND_PER_VERTEX); } }}[/code] Since the material code is unique within geometries, so actually I would need to transfer it only once per Geometry. If I change to BIND_OVERALL, the data is no longer transferred, or at least my shader cannot detect it anymore. I thought i should maybe reduce the VertexAttribArray (l_Array) to one single entry, but this doesn't work either. What is the correct way of passing general or common data, on a per geometry (and not vertex) basis? RegardsDaniel,___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
Re: [osg-users] custom vertex attribut, using BIND_OVERALL
When I would use uniforms, I cannot set different values for different geometries. Uniforms are global for a particular stateset. So I HAVE to use vertex attributes, since in my shader I want to treat some particular surface in a special way, but without the need of separate stateset. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=50748#50748 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Custom CullingVisitor
Hi, In my application, I use a custom CullVisitor, this way : osgUtil::CullVisitor::prototype() = new MyCustomCullVisitor(); But this affects all viewers in my application. Is there anyway to explicitly set a custom CullVisitor on a specific osgViewer::Viewer ? I would like to use twos different CullVisitor for two different viewers. Thank you! Cheers, Aurelien -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=50750#50750 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] custom vertex attribut, using BIND_OVERALL
Hi Daniel, you are right, with BIND_OVERALL and just one element in the array, OSG should apply the single attribute to all vertices of the geometry. You can check this behavior in Geometry.cpp searching for BIND_OVERALL. Also there is the createTexturedQuadGeometry() function which does setup a geometry like you want, so check it out if you do it the same way. If it does not work, try to put a breakpoint into Geometry.cpp and debug to see what happens. As you say, setting Uniforms requires a state change, while with an attribute the rendering is done at the GPU completely. Thank you! Cheers, Tassilo -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=50751#50751 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] custom vertex attribut, using BIND_OVERALL
Hi As you say, setting Uniforms requires a state change, while with an attribute the rendering is done at the GPU completely. it is kind of same both ways... here you need glUniform* call, there you need to bind vertex attrib and call glVertexAttribPointer* and rendering is done at the GPU completely no matter what way you choose. Cheers. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] custom vertex attribut, using BIND_OVERALL
Hi, I think OpenGL specs doesn't allow to share a vertex attribute values between multiple vertices. Aurelien -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=50753#50753 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] [Tutorial] Building osgAndroidExampleGLES1/2 on Ubuntu 11.10
Hi samfan, I tried it again with the updated SDKs and NDKs, using SDK r20 and NDK r8b. What I think is that it's a change in the NDK that brings on this error. I got it to build (and work without linker errors) by modifying the file jni/osgNativeLib.cpp by changing 3 lines: line 78: const char *nativeAddress = env-GetStringUTFChars(address, 0); line 87: const char *nativeAddress = env-GetStringUTFChars(address, 0); line 88: const char *nativeName = env-GetStringUTFChars(name, 0); for the rest i did everything the same as in the tutorial and it works for me. again, ymmv. Thank you! Cheers, Bernd -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=50754#50754 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [Android osgViewer] OpenGL ES context lost (how do i preserve it?)
Hi dev community, I'm working on an Android App based on the example AndroidExampleGLES1/2. In my case it's GLES1, but this problem persists in both GLES versions. The Problem occurs after the following steps (and it's easily reproducible): 1. run the android osgviewer app 2. load a model 3. put the android device to sleep (short press on power button) 4. wake up the android device 5. the model is gone. i know the error stems from losing the opengl context, which is then again created when the device is waking up again. so the obvious workaround/bugfix would be to preserve the opengl context. my problem is that i don't really know how to do this. i found a few more or less helpful comments on other web pages, but nothing to fix this particular problem yet. maybe someone can help me to fix this, i'd then be happy to somehow put this fix upstream (if that's possible) since that's a problem that persists in the example files. Thank you! Cheers, Bernd -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=50755#50755 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Uniform arrays not working for me using Visual Studio 2010
Hi,
I ported my program from mingw and Code Blocks to Visual Studio 2010 Express
and found that I couldn't get uniform arrays to work. Has anyone experienced
this? I'm new to Visual Studio so I might have missed something.
I made a small test program that works on my old system but not on my new
system:
(sorry for the weird symbols and that the include dirs fell off)
Code:
#include osg/Group
#include osgDB/ReadFile
#include osgViewer/Viewer
#include osgGA/TrackballManipulator
int main( int argc, char **argv )
{
osg::setNotifyLevel( osg::WARN );
osg::Group *root = new osg::Group;
std::string url = cow.osg;
osg::Node* modelNode = osgDB::readNodeFile( url );
//setup shaders
osg::Shader *vertshader = new osg::Shader( osg::Shader::VERTEX );
vertshader-loadShaderSourceFromFile( uniformarray.vert );
osg::Shader *fragshader = new osg::Shader( osg::Shader::FRAGMENT );
fragshader-loadShaderSourceFromFile( uniformarray.frag );
osg::Program *shaderprog = new osg::Program();
shaderprog-addShader( vertshader );
shaderprog-addShader( fragshader );
modelNode-getOrCreateStateSet()-setAttributeAndModes( shaderprog );
// Array uniform
osg::Uniform *arrayUFM = new osg::Uniform( osg::Uniform::FLOAT, array, 2
);
arrayUFM-setElement( 0, 0.5f );
arrayUFM-setElement( 1, 1.0f );
modelNode-getOrCreateStateSet()-addUniform( arrayUFM );
root-addChild( modelNode );
// Graphics Context and Traits
osg::ref_ptrosg::GraphicsContext::Traits traits = new
osg::GraphicsContext::Traits;
traits-x = 10;
traits-y = 10;
traits-width = 800;
traits-height = 600;
traits-doubleBuffer = true;
const std::string version( 3.1 );
traits-glContextVersion = version;
osg::ref_ptrosg::GraphicsContext gc =
osg::GraphicsContext::createGraphicsContext( traits.get() );
// Viewer
osg::ref_ptrosgViewer::Viewer viewer = new osgViewer::Viewer();
viewer-getCamera()-setGraphicsContext( gc.get() );
viewer-getCamera()-setViewport( new osg::Viewport( 0, 0, traits-width,
traits-height ) );
viewer-setSceneData( root );
viewer-setCameraManipulator( new osgGA::TrackballManipulator() );
viewer-run();
return 0;
}
Vertex shader:
Code:
#version 140
uniform mat4 osg_ModelViewProjectionMatrix;
in vec4 osg_Vertex;
void main()
{
gl_Position = osg_ModelViewProjectionMatrix * osg_Vertex;
};
Fragment shader using the array:
Code:
#version 140
uniform float array[2];
out vec4 fragData;
void main()
{
fragData = vec4( 1.0, array[0], array[1], 1.0 );
}
Old system:
OSG 3.0 (revision 12753)
MinGW and Code Blocks
NVIDIA GEFORCE 260
WIN 7
New system
OSG 3.0.1 (stable release)
Visual C++ 2010 Express
NVIDIA GEFORCE 680
WIN 7
Thank you!
Cheers,
David[/code]
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=50756#50756
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Projective Multi-Texturing
On 10/24/2012 03:03 AM, Christoph Heindl wrote: Thanks for the hints. From browsing the documentation it seems though that this would also texture non-visible triangles (i.e backfacing triangles)? This however would lead to messy texturing, since I have photos from around the mesh. Shouldn't be a problem if you don't render back faces (which is the default). The fragment shader won't even run for those pixels, as they'll already have been culled. Once you're familiar with that technique, you'll probably be able to come up with a specific technique that works better for your situation. Another benefit of using shaders is that you'll be able to do any blending, exposure compensation, etc. that you might be needing to do really easily as part of the texturing process. I think I'd need a starter sample for how to use EYE_LINEAR in combination with a shader. Here's a page from the nVidia Cg tutorial that talks about projective texturing, including the texture coordinate generation. The example code is in Cg, but it shouldn't be too hard to port to OpenGL (vec4 instead of float4, things like that). Best I could do in a few minutes. http://http.developer.nvidia.com/CgTutorial/cg_tutorial_chapter09.html If you Google around a bit, I'm sure you can find other examples. Your photo texture samplers will be one set of uniforms, and you'll need another set to encode the photo position and orientation, as these will be needed to calculate the texture coordinates. You won't need to pass texture coordinates as vertex attributes, because you'll be generating them in the vertex shader. As long as you don't have more than a few photos per vertex, you shouldn't have any issues with the limited number of vertex attributes that can be passed between shader stages. That sounds interesting. You don't have an example at hands? Afraid not, I've never actually done it myself :-) There is probably at least a basic example online somewhere, though. A rather related problem is the export of meshes. Using the shader approach, how would one deliver such a textured mesh? Wouldn't it make more sense to pre-calucate the UV coordinates for each vertex/foto infront (incl. visibility detection) and pass this to the shader (possible?), so that I could decide on file export (based on the format chosen) to either - split the mesh if the format does not support multiple texture layers (.ply/.obj maybe). - don't split the mesh if the format supports multiple layers (.fbx) Ah, yes. If you want to end up exporting the mesh, then a real-time shader might be a problem. It's not impossible, as there are formats like COLLADA that allow you to embed shaders, but from my experience, run-time systems don't often fully support those features. If you do need to export to a static format (like fbx), then I don't see a way around splitting the mesh. If your maximum photo count is 64, there's no way you can have all of the textures enabled and statically mapped at the same time (that would mean you'd need 64 sets of texture coordinates, and no graphics card supports that many vertex attributes). I think you'd need to do an initial pass to see which photos cover which vertices, then divide up the mesh accordingly. Only one (maybe two or three) textures will need to be active for each patch, which means you'd only need at most three sets of texture coordinates for each vertes. This should be exportable to one of several modern formats. Yes, you'll have some duplication of vertices along the boundaries, but this isn't really a huge problem. The vertex processing most likely isn't going to be your bottleneck here. Maybe someone smarter than me can come up with a solution that doesn't require splitting the mesh, but I don't see one... --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] custom vertex attribut, using BIND_OVERALL
On 10/24/2012 05:28 AM, Daniel Schmid wrote: Since the material code is unique within geometries, so actually I would need to transfer it only once per Geometry. If I change to BIND_OVERALL, the data is no longer transferred, or at least my shader cannot detect it anymore. I thought i should maybe reduce the VertexAttribArray (l_Array) to one single entry, but this doesn't work either. What is the correct way of passing general or common data, on a per geometry (and not vertex) basis? I don't think BIND_OVERALL is valid for generic attributes. Sergey's right, use a Uniform. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] custom vertex attribut, using BIND_OVERALL
Hi, sorry, I was wrong. It really seems the same in terms of state changes. A use case for a BIND_OVERALL attribute is probably that you have different types of geometry with and without individual attributes (for example color) in your scene that you want to render using the same shader. Thank you! Cheers, Tassilo -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=50759#50759 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] custom vertex attribut, using BIND_OVERALL
On Wed, Oct 24, 2012 at 12:37 PM, Sergey Polischuk pol...@yandex.ru wrote: Hi As you say, setting Uniforms requires a state change, while with an attribute the rendering is done at the GPU completely. it is kind of same both ways... here you need glUniform* call, there you need to bind vertex attrib and call glVertexAttribPointer* and rendering is done at the GPU completely no matter what way you choose. Actually, OSG could use one of the glVertexAttrib calls without binding anything. This is reputed to be a fast way to get per object data to a vertex shader. Tim Cheers. ___ 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] custom CompositeDragger and AntiSquish
Hi, I am trying to add a 2D box to my scene (consisting of lines 1 pixel wide) that a user can resize by dragging the sides or corners, or rotate by dragging a handle. I'm attempting to use the osgManipulator Dragger classes for this purpose. I created a subclass of CompositeDragger and added to it a Scale2DDragger (for the corners) and two Scale1DDraggers (for each pair of sides). Basically the code is a copy of the TabPlaneDragger without the TranslatePlaneDragger child dragger. I added the dragger to my scene using the osgManipulator example as a guide. My scene looks like this: Group | \ MatrixTransform CustomDragger | Geode (containing box geometry) and I call addTransformUpdating() on CustomDragger passing the MatrixTransform. The box resizes correctly when I drag the handles. A problem I am having is that the drag handles will not stay a constant size. If I drag the box so that one side is longer than the other, the handle boxes will have the same non-uniform scaling. I am using AutoTransform and AntiSquish in my code exactly the way TabPlaneDragger does to prevent this from happening, but for some reason it doesn't work in my code (although it works in the osgManipulator example). The only real difference in my code is that I set a rotation matrix in the CustomDragger, in order to draw the drag boxes in the XY plane (it seems to default to the XZ plane). What could be causing the drag handles to scale instead of staying a constant screen size? What I ultimately want is for the entire box to be draggable. So I want the handles to cover the box, and be a constant few pixels wide in screen coordinates regardless of the zoom level. Then I will make the handles invisible so only the 1-pixel wide box is visible. Any advice on how to do this? (I am using OSG 3.0.0.) ... Thank you! Cheers, Michael -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=50761#50761 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [Android osgViewer] OpenGL ES context lost (how do i preserve it?)
If you did exactly as it was the original example then it's the normal behaviour... because the viewer is reinitialized every time (it's stated in the docs), if not... I'm not a seer that knows what have you done in the code. 2012/10/24 Bernd Kampl bernd.ka...@gmail.com m working on an Android App based on the example AndroidExampleGLES1/2. In my case it's GLES1, but this problem persists in both GLES versions. The Problem occurs after the following steps (and it's easily reproducible): 1. run the android osgviewer app 2. load a model 3. put the android device to sleep (short press on power button) 4. wake up the android device 5. the model is gone. i know the error stems from losing the opengl context, which is then again created when the device is waking up again. so the obvious workaround/bugfix would be to preserve the opengl context. my problem is that i don't really know how to do this. i found a few more or less helpful comments on other web pages, but nothing to fix this particular problem yet. maybe someone can help me to fix this, i'd then be happy to somehow put this fix upstream (if that's possible) since that's a problem that persists in the example files. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Compute near far and multiple cameras
Hello Andy, First of all, thank you for responding, I wasn't even sure the mail got through ;-) Hey Sebastian, I've been looking at this off-and-on for a while now, though I have no clean solution. From my investigation it looks like the osg::CullVisitor tweaks the _computed_znear and _computed_zfar values to their needed settings during the handlle_cull_callbacks_and_traversal() call in the apply(osg::Camera) method. Once the traversal call is complete, the znear and zfar values are correct for all the geometry under that camera. The problem is that between that point and the code a few lines down where the z-values are reset for the next camera there is no mechanism to install a callback to retrieve the computed values. The two solutions I was going to try were: 1) Attach a custom node to the scenegraph in a way that assures it is the last node traversed, is always visited, yet doesn't influence the scene bounds, and then cache off the znear and zfar values from the CullVisitor using a cull callback on that node (seems tricky to manage) Okay, seems like this a valid approach, yet it sounds like a kludge. I'm just wondering how to achieve the yet doesn't influence the scene bounds-part. Or: 2) Subclass the osg::CullVisitor (which we've already done anyway in our project), copy/paste the virtual apply(osg::Camera) method body, and insert the code that I needed to cache / broadcast the z-values after the traversal. Okay, sounds a litte bit cleaner. If I understood this correctly, the Cullvisitor, depending on if it is the first or the second camera will either store or set the near-far value? I'll think about it and try. In either case the callback or broadcast mechanism could update the projections for any other cameras down the pipeline before they're hit by the CullVisitor. What I really want is the ability to give one camera references to other cameras as sort of projection slaves and have the osg::CullVisitor set the slave projections after the traversal. I haven't dug through the osg code enough to see if that paradigm is valid or if there's a more obvious solution I'm overlooking. I really hoped, that may be Robert could drop in some words here. He might point us to the obvious solution. Note that this is all in theory. I haven't been tasked to fix this issue yet in our code, we've just been using hard-coded fixed near/far values in the interim. That's exactly my approach right now. Unfortunately this won't work for geocentric databases in any case ;-) I'm still waiting for two features in OpenGL: 256bit depth buffer and separate stencil buffer targets that work with FBOs ;-) cheers Sebastian - Andy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=50742#50742 ___ 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] custom vertex attribut, using BIND_OVERALL
On 10/24/2012 11:35 AM, Jason Daly wrote: On 10/24/2012 05:28 AM, Daniel Schmid wrote: Since the material code is unique within geometries, so actually I would need to transfer it only once per Geometry. If I change to BIND_OVERALL, the data is no longer transferred, or at least my shader cannot detect it anymore. I thought i should maybe reduce the VertexAttribArray (l_Array) to one single entry, but this doesn't work either. What is the correct way of passing general or common data, on a per geometry (and not vertex) basis? I don't think BIND_OVERALL is valid for generic attributes. Sergey's right, use a Uniform. Scratch that, I'm wrong... From the man page for glVertexAttrib: If a generic vertex attribute bound to an attribute variable in a vertex shader is not updated while the vertex shader is executing, the vertex shader will repeatedly use the current value for the generic vertex attribute. So it seems that BIND_OVERALL should be working just fine. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Orbit manipulator right and middle mouse movement speed
Hi,
I've noticed that osgGA::OrbitManipulator code for right and middle mouse
movement has hard-coded values such as:
Code:
// doc in parent
bool OrbitManipulator::performMovementMiddleMouseButton( const double
eventTimeDelta, const double dx, const double dy )
{
// pan model
float scale = -0.3f * _distance * getThrowScale( eventTimeDelta );
panModel( dx*scale, dy*scale );
return true;
}
see zoomModel() and performMovementRightMouseButton() for the rest.
Is there particular reason scale is hard-coded and no parameter is exposed to
be able to modify movement scale for middle and right mouse button? Or is there
some other way to do it?
Thank you!
Janna
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=50766#50766
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Orbit manipulator right and middle mouse movement speed
Hello Janna, Is there particular reason scale is hard-coded and no parameter is exposed to be able to modify movement scale for middle and right mouse button? Or is there some other way to do it? There was a large refactoring of camera manipulators about 2 years ago. OrbitManipulator is one of the camera manipulators that were added during that process, so it's relatively recent in OSG. As such, I suspect the reason is simply the standard open-source development one: no one in the past has yet needed to change these values, so they were not exposed. There are two options worth considering IMHO: - The methods are virtual, you can subclass OrbitManipulator and do what you want, even add tweakable parameters with setters/getters and use them in the overridden version of the methods. - Modify the OSG sources to expose new parameters, submit the change and use that once it's integrated. There are a few cases when I was at CM-Labs where I did both: I subclassed to get the behavior I wanted right away (and test that it really worked in our applications) while at the same time submitting a code change to OSG to do the same thing. Once the change was integrated into OSG and we had moved to this new version that included it, I could remove the subclassed version in our code to avoid having to maintain that code in our own code-base. There were more than a few cases where subsequent discussion on this list led to me refactoring or improving my change beyond what I would have done if it had stayed in our code. This kind of collaboration really benefits everyone. Hope this helps, J-S -- __ Jean-Sebastien Guay jean_...@videotron.ca http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
