Re: [osg-users] RTT into a single color channel
Hi,
I can't follow what you expect and what is working/not?
If you are using 2DRect remember that texture coords are not between 0
and 1, so it does not make sense to directly put them into colours then.
jp
On 15/07/2011 20:31, Bolstad, Mark wrote:
So I've done some testing. I've decided to go the shader route as it
will give the most flexibility. I've modified osgdistortion from the
latest svn. At the end is a short patch to show the changes.
The main problem I'm getting is that the FBO texture doesn't appear to
be passing to the shader properly. All I'm getting is a black screen. If
I swap the shader to color based on texture coordinates, the output is
correct. I'm sure that I'm probably missing something simple in the
setup/texture binding, and any help is appreciated.
Mark
34,36d33
#include osg/Program
#include osg/Shader
#include osg/Uniform
58,80d54
///
// in-line GLSL source code for the microshader example
static const char *shaderVertSource = {
// passthru - Simple pass through vertex shader\n
void main(void)\n
{\n
gl_TexCoord[0].xy = gl_MultiTexCoord0.xy;\n
gl_Position = ftransform();\n
}\n
};
static const char *shaderFragSource = {
uniform sampler2DRect textureIn;\n
void main(void)\n
{\n
// gl_FragColor = vec4( gl_TexCoord[0].s, gl_TexCoord[0].t, 0.0, 1.0
);\n
gl_FragColor = texture2DRect( textureIn, gl_TexCoord[0].st );\n
}\n
};
///
94,98d67
osg::Program* program = new osg::Program;
program-setName( texture_shader );
program-addShader( new osg::Shader( osg::Shader::VERTEX,
shaderVertSource ) );
program-addShader( new osg::Shader( osg::Shader::FRAGMENT,
shaderFragSource ) );
156,157d124
osg::Vec3 cursor = bottom;
osg::Vec2 texcoord = bottom_texcoord;
198,201c165,166
stateset-setTextureAttributeAndModes( 0, texture,
osg::StateAttribute::ON );
stateset-addUniform( new osg::Uniform( textureIn, 0 ) );
stateset-setAttributeAndModes( program, osg::StateAttribute::ON );
stateset-setMode(GL_LIGHTING,osg::StateAttribute::ON);
---
stateset-setTextureAttributeAndModes(0,
texture,osg::StateAttribute::ON);
stateset-setMode(GL_LIGHTING,osg::StateAttribute::OFF);
391d355
osg::Vec3 cursor = bottom;
393,394d356
705c667
if (!loadedModel) loadedModel = osgDB::readNodeFile(cow.osg);
---
if (!loadedModel) loadedModel = osgDB::readNodeFile(cow.osgt);
786d747
viewer.setUpViewOnSingleScreen( 0 );
*/Mark A. Bolstad/*
Scientific Computing
Janelia Farm Research Campus
Howard Hughes Medical Institute
19700 Helix Drive, Ashburn, VA 20147
email:*bolst...@janelia.hhmi.or mailto:bolst...@janelia.hhmi.or**g*
office: +1.571.209.4623
web: http://www.hhmi.org/janelia/
On Jul 14, 2011, at 10:45 AM, J.P. Delport wrote:
Hi,
On 14/07/2011 16:37, Jason Daly wrote:
On 07/14/2011 10:08 AM, Bolstad, Mark wrote:
I like the idea of combining the passes into one, but if I had a blue
object and had to mask it into the red channel, wouldn't it just be
black?
Yes, it would be black on the red and green passes, but it would show up
on the blue pass. When you combined the three passes of the image to an
RGB texture, you'd have your blue object. The flow would look something
like this:
- set the camera to draw to an RGB texture
- set camera's color mask to red only
- draw the first object
- set camera's color mask to green only
- draw the second object
- set camera's color mask to blue only
- draw the third object
- fetch the texture from the camera and use it however you need it
as J-S said, you save the combine pass and you don't even need any
special shader magic.
I had talked to a professor who had suggested a one-line fragment
shader to do RGB- Luminance and use Color Masking to write into the
appropriate channel. Would rendering straight into a Luminance texture
with Color Masking work?
Maybe I'm not understanding you correctly, but I don't think this would
work. You'd end up with a luminance image (effectively, a grayscale
image) at the end and not a color image.
I think prof meant he must stick the calculated luminance value into
all three channels.
jp
In reality, this is actually more complicated in that it's not three
objects, but three separate frames of animation. So the main loop is:
while(1)
{
advance sim
frame(); // Render to red
advance sim
frame(); // Render to green
advance sim
frame(); // Render to blue
Render RTT texture to display.
}
Maybe if you explained what you're trying to do at a higher level, we'd
be able to better help. What is the problem you're trying to solve?
--J
___
osg-users mailing list
osg-users@lists.openscenegraph.org
mailto:osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
This message is subject to the CSIR's copyright terms and conditions,
e-mail legal notice,
Re: [osg-users] stencil buffer and CSG Boolean operations
Hi
Thanks alot for your comments Sergey and Chris.
I have tried to implement the algorithm, code and comments below but it doesn't
work as I had hoped.
What I expected to see is the back wall of a cylinder (which intersects a box).
What I actually see is the whole back wall of a cylinder rendered and the
image flickers.
Perhaps I have approached this the wrong way regarding loading the depth buffer
and then creating the stencil mask or have just misunderstood how to do it? Any
comments or pointers on the code would be very welcome.
#include stdafx.h
#include osg/Geode
#include osgViewer/Viewer
#include osgGA/TrackballManipulator
#include osgViewer/ViewerEventHandlers
#include osg/ShapeDrawable
#include osg/Depth
#include osg/Stencil
#include osg/CullFace
#include time.h
osg::ref_ptrosg::Group root;
osg::ref_ptrosg::Geode myBoxGeode;
osg::ref_ptrosg::Geode myCylinderGeode;
void loadCylinder()
{
osg::ref_ptrosg::Cylinder myCylinder = new
osg::Cylinder(osg::Vec3(0,0,0),0.1,1.0);
osg::ref_ptrosg::ShapeDrawable myCylinderDrawable = new
osg::ShapeDrawable(myCylinder);
myCylinderGeode = new osg::Geode();
myCylinderGeode-addDrawable(myCylinderDrawable);
root-addChild(myCylinderGeode);
}
void loadBox()
{
//create a box
osg::ref_ptrosg::Box myBox = new osg::Box(osg::Vec3(0,0,0),0.5);
osg::ref_ptrosg::ShapeDrawable myBoxDrawable = new
osg::ShapeDrawable(myBox);
myBoxGeode = new osg::Geode();
myBoxGeode-addDrawable(myBoxDrawable);
root-addChild(myBoxGeode);
}
int _tmain(int argc, _TCHAR* argv[])
{
root = new osg::Group;
loadCylinder();
loadBox();
osg::StateSet* cylState = myCylinderGeode-getOrCreateStateSet();
osg::CullFace* cfCyl = new osg::CullFace();
cylState-setAttributeAndModes(cfCyl);
osg::StateSet* boxState = myBoxGeode-getOrCreateStateSet();
osg::CullFace* cfBox = new osg::CullFace();
boxState-setAttributeAndModes(cfBox);
osg::StateSet* state = root-getOrCreateStateSet();
osg::ColorMask* colorMask = new osg::ColorMask();
osg::Depth* depth = new osg::Depth();
osg::Stencil* stencil = new osg::Stencil();
state-setAttribute(stencil);
state-setAttribute(colorMask);
state-setAttribute(depth);
osgViewer::Viewer viewer;
viewer.addEventHandler(new osgViewer::StatsHandler());
viewer.setUpViewInWindow( 50, 50, 1024, 768 );
viewer.setSceneData( root );
viewer.setCameraManipulator(new osgGA::TrackballManipulator());
osg::DisplaySettings::instance()-setMinimumNumStencilBits(8);
while( !viewer.done() )
{
/*
* Turn off writing to the colour buffer, so nothing is rendered
* to the screen yet
*
***/
colorMask-setMask(false, false,false,false);
/*
* Clear stencil buffer to O ??
*
*
***/
/*
* Turn on depth testing
*
*
***/
state-setAttribute(depth, osg::StateAttribute::ON );
/***
* Render the back face of cylinder (object a) into depth buffer
* Ensure the box (object b ) isn't rendered
*
*/
cfCyl-setMode(osg::CullFace::FRONT);
cfBox-setMode(osg::CullFace::FRONT_AND_BACK);
viewer.frame();
/***
* Disable writing to the depth buffer
*
*
*/
depth-setWriteMask( false );
/*
* Set the stencil buffer to increment if the depth test passes
*
*
**/
//enable the stencil test
stencil-setWriteMask(true);
state-setAttribute( stencil, osg::StateAttribute::ON );
//set the stencil functions
stencil-setFunction(osg::Stencil::ALWAYS,0,0);
stencil-setOperation(osg::Stencil::KEEP,osg::Stencil::KEEP,osg::Stencil::INCR);
/*
* Render the front faces of the box object b
*
*
Re: [osg-users] osgGA modifications for IPhone and other
Hi Stephan, I just tried your modification on my iPhone (3gs) and also on iPad. The rendering looks ok when I change the orientation to landscape. However, the touch input space does not seem to be correct, there are some offsets between the location that I actually touch and the location in the clip space (only happens in landscape mode). I used simpleExample inside the iPhoneExample folder in the OSGIPhone project, which has the DebugTouchPointsEventHandler to draw the touch location. Thank you! Cheers, William -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=41418#41418 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] RTT into a single color channel
Hi, Mark
Afaik osgdistortion uses 2d textures not rect textures.
Cheers,
Sergey.
18.07.2011, 11:42, J.P. Delport jpdelp...@csir.co.za:
Hi,
I can't follow what you expect and what is working/not?
If you are using 2DRect remember that texture coords are not between 0
and 1, so it does not make sense to directly put them into colours then.
jp
On 15/07/2011 20:31, Bolstad, Mark wrote:
So I've done some testing. I've decided to go the shader route as it
will give the most flexibility. I've modified osgdistortion from the
latest svn. At the end is a short patch to show the changes.
The main problem I'm getting is that the FBO texture doesn't appear to
be passing to the shader properly. All I'm getting is a black screen. If
I swap the shader to color based on texture coordinates, the output is
correct. I'm sure that I'm probably missing something simple in the
setup/texture binding, and any help is appreciated.
Mark
34,36d33
#include osg/Program
#include osg/Shader
#include osg/Uniform
58,80d54
///
// in-line GLSL source code for the microshader example
static const char *shaderVertSource = {
// passthru - Simple pass through vertex shader\n
void main(void)\n
{\n
gl_TexCoord[0].xy = gl_MultiTexCoord0.xy;\n
gl_Position = ftransform();\n
}\n
};
static const char *shaderFragSource = {
uniform sampler2DRect textureIn;\n
void main(void)\n
{\n
// gl_FragColor = vec4( gl_TexCoord[0].s, gl_TexCoord[0].t, 0.0, 1.0
);\n
gl_FragColor = texture2DRect( textureIn, gl_TexCoord[0].st );\n
}\n
};
///
94,98d67
osg::Program* program = new osg::Program;
program-setName( texture_shader );
program-addShader( new osg::Shader( osg::Shader::VERTEX,
shaderVertSource ) );
program-addShader( new osg::Shader( osg::Shader::FRAGMENT,
shaderFragSource ) );
156,157d124
osg::Vec3 cursor = bottom;
osg::Vec2 texcoord = bottom_texcoord;
198,201c165,166
stateset-setTextureAttributeAndModes( 0, texture,
osg::StateAttribute::ON );
stateset-addUniform( new osg::Uniform( textureIn, 0 ) );
stateset-setAttributeAndModes( program, osg::StateAttribute::ON );
stateset-setMode(GL_LIGHTING,osg::StateAttribute::ON);
---
stateset-setTextureAttributeAndModes(0,
texture,osg::StateAttribute::ON);
stateset-setMode(GL_LIGHTING,osg::StateAttribute::OFF);
391d355
osg::Vec3 cursor = bottom;
393,394d356
705c667
if (!loadedModel) loadedModel = osgDB::readNodeFile(cow.osg);
---
if (!loadedModel) loadedModel = osgDB::readNodeFile(cow.osgt);
786d747
viewer.setUpViewOnSingleScreen( 0 );
*/Mark A. Bolstad/*
Scientific Computing
Janelia Farm Research Campus
Howard Hughes Medical Institute
19700 Helix Drive, Ashburn, VA 20147
email:*bolst...@janelia.hhmi.or mailto:bolst...@janelia.hhmi.or**g*
office: +1.571.209.4623
web: http://www.hhmi.org/janelia/
On Jul 14, 2011, at 10:45 AM, J.P. Delport wrote:
Hi,
On 14/07/2011 16:37, Jason Daly wrote:
On 07/14/2011 10:08 AM, Bolstad, Mark wrote:
I like the idea of combining the passes into one, but if I had a blue
object and had to mask it into the red channel, wouldn't it just be
black?
Yes, it would be black on the red and green passes, but it would show up
on the blue pass. When you combined the three passes of the image to an
RGB texture, you'd have your blue object. The flow would look something
like this:
- set the camera to draw to an RGB texture
- set camera's color mask to red only
- draw the first object
- set camera's color mask to green only
- draw the second object
- set camera's color mask to blue only
- draw the third object
- fetch the texture from the camera and use it however you need it
as J-S said, you save the combine pass and you don't even need any
special shader magic.
I had talked to a professor who had suggested a one-line fragment
shader to do RGB- Luminance and use Color Masking to write into the
appropriate channel. Would rendering straight into a Luminance texture
with Color Masking work?
Maybe I'm not understanding you correctly, but I don't think this would
work. You'd end up with a luminance image (effectively, a grayscale
image) at the end and not a color image.
I think prof meant he must stick the calculated luminance value into
all three channels.
jp
In reality, this is actually more complicated in that it's not three
objects, but three separate frames of animation. So the main loop is:
while(1)
{
advance sim
frame(); // Render to red
advance sim
frame(); // Render to green
advance sim
frame(); // Render to blue
Render RTT texture to display.
}
Maybe if you explained what you're trying to do at a higher level, we'd
be able to better help. What is
Re: [osg-users] OSG based WebKit plugin - Mac OSX - Crash
Hi Robert! Thank you for your prompt replay, and sorry for my late one. I upgraded to OSG 3.0 and now everything seems to be ok. :) G. Il giorno 19.giu.2011, alle ore 18:59, Robert Osfield ha scritto: Hi Gino, What form is your colour data? A Vec3Array? A Vec4Array? A Vec4ubArary? With all of these the format will be RGB or RGBA so BGRA will not be appropriate. The code segments look like a hacks around drivers bugs to me as they don't seem related to what I'd expect the OSG to be passing. As a general comment I would strongly suggest you upgrade to the svn/trunk, OSG-3.0.0-rc1 as this will contain lots of bugs fixes and improvements over that was in 2.9.9. If it does come to applying a fix to the OSG it'll be svn/trunk or the OSG-3.0 so you usage of 2.9.9 just clouds the issue. Robert. On Sun, Jun 19, 2011 at 5:00 PM, Gino ginofiliber...@yahoo.it wrote: Good evening to everybody. I'm currently finishing my OSG plugin for WebKit based browsers... But I'm having a trouble: Sometimes, during testing, it crashes unpredictably , with the following crashlog: Process: WebKitPluginHost [4642] Path: /System/Library/Frameworks/WebKit.framework/WebKitPluginHost.app/Contents/MacOS/WebKitPluginHost Identifier: com.apple.WebKit.PluginHost Version: 6533.20 (6533.20.20) Build Info: WebKitPluginHost-75332020~1 Code Type: X86 (Native) Parent Process: WebKitPluginAgent [380] PlugIn Path: /usr/local/lib/osg.framework/Versions/66/osg PlugIn Identifier: osg PlugIn Version:??? () Date/Time: 2011-05-23 15:33:59.499 +0200 OS Version: Mac OS X 10.6.7 (10J869) Report Version: 6 Interval Since Last Report: 426612 sec Crashes Since Last Report: 80 Per-App Interval Since Last Report: 71487 sec Per-App Crashes Since Last Report: 58 Anonymous UUID: 147D37FA-E541-46DE-8C6E-C4EFDFACF4A4 Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x Crashed Thread: 0 Dispatch queue: com.apple.main-thread Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 GLEngine0x14062832 gleRunVertexSubmitImmediate + 722 1 GLEngine0x140624fc gleLLVMArrayFunc + 60 2 GLEngine0x140624b4 gleSetVertexArrayFunc + 116 3 GLEngine0x1404b3c9 gleDrawArraysOrElements_ExecCore + 1216 4 GLEngine0x13fd4e23 glDrawElements_Exec + 834 5 libGL.dylib 0x95d12050 glDrawElements + 52 6 osg 0x1399c4c2 osg::DrawElementsUShort::draw(osg::State, bool) const + 1058 7 osg 0x139036fc osg::Geometry::drawImplementation(osg::RenderInfo) const + 4588 8 osgUtil 0x13c070af osgUtil::RenderLeaf::render(osg::RenderInfo, osgUtil::RenderLeaf*) + 607 9 osgUtil 0x13c00627 osgUtil::RenderBin::drawImplementation(osg::RenderInfo, osgUtil::RenderLeaf*) + 343 10 osgUtil 0x13c094d7 osgUtil::RenderStage::drawImplementation(osg::RenderInfo, osgUtil::RenderLeaf*) + 647 11 osgUtil 0x13c0984d osgUtil::RenderStage::drawInner(osg::RenderInfo, osgUtil::RenderLeaf*, bool) + 125 12 osgUtil 0x13c0cb6a osgUtil::RenderStage::draw(osg::RenderInfo, osgUtil::RenderLeaf*) + 1914 13 osgUtil 0x13c17f88 osgUtil::SceneView::draw() + 600 14 osgViewer 0x13e1d32c osgViewer::Renderer::cull_draw() + 972 15 osg 0x13939d1a osg::GraphicsContext::runOperations() + 234 16 osgViewer 0x13e6762e osgViewer::ViewerBase::renderingTraversals() + 5246 17 libFunCored.dylib 0x1466608a CoreBase::RenderScene() + 210 (CoreBase.cpp:308) ... ... ... ... ... ... I'm using actually OSG version 2.9.9, OSX 10.6.7 The technologies that I'm using are ImageIO cocoaevents and core animation... After some google-ing, I found on the Irrlicht forum, a very similar bugreport. It seems that they corrected it by introducing the following ifdef, in order to manage better the size argument in the glColorPointer //#if defined(GL_ARB_vertex_array_bgra) || defined(GL_EXT_vertex_array_bgra) #ifdef GL_BGRA const GLint colorSize=(FeatureAvailable[IRR_ARB_vertex_array_bgra] || FeatureAvailable[IRR_EXT_vertex_array_bgra])?GL_BGRA:4; #else const GLint colorSize=4; #endif ... glColorPointer(colorSize, GL_UNSIGNED_BYTE, sizeof(S3DVertex), (static_castconst S3DVertex*(vertices))[0].Color); This could be my case too? Any further tip or suggestion? Thanks in advance G. ___ osg-users
Re: [osg-users] [build] problem compiling osg 3.0.0 for Android
Hi again, Have fun with Osg and Android. Thanks, I'll do my best :P I've been checking out the android examples, both osgAndroidExampleGLES1 and osgAndroidExampleGLES2. No problem with osgAndroidExampleGLES1 :) But when it comes to do the same thing with osgAndroidExampleGLES2, I am not having the same luck. I get a bunch of errors when I use ndk-build. I am gonna assume that osg has been compiled using the OpenGL ES 1.1 API? Do I have to recompile or something? Thanks once again. Cheers, Rubén -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=41427#41427 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] problem compiling osg 3.0.0 for Android
Yes, you have to build two versions of OSG one with Gles1 and one with Gles2. According the Ndk google group it's not good to mix them up. If you used the cmake chain that was on the wiki I think it was for Gles1 ... if not I don't know. But as I was saying you need one for each one. Although looking how they load libraries in Android it should be theorically possible to build with support for both of them... But i've not delved into the subject... I'm bussy with my End of Degree project so... it's not something prioritary for me and i'm not testing those posibilities, right now I'm more concerned to do Osg Dynamic Linking to ease the life of developing with OSG and Android. Good luck and keep the Robot Fight! 2011/7/18 Rubén Díaz ruw...@hotmail.com But when it comes to do the same thing with osgAndroidExampleGLES2, I am not having the same luck. I get a bunch of errors when I use ndk-build. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] AutoTransform and multiple views
Hi,
I am using the Drag handlers with an autotransform on them (see code below). I
have it set to AutoscaleToScreen. This works great as long as I only have 1
view of the scene. When I have multiple views though, I get a problem where
zooming in on one will cause the autotransform to change the scale of the
dragger. I can click on the dragger just fine in that window, but when I go
back to the other window and try and click on the dragger it is no longer
scaled correctly. As an example, if I zoom in to view A then the translate drag
handler become larger. I can click anywhere on them and they work correctly.
When I go to View B that is zoomed out then I can click not only on the visual
representation of the drag handler, but on a projection of it that extends past
the visual end of the axis. If I do this the opposite way (Zoom out A and look
at zoomed in B), then the opposite happens. I can only click on the drag
handler on a smaller portion of the visible axis.
I looked around and found this post
(http://forum.openscenegraph.org/viewtopic.php?t=4637highlight=).
The issue you are hitting up against is a limitation of
osg::AutoTransform in that it only has a single set of state so when
you have two or more views that require different stats you'll get
issues with both views attempting to sets it's value. The only way to
solve this would be to refactor osg::AutoTransform to have multiple
states in some way.
It looks like this may be related to this problem, but I am not sure. Does
anyone have any experience with this issue? Is this issue caused by the state
problem of autotransform? Has anyone else found a way around this problem? Does
anyone have any suggestions for an easy way to get around this problem without
redoing the autotransform node?
Here is my drag handler code.
Code:
VsDragger::VsDragger(VsMovableItem *lpParent, BOOL bAllowTranslateX, BOOL
bAllowTranslateY, BOOL bAllowTranslateZ,
BOOL bAllowRotateX, BOOL
bAllowRotateY, BOOL bAllowRotateZ)
{
if(!lpParent)
THROW_ERROR(Al_Err_lParentNotDefined,
Al_Err_strParentNotDefined);
m_lpVsParent = lpParent;
//Create the gripperMT and default it to loc=0, rot=0
m_osgGripperMT = new osg::MatrixTransform();
osg::Matrix osgMT; osgMT.makeIdentity();
m_osgGripperMT-setMatrix(osgMT);
m_osgGripperMT-addChild(this);
_autoTransform = new osg::AutoTransform;
_autoTransform-setAutoScaleToScreen(true);
addChild(_autoTransform.get());
_sizeTransform = new osg::MatrixTransform;
// Screen coordinates because of AutoTransform parent
_sizeTransform-setMatrix(osg::Matrix::scale(100, 100, 100));
_autoTransform-addChild(_sizeTransform.get());
_tbDragger = new VsTrackballDragger(bAllowRotateX, bAllowRotateY,
bAllowRotateZ);
_tbDragger-setName(TrackballDragger);
//addChild(_tbDragger.get());
_sizeTransform-addChild(_tbDragger.get());
_transDragger = new VsTranslateAxisDragger(bAllowTranslateX,
bAllowTranslateY, bAllowTranslateZ);
_transDragger-setName(TranslateAxisDragger);
//addChild(_transDragger.get());
_sizeTransform-addChild(_transDragger.get());
this-addDragger(_tbDragger.get());
this-addDragger(_transDragger.get());
this-getOrCreateStateSet()-setMode(GL_RESCALE_NORMAL,
osg::StateAttribute::ON);
this-setParentDragger(getParentDragger());
}
VsDragger::~VsDragger(void)
{
}
void VsDragger::setupDefaultGeometry()
{
_tbDragger-setupDefaultGeometry();
_transDragger-setupDefaultGeometry();
SetupMatrix();
}
void VsDragger::AddToScene()
{
SetupMatrix();
if(m_lpVsParent m_lpVsParent-RootGroup() m_osgGripperMT.valid())
if(!m_lpVsParent-RootGroup()-containsNode(m_osgGripperMT.get()))
m_lpVsParent-RootGroup()-addChild(m_osgGripperMT.get());
}
void VsDragger::RemoveFromScene()
{
if(m_lpVsParent m_lpVsParent-RootGroup() m_osgGripperMT.valid())
if(m_lpVsParent-RootGroup()-containsNode(m_osgGripperMT.get()))
m_lpVsParent-RootGroup()-removeChild(m_osgGripperMT.get());
}
void VsDragger::SetupMatrix()
{
if(m_lpVsParent m_lpVsParent-RootGroup() m_osgGripperMT.valid())
{
//This gives the radius of the boundign sphere for the selected
part.
//We will multiply that by 2 and then scale the entire dragger
by that amount.
//We will also use that setting for the minimum scale of the
autotransform.
float fltMaxDim = m_lpVsParent-Physics_GetBoundingRadius();
Simulator *lpSim = GetSimulator();
if(fltMaxDim (lpSim-InverseDistanceUnits()/2.0f))
fltMaxDim = (lpSim-InverseDistanceUnits()/2.0f);
[osg-users] Unit of preMult-(osg::Matrix::Translate(osg::Vec3(x, y, z)
Hi, I'm rendering new 3d models using OSG. In translate fuction (preMult-(osg::Matrix::translate(osg::Vec3(x,y,z)) What unit are x, y and z? There are metres, milimetres, pixels? Thanks in advance! Cheers, Nagore -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=41433#41433 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] AutoTransform and multiple views
Hi,
On 18/07/2011 13:19, David Cofer wrote:
Hi,
I am using the Drag handlers with an autotransform on them (see code
below). I have it set to AutoscaleToScreen. This works great as long
as I only have 1 view of the scene. When I have multiple views
though, I get a problem where zooming in on one will cause the
autotransform to change the scale of the dragger. I can click on the
dragger just fine in that window, but when I go back to the other
window and try and click on the dragger it is no longer scaled
correctly. As an example, if I zoom in to view A then the translate
drag handler become larger. I can click anywhere on them and they
work correctly. When I go to View B that is zoomed out then I can
click not only on the visual representation of the drag handler, but
on a projection of it that extends past the visual end of the axis.
If I do this the opposite way (Zoom out A and look at zoomed in B),
then the opposite happens. I can only click on the drag handler on a
smaller portion of the visible axis.
I looked around and found this post
(http://forum.openscenegraph.org/viewtopic.php?t=4637highlight=).
The issue you are hitting up against is a limitation of
osg::AutoTransform in that it only has a single set of state so
when you have two or more views that require different stats you'll
get issues with both views attempting to sets it's value. The only
way to solve this would be to refactor osg::AutoTransform to have
multiple states in some way.
It looks like this may be related to this problem, but I am not sure.
It is.
Does anyone have any experience with this issue? Is this issue caused
by the state problem of autotransform?
Yes, basically the autotransform's scale is set when it is visited by
the cull traversal of a specific view, so it renders at the correct
size. Picking is also a traversal, but just gets the bounds calculated
on the latest cull traversal and this could be from any view...
Has anyone else found a way
around this problem? Does anyone have any suggestions for an easy way
to get around this problem without redoing the autotransform node?
I've recently worked around this by doing picking in a specific view's
camera callback. My pick handler now basically queues picks to be
executed after the camera's cull traversal has happened and this ensures
the correct scale is used during picking.
I'm not sure how easy this would be to do for the draggers...
Only other option is to make autotransform more intelligent or add
another type of visitor to osg.
jp
Here is my drag handler code.
Code:
VsDragger::VsDragger(VsMovableItem *lpParent, BOOL bAllowTranslateX,
BOOL bAllowTranslateY, BOOL bAllowTranslateZ, BOOL bAllowRotateX,
BOOL bAllowRotateY, BOOL bAllowRotateZ) { if(!lpParent)
THROW_ERROR(Al_Err_lParentNotDefined, Al_Err_strParentNotDefined);
m_lpVsParent = lpParent;
//Create the gripperMT and default it to loc=0, rot=0 m_osgGripperMT
= new osg::MatrixTransform(); osg::Matrix osgMT;
osgMT.makeIdentity(); m_osgGripperMT-setMatrix(osgMT);
m_osgGripperMT-addChild(this); _autoTransform = new
osg::AutoTransform; _autoTransform-setAutoScaleToScreen(true);
addChild(_autoTransform.get());
_sizeTransform = new osg::MatrixTransform; // Screen coordinates
because of AutoTransform parent
_sizeTransform-setMatrix(osg::Matrix::scale(100, 100, 100));
_autoTransform-addChild(_sizeTransform.get());
_tbDragger = new VsTrackballDragger(bAllowRotateX, bAllowRotateY,
bAllowRotateZ); _tbDragger-setName(TrackballDragger);
//addChild(_tbDragger.get());
_sizeTransform-addChild(_tbDragger.get());
_transDragger = new VsTranslateAxisDragger(bAllowTranslateX,
bAllowTranslateY, bAllowTranslateZ);
_transDragger-setName(TranslateAxisDragger);
//addChild(_transDragger.get());
_sizeTransform-addChild(_transDragger.get());
this-addDragger(_tbDragger.get());
this-addDragger(_transDragger.get());
this-getOrCreateStateSet()-setMode(GL_RESCALE_NORMAL,
osg::StateAttribute::ON);
this-setParentDragger(getParentDragger()); }
VsDragger::~VsDragger(void) { }
void VsDragger::setupDefaultGeometry() {
_tbDragger-setupDefaultGeometry();
_transDragger-setupDefaultGeometry();
SetupMatrix(); }
void VsDragger::AddToScene() { SetupMatrix(); if(m_lpVsParent
m_lpVsParent-RootGroup() m_osgGripperMT.valid())
if(!m_lpVsParent-RootGroup()-containsNode(m_osgGripperMT.get()))
m_lpVsParent-RootGroup()-addChild(m_osgGripperMT.get()); }
void VsDragger::RemoveFromScene() { if(m_lpVsParent
m_lpVsParent-RootGroup() m_osgGripperMT.valid())
if(m_lpVsParent-RootGroup()-containsNode(m_osgGripperMT.get()))
m_lpVsParent-RootGroup()-removeChild(m_osgGripperMT.get()); }
void VsDragger::SetupMatrix() { if(m_lpVsParent
m_lpVsParent-RootGroup() m_osgGripperMT.valid()) { //This gives
the radius of the boundign sphere for the selected part. //We will
multiply that by 2 and then scale the entire dragger by that amount.
//We will also use that setting for the minimum scale of the
autotransform. float fltMaxDim =
Re: [osg-users] RTT into a single color channel
Switching the shader to use *2D instead of *2DRect fixed it. Thanks!
Mark
Mark A. Bolstad
Scientific Computing
Janelia Farm Research Campus
Howard Hughes Medical Institute
19700 Helix Drive, Ashburn, VA 20147
email: bolst...@janelia.hhmi.org
office: +1.571.209.4623
web: http://www.hhmi.org/janelia/
On Jul 18, 2011, at 6:03 AM, Sergey Polischuk wrote:
Hi, Mark
Afaik osgdistortion uses 2d textures not rect textures.
Cheers,
Sergey.
18.07.2011, 11:42, J.P. Delport jpdelp...@csir.co.za:
Hi,
I can't follow what you expect and what is working/not?
If you are using 2DRect remember that texture coords are not between 0
and 1, so it does not make sense to directly put them into colours then.
jp
On 15/07/2011 20:31, Bolstad, Mark wrote:
So I've done some testing. I've decided to go the shader route as it
will give the most flexibility. I've modified osgdistortion from the
latest svn. At the end is a short patch to show the changes.
The main problem I'm getting is that the FBO texture doesn't appear to
be passing to the shader properly. All I'm getting is a black screen. If
I swap the shader to color based on texture coordinates, the output is
correct. I'm sure that I'm probably missing something simple in the
setup/texture binding, and any help is appreciated.
Mark
34,36d33
#include osg/Program
#include osg/Shader
#include osg/Uniform
58,80d54
///
// in-line GLSL source code for the microshader example
static const char *shaderVertSource = {
// passthru - Simple pass through vertex shader\n
void main(void)\n
{\n
gl_TexCoord[0].xy = gl_MultiTexCoord0.xy;\n
gl_Position = ftransform();\n
}\n
};
static const char *shaderFragSource = {
uniform sampler2DRect textureIn;\n
void main(void)\n
{\n
// gl_FragColor = vec4( gl_TexCoord[0].s, gl_TexCoord[0].t, 0.0, 1.0
);\n
gl_FragColor = texture2DRect( textureIn, gl_TexCoord[0].st );\n
}\n
};
///
94,98d67
osg::Program* program = new osg::Program;
program-setName( texture_shader );
program-addShader( new osg::Shader( osg::Shader::VERTEX,
shaderVertSource ) );
program-addShader( new osg::Shader( osg::Shader::FRAGMENT,
shaderFragSource ) );
156,157d124
osg::Vec3 cursor = bottom;
osg::Vec2 texcoord = bottom_texcoord;
198,201c165,166
stateset-setTextureAttributeAndModes( 0, texture,
osg::StateAttribute::ON );
stateset-addUniform( new osg::Uniform( textureIn, 0 ) );
stateset-setAttributeAndModes( program, osg::StateAttribute::ON );
stateset-setMode(GL_LIGHTING,osg::StateAttribute::ON);
---
stateset-setTextureAttributeAndModes(0,
texture,osg::StateAttribute::ON);
stateset-setMode(GL_LIGHTING,osg::StateAttribute::OFF);
391d355
osg::Vec3 cursor = bottom;
393,394d356
705c667
if (!loadedModel) loadedModel = osgDB::readNodeFile(cow.osg);
---
if (!loadedModel) loadedModel = osgDB::readNodeFile(cow.osgt);
786d747
viewer.setUpViewOnSingleScreen( 0 );
*/Mark A. Bolstad/*
Scientific Computing
Janelia Farm Research Campus
Howard Hughes Medical Institute
19700 Helix Drive, Ashburn, VA 20147
email:*bolst...@janelia.hhmi.or mailto:bolst...@janelia.hhmi.or**g*
office: +1.571.209.4623
web: http://www.hhmi.org/janelia/
On Jul 14, 2011, at 10:45 AM, J.P. Delport wrote:
Hi,
On 14/07/2011 16:37, Jason Daly wrote:
On 07/14/2011 10:08 AM, Bolstad, Mark wrote:
I like the idea of combining the passes into one, but if I had a blue
object and had to mask it into the red channel, wouldn't it just be
black?
Yes, it would be black on the red and green passes, but it would show up
on the blue pass. When you combined the three passes of the image to an
RGB texture, you'd have your blue object. The flow would look something
like this:
- set the camera to draw to an RGB texture
- set camera's color mask to red only
- draw the first object
- set camera's color mask to green only
- draw the second object
- set camera's color mask to blue only
- draw the third object
- fetch the texture from the camera and use it however you need it
as J-S said, you save the combine pass and you don't even need any
special shader magic.
I had talked to a professor who had suggested a one-line fragment
shader to do RGB- Luminance and use Color Masking to write into the
appropriate channel. Would rendering straight into a Luminance texture
with Color Masking work?
Maybe I'm not understanding you correctly, but I don't think this would
work. You'd end up with a luminance image (effectively, a grayscale
image) at the end and not a color image.
I think prof meant he must stick the calculated luminance value into
all three channels.
jp
In reality, this is actually more complicated
Re: [osg-users] [osgPlugins] VRML plugin - file url
Hi Michael, On 07/10/2011 03:48 PM, Michael Chechow wrote: Hi, .. I removed all of these lines except the last line: Code: fileName = unixFileName; After recompiling the VRML plugin, it could load the VRML file from whichever location I specified. I use OSG on Mac OS X 10.6.8, which does not seem to understand the file : // url in C++. Does this behaviour only occur on my machine? Why is file : // even used at all? It is used because the correct local filesystem URI for a file is file:///somewhere/something.wrl for a file in /somewhere/something.wrl (absolute filename). OpenVRML does not take filenames, but needs full URIs because the files may come from the Internet as well. For Windows there is a special case, because the file names on Windows are different, including the drive letters. You can find an explanation of the whole thing here: http://en.wikipedia.org/wiki/File_URI_scheme If the filename is relative (doesn't start with slash), then it should work just fine (see the else branch of the code just below the #endif). What kind of filename did you try to use? Regards, Jan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] VRML plugin - file url
Hi Jan, I tried both relative and absolute file paths. The VRML file, which I try to load, is located at /Developer/workspace/osgtest/model.wrl . I reverted my changes of the VRML plugin and added the following line for debugging purposes: osg::notify(osg::INFO) fileName= fileName.c_str() std::endl; After running this code, osg::setNotifyLevel(osg::DEBUG_FP); osg::ref_ptrosg::Node model = osgDB::readNodeFile(model.wrl); osgViewer::Viewer viewer; viewer.setSceneData(model.get()); I get the following debug output: [...] Opened DynamicLibrary osgPlugins-3.0.0/osgdb_vrml.so itr='/Developer/workspace/osgtest/osgtest.app/Contents/Resources' FindFileInPath() : trying /Developer/workspace/osgtest/osgtest.app/Contents/Resources/model.wrl ... itr='/Developer/workspace/osgtest' FindFileInPath() : trying /Developer/workspace/osgtest/model.wrl ... FindFileInPath() : USING /Developer/workspace/osgtest/model.wrl fileName=file:///Developer/workspace/osgtest/model.wrl [...] OSG finds the correct file path and according to the last line of the debug output, the VRML plugin prepends file://. But the plugin does not load anything and nothing is displayed on the screen. If I use an absolute path, this is the debug output: [...] FindFileInPath(/Developer/workspace/osgtest/model.wrl): returning /Developer/workspace/osgtest/model.wrl fileName=file:///Developer/workspace/osgtest/model.wrl [...] But still no model is visible. If I disable the addition of file:// in the VRML plugin, the model is loaded and displayed, and the following debug output is generated: [...] FindFileInPath(/Developer/workspace/osgtest/model.wrl): returning /Developer/workspace/osgtest/model.wrl fileName=/Developer/workspace/osgtest/model.wrl [...] Both the absolute and relative file path works. Thanks, Michael ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] viewer focus event
Hi, Is there a viewer window focus event? I have been looking through the GUIEventAdapter and I do not see anything that would signal when a window gets the focus? Is it possible to get this info in OSG? Thank you! Cheers, David -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=41454#41454 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] building for xcode on os x
I'm getting the following errors when trying to build osg for xcode on mac os x.
Does anyone have any idea what's going on and how to fix. I'm a newbie and
following instructions for osg book and this is what i got:
osgdb_jp2
/Users/brojas/Desktop/OpenSceneGraph-3.0.0/src/osgPlugins/jp2/ReaderWriterJP2.cpp
/Users/brojas/Desktop/OpenSceneGraph-3.0.0/src/osgPlugins/jp2/ReaderWriterJP2.cpp:20:31:
error: jasper/jasper.h: No such file or directory
/Users/brojas/Desktop/OpenSceneGraph-3.0.0/src/osgPlugins/jp2/ReaderWriterJP2.cpp:32:
error: 'jas_stream_t' was not declared in this scope
/Users/brojas/Desktop/OpenSceneGraph-3.0.0/src/osgPlugins/jp2/ReaderWriterJP2.cpp:32:
error: 'out' was not declared in this scope
/Users/brojas/Desktop/OpenSceneGraph-3.0.0/src/osgPlugins/jp2/ReaderWriterJP2.cpp:32:
error: 'jas_image_t' was not declared in this scope
/Users/brojas/Desktop/OpenSceneGraph-3.0.0/src/osgPlugins/jp2/ReaderWriterJP2.cpp:32:
error: 'image' was not declared in this scope
/Users/brojas/Desktop/OpenSceneGraph-3.0.0/src/osgPlugins/jp2/ReaderWriterJP2.cpp:32:
error: expected primary-expression before 'int'
/Users/brojas/Desktop/OpenSceneGraph-3.0.0/src/osgPlugins/jp2/ReaderWriterJP2.cpp:32:
error: initializer expression list treated as compound expression
/Users/brojas/Desktop/OpenSceneGraph-3.0.0/src/osgPlugins/jp2/ReaderWriterJP2.cpp:33:
error: expected ',' or ';' before '{' token
/Users/brojas/Desktop/OpenSceneGraph-3.0.0/src/osgPlugins/jp2/ReaderWriterJP2.cpp:522:
error: expected `}' at end of input
/Users/brojas/Desktop/OpenSceneGraph-3.0.0/src/osgPlugins/jp2/ReaderWriterJP2.cpp:32:
warning: 'putdata' defined but not used
Thanks in advance
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Write the Android example exclusively in C++
Hi all, It's exciting to see the Android support is added in the OSG trunk, as well as two examples showing the integrations with ES1 and ES2. Unfortunately they are both written with Java and hard to be compiled along with other libraries and examples. It will be much better if we could have a pure C++ viewer example that working under Android someday. I've just found some articles about how to use NDK exclusively in C++ at: http://android-developers.blogspot.com/2011/01/gingerbread-ndk-awesomeness.html http://developer.android.com/reference/android/app/NativeActivity.html But I'm still a beginner of Android development so can't say more about this topic. And I don't know if anybody has already discussed about the methods on the links above and proved them to be unusable. But if the solution is feasible, we may then have a more friendly Android integration example for developers with some efforts. Any ideas about it? :-) Wang Rui ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] VRML plugin - file url
Hi, On Monday 18 July 2011, Michael Chechow wrote: [...] Both the absolute and relative file path works. I observed something similar here. For my local hacky use, I have just removed the 'file://' too. I have put invesigating why this is required for my environment onto the todo list, where it is still lurking around. So in the end here my +1 for 'there might be something wrong with osg's current vrml uri usage'. Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Philippe Miltin Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
