Re: [osg-users] Errors reported on BINO-PC on CDash
Hi, You can safely ignore this. It was due to a failing hard drive. The linker crashed a lot. ... Thank you! Cheers, Albino -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=41006#41006 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Android and a mix of Java + native C++ now possible
Hi Jason, Thanks for sharing your experience and your CMake :) Yes, that's the modified NDK I was referring to. Damn, I completely forgot about osgGA and didn't know about GLSurfaceView (I'm new to the Android SDK). Cheers, Albino -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=27644#27644 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Android and a mix of Java + native C++ now possible
Hi, I am currently in the process of doing a test port of an OSG application we have here to Odroid - ODROID_WEBSITE. It is basically an entertainment device built on top of Android 2.1. While going through the Android toolchain documentation for the latest NDK (rev3) I noticed two critical points. No standard C++ library support: The Android 1.5 system does not use any C++ standard library, and does not provide one to applicative native code. Instead, a very limited set of headers are provided (see docs/STABLE-APIS.TXT) which correspond to the C++ support code used to build the Android platform. It is possible to hack existing C++ STL implementations to work on top of this, but this is not supported yet. We recommend trying with uSTL and STLport at this point if you really need this. No support for C++ exceptions and RTTI: --- The Android 1.5 system image lacks several features necessary to reliably implement C++ exceptions and RTTI. C++ code that depends on these features will simply not link or run appropriately on Android 1.5 I'm curious if anyone has worked with Android's NDK and OSG and has a work around or other ideas. I found WEBSITE_WITH_PATCH which adds exceptions, STL and RTTI but reading through the android google groups people are having issues with it. Cheers, bino ps: Sorry I can't post the full URL due to the forums spam filters (You must have 2 posts before you can post URL's/Links.) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=27547#27547 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSGSpotLight example on a GLSL material
Hi,
Try including the vertex and fragment shaders you are using then
others might have a chance of spotting what is up.
My apologies for the lack of source code.
The Normal Vertex Map Shader:
varying vec3 lightVec;
varying vec3 eyeVec;
varying vec2 texCoord;
attribute vec3 tangent;
void main(void)
{
gl_Position = ftransform();
texCoord = gl_MultiTexCoord0.xy;
vec3 n = normalize(gl_NormalMatrix * gl_Normal);
vec3 t = normalize(gl_NormalMatrix * tangent);
vec3 b = cross(n, t);
vec3 vVertex = vec3(gl_ModelViewMatrix * gl_Vertex);
vec3 tmpVec = gl_LightSource[0].position.xyz - vVertex;
lightVec.x = dot(tmpVec, t);
lightVec.y = dot(tmpVec, b);
lightVec.z = dot(tmpVec, n);
tmpVec = -vVertex;
eyeVec.x = dot(tmpVec, t);
eyeVec.y = dot(tmpVec, b);
eyeVec.z = dot(tmpVec, n);
}
The Normal Fragment Map Shader:
varying vec3 lightVec;
varying vec3 eyeVec;
varying vec2 texCoord;
uniform sampler2D diffuseMap;
uniform sampler2D normalMap;
uniform float lightFallOff;
void main (void)
{
float distSqr = dot(lightVec, lightVec);
float att = clamp(1.0 - lightFallOff * sqrt(distSqr), 0.0, 1.0);
vec3 lVec = lightVec * inversesqrt(distSqr);
vec3 vVec = normalize(eyeVec);
vec4 base = texture2D(diffuseMap, texCoord.xy);
vec3 bump = normalize( texture2D(normalMap, texCoord.xy).xyz * 2.0 -
1.0);
vec4 vAmbient = gl_LightSource[0].ambient *
gl_FrontMaterial.ambient;
float diffuse = max( dot(lVec, bump), 0.0 );
vec4 vDiffuse = gl_LightSource[0].diffuse * gl_FrontMaterial.diffuse
*
diffuse;
float specular = pow(clamp(dot(reflect(-lVec, bump), vVec), 0.0,
1.0),
gl_FrontMaterial.shininess );
vec4 vSpecular = gl_LightSource[0].specular *
gl_FrontMaterial.specular *
specular;
vec3 color = vec3(( vAmbient*base +
vDiffuse*base +
vSpecular) * att);
gl_FragColor = vec4(color,gl_FrontMaterial.ambient.a);
gl_FragColor = mix(base, colour, gl_FrontMaterial.ambient.a);
gl_FragColor = vec4(1,0,0,1);
}
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert
Osfield
Sent: Friday, 12 June 2009 6:10 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] OSGSpotLight example on a GLSL material
Hi Bino,
I can't see how many of us will be able divine what is up with your
shaders as we have absolutely no knowledge of what you've put into
your shader. You question is equivalent to I have a piece of string
you can't see, but can you tell me exactly how long it is.
Try including the vertex and fragment shaders you are using then
others might have a chance of spotting what is up.
Robert.
On Fri, Jun 12, 2009 at 6:28 AM, Albino Rodriguesb...@vrspace.com.au
wrote:
Hi,
I have been using the OSGSpotLight example as a starting base to simulate
a
flashlight with success.
The scene I was using has now been updated to be drawn with a GLSL
NormalMap
shader (included as part of the .ive). The spotlight can no longer be
seen.
It does however appear to affect the general lighting of the area it's in,
but the spotlight and the texture image that goes with it can no longer be
seen.
Any ideas on how to get around this would be much appreciated.
Cheers,
Bino
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSGSpotLight example on a GLSL material
Hi, I have been using the OSGSpotLight example as a starting base to simulate a flashlight with success. The scene I was using has now been updated to be drawn with a GLSL NormalMap shader (included as part of the .ive). The spotlight can no longer be seen. It does however appear to affect the general lighting of the area it's in, but the spotlight and the texture image that goes with it can no longer be seen. Any ideas on how to get around this would be much appreciated. Cheers, Bino ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Multi Projector edge blend and bend (distortion correction)
Hi, I was wondering if OSG has distortion correction built in for multi projector displays so that the edges blend nicely. I vaguely recall reading that OSG has built in support for this but can't seem to find any information on it. (other than the post: http://www.mail-archive.com/osg-us...@openscenegraph.net/msg10361.html) Thanks in advance, Bino ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG MFC Fullscreen
Hi Simon, Thanks for the reply. I didn't have much luck with ChangeDisplaySettingsEx However, I found this http://www.codeguru.com/forum/showthread.php?t=363365 and it's worked quite well. It's a fake fullscreen where you hide components of your GUI and stretch the drawing window. It needs a bit of tweaking here and there. Bino From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simon Hammett Sent: Monday, 3 November 2008 7:11 PM To: OpenSceneGraph Users Subject: Re: [osg-users] OSG MFC Fullscreen Try ChangeDisplaySettingsEx Not sure how that interacts with MFC though. 2008/11/3 Albino Rodrigues [EMAIL PROTECTED] Hi, I've created an application based off the OSG MFC example. Does anyone know how to swap the rendering context between non full screen and full screen (where no GUI is visible)? I haven't had much luck researching on MSDN. Bino ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- The truth is out there. Usually in header files. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSG MFC Fullscreen
Hi, I've created an application based off the OSG MFC example. Does anyone know how to swap the rendering context between non full screen and full screen (where no GUI is visible)? I haven't had much luck researching on MSDN. Bino ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] ComputeIntersections problem
Hi all, I have just converted a number of applications from osg 2.2 to osg 2.61 and have found issues with computeIntersections. If I use y values relative to left/top (as 2.2) in the call they fail, but if I use y values relative to left/bottom in the call then everything works fine. Is this by design, or is there a bug in osg 2.61? Bino ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SpeedTree example
My apologizes for the late reply. You've no doubt got something working by
now.
The following is what I did to work out quickly how to get speed tree
working in OSG using a custom drawable. The lead coder has since taken this
and implemented it a much nicer fashion.
First of all, I recommend reading all the documentation. There's not too
much of it to go through. But it will help you plan the best way to
integrate osg for your needs and develop a workflow around it. Also go
through the reference application OpenGL example line by line. Make changes
here and there and see the effect of it.
If you plan on going down the custom drawable route, check out -
http://www.openscenegraph.org/projects/osg/attachment/wiki/Support/Tutorials
/Tuto10.zip
It's a good tutorial on custom drawables.
In essence, the implementation can be distilled like so:
- Create a speed tree forest
- Create a custom drawable to draw speed tree forest using the
reference application code
- Add custom drawable to a geode
- Add it to the scene
This implementation is by no means the best way of doing things. I chose
this for the following reasons:
- Easy to implement
- Suited my employer's immediate needs
We anticipate it will have troubles when we start creating scene with a lot
of alpha transparencies on objects. So if anyone reading has solved this
problem, I'd love to hear your method.
Before coding, I recommended creating a simple terrain model, and a
SpeedTree forest for this model in your modeling tool of choice.
Custom Drawable (ignore the dodgy formatting from copy\pasting):
virtual void drawImplementation(osg::RenderInfo renderInfo) const
{
float afProjection[16];
float afModelView[16];
glGetFloatv(GL_PROJECTION_MATRIX, afProjection);
glGetFloatv(GL_MODELVIEW_MATRIX, afModelView);
glPushAttrib(GL_ALL_ATTRIB_BITS);
//for obvious reasons, IDV code isn't shown.
//Update the forest camera
//Update time
//Draw
glPopAttrib();
//renderInfo.getState()-apply(); //needed?
}
//Based on Robert's advice. Return a default bounding box so that osg
doesn't cull this forest drawable
//This implementation relies solely on SpeedTree's culling and LODing
virtual osg::BoundingBox computeBound() const
{
osg::BoundingBox b;
return b;
}
Test Application (will just paste the relevant code):
int main()
{
//Create your osg stuff, root node etc
//Setup terrain model
//I couldn't find a way around this. You have to init glew.
//I can't remember what happens if you don't do this. but I suspect it's
less than ideal.
viewer-getCamera()-getGraphicsContext()-makeCurrent();
if (!bGlewInitialized)
{
GLenum err = glewInit( );
if (err != GLEW_OK)
{
printf(GLEW initialization failed: %s\n,
glewGetErrorString(err));
exit(-1);
}
}
//create your speed tree forests (again IDV code, so look at the reference
application). Store them in the supplied //vector if you need.
//you could of course do this in the custom drawable. I just happened to do
it here as I was following the reference
//application.
//set forest lighting
//populate from forest file
//set fog - horrible looking!
//set lod
//set projection
//set lod distances
//I then created an OSG stateset that replicated the reference app. But I
found it wasn't needed using
//the custom drawable code. Experiment.
//Create a Forest Drawable
forestDrawable-setUseDisplayList(false);
osg::Geode *fGeode = new osg::Geode();
//fGeode-setStateSet(speedTreeState);
fGeode-addDrawable(forestDrawable);
root-addChild(fGeode);
while(!viewer-done() )
{
viewer-frame();
}
}
You'll probably come across weird problems, but that's the probably the
easiest way to get SpeedTree into OSG. But keep in mind it's far from ideal.
So evaluate it to see if it meets your needs. Best of luck!
Bino
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Seppo
Laukkanen
Sent: Saturday, August 23, 2008 9:19 PM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] SpeedTree example
Hi!
I read from posts that people have been successful to integrate SpeedTree to
OSG at least by 1. alternative: Just use the opengl example from speedtree
and wrap it with a custom drawable..
Is it possible for someone who have accomplished this to put some short
example etc how to get started?
Thanks!
Seppo
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] SpeedTree4.1\OSG2.2 draw lagging
Hi, I have implemented SpeedTree4.1 as a custom drawable in OSG2.2. While the camera is stationary the trees appear to draw correctly. However once the camera moves, the trees rendering (translations?) appears to lag in relation to the rest of the scene. Once the camera stops, they catch up. In my test application, I integrate a speedtree forest into a custom drawable and have a simple terrain model loaded into a osg::Node. The scenegraph has a Group node as the root with the custom drawable and terrain as children. Screenshot of the scene with a stationary camera: The trees are rendering where they were placed. (feel free to admire the programmer art :) http://img293.imageshack.us/img293/5408/stationaryrv8.jpg Screenshot of the camera being moved down: Once the camera stops, the trees will catch up and the scene will render correctly like in the above screenshot. http://img242.imageshack.us/img242/764/lagmq5.jpg Implementation details: I've adapted my implementation using the reference application that comes with speedtree as it suits my needs pretty well. I'm happy to leave LODding and culling to speedtree. The drawImplementation of my custom drawable: (speed tree code is commented out in case it violates the license agreement. It's just a line of code.) glGetFloatv(GL_PROJECTION_MATRIX, projMat); glGetFloatv(GL_MODELVIEW_MATRIX, modelViewMat); glPushAttrib(GL_ALL_ATTRIB_BITS); //Draw speedtree forest //Update speedtree camera with the camera's position, projMat, modelViewMat and false as the final parameter. //Update wind glPopAttrib(); renderInfo.getState()-apply(); //needed? I set the boundingbox to be osg::BoundingBox bbox(0,0,0, 999, 999, 999); My rationale behind this is to make a HUGE box so that OSG doesn't try culling it. I leave that upto speedtree. Is there a better way? Finally, I set this drawable not to use display lists, so that the speedtree code called from drawImplementation always gets called. I haven't found a good strategy to solve this yet. - I've moved around API calls. - Look into forcing draw calls. - Forced OSG to not use multithreading - Prayed to some deity My next plan of attack will be to throw in the osgteapot custom drawable example and see if the same issue occurs but with teapots. Any ideas or thoughts are greatly appreciated. Bino ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SpeedTree4.1\OSG2.2 draw lagging
Hi Albino, why don't you //Update camera //Update speedtree forest //Draw forest Richard, you're a legend that worked! This might be hard to believe, but that was one of the ways I moved the API calls around (it makes sense afterall). I've just realized that Visual Studio, although compiling changes to my custom drawable... doesn't seem to do anything. I just noticed this by chance as a console debug statement wasn't reflecting my changes. A full rebuild has rectified that. Very strange. Very annoying. I think the lesson is to not follow the examples too blindly... The reference application probably has this issue but isn't noticeable since there isn't a terrain reference point. Hi Bino, I have no ideas why you trees are floating, too little code available to really have a go at what might be up. Sorry about that and thanks for the culling tip. Bino -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Schmidt, Richard Sent: Wednesday, August 20, 2008 11:46 PM To: OpenSceneGraph Users Subject: Re: [osg-users] SpeedTree4.1\OSG2.2 draw lagging Hi Albino, why don't you //Update camera //Update speedtree forest //Draw forest ??? Greetings, Richard Hi, I have implemented SpeedTree4.1 as a custom drawable in OSG2.2. While the camera is stationary the trees appear to draw correctly. However once the camera moves, the trees rendering (translations?) appears to lag in relation to the rest of the scene. Once the camera stops, they catch up. In my test application, I integrate a speedtree forest into a custom drawable and have a simple terrain model loaded into a osg::Node. The scenegraph has a Group node as the root with the custom drawable and terrain as children. Screenshot of the scene with a stationary camera: The trees are rendering where they were placed. (feel free to admire the programmer art :) http://img293.imageshack.us/img293/5408/stationaryrv8.jpg Screenshot of the camera being moved down: Once the camera stops, the trees will catch up and the scene will render correctly like in the above screenshot. http://img242.imageshack.us/img242/764/lagmq5.jpg Implementation details: I've adapted my implementation using the reference application that comes with speedtree as it suits my needs pretty well. I'm happy to leave LODding and culling to speedtree. The drawImplementation of my custom drawable: (speed tree code is commented out in case it violates the license agreement. It's just a line of code.) glGetFloatv(GL_PROJECTION_MATRIX, projMat); glGetFloatv(GL_MODELVIEW_MATRIX, modelViewMat); glPushAttrib(GL_ALL_ATTRIB_BITS); //Draw speedtree forest //Update speedtree camera with the camera's position, projMat, modelViewMat and false as the final parameter. //Update wind glPopAttrib(); renderInfo.getState()-apply(); //needed? I set the boundingbox to be osg::BoundingBox bbox(0,0,0, 999, 999, 999); My rationale behind this is to make a HUGE box so that OSG doesn't try culling it. I leave that upto speedtree. Is there a better way? Finally, I set this drawable not to use display lists, so that the speedtree code called from drawImplementation always gets called. I haven't found a good strategy to solve this yet. - I've moved around API calls. - Look into forcing draw calls. - Forced OSG to not use multithreading - Prayed to some deity My next plan of attack will be to throw in the osgteapot custom drawable example and see if the same issue occurs but with teapots. Any ideas or thoughts are greatly appreciated. Bino ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
