Re: [osg-users] OSG for Android
Hi Jorge, So, that means that I am doing thing in the correct order. After some more test I found out the problem: it's something in Cygwin. If I use relative paths instead of absolute ones everything works fine. No idea why and I don't want to investigate further, but at least now I know it's a cygwin-specific thing... Thanks! Luca -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42106#42106 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to manipulate node in loaded model.
Of course. I found solution by inserting POV between node, which i want to rotate/transform, and it's parent. It's work fine, but I'm not sure that this solution is correct. I mean, if i have 3d-model in 3ds/obj, what right way to manipulate one or few of its node? Victor -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42107#42107 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::Image Serialization
Hi Jeremy, 2011/8/18 Jeremy Moles jer...@emperorlinux.com: I'm not entirely sure this is accurate; if you look at osgimagesequence example, it lets you write the file out to disk: osgimagesequence -o foo.osgt ...but that file isn't readable by OSG. In fact, I had no trouble ever writing my custom Image to disk, only reading it back in. However, the serializer backend is very complex (or rather, quite abstracted away in macros), and so I've found it difficult to track down where exactly to investigate... So it may be a bug of image serializers. I'll try to catch up as soon as possible. I'm currently work on the latest chapter of my second OSG book and the dead line is coming. So I have to focus on the writing work this weekend. I will announce the progress of the book OpenSceneGraph Cookbook later in the community and then get back to the serializer problem with you. :-) Wang Rui ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSG 3.0.0 appearance of osg::Box changed when rendered in Wireframe mode?
Hi,
with OSG 2.8.2 we were able to create a cube like this and set polygon
mode to LINE. And it would show up as the outline
of a box with no diagonals in the faces.
With OSG 3.0.0 the same code produces a box that now contains diagonal
lines, as if the quads are now actually tesselated
into triangles.
Is there any compatibility flag that would allow us to get the old
behavior back?
Code snippets follow:
static osg::Geode* createCube(float fRadius,osg::Vec3 vPosition,
osg::Vec4 color)
{
// create a cube shape
osg::Box *bCube = new osg::Box(vPosition,fRadius);
// create a container that makes the cube drawable
osg::ShapeDrawable *sdCube = new osg::ShapeDrawable(bCube);
sdCube-setColor(color);
// create a geode object to as a container for our drawable cube object
osg::Geode* geodeCube = new osg::Geode();
// add our drawable cube to the geode container
geodeCube-addDrawable(sdCube);
return(geodeCube);
}
if (m_wireframeCube == NULL) m_wireframeCube = createCube(1.0,
osg::Vec3(0.0, 0.0, 0.5), osg::Vec4(0.5f, 0.5f, 0.5f, 1.0f));
//
// Wireframe box
//
osg::StateSet *state2 = new osg::StateSet();
state2-setMode( GL_LIGHTING, osg::StateAttribute::PROTECTED |
osg::StateAttribute::OFF );
m_transform2 = new osg::MatrixTransform;
m_transform2-setMatrix(osg::Matrix::scale(m_width, m_width,
m_height) * osg::Matrix::translate(position));
osg::PolygonMode *polyModeObj;
if ( !(polyModeObj = dynamic_cast osg::PolygonMode* (
state2-getAttribute( osg::StateAttribute::POLYGONMODE ))) ) {
state2-setAttribute( new osg::PolygonMode(
osg::PolygonMode::FRONT_AND_BACK, osg::PolygonMode::LINE ));
} else polyModeObj-setMode( osg::PolygonMode::FRONT_AND_BACK,
osg::PolygonMode::LINE );
osg::LineWidth *lineWidthObj;
if ( !(lineWidthObj = dynamic_cast osg::LineWidth* (
state2-getAttribute( osg::StateAttribute::LINEWIDTH ))) ) {
state2-setAttribute( new osg::LineWidth( 2.0f ) );
} else lineWidthObj-setWidth( 2.0f );
m_transform2-addChild(m_wireframeCube);
m_transform2-setStateSet(state2);
addChild(m_transform2);
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG 3.0.0 appearance of osg::Box changed when rendered in Wireframe mode?
Hi all,
I solved this by rolling my own geometry and dropping the use of
osg::Box. This function replaces the createCube function from the
previously posted code snippet.
I simply define my own color, vertex and normal buffer using Quad primitives.
Now the wireframe looks sane again.
static osg::Geode* createCube(float fRadius, osg::Vec3 vPosition,
osg::Vec4 color)
{
osg::Geode* geode = new osg::Geode();
osg::Geometry* cubeGeom = new osg::Geometry();
osg::Vec4Array *colors = new osg::Vec4Array;
colors-push_back(color);
// define normals for each face
osg::ref_ptrosg::Vec3Array cube_normals = new osg::Vec3Array;
cube_normals-push_back(osg::Vec3( 0.0f,-1.0f, 0.0f));
cube_normals-push_back(osg::Vec3( 0.0f,-1.0f, 0.0f));
cube_normals-push_back(osg::Vec3( 0.0f,-1.0f, 0.0f));
cube_normals-push_back(osg::Vec3( 0.0f,-1.0f, 0.0f));
cube_normals-push_back(osg::Vec3( 0.0f,+1.0f, 0.0f));
cube_normals-push_back(osg::Vec3( 0.0f,+1.0f, 0.0f));
cube_normals-push_back(osg::Vec3( 0.0f,+1.0f, 0.0f));
cube_normals-push_back(osg::Vec3( 0.0f,+1.0f, 0.0f));
cube_normals-push_back(osg::Vec3(+1.0f,+0.0f, 0.0f));
cube_normals-push_back(osg::Vec3(+1.0f,+0.0f, 0.0f));
cube_normals-push_back(osg::Vec3(+1.0f,+0.0f, 0.0f));
cube_normals-push_back(osg::Vec3(+1.0f,+0.0f, 0.0f));
cube_normals-push_back(osg::Vec3(-1.0f,+0.0f, 0.0f));
cube_normals-push_back(osg::Vec3(-1.0f,+0.0f, 0.0f));
cube_normals-push_back(osg::Vec3(-1.0f,+0.0f, 0.0f));
cube_normals-push_back(osg::Vec3(-1.0f,+0.0f, 0.0f));
cube_normals-push_back(osg::Vec3( 0.0f,+0.0f,-1.0f));
cube_normals-push_back(osg::Vec3( 0.0f,+0.0f,-1.0f));
cube_normals-push_back(osg::Vec3( 0.0f,+0.0f,-1.0f));
cube_normals-push_back(osg::Vec3( 0.0f,+0.0f,-1.0f));
cube_normals-push_back(osg::Vec3( 0.0f,+0.0f,+1.0f));
cube_normals-push_back(osg::Vec3( 0.0f,+0.0f,+1.0f));
cube_normals-push_back(osg::Vec3( 0.0f,+0.0f,+1.0f));
cube_normals-push_back(osg::Vec3( 0.0f,+0.0f,+1.0f));
vPosition += osg::Vec3(+fRadius/2, +fRadius/2, +fRadius/2);
// note, counterclockwise winding order with respect to normals
osg::Vec3 myCoords[] =
{
// bottom face
osg::Vec3(-fRadius, -fRadius, -fRadius) + vPosition,
osg::Vec3(+fRadius, -fRadius, -fRadius) + vPosition,
osg::Vec3(+fRadius, -fRadius, +fRadius) + vPosition,
osg::Vec3(-fRadius, -fRadius, +fRadius) + vPosition,
// top face
osg::Vec3(-fRadius, +fRadius, +fRadius) + vPosition,
osg::Vec3(+fRadius, +fRadius, +fRadius) + vPosition,
osg::Vec3(+fRadius, +fRadius, -fRadius) + vPosition,
osg::Vec3(-fRadius, +fRadius, -fRadius) + vPosition,
// right face
osg::Vec3(+fRadius, -fRadius, -fRadius) + vPosition,
osg::Vec3(+fRadius, +fRadius, -fRadius) + vPosition,
osg::Vec3(+fRadius, +fRadius, +fRadius) + vPosition,
osg::Vec3(+fRadius, -fRadius, +fRadius) + vPosition,
// left face
osg::Vec3(-fRadius, -fRadius, +fRadius) + vPosition,
osg::Vec3(-fRadius, +fRadius, +fRadius) + vPosition,
osg::Vec3(-fRadius, +fRadius, -fRadius) + vPosition,
osg::Vec3(-fRadius, -fRadius, -fRadius) + vPosition,
// front face
osg::Vec3(-fRadius, +fRadius, -fRadius) + vPosition,
osg::Vec3(+fRadius, +fRadius, -fRadius) + vPosition,
osg::Vec3(+fRadius, -fRadius, -fRadius) + vPosition,
osg::Vec3(-fRadius, -fRadius, -fRadius) + vPosition,
// back face
osg::Vec3(-fRadius, -fRadius, +fRadius) + vPosition,
osg::Vec3(+fRadius, -fRadius, +fRadius) + vPosition,
osg::Vec3(+fRadius, +fRadius, +fRadius) + vPosition,
osg::Vec3(-fRadius, +fRadius, +fRadius) + vPosition
};
int numCoords = sizeof(myCoords)/sizeof(osg::Vec3);
osg::Vec3Array* vertices = new osg::Vec3Array(numCoords,myCoords);
cubeGeom-setVertexArray(vertices);
cubeGeom-addPrimitiveSet(new
osg::DrawArrays(osg::PrimitiveSet::QUADS,0,numCoords));
cubeGeom-setColorArray(colors);
cubeGeom-setColorBinding(osg::Geometry::BIND_OVERALL);
cubeGeom-setNormalArray(cube_normals.get());
cubeGeom-setNormalBinding(osg::Geometry::BIND_PER_VERTEX);
geode-addDrawable(cubeGeom);
return geode;
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Multi GPU Rendering
Hello, I would like to know if OSG can benefit of a PC with several GPU ? I mean, Can we say this part will be rendered by GPU 1 and the other by GPU 2 ? Thank you. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42112#42112 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgAndroidExampleGLES1 and 2 error on Android 3.x device
Hi Jorge,
I've added some Log as you suggested, and apparently as soon as it construct
the osgMainApp native object, something goes wrong.
In particular I've added a log in the EGL Renderer like this:
public void onSurfaceChanged(GL10 gl, int width, int height)
{
Log.e(TAG, BEFORE_NATIVE_INIT);
osgNativeLib.init(width, height);
}
and one log in the init() method of osgNativeLib.cpp like this:
JNIEXPORT void JNICALL Java_osg_AndroidExample_osgNativeLib_init(JNIEnv *
env, jobject obj, jint width, jint height)
{
__android_log_write(ANDROID_LOG_ERROR, OSGANDROID,
NATIVE_INIT_CODE);
mainApp.initOsgWindow(0,0,width,height);
}
Finally, I've also added 2 log as first and last instruction of the
OsgMainApp ctor (in the cpp file):
OsgMainApp::OsgMainApp()
{
__android_log_write(ANDROID_LOG_ERROR, OSGANDROID,
OSG_MAIN_APP_CTOR_BEGIN);
_lodScale = 1.0f;
_prevFrame = 0;
_initialized = false;
_clean_scene = false;
__android_log_write(ANDROID_LOG_ERROR, OSGANDROID,
OSG_MAIN_APP_CTOR_END);
}
What happens is that BEFORE_NATIVE_INIT is printed, the 2 logs in the cpp
ctor are printed as well,
but NOT he NATIVE_INIT_CODE, which suggests some error related to the
native object right after it's created.
The new logcat is in attach.
One more info is that I've tried to build all the example with both 2.3.3
and 3.1 target profile, and they show the same problem on the tablet.
I've tried as well to modify manually the minimum and target version of the
sdk in the AndroidManifest.xml but nothing changed.
Ricky
P.S. I'll run some more tests today, but since tomorrow I'll be in vacation
for a couple of weeks =) My colleague Luca will run some tests and follow
this thread while I'm away. Thank you.
On Wed, Aug 17, 2011 at 18:44, Jorge Izquierdo Ciges jori...@gmail.comwrote:
Well it's easy... there are some debug messages that I put them because the
obscureness and difficulties to find some error so usually the trace should
have first the message:
08-16 15:59:29.331: WARN/EGLview(4904): creating OpenGL ES 1 context
That message come from the EGL java class WHICH initializes the GLES context.
That message is in your logs. Now when you have the context the method
onSurfaceCreated is called and it's a do nothing in my example, for more
complex programs the correct initialization should be done there and the
surfaceChange have another initialization code, because that function is
called when you change possition on your device and on other places. So they
should not have the same code.
When you enter onSurfaceChanged, that's when OSG initializes everything so
NOW we have the BIG trouble. the init function goes through a JNI bridge
(init function) and calls the function initOsgWindow of mainApp.
Inside initOsgWindow there's another LOG that should write. It's the FIRST
instruction and it is dispatchet through __android_log_write so that will
ever show whathever happens.
Initializing geometry
If you don't see that Log entry then no OSG code has been used.
Then Maybe it's the same strange bug that Rafa told me once (he could fix it
for his samsung) but since 2.2 that bug dissapeared... And i don't know e
Now you should test if the application can reach the JNI bridge, put some
__android_log_write in the osgNativeLib in the init function after and before
calling the osg function.
And about the log that's just the full heap. There are some manuals if you
want to know more to translate to code but just by looking what I've said to
you... it's a strange bug.
2011/8/17 Riccardo Corsi riccardo.co...@kairos3d.it
Hi Jorge,
I've set some breakpoints and stepped into the java code with the
debugger.
From the GLThread these methods are called in this order:
- EGLView::onSurfaceCreated()
- EGLView::onSurfaceChanged()
Inside onSurfaceChanged(), when it calls the native method
osgNativeLib.init(), it exits and thus never reaches onDrawFrame() is never
reached.
Ricky
P.S. By the way... how did you get that info from the logcat? it's still
quite obscure to me...
On Wed, Aug 17, 2011 at 16:38, Jorge Izquierdo Ciges
jori...@gmail.comwrote:
That's one hell of a error. ¡He doesn't reach the initOsgWindow function!
I've never seen it, but I have some ideas. First it's the same error for
both of them. This must be some Native compatibility isue. I've heard that
the EglView in which the example is based has some troubles with some
devices but no one has said something solid about it. So, try to check by
debug or just Log (quicker) which methods of the EGLview.java if onDraw is
calle before onSurfaceChange or if onSurfaceChanged is never called we'll
hace to see if there has been some changes in the API that requiere a SDK
target version on the manifest. If not... well we'll see.
2011/8/17 Riccardo Corsi riccardo.co...@kairos3d.it
Hi Jorge and all,
I start a new thread as I
Re: [osg-users] OSG 3.0.0 appearance of osg::Box changed when rendered in Wireframe mode?
On 8/18/2011 4:28 AM, Christian Buchner wrote: Hi, with OSG 2.8.2 we were able to create a cube like this and set polygon mode to LINE. And it would show up as the outline of a box with no diagonals in the faces. With OSG 3.0.0 the same code produces a box that now contains diagonal lines, as if the quads are now actually tesselated into triangles. Right. The GL_QUADS primitive was removed in OpenGL 3.1. The OSG ShapeDrawable code was modified to use triangles so that the same code path could be used for both GL 3x and GL 1x/2x. Is there any compatibility flag that would allow us to get the old behavior back? For ShapeDrawable? Not that I know of. However, osgworks.googlecode.com offers a Geometry-based version of OSG's ShapeDrawables, and the makeWireBox function will produce results similar to what you are used to seeing, so you might want to consider that. osgWorks is compatible with OSG v2.6 through current v3.0.1. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgAndroidExampleGLES1 and 2 error on Android 3.x device
Ok. I was thinking that the error would be in the JNI bridge. I think there are some changes about how android treats native processes. There is a mode to debug JNI by the way which gives more info. 2011/8/18 Riccardo Corsi riccardo.co...@kairos3d.it One more info is that I've tried to build all the example with both 2.3.3 and 3.1 target profile, and they show the same problem on the tablet. I've tried as well to modify manually the minimum and target version of the sdk in the AndroidManifest.xml but nothing changed. Ricky P.S. I'll run some more tests today, but since tomorrow I'll be in vacation for a couple of weeks =) My colleague Luca will run some tests and follow this thread while I'm away. Thank you. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] web page down
Hi all -- The OSG web page is inaccessible from the Americas, and has been so for several hours how. Can someone reboot the server please? :-) -- -Paul Martz Skew Matrix Software http://www.skew-matrix.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SIGGRAPH 2011 OpenSceneGraph BOF
Hello Jean-Sébastien and David and Robert, Thanks for presenting [Robert via Jean-Sébastien]. Yes, it was a standing room only crowd. Also thanks to Jean-Sébastien for talking at the Computer Graphics for Simulation BOF that afternoon. There was a possibility that the webinar [COMSOL multiphysics] I had arranged would experience technical difficulties and lead to silent conversion of oxygen to carbon monoxide. However, the webinar proceeded [Jean-Sébastien was able to decipher my speaker connection drawing to correct acoustic connections]. Maybe a podcast next year..:) The COMSOL multiphysics talk focused on hard core simulation on a small scale [example: a room or small machine,...]. Jean-Sébastien's talk was a repeat [extended since he had more time] of the Vortex simulation SDK and Robot simulations plus examples he talked about in the OSG BOF. In the OSG BOF he focused more on OSG, OpenGL and compiling and less on Vortex. This was simulation on a larger scale [a mine, vehicle dynamics,...] than the standard COMSOL spatial domain. Just look over his presentation on the wiki and imagine him talking more on the simulation part of the talk in the OSG BOF. Vortex - check it out I gave a short Simulation year in review talk that summarized some trends in research from several simulation conferences. However, I would not have been able to speak for an hour so thanks again Jean-Sébastien. Macintosh Binaries from Alpha Pixel The execute bit has to be set manually. Not a horrible issue. The package also in some cases is a 7zip package so the Mac user has to have Stuffit Deluxe or WinZip to extract. Perhaps a command line will extract. 7zip is not on the Mac. Probably needs a tutorial on running the executables from the terminal command line. We [Jean-Sébastien, David, me] could not figure out the syntax for the command [path's to be set,,etc.]. John F. Richardson -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien Guay Sent: Friday, August 12, 2011 7:49 AM To: OpenSceneGraph Users Subject: [osg-users] SIGGRAPH 2011 OpenSceneGraph BOF SNIP - to save bandwidth... smime.p7s Description: S/MIME cryptographic signature ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SIGGRAPH 2011 OpenSceneGraph BOF
On 8/18/2011 4:00 PM, John Richardson wrote: Macintosh Binaries from Alpha Pixel The execute bit has to be set manually. Not a horrible issue. The package also in some cases is a 7zip package so the Mac user has to have Stuffit Deluxe or WinZip to extract. Perhaps a command line will extract. 7zip is not on the Mac. Probably needs a tutorial on running the executables from the terminal command line. We [Jean-Sébastien, David, me] could not figure out the syntax for the command [path's to be set,,etc.]. I'll check with my Mac build guy about improving this. We're not heavy Mac users, so advice is welcomed. -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://www.alphapixel.com/ Digital Imaging. OpenGL. Scene Graphs. GIS. GPS. Training. Consulting. Contracting. There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
