Re: [osg-users] Problems with loading model in OSG 2.2
Hi Ricky, 2.x shouldn't be slower than 1.2, if it is then this suggests that perhaps you are comparing debug build vs release build, or that the graphics window that's been allocated is forcing the OpenGL driver to run with software rendering. You really need to pass on what hardware/drivers you are using, there is little chance of anyone else being able to divine what is wrong. Robert. On Tue, Jun 17, 2008 at 9:42 PM, Ricky [EMAIL PROTECTED] wrote: Thank Jean-Sébastien and Robert. I've done it. But now my problem is: when I debug, there're many command lines appearing on the console window: Where is it from and can I get rid of it? And the second problem: although I only loaded a model but a program run really slow, with low frame when i rotate or zoom the object. It worked well and fast in OSG 1.2 So can I improve this? Thank you! ___ 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] PSSM : Win32 users, please test latest version (SVN)
Hi Adrain, In future could you specify what your package contains, i.e. binaries for running under Windows, as I downloaded expecting to find a test model or two, or source code, but only got a bunch of dll's and .exe's. Alas not much use for over half the user base that don't use Windows. W.r.t PSSM update's I should get these reviewed today. Robert. On Mon, Jun 16, 2008 at 1:07 PM, Adrian Egli OpenSceneGraph (3D) [EMAIL PROTECTED] wrote: hi all http://webaddon3d.assoftware.ch/AE/PSSM_SHADOW_TEST_OpenSceneGraph_WIN32.rar please test latest version, this version is the version a asked robert to commit into SVN, should produce correct PSSM shadow regards adrian -- Adrian Egli ___ 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] Upgrading from version 1.2 and Producer using Visual Studio
Hi Rick, On Wed, Jun 18, 2008 at 12:12 AM, Rick Pingry [EMAIL PROTECTED] wrote: Producer::KeyboardMouse::positionPointer( float x, float y ) Any way to set the mouse position like this? GraphicsWindow::requestWarpPointer(x,y); and View::requestWarpPointer(x,y); The later will automatically work out which window to warp to. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Add get/setCoordinateSystemType to osg::CoordinateSystemNode?
Robert, I propose that osg::CoordinateSystemNode should have the same get/setCoordinateSystemType() methods that are found in osgTerrain::Locator. Without them, it is not possible to differentiate between a geocentric and a projected plate carre projection. If you agree, I will submit the change. Thanks. Glenn -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : 703-652-4791 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Add get/setCoordinateSystemType to osg::CoordinateSystemNode?
On Wed, Jun 18, 2008 at 12:41 PM, Glenn Waldron [EMAIL PROTECTED] wrote: Robert, I propose that osg::CoordinateSystemNode should have the same get/setCoordinateSystemType() methods that are found in osgTerrain::Locator. Without them, it is not possible to differentiate between a geocentric and a projected plate carre projection. If you agree, I will submit the change. Thanks. I have no objection, the only thing to be wary of is if the coordinate system string and the type disagree - this would be a garbage in/garbage out issue, if the user sets things correctly, they will agree, if they mess up there won't be an automatic way of checking i.e. you'd need something like PROJ to check. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] question about osg::image
Hi i´ve created an osg::image and i want to call the method allocateImage to allocate memory for the image data void allocateImage (int s, int t, int r, GLenum pixelFormat, GLenum type, int packing=1) my problem is that i can´t find a list of valid GLenum pixelFormat values and the same for GLenum type in the osg::image header file i can see this macros declared at the beginning #define GL_BGR 0x80E0 #define GL_BGRA 0x80E1 #define GL_UNSIGNED_BYTE_3_3_2 0x8032 #define GL_UNSIGNED_BYTE_2_3_3_REV 0x8362 #define GL_UNSIGNED_SHORT_5_6_5 0x8363 #define GL_UNSIGNED_SHORT_5_6_5_REV 0x8364 #define GL_UNSIGNED_SHORT_4_4_4_4 0x8033 #define GL_UNSIGNED_SHORT_4_4_4_4_REV 0x8365 #define GL_UNSIGNED_SHORT_5_5_5_1 0x8034 #define GL_UNSIGNED_SHORT_1_5_5_5_REV 0x8366 #define GL_UNSIGNED_INT_8_8_8_8 0x8035 #define GL_UNSIGNED_INT_8_8_8_8_REV 0x8367 #define GL_UNSIGNED_INT_10_10_10_2 0x8036 #define GL_UNSIGNED_INT_2_10_10_10_REV 0x8368 i want to create RGBA, RGB and Alpha (1byte per pixel) images and don´t know which parameters to use i guess that the pixel format is GL_BGR and GL_BGRA for the first two ones, but no idea of how to declare a just alpha image what is the GLenum type parameter??? thanks _ MSN Noticias http://noticias.msn.es/comunidad.aspx___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] question about osg::image
Hi David, You could take a look at an OpenGL manual page/examples since the same parameters need to be used for osg. regards Raymond David _ wrote: Hi i´ve created an osg::image and i want to call the method allocateImage to allocate memory for the image data void allocateImage http://www.openscenegraph.org/documentation/OpenSceneGraphReferenceDocs/a01233.html#a12 (int s, int t, int r, GLenum pixelFormat, GLenum type, int packing=1) my problem is that i can´t find a list of valid GLenum pixelFormat values and the same for GLenum type in the osg::image header file i can see this macros declared at the beginning #define GL_BGR 0x80E0 #define GL_BGRA 0x80E1 #define GL_UNSIGNED_BYTE_3_3_2 0x8032 #define GL_UNSIGNED_BYTE_2_3_3_REV 0x8362 #define GL_UNSIGNED_SHORT_5_6_5 0x8363 #define GL_UNSIGNED_SHORT_5_6_5_REV 0x8364 #define GL_UNSIGNED_SHORT_4_4_4_4 0x8033 #define GL_UNSIGNED_SHORT_4_4_4_4_REV 0x8365 #define GL_UNSIGNED_SHORT_5_5_5_1 0x8034 #define GL_UNSIGNED_SHORT_1_5_5_5_REV 0x8366 #define GL_UNSIGNED_INT_8_8_8_8 0x8035 #define GL_UNSIGNED_INT_8_8_8_8_REV 0x8367 #define GL_UNSIGNED_INT_10_10_10_2 0x8036 #define GL_UNSIGNED_INT_2_10_10_10_REV 0x8368 i want to create RGBA, RGB and Alpha (1byte per pixel) images and don´t know which parameters to use i guess that the pixel format is GL_BGR and GL_BGRA for the first two ones, but no idea of how to declare a just alpha image what is the GLenum type parameter??? thanks Tecnología, moda, motor, viajes,.suscríbete a nuestros boletines para estar siempre a la última MSN Newsletters http://newsletters.msn.com/hm/maintenanceeses.asp?L=ESC=ESP=WCMaintenanceBrand=WLRU=http%3a%2f%2fmail.live.com ___ 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] Add get/setCoordinateSystemType to osg::CoordinateSystemNode?
On Wed, Jun 18, 2008 at 8:06 AM, Robert Osfield [EMAIL PROTECTED] wrote: On Wed, Jun 18, 2008 at 12:41 PM, Glenn Waldron [EMAIL PROTECTED] wrote: Robert, I propose that osg::CoordinateSystemNode should have the same get/setCoordinateSystemType() methods that are found in osgTerrain::Locator. Without them, it is not possible to differentiate between a geocentric and a projected plate carre projection. If you agree, I will submit the change. Thanks. I have no objection, the only thing to be wary of is if the coordinate system string and the type disagree - this would be a garbage in/garbage out issue, if the user sets things correctly, they will agree, if they mess up there won't be an automatic way of checking i.e. you'd need something like PROJ to check. The real issue that I'm facing is this: when you use osgdem with WGS84 input data, but without the --geocentric flag, you get a database with a projected coordinate system (specifically Plate Carree projection). However, the CoordinateSystemNode reports a WGS84 WKT, and the osgTerrain::Locator node reports WGS84/PROJECTED (a type disagreement) -- both of which I would argue are incorrect. In this scenario, the WKT should actually be a variant of this: PROJCS[World_Plate_Carree,GEOGCS[GCS_WGS_1984,DATUM[D_WGS_1984,SPHEROID[WGS_1984,6378137,298.257223563]],PRIMEM[Greenwich,0],UNIT[Degree,0.017453292519943295]],PROJECTION[Equirectangular],PARAMETER[False_Easting,0],PARAMETER[False_Northing,0],PARAMETER[Central_Meridian,0],UNIT[Meter,1]] Now, when you do use --geocentric, the WGS84 WKT is OK since one can assume that this implies a geocentric database (since the OSG cannot use angular coordinates :) Anyway I guess this is more of a VPB issue. I appreciate your thoughts on the matter. Glenn -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : 703-652-4791 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] question about osg::image
David _ wrote: Hi i´ve created an osg::image and i want to call the method allocateImage to allocate memory for the image data void allocateImage http://www.openscenegraph.org/documentation/OpenSceneGraphReferenceDocs/a01233.html#a12 (int s, int t, int r, GLenum pixelFormat, GLenum type, int packing=1) my problem is that i can´t find a list of valid GLenum pixelFormat values and the same for GLenum type in the osg::image header file i can see this macros declared at the beginning These are just copies of the ones defined by the OpenGL headers. #define GL_BGR 0x80E0 #define GL_BGRA 0x80E1 #define GL_UNSIGNED_BYTE_3_3_2 0x8032 #define GL_UNSIGNED_BYTE_2_3_3_REV 0x8362 #define GL_UNSIGNED_SHORT_5_6_5 0x8363 #define GL_UNSIGNED_SHORT_5_6_5_REV 0x8364 #define GL_UNSIGNED_SHORT_4_4_4_4 0x8033 #define GL_UNSIGNED_SHORT_4_4_4_4_REV 0x8365 #define GL_UNSIGNED_SHORT_5_5_5_1 0x8034 #define GL_UNSIGNED_SHORT_1_5_5_5_REV 0x8366 #define GL_UNSIGNED_INT_8_8_8_8 0x8035 #define GL_UNSIGNED_INT_8_8_8_8_REV 0x8367 #define GL_UNSIGNED_INT_10_10_10_2 0x8036 #define GL_UNSIGNED_INT_2_10_10_10_REV 0x8368 i want to create RGBA, RGB and Alpha (1byte per pixel) images and don´t know which parameters to use i guess that the pixel format is GL_BGR and GL_BGRA for the first two ones, but no idea of how to declare a just alpha image what is the GLenum type parameter??? From my /usr/include/GL/gl.h /* PixelFormat */ #define GL_COLOR_INDEX0x1900 #define GL_STENCIL_INDEX 0x1901 #define GL_DEPTH_COMPONENT0x1902 #define GL_RED0x1903 #define GL_GREEN 0x1904 #define GL_BLUE 0x1905 #define GL_ALPHA 0x1906 #define GL_RGB0x1907 #define GL_RGBA 0x1908 #define GL_LUMINANCE 0x1909 #define GL_LUMINANCE_ALPHA0x190A /* PixelType */ #define GL_BITMAP 0x1A00 /* GL_BYTE */ /* GL_UNSIGNED_BYTE */ /* GL_SHORT */ /* GL_UNSIGNED_SHORT */ /* GL_INT */ /* GL_UNSIGNED_INT */ /* GL_FLOAT */ /* GL_UNSIGNED_BYTE_3_3_2_EXT */ /* GL_UNSIGNED_SHORT_4_4_4_4_EXT */ /* GL_UNSIGNED_SHORT_5_5_5_1_EXT */ /* GL_UNSIGNED_INT_8_8_8_8_EXT */ /* GL_UNSIGNED_INT_10_10_10_2_EXT */ At least, I think these are the right ones :) The defined like GL_BYTE, etc. are commented out because they're already defined earlier (under DataType). Paul PS I think you can find the official values through this (http://opengl.org/registry/api) page. The enums are defined in http://opengl.org/registry/api/enum.spec, but it's a bit hard to digest. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] question about osg::image
problem solved thanks Date: Wed, 18 Jun 2008 14:25:58 +0200 From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] question about osg::image Hi David, You could take a look at an OpenGL manual page/examples since the same parameters need to be used for osg. regards Raymond David _ wrote: Hi i´ve created an osg::image and i want to call the method allocateImage to allocate memory for the image data void allocateImage http://www.openscenegraph.org/documentation/OpenSceneGraphReferenceDocs/a01233.html#a12 (int s, int t, int r, GLenum pixelFormat, GLenum type, int packing=1) my problem is that i can´t find a list of valid GLenum pixelFormat values and the same for GLenum type in the osg::image header file i can see this macros declared at the beginning #define GL_BGR 0x80E0 #define GL_BGRA 0x80E1 #define GL_UNSIGNED_BYTE_3_3_2 0x8032 #define GL_UNSIGNED_BYTE_2_3_3_REV 0x8362 #define GL_UNSIGNED_SHORT_5_6_5 0x8363 #define GL_UNSIGNED_SHORT_5_6_5_REV 0x8364 #define GL_UNSIGNED_SHORT_4_4_4_4 0x8033 #define GL_UNSIGNED_SHORT_4_4_4_4_REV 0x8365 #define GL_UNSIGNED_SHORT_5_5_5_1 0x8034 #define GL_UNSIGNED_SHORT_1_5_5_5_REV 0x8366 #define GL_UNSIGNED_INT_8_8_8_8 0x8035 #define GL_UNSIGNED_INT_8_8_8_8_REV 0x8367 #define GL_UNSIGNED_INT_10_10_10_2 0x8036 #define GL_UNSIGNED_INT_2_10_10_10_REV 0x8368 i want to create RGBA, RGB and Alpha (1byte per pixel) images and don´t know which parameters to use i guess that the pixel format is GL_BGR and GL_BGRA for the first two ones, but no idea of how to declare a just alpha image what is the GLenum type parameter??? thanks Tecnología, moda, motor, viajes,.suscríbete a nuestros boletines para estar siempre a la última MSN Newsletters http://newsletters.msn.com/hm/maintenanceeses.asp?L=ESC=ESP=WCMaintenanceBrand=WLRU=http%3a%2f%2fmail.live.com ___ 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 _ MSN Noticias http://noticias.msn.es/comunidad.aspx___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] question about osg::image
See your GL header GL/gl.h this is were you will find most defines as per OGL 1.2 ( maybe 1.4), after that you have to look in the extension headers _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David _ Sent: Wednesday, June 18, 2008 8:15 AM To: osg-users@lists.openscenegraph.org Subject: [osg-users] question about osg::image Hi i´ve created an osg::image and i want to call the method allocateImage to allocate memory for the image data void allocateImage http://www.openscenegraph.org/documentation/OpenSceneGraphReferenceDocs/a01 233.html#a12 (int s, int t, int r, GLenum pixelFormat, GLenum type, int packing=1) my problem is that i can´t find a list of valid GLenum pixelFormat values and the same for GLenum type in the osg::image header file i can see this macros declared at the beginning #define GL_BGR 0x80E0 #define GL_BGRA 0x80E1 #define GL_UNSIGNED_BYTE_3_3_2 0x8032 #define GL_UNSIGNED_BYTE_2_3_3_REV 0x8362 #define GL_UNSIGNED_SHORT_5_6_5 0x8363 #define GL_UNSIGNED_SHORT_5_6_5_REV 0x8364 #define GL_UNSIGNED_SHORT_4_4_4_4 0x8033 #define GL_UNSIGNED_SHORT_4_4_4_4_REV 0x8365 #define GL_UNSIGNED_SHORT_5_5_5_1 0x8034 #define GL_UNSIGNED_SHORT_1_5_5_5_REV 0x8366 #define GL_UNSIGNED_INT_8_8_8_8 0x8035 #define GL_UNSIGNED_INT_8_8_8_8_REV 0x8367 #define GL_UNSIGNED_INT_10_10_10_2 0x8036 #define GL_UNSIGNED_INT_2_10_10_10_REV 0x8368 i want to create RGBA, RGB and Alpha (1byte per pixel) images and don´t know which parameters to use i guess that the pixel format is GL_BGR and GL_BGRA for the first two ones, but no idea of how to declare a just alpha image what is the GLenum type parameter??? thanks _ Tecnología, moda, motor, viajes,.suscríbete a nuestros boletines para estar siempre a la última MSN Newsletters http://newsletters.msn.com/hm/maintenanceeses.asp?L=ESC=ESP=WCMaintenance Brand=WLRU=http%3a%2f%2fmail.live.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] problem with osg 2.4 stable release
Hi J-S I have the same problem of David load png file problem. I put the libpng13.dll in the same directory of osgdb_png.dll but in visual studio output window the dll is called anytime I try to read a png and then unloaded after the operation. Do you have an other solution? Best regards ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] problem using camera and matrix
Hi all,
I am working on a program which display a little map of a particular
place.
I know the question has been already asked but I really don't
understand how to proceed.
I would like use 3d space navigator which is mapped like a simple
joystick
(with RBC9-SpaceNav driver),
values' access from axes can do with variables : etat.lX, etat.lY,
etat.lZ for translation and
etat.lRx, etat.lRy, etat.lRz for rotation which give a value between 0
and 360.
I use directinput to enable joystick too.
so, here's the problem, i want control main camera (as an helicopter)
movements of this camera moves the point of view and not the map.
I saw I don't declare a trackball/flight/..manipulator but
on the main loop I must do something like that :
DIJOYSTATE2 etat;
Matrixd, myViewMatrix, camRot, camTrans;
viewer.realize();
while(!viewer.done())
{
//Recover joystick's state
joystick-etatsJoystick(etat);
camRot.makeRotate(degreesToRadians(etat.lRx),Vec3(1,0,0),
degreesToRadians(etat.lRy),Vec3(0,0,1),
degreesToRadians(etat.lRz),Vec3(0,1,0)
);
camTrans.makeTranslate(etat.lX,etat.lZ,etat.lY);
myViewMatrix = camRot*camTrans;
viewer.getCamera()-setViewMatrix(myViewMatrix);
viewer.frame();
}
1) my map is not centered like when i use trackball/Flight/
terrain...Manipulator
so how to do to center my object in the middle of the screen ?
I initialize object with positionAttitudetransform with a 60°deg
rotation of x-axis.
2) How to keep the last position when I release 3d mouse ?
at this time, when I release, object takes his initial position.
these questions comes from missunderstanding of osg and algorithmic/
logic problems.
thanks for reading.. and answering.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenFlight exporter question
Thanks for keeping me on my toes, Gordon. :-) Hmm... I just went back and re-read the FLT spec section regarding LOD Records. Throughout the description, the spec refers to distance calculations and switch in/out distances, implying strongly that distance is the only way to change active LODs. Finally, the section ends with the following (arguably cryptic) text: Significant size is a value used to calculate switch in and out distances based on viewing parameters of your simulation display system. This value is used internally by MultiGen-Paradigm and will be enhanced in future versions of OpenFlight. So this is just for internal use. We can hijack this field if we want, but it's vague enough (based on viewing parameters of your simulation display system) that, if ever exposed for public use, this field could be used for just about anything. I'm not trying to get out of doing work, and it would be trivial to map OSG's pixel size on screen to this field. But the 16.1 spec language doesn't convince me that this is the right thing to do. If I'm way off base, please correct me... -Paul Hi Paul Err Creator/Openflight does support this ;) it's called 'Significant Size', which is a single value. On the Open Flight LOD node Obviously it up to the scene graph what field means ;), the OSG flight loader may not support this ( not checked ), so to support it Changes may need to be made to the read and write __ Gordon Tomlinson Email : [EMAIL PROTECTED] YIM/AIM : gordon3dBrit MSN IM : [EMAIL PROTECTED] Website : www.vis-sim.com www.gordontomlinson.com __ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Monday, June 16, 2008 11:04 PM To: [EMAIL PROTECTED]; 'OpenSceneGraph Users' Subject: Re: [osg-users] OpenFlight exporter question Hi Brian -- Your LOD node is configured to switch children based on screen size. OpenFlight doesn't support this. You'll need to re-model the LODs using eye distance. The LOD exporter should probably display a warning in this case, but as I am in the middle of a vacation, I won't be able to make that change immediately. Could you please add the warning message and post to osg-submissions? Thanks. -Paul Hi Paul, Yes, I thought about the version possibly being an issue, so I downloaded 2.5.2 but saw the same problem. Back a few months ago, I was given a sample LOD OSG file. As a test I ran the converter against it, but it also had the same problem. I've attached the file that Hans Elbers provided me and am curious as to whether its format is correct in terms of the converter. Are there any command line switches that I need to use with osgconv? Thanks, Brian On Mon Jun 16 12:43 , 'Paul Martz' [EMAIL PROTECTED] sent: Hi Brian -- First, make sure you're on 2.5.x, as some important changes were made post-2.4. OSG LOD nodes are exported; see FltExportVisitor.cpp line 210. The FltExportVisitor class does _not_ override apply(PagedLOD), so PagedLOD nodes should be treated as regular LOD nodes for purposes of export. This means they receive no additional special interpretation or treatment (they don't write external reference records), and it means they must look like LOD nodes (they must have actual subtree children; file names alone are not sufficient). I hope that helps, -Paul -Original Message- From: [EMAIL PROTECTED] [EMAIL PROTECTED]','','','')osg-users-bou [EMAIL PROTECTED] On Behalf Of Brian Sent: Monday, June 16, 2008 9:47 AM To: osg-users@lists.openscenegraph.org Subject: [osg-users] OpenFlight exporter question Hi, I was trying to convert some OSG models to the FLT format but ran into a little trouble with one of the models. Only part of the model was converted. The model's LOD nodes were not touched by the converter. I noticed in an earlier message that paged LOD support does not exist yet, so is it safe to assume that what I am seeing is a direct result of that? Thanks, Brian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org
[osg-users] Problems about draw Complex polygons
hi everyone, Recently,i have some troubles with drawing complex polygon.These polygons contains Convex polygon ,concave polygon.Sometimes the polygon contains holes in it. I only know how to draw them using Opengl,there two methods: 1 using glEdgeFlag() 2 using gluTessCallBack gluTessBeginPolygon... But these methods have some problems,they all draw points one by one,they don't use vertexs array. And I also don't know how to draw them using Osg and i don't konw whether osg has provided us with Convex decomposition Algorithm. Any help would be appreaciated. Thanks, Yang ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problems about draw Complex polygons
Hi Yang, Try preprocessing your scene using osgUtil::Tesselator, this uses glu to break concave polygons down into non convex primitives. However, ideally you should be importing data that doesn't have convex polygons, as this would do away with the need to preprocess. Robert. 2008/6/18 heishuijing_2000 [EMAIL PROTECTED]: hi everyone, Recently,i have some troubles with drawing complex polygon.These polygons contains Convex polygon ,concave polygon.Sometimes the polygon contains holes in it. I only know how to draw them using Opengl,there two methods: 1 using glEdgeFlag() 2 using gluTessCallBack gluTessBeginPolygon.. But these methods have some problems,they all draw points one by one,they don't use vertexs array. And I also don't know how to draw them using Osg and i don't konw whether osg has provided us with Convex decomposition Algorithm. Any help would be appreaciated. Thanks, Yang 快来用音乐为奥运加油 得奥运会、演唱会门票 ___ 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] [Problem with osgLight]
Hi everyone, I have some problem with OSG Light, and I don't find answer in the osg archives. My problem is the following : I don't understand why with the following code my object isn't uniformly enlighten. (cf. image in attached document) -The black and white square of the image is centered at (0, 0, 0) (in world frame with convention (x, y, z)) -The camera is located at (0, 0, -20) -the light is located at (0,20, -15) The code for activating light is the following: /*** light */ //Creation of light source osg::Light* light = new osg::Light(); osg::LightSource * lightsource = new osg::LightSource(); lightsource-setLight(light); // put the light source in the scenegraph root-addChild(lightsource); // turn light on osg::StateSet * stateset = root-getOrCreateStateSet(); lightsource-setStateSetModes(*stateset, osg::StateAttribute::ON); light-setAmbient(osg::Vec4d(1.0, 1.0, 1.0, 1.0)); //light-setDiffuse(osg::Vec4d(0.0, 0.0, 0.0, 0.0)); //light-setSpecular(osg::Vec4d(1.0, 1.0, 1.0, 1.0)); light-setPosition(osg::Vec4d(0.0, 20.0, -15.0, 1.0)); /**/ So, I don't understand why the bottom-left corner of my square is darker than the others corners Has anybody an Idea? Best regards, Jean-Baptiste. attachment: 001.jpg___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] CMake 2.6 problem when compile with 64bit vista
Hi, I try to compile osg with cmake in vista 64bit pc, but it crash at beginning time and here is the error: Check for working C compiler: cl Check for working C compiler: cl -- broken CMake Error at C:/Program Files (x86)/CMake 2.6/share/cmake-2.6/Modules/CMakeTestCCompiler.cmake:32 (MESSAGE): The C compiler cl is not able to compile a simple test program. It fails with the following output: Change Dir: C:/bin/osg-bin/CMakeFiles/CMakeTmp Run Build Command:C:\PROGRA~2\MICROS~1.0\Common7\IDE\VCExpress.exe CMAKE_TRY_COMPILE.sln /build Debug /project cmTryCompileExec Microsoft (R) Visual C++ Express Edition Version 9.0.21022.8. Copyright (C) Microsoft Corp 2007. All rights reserved. The project consists entirely of configurations that require support for platforms which are not installed on this machine. The project cannot be loaded. The project consists entirely of configurations that require support for platforms which are not installed on this machine. The project cannot be loaded. Invalid project Use: vcexpress [solutionfile | projectfile | anyfile.ext] [switches] The first argument for devenv is usually a solution file or project file. You can also use any other file as the first argument if you want to have the file open automatically in an editor. When you enter a project file, the IDE looks for an .sln file with the same base name as the project file in the parent directory for the project file. If no such .sln file exists, then the IDE looks for a single .sln file that references the project. If no such single .sln file exists, then the IDE creates an unsaved solution with a default .sln file name that has the same base name as the project file. Command line builds: devenv solutionfile.sln /build [ solutionconfig ] [ /project projectnameorfile [ /projectconfig name ] ] Available command line switches: /Log Logs IDE activity to the specified file for troubleshooting. /ResetSettings Restores the IDE's default settings, optionally resets to the specified VSSettings file. /SafeMode Launches the IDE in safe mode loading minimal windows. Product-specific switches: /debugexe Open the specified executable to be debugged. The remainder of the command line is passed to this executable as its arguments. /useenv Use PATH, INCLUDE, LIBPATH, and LIB environment variables instead of IDE paths for VC++ builds. To attach the debugger from the command line, use: VsJITDebugger.exe -p pid CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:15 (PROJECT) Configuring done // since CMake doesn't have 64 bit version, does that means that 64 bit cannot be used for cmake? Thanks ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] problem with osg 2.4 stable release
Hi J-S I finaly found my problem. Indeed osgdb_png.dll needs libpng13.dll but libpng13.dll needs also zlib1.dll. Best regards ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [Problem with osgLight]
Jean-Baptiste Authesserre wrote: Hi everyone, I have some problem with OSG Light, and I don't find answer in the osg archives. My problem is the following : I don't understand why with the following code my object isn't uniformly enlighten. (cf. image in attached document) -The black and white square of the image is centered at (0, 0, 0) (in world frame with convention (x, y, z)) -The camera is located at (0, 0, -20) -the light is located at (0,20, -15) If you didn't change this yourself then +Z will be the up axis, btw The code for activating light is the following: /* ** light */ //Creation of light source osg::Light* light = new osg::Light(); osg::LightSource * lightsource = new osg::LightSource(); lightsource-setLight(light); // put the light source in the scenegraph root-addChild(lightsource); // turn light on osg::StateSet * stateset = root-getOrCreateStateSet(); lightsource-setStateSetModes(*stateset, osg::StateAttribute::ON); light-setAmbient(osg::Vec4d(1.0, 1.0, 1.0, 1.0)); //light-setDiffuse(osg::Vec4d(0.0, 0.0, 0.0, 0.0)); //light-setSpecular(osg::Vec4d(1.0, 1.0, 1.0, 1.0)); light-setPosition(osg::Vec4d(0.0, 20.0, -15.0, 1.0)); /**/ So, I don't understand why the bottom-left corner of my square is darker than the others corners I don't see any difference here between left and right bottom corners, they're equally dark IMHO. Which seems to make sense, as you've put the light source above and little in front of the camera, but in the center of the object (the X plane). Paul Has anybody an Idea? Best regards, Jean-Baptiste. ___ 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] problem with osg 2.4 stable release
Bonjour Arnaud, I put the libpng13.dll in the same directory of osgdb_png.dll but in visual studio output window the dll is called anytime I try to read a png and then unloaded after the operation. No, libpng13.dll should be in your PATH or in your executable's directory. The plugins are in OSG_BIN_DIR\osgPlugins-version, which is not on your PATH (and should not be) - OSG loads them directly which is why it works, but the libpng13.dll needs to be on the DLL search path. It's up to you where you want to put it. I usually put it alongside osgNN-osg.dll (in my case my OSG_BIN_PATH is on my PATH). If you include the OSG DLLs alongside your application in an installer, for example, you should include libpng13.dll alongside the OSG DLLs (not the plugins). Hope this helps, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problem with osg 2.4 stable release
Hi J-S, Jean-Sébastien Guay wrote: Bonjour Arnaud, I put the libpng13.dll in the same directory of osgdb_png.dll but in visual studio output window the dll is called anytime I try to read a png and then unloaded after the operation. No, libpng13.dll should be in your PATH or in your executable's directory. The plugins are in OSG_BIN_DIR\osgPlugins-version, which is not on your PATH (and should not be) - OSG loads them directly which is why it works, but the libpng13.dll needs to be on the DLL search path. It's up to you where you want to put it. I usually put it alongside osgNN-osg.dll (in my case my OSG_BIN_PATH is on my PATH). If you include the OSG DLLs alongside your application in an installer, for example, you should include libpng13.dll alongside the OSG DLLs (not the plugins). Hope this helps, This seems to come up quite often for the Windows users. Would linking against a static version of dependencies like png, jpeg, zlib, etc be a helpful solution? Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problem with osg 2.4 stable release
Bonjour Arnaud, I finaly found my problem. Indeed osgdb_png.dll needs libpng13.dll but libpng13.dll needs also zlib1.dll. Ha! I had forgotten that one. I generally just copy all the DLLs from the 3rdParty/bin directory to my OSG bin directory. :-) J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [Problem with osgLight]
Hi, I am a little confused. My camera 2008/6/18 Paul Melis [EMAIL PROTECTED]: Jean-Baptiste Authesserre wrote: Hi everyone, I have some problem with OSG Light, and I don't find answer in the osg archives. My problem is the following : I don't understand why with the following code my object isn't uniformly enlighten. (cf. image in attached document) -The black and white square of the image is centered at (0, 0, 0) (in world frame with convention (x, y, z)) -The camera is located at (0, 0, -20) -the light is located at (0,20, -15) If you didn't change this yourself then +Z will be the up axis, btw The code for activating light is the following: /* ** light */ //Creation of light source osg::Light* light = new osg::Light(); osg::LightSource * lightsource = new osg::LightSource(); lightsource-setLight(light); // put the light source in the scenegraph root-addChild(lightsource); // turn light on osg::StateSet * stateset = root-getOrCreateStateSet(); lightsource-setStateSetModes(*stateset, osg::StateAttribute::ON); light-setAmbient(osg::Vec4d(1.0, 1.0, 1.0, 1.0)); //light-setDiffuse(osg::Vec4d(0.0, 0.0, 0.0, 0.0)); //light-setSpecular(osg::Vec4d(1.0, 1.0, 1.0, 1.0)); light-setPosition(osg::Vec4d(0.0, 20.0, -15.0, 1.0)); /**/ So, I don't understand why the bottom-left corner of my square is darker than the others corners I don't see any difference here between left and right bottom corners, they're equally dark IMHO. Which seems to make sense, as you've put the light source above and little in front of the camera, but in the center of the object (the X plane). Paul Has anybody an Idea? Best regards, Jean-Baptiste. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problem with osg 2.4 stable release
Hi Paul, This seems to come up quite often for the Windows users. Would linking against a static version of dependencies like png, jpeg, zlib, etc be a helpful solution? Not sure how the executable size would increase in that case... But yeah, they're pretty much required dependencies if you want to do anything useful, so I'd agree that it could be helpful. Though I think when developing on Windows you need to be able to diagnose and fix DLL search path and dependency problems, because they'll bite you sooner or later. I'm not trying to imply that OSG should be a teaching aid in Windows programming and troubleshooting, but we should consider how much time we spend on making things easier for newbies which they'll have to learn anyways. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Quicktime plugin livestreaming documentation/examples
Hi I am using osgmovie like Colin has described to visualise a live stream from a webcam (and it works very good) - but I can only see a resolution of 320x240; is there a limitation to this resolution ? - is there any way to realise a higher resolution ? Using Windows XP and OSG 2.3.6 Thanks Dieter Unclassified Mail -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Colin Dunlop Sent: Tuesday, 08 April, 2008 17:07 To: OpenSceneGraph Users Subject: Re: [osg-users] Quicktime plugin livestreaming documentation/examples Hi Adrian, I've not documented anything on the wiki yet but below is how the result was achieved on Windows XP. See my previous post for any more detail. The demo/example is really just a quad with your live feed playing - so a I've just tweaked osgmovie here to force load the plug-in from a .live association and then interpret the file basename to get a device and input ID - ugly but working... 0. If you have NO QuickTime driver for your device then install http://www.abstractplane.com/products/vdig.jsp Use the latest version and do the manual install from the zip. You will jave to live with the demo mode or fork out some $$$. If your capture device has a QuickTime driver then you do not need this VDIG for Windows thing eg BlackMagic Intensity Pro. 1. Modify the osgmovie.cpp and make sure that the .live extension is associated with the osgdb_qt plugin: osgDB::Registry::instance()-addFileExtensionAlias(live,qt); 2. run osgmovie --devices If you have any live feed devices associated with a QuickTime driver then this will spit out some command line options and associations. It will also spit out any pseudo Windows VDIG wrapped Direct Show devices in the same way eg: ... 4:1.liveBlackmagic HDTV 720Intensity HDTV 720p 59.94 ... 1:4.liveHauppauge WinTV 418 Video Capture (4E384A6E048F0)S-Video 3 UYVY @ 720x480 ... 3. run osgmovie and pass it a pseudo file name that will be translated by the plug-in to point at an input device eg $ osgmovie x:y.live This will force load the osgdb_qt plug-in, and then attempt to decode the x:y.live where x and y are the input and channel of your input - eg 5:0.live I plan to submit to Robert an osgvideo example which wraps some of this up a bit better. Cheers, Colin. Adrian Egli OpenSceneGraph (3D) wrote: Hi any demo / example ? regards 2008/4/3, Mike Greene [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Colin, Success! Using the later version of VDIG that you referenced, I was able to get a live stream to work with osgmovie. I'm using a KOCOM camera running video through a Canopus ADVC 110 A/D video convertor into a firewire cable. This is on Windows XP, OSG 2.3.5, Visual Studio 2005 debug, Quicktime SDK 7.3. Mike Greene ___ 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 -- Adrian Egli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problem with osg 2.4 stable release
Jean-Sébastien Guay wrote: This seems to come up quite often for the Windows users. Would linking against a static version of dependencies like png, jpeg, zlib, etc be a helpful solution? Not sure how the executable size would increase in that case... But yeah, they're pretty much required dependencies if you want to do anything useful, so I'd agree that it could be helpful. Yes, the increase in size would be a downside. But disk space and memory are fairly cheap these days. I suspect only a small number of plugins would increase (jpg, png, tiff, jp2). Though I think when developing on Windows you need to be able to diagnose and fix DLL search path and dependency problems, because they'll bite you sooner or later. Absolutely! (I'm glad I only work with Linux these days ;-)) I'm not trying to imply that OSG should be a teaching aid in Windows programming and troubleshooting, but we should consider how much time we spend on making things easier for newbies which they'll have to learn anyways. It would be interesting to know which users specifically are having problems: 1. using prebuilt OSG + dependencies (either Mike's deps or perhaps from the gnuwin32 project), not compiling their own app, are merely trying out the OSG 2. using prebuilt OSG + dependencies, are compiling their own app 3. using prebuilt dependencies, compiling OSG from source, compiling their own apps 4. compiling everything from source I doubt that category 4 will have these DLL problems. But I'm curious about the spread over the other 3 categories.. Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [Problem with osgLight]
Sorry for the previous mail. I'm a little confused. My camera is configured to take Y-axis as UP axis. In my 3D-model, I put the helmet so that the bottom of the helmet correspond to negative Y, and the top to positive Y (cf attached figure). The camera look at (0, 0, 0). Thus I can obtain the attached image. To enlight the scene I put the light at 0 on X-axis so the region around the bottom corners of the square be enlighten the same way (the square is in the XY plane). However the region around bottom-left corner is darker than the region around bottom-right corner. What have I missed? Jean-Baptiste 2008/6/18 Jean-Baptiste Authesserre [EMAIL PROTECTED]: Hi, I am a little confused. My camera 2008/6/18 Paul Melis [EMAIL PROTECTED]: Jean-Baptiste Authesserre wrote: Hi everyone, I have some problem with OSG Light, and I don't find answer in the osg archives. My problem is the following : I don't understand why with the following code my object isn't uniformly enlighten. (cf. image in attached document) -The black and white square of the image is centered at (0, 0, 0) (in world frame with convention (x, y, z)) -The camera is located at (0, 0, -20) -the light is located at (0,20, -15) If you didn't change this yourself then +Z will be the up axis, btw The code for activating light is the following: /* ** light */ //Creation of light source osg::Light* light = new osg::Light(); osg::LightSource * lightsource = new osg::LightSource(); lightsource-setLight(light); // put the light source in the scenegraph root-addChild(lightsource); // turn light on osg::StateSet * stateset = root-getOrCreateStateSet(); lightsource-setStateSetModes(*stateset, osg::StateAttribute::ON); light-setAmbient(osg::Vec4d(1.0, 1.0, 1.0, 1.0)); //light-setDiffuse(osg::Vec4d(0.0, 0.0, 0.0, 0.0)); //light-setSpecular(osg::Vec4d(1.0, 1.0, 1.0, 1.0)); light-setPosition(osg::Vec4d(0.0, 20.0, -15.0, 1.0)); /**/ So, I don't understand why the bottom-left corner of my square is darker than the others corners I don't see any difference here between left and right bottom corners, they're equally dark IMHO. Which seems to make sense, as you've put the light source above and little in front of the camera, but in the center of the object (the X plane). Paul Has anybody an Idea? Best regards, Jean-Baptiste. ___ 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 attachment: 001.jpg___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Win32 keyboard bug (was: X11 keyboard bug (+ ugly fix))
Hello all, To reproduce start the osgkeyboard example, press a few modifier keys (let's say Ctrl and Shift) and while keeping them pressed switch the desktop (e.g. on KDE) or minimize the window. Release the modifier keys. Now, when you switch back or open the minimized window, you'll see Ctrl and Shift still activated. And it's not only an visual problem. These keys are actually not released, and pressing 'a' will now really be seen as 'A'. That's very annoying in FlightGear. One has to press and release the respective modifier keys to get the missing release event. This also happens on Win32 (SVN version)... For example, press Alt+tab to switch to another window, and then go back to the osgkeyboard window, and you'll see that the alt key is stuck. Does anyone have a fix? I'd work on it, but it's relatively low on my priority list, but it's annoying. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Upgrading from version 1.2 and Producer using Visual Studio
Excellent, THANKS! For the computePixelCoords, I just copied from what Producer::KeyboardMouse was doing, and made the appropriate changes. I am assuming the mouse coordinates work the same way they did before. -- Rick On Wed, Jun 18, 2008 at 4:48 AM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Rick, On Wed, Jun 18, 2008 at 12:12 AM, Rick Pingry [EMAIL PROTECTED] wrote: Producer::KeyboardMouse::positionPointer( float x, float y ) Any way to set the mouse position like this? GraphicsWindow::requestWarpPointer(x,y); and View::requestWarpPointer(x,y); The later will automatically work out which window to warp to. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Rick Check us out at http://fringe-online.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [Problem with osgLight]
Jean-Baptiste Authesserre wrote: Sorry for the previous mail. I'm a little confused. My camera is configured to take Y-axis as UP axis. In my 3D-model, I put the helmet so that the bottom of the helmet correspond to negative Y, and the top to positive Y (cf attached figure). The camera look at (0, 0, 0). Thus I can obtain the attached image. To enlight the scene I put the light at 0 on X-axis so the region around the bottom corners of the square be enlighten the same way (the square is in the XY plane). However the region around bottom-left corner is darker than the region around bottom-right corner. What have I missed? Ah! You said my object isn't uniformly enlighten in your original mail. With object I figured you meant the whole thing/helmet. I now see what you mean w.r.t. the dark corner on the square. Could it be that you have an incorrect normal for that corner of the square? Are the square and helmet one object? Does it still show when you display only the square (i.e. could it be an artifact that actually comes from the helmet, and not the square)? Paul Jean-Baptiste 2008/6/18 Jean-Baptiste Authesserre [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Hi, I am a little confused. My camera 2008/6/18 Paul Melis [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Jean-Baptiste Authesserre wrote: Hi everyone, I have some problem with OSG Light, and I don't find answer in the osg archives. My problem is the following : I don't understand why with the following code my object isn't uniformly enlighten. (cf. image in attached document) -The black and white square of the image is centered at (0, 0, 0) (in world frame with convention (x, y, z)) -The camera is located at (0, 0, -20) -the light is located at (0,20, -15) If you didn't change this yourself then +Z will be the up axis, btw The code for activating light is the following: /* ** light */ //Creation of light source osg::Light* light = new osg::Light(); osg::LightSource * lightsource = new osg::LightSource(); lightsource-setLight(light); // put the light source in the scenegraph root-addChild(lightsource); // turn light on osg::StateSet * stateset = root-getOrCreateStateSet(); lightsource-setStateSetModes(*stateset, osg::StateAttribute::ON); light-setAmbient(osg::Vec4d(1.0, 1.0, 1.0, 1.0)); //light-setDiffuse(osg::Vec4d(0.0, 0.0, 0.0, 0.0)); //light-setSpecular(osg::Vec4d(1.0, 1.0, 1.0, 1.0)); light-setPosition(osg::Vec4d(0.0, 20.0, -15.0, 1.0)); /**/ So, I don't understand why the bottom-left corner of my square is darker than the others corners I don't see any difference here between left and right bottom corners, they're equally dark IMHO. Which seems to make sense, as you've put the light source above and little in front of the camera, but in the center of the object (the X plane). Paul Has anybody an Idea? Best regards, Jean-Baptiste. ___ 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 ___ 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 ___ 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] problem with osg 2.4 stable release
Hi Paul, Yes, the increase in size would be a downside. But disk space and memory are fairly cheap these days. I suspect only a small number of plugins would increase (jpg, png, tiff, jp2). I think we need to quantify it. Then we can evaluate if it's significant or not. If I have 16 OSG apps which all include (for example, I didn't try it) 5MB of dependencies statically linked each, that's 80MB instead of 5 (for the DLLs which could be shared). However, if I need to link to a specific version of OSG+deps, I'd need my application to include the specific DLLs in its directory anyways, so no savings there... Perhaps linking to static dependencies could be an option in the CMake generation process, with the deps binary packages including static libs, and the default being static. Then if others want to compile and link to DLLs, they can switch the option in OSG's CMake config. Here I am suggesting ideas which I don't have time to implement... Shame on me. It would be interesting to know which users specifically are having problems: 1. using prebuilt OSG + dependencies (either Mike's deps or perhaps from the gnuwin32 project), not compiling their own app, are merely trying out the OSG 2. using prebuilt OSG + dependencies, are compiling their own app 3. using prebuilt dependencies, compiling OSG from source, compiling their own apps 4. compiling everything from source Are you suggesting a poll? Doing this on the mailing list would be a bit hard to keep track of... (Incidentally, I'm mostly in 3, though I'll have to move to 4 for 64 bit soon) Does the wiki have a poll functionality? Or perhaps we could use Gordon's forum for that? J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problem with osg 2.4 stable release
Hi J-S, Jean-Sébastien Guay wrote: Yes, the increase in size would be a downside. But disk space and memory are fairly cheap these days. I suspect only a small number of plugins would increase (jpg, png, tiff, jp2). I think we need to quantify it. Then we can evaluate if it's significant or not. If I have 16 OSG apps which all include (for example, I didn't try it) 5MB of dependencies statically linked each, that's 80MB instead of 5 (for the DLLs which could be shared). However, if I need to link to a specific version of OSG+deps, I'd need my application to include the specific DLLs in its directory anyways, so no savings there... I wasn't suggesting that _apps_ link statically, merely that the plugin DLLs link statically against their (non-OSG) dependencies. Perhaps linking to static dependencies could be an option in the CMake generation process, with the deps binary packages including static libs, and the default being static. Then if others want to compile and link to DLLs, they can switch the option in OSG's CMake config. Here I am suggesting ideas which I don't have time to implement... Shame on me. Spoken like a true open source contributor :) It would be interesting to know which users specifically are having problems: 1. using prebuilt OSG + dependencies (either Mike's deps or perhaps from the gnuwin32 project), not compiling their own app, are merely trying out the OSG 2. using prebuilt OSG + dependencies, are compiling their own app 3. using prebuilt dependencies, compiling OSG from source, compiling their own apps 4. compiling everything from source Are you suggesting a poll? Doing this on the mailing list would be a bit hard to keep track of... (Incidentally, I'm mostly in 3, though I'll have to move to 4 for 64 bit soon). Does the wiki have a poll functionality? Or perhaps we could use Gordon's forum for that? Well, it was more of a philosophical question, but a poll would be interesting. Using the ML for that will be horrible, although easy to do. I don't think trac supports polls out of the box. If we could have a web-based poll on the forum site we'd only have to publicize it on osg-users. What do you mean with the 4th mailing list for 64 bit, b.t.w? Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenFlight exporter question
Hi Paul If I can remember back enough ;) I believe this was added in for Vega Prime and basically its the scenegraphs that takes this value and maps it to a screen pixel size, if this field is anything other than zero then its is assumed if the scenegraph supports this it will use that value rather than distance switching. I would say the docs wording is poor, its not an internal thing, creator does not use this its a scenegraph/run-time param or at least the last version Creator I used 3.0 So I would say there is no problem using this, as I believe thats its use ;) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Wednesday, June 18, 2008 9:27 AM To: [EMAIL PROTECTED]; 'OpenSceneGraph Users' Subject: Re: [osg-users] OpenFlight exporter question Thanks for keeping me on my toes, Gordon. :-) Hmm... I just went back and re-read the FLT spec section regarding LOD Records. Throughout the description, the spec refers to distance calculations and switch in/out distances, implying strongly that distance is the only way to change active LODs. Finally, the section ends with the following (arguably cryptic) text: Significant size is a value used to calculate switch in and out distances based on viewing parameters of your simulation display system. This value is used internally by MultiGen-Paradigm and will be enhanced in future versions of OpenFlight. So this is just for internal use. We can hijack this field if we want, but it's vague enough (based on viewing parameters of your simulation display system) that, if ever exposed for public use, this field could be used for just about anything. I'm not trying to get out of doing work, and it would be trivial to map OSG's pixel size on screen to this field. But the 16.1 spec language doesn't convince me that this is the right thing to do. If I'm way off base, please correct me... -Paul Hi Paul Err Creator/Openflight does support this ;) it's called 'Significant Size', which is a single value. On the Open Flight LOD node Obviously it up to the scene graph what field means ;), the OSG flight loader may not support this ( not checked ), so to support it Changes may need to be made to the read and write __ Gordon Tomlinson Email : [EMAIL PROTECTED] YIM/AIM : gordon3dBrit MSN IM : [EMAIL PROTECTED] Website : www.vis-sim.com www.gordontomlinson.com __ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Monday, June 16, 2008 11:04 PM To: [EMAIL PROTECTED]; 'OpenSceneGraph Users' Subject: Re: [osg-users] OpenFlight exporter question Hi Brian -- Your LOD node is configured to switch children based on screen size. OpenFlight doesn't support this. You'll need to re-model the LODs using eye distance. The LOD exporter should probably display a warning in this case, but as I am in the middle of a vacation, I won't be able to make that change immediately. Could you please add the warning message and post to osg-submissions? Thanks. -Paul Hi Paul, Yes, I thought about the version possibly being an issue, so I downloaded 2.5.2 but saw the same problem. Back a few months ago, I was given a sample LOD OSG file. As a test I ran the converter against it, but it also had the same problem. I've attached the file that Hans Elbers provided me and am curious as to whether its format is correct in terms of the converter. Are there any command line switches that I need to use with osgconv? Thanks, Brian On Mon Jun 16 12:43 , 'Paul Martz' [EMAIL PROTECTED] sent: Hi Brian -- First, make sure you're on 2.5.x, as some important changes were made post-2.4. OSG LOD nodes are exported; see FltExportVisitor.cpp line 210. The FltExportVisitor class does _not_ override apply(PagedLOD), so PagedLOD nodes should be treated as regular LOD nodes for purposes of export. This means they receive no additional special interpretation or treatment (they don't write external reference records), and it means they must look like LOD nodes (they must have actual subtree children; file names alone are not sufficient). I hope that helps, -Paul -Original Message- From: [EMAIL PROTECTED] [EMAIL PROTECTED]','','','')osg-users-bou [EMAIL PROTECTED] On Behalf Of Brian Sent: Monday, June 16, 2008 9:47 AM To: osg-users@lists.openscenegraph.org Subject: [osg-users] OpenFlight exporter question Hi, I was trying to convert some OSG models to the FLT format but ran into a little trouble with one of the models. Only part of the model was converted. The model's LOD nodes were not touched by the converter. I noticed in an earlier message that paged LOD support
Re: [osg-users] problem with osg 2.4 stable release
Hi Paul, I wasn't suggesting that _apps_ link statically, merely that the plugin DLLs link statically against their (non-OSG) dependencies. Ah, I hadn't seen it that way. It would in that case increase the size of plugins that use the same dependencies (zlib is used by multiple plugins I think), and the thing with multiple OSG versions using more space would remain. But it would be much better than linking apps statically. Well, it was more of a philosophical question, but a poll would be interesting. Using the ML for that will be horrible, although easy to do. I don't think trac supports polls out of the box. If we could have a web-based poll on the forum site we'd only have to publicize it on osg-users. I think we could use Gordon's http://www.vis-sim.com/ for that, it already has lots of OSG-related content so it wouldn't be out of place. But I agree, it's not as active as the mailing list, so we'd need to publicize the poll on the mailing list. What do you mean with the 4th mailing list for 64 bit, b.t.w? Not 4th mailing list, 4th option in your enumerated list of possibilities of using prebuilt vs self-compiled OSG/dependencies. Mike's 3rd Party binary package is for 32 bit, so if I want to compile OSG in 64 bit I'll have to recompile the dependencies in 64 bit myself. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problem with osg 2.4 stable release
Hi Robert, So if you want to go static link of external dependencies under Windows then guys, you have my backing. I agree, Paul's idea is a great one for the initial user experience on Windows. Though I would keep it optional, just default to static, since there are cases where you'd want DLLs for dependencies but in that case you should know what you're doing. Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problem with osg 2.4 stable release
No problem doing a poll on http://www.vis-sim.com/3dsceneBB/, the form is setup for users to create polls... ( please note I have *.gmail.com on new account addresses disabled due to high spam attacks, I will turn this off if needed -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Melis Sent: Wednesday, June 18, 2008 11:12 AM To: OpenSceneGraph Users Subject: Re: [osg-users] problem with osg 2.4 stable release Hi J-S, Jean-Sébastien Guay wrote: Yes, the increase in size would be a downside. But disk space and memory are fairly cheap these days. I suspect only a small number of plugins would increase (jpg, png, tiff, jp2). I think we need to quantify it. Then we can evaluate if it's significant or not. If I have 16 OSG apps which all include (for example, I didn't try it) 5MB of dependencies statically linked each, that's 80MB instead of 5 (for the DLLs which could be shared). However, if I need to link to a specific version of OSG+deps, I'd need my application to include the specific DLLs in its directory anyways, so no savings there... I wasn't suggesting that _apps_ link statically, merely that the plugin DLLs link statically against their (non-OSG) dependencies. Perhaps linking to static dependencies could be an option in the CMake generation process, with the deps binary packages including static libs, and the default being static. Then if others want to compile and link to DLLs, they can switch the option in OSG's CMake config. Here I am suggesting ideas which I don't have time to implement... Shame on me. Spoken like a true open source contributor :) It would be interesting to know which users specifically are having problems: 1. using prebuilt OSG + dependencies (either Mike's deps or perhaps from the gnuwin32 project), not compiling their own app, are merely trying out the OSG 2. using prebuilt OSG + dependencies, are compiling their own app 3. using prebuilt dependencies, compiling OSG from source, compiling their own apps 4. compiling everything from source Are you suggesting a poll? Doing this on the mailing list would be a bit hard to keep track of... (Incidentally, I'm mostly in 3, though I'll have to move to 4 for 64 bit soon). Does the wiki have a poll functionality? Or perhaps we could use Gordon's forum for that? Well, it was more of a philosophical question, but a poll would be interesting. Using the ML for that will be horrible, although easy to do. I don't think trac supports polls out of the box. If we could have a web-based poll on the forum site we'd only have to publicize it on osg-users. What do you mean with the 4th mailing list for 64 bit, b.t.w? Paul ___ 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] problem with osg 2.4 stable release
Just a side note, some Plugins licenses do not allow static linking so you need to check that issue -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Melis Sent: Wednesday, June 18, 2008 10:21 AM To: OpenSceneGraph Users Subject: Re: [osg-users] problem with osg 2.4 stable release Hi J-S, Jean-Sébastien Guay wrote: Bonjour Arnaud, I put the libpng13.dll in the same directory of osgdb_png.dll but in visual studio output window the dll is called anytime I try to read a png and then unloaded after the operation. No, libpng13.dll should be in your PATH or in your executable's directory. The plugins are in OSG_BIN_DIR\osgPlugins-version, which is not on your PATH (and should not be) - OSG loads them directly which is why it works, but the libpng13.dll needs to be on the DLL search path. It's up to you where you want to put it. I usually put it alongside osgNN-osg.dll (in my case my OSG_BIN_PATH is on my PATH). If you include the OSG DLLs alongside your application in an installer, for example, you should include libpng13.dll alongside the OSG DLLs (not the plugins). Hope this helps, This seems to come up quite often for the Windows users. Would linking against a static version of dependencies like png, jpeg, zlib, etc be a helpful solution? Paul ___ 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] problem with osg 2.4 stable release
Gordon Tomlinson wrote: No problem doing a poll on http://www.vis-sim.com/3dsceneBB/, the form is setup for users to create polls... Would voting there imply registration on the forum? I've tried to formulate a poll below. It's impossible to cover every possibility, of course. For OS/X there are no prebuilt packages, right? How do you get your OpenSceneGraph binaries? (Windows) I use Mike Weiblen's precompiled binaries for both OSG and its dependencies (Windows) I compile OSG from source, but use precompiled dependencies (Windows) I compile OSG and its dependencies from source (Windows) Other (Linux) I compile OSG from source myself (Linux) I use packages provided by my distribution (Linux) Other Paul ( please note I have *.gmail.com on new account addresses disabled due to high spam attacks, I will turn this off if needed -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Melis Sent: Wednesday, June 18, 2008 11:12 AM To: OpenSceneGraph Users Subject: Re: [osg-users] problem with osg 2.4 stable release Hi J-S, Jean-Sébastien Guay wrote: Yes, the increase in size would be a downside. But disk space and memory are fairly cheap these days. I suspect only a small number of plugins would increase (jpg, png, tiff, jp2). I think we need to quantify it. Then we can evaluate if it's significant or not. If I have 16 OSG apps which all include (for example, I didn't try it) 5MB of dependencies statically linked each, that's 80MB instead of 5 (for the DLLs which could be shared). However, if I need to link to a specific version of OSG+deps, I'd need my application to include the specific DLLs in its directory anyways, so no savings there... I wasn't suggesting that _apps_ link statically, merely that the plugin DLLs link statically against their (non-OSG) dependencies. Perhaps linking to static dependencies could be an option in the CMake generation process, with the deps binary packages including static libs, and the default being static. Then if others want to compile and link to DLLs, they can switch the option in OSG's CMake config. Here I am suggesting ideas which I don't have time to implement... Shame on me. Spoken like a true open source contributor :) It would be interesting to know which users specifically are having problems: 1. using prebuilt OSG + dependencies (either Mike's deps or perhaps from the gnuwin32 project), not compiling their own app, are merely trying out the OSG 2. using prebuilt OSG + dependencies, are compiling their own app 3. using prebuilt dependencies, compiling OSG from source, compiling their own apps 4. compiling everything from source Are you suggesting a poll? Doing this on the mailing list would be a bit hard to keep track of... (Incidentally, I'm mostly in 3, though I'll have to move to 4 for 64 bit soon). Does the wiki have a poll functionality? Or perhaps we could use Gordon's forum for that? Well, it was more of a philosophical question, but a poll would be interesting. Using the ML for that will be horrible, although easy to do. I don't think trac supports polls out of the box. If we could have a web-based poll on the forum site we'd only have to publicize it on osg-users. What do you mean with the 4th mailing list for 64 bit, b.t.w? Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [Problem with osgLight]
Jean-Baptiste Authesserre wrote: This is the result when I remove the helmet. I really don(t understand. The square is obtained thanks to the following way. I ceated a cube with blender 3*3*0.1 (small depth along th Z-axis) I load on that cube a texture. I attach to this mail the result without the helmet and the texture attached to the cube. It's very strange... You can check the .osg file exported by Blender to see if the normals are set correctly. There shouldn't be that many for this simple model I suspect. Paul 2008/6/18 Paul Melis [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Jean-Baptiste Authesserre wrote: Sorry for the previous mail. I'm a little confused. My camera is configured to take Y-axis as UP axis. In my 3D-model, I put the helmet so that the bottom of the helmet correspond to negative Y, and the top to positive Y (cf attached figure). The camera look at (0, 0, 0). Thus I can obtain the attached image. To enlight the scene I put the light at 0 on X-axis so the region around the bottom corners of the square be enlighten the same way (the square is in the XY plane). However the region around bottom-left corner is darker than the region around bottom-right corner. What have I missed? Ah! You said my object isn't uniformly enlighten in your original mail. With object I figured you meant the whole thing/helmet. I now see what you mean w.r.t. the dark corner on the square. Could it be that you have an incorrect normal for that corner of the square? Are the square and helmet one object? Does it still show when you display only the square (i.e. could it be an artifact that actually comes from the helmet, and not the square)? Paul Jean-Baptiste 2008/6/18 Jean-Baptiste Authesserre [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Hi, I am a little confused. My camera 2008/6/18 Paul Melis [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Jean-Baptiste Authesserre wrote: Hi everyone, I have some problem with OSG Light, and I don't find answer in the osg archives. My problem is the following : I don't understand why with the following code my object isn't uniformly enlighten. (cf. image in attached document) -The black and white square of the image is centered at (0, 0, 0) (in world frame with convention (x, y, z)) -The camera is located at (0, 0, -20) -the light is located at (0,20, -15) If you didn't change this yourself then +Z will be the up axis, btw The code for activating light is the following: /* ** light */ //Creation of light source osg::Light* light = new osg::Light(); osg::LightSource * lightsource = new osg::LightSource(); lightsource-setLight(light); // put the light source in the scenegraph root-addChild(lightsource); // turn light on osg::StateSet * stateset = root-getOrCreateStateSet(); lightsource-setStateSetModes(*stateset, osg::StateAttribute::ON); light-setAmbient(osg::Vec4d(1.0, 1.0, 1.0, 1.0)); //light-setDiffuse(osg::Vec4d(0.0, 0.0, 0.0, 0.0)); //light-setSpecular(osg::Vec4d(1.0, 1.0, 1.0, 1.0)); light-setPosition(osg::Vec4d(0.0, 20.0, -15.0, 1.0)); /**/ So, I don't understand why the bottom-left corner of my square is darker than the others corners I don't see any difference here between left and right bottom corners, they're equally dark IMHO. Which seems to make sense, as you've put the light source above and little in front of the camera, but in the center of the object (the X plane). Paul Has anybody an Idea? Best regards, Jean-Baptiste. ___ osg-users mailing list
Re: [osg-users] problem with osg 2.4 stable release
Paul Melis wrote: Gordon Tomlinson wrote: No problem doing a poll on http://www.vis-sim.com/3dsceneBB/, the form is setup for users to create polls... Would voting there imply registration on the forum? I've tried to formulate a poll below. It's impossible to cover every possibility, of course. Hmm, people that are merely trying out the OSG and using Mike's prebuilt OSG binaries might not have a clue what dependencies we're talking about, as these are included in the package already. Paul For OS/X there are no prebuilt packages, right? How do you get your OpenSceneGraph binaries? (Windows) I use Mike Weiblen's precompiled binaries for both OSG and its dependencies (Windows) I compile OSG from source, but use precompiled dependencies (Windows) I compile OSG and its dependencies from source (Windows) Other (Linux) I compile OSG from source myself (Linux) I use packages provided by my distribution (Linux) Other Paul ( please note I have *.gmail.com on new account addresses disabled due to high spam attacks, I will turn this off if needed -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Melis Sent: Wednesday, June 18, 2008 11:12 AM To: OpenSceneGraph Users Subject: Re: [osg-users] problem with osg 2.4 stable release Hi J-S, Jean-Sébastien Guay wrote: Yes, the increase in size would be a downside. But disk space and memory are fairly cheap these days. I suspect only a small number of plugins would increase (jpg, png, tiff, jp2). I think we need to quantify it. Then we can evaluate if it's significant or not. If I have 16 OSG apps which all include (for example, I didn't try it) 5MB of dependencies statically linked each, that's 80MB instead of 5 (for the DLLs which could be shared). However, if I need to link to a specific version of OSG+deps, I'd need my application to include the specific DLLs in its directory anyways, so no savings there... I wasn't suggesting that _apps_ link statically, merely that the plugin DLLs link statically against their (non-OSG) dependencies. Perhaps linking to static dependencies could be an option in the CMake generation process, with the deps binary packages including static libs, and the default being static. Then if others want to compile and link to DLLs, they can switch the option in OSG's CMake config. Here I am suggesting ideas which I don't have time to implement... Shame on me. Spoken like a true open source contributor :) It would be interesting to know which users specifically are having problems: 1. using prebuilt OSG + dependencies (either Mike's deps or perhaps from the gnuwin32 project), not compiling their own app, are merely trying out the OSG 2. using prebuilt OSG + dependencies, are compiling their own app 3. using prebuilt dependencies, compiling OSG from source, compiling their own apps 4. compiling everything from source Are you suggesting a poll? Doing this on the mailing list would be a bit hard to keep track of... (Incidentally, I'm mostly in 3, though I'll have to move to 4 for 64 bit soon). Does the wiki have a poll functionality? Or perhaps we could use Gordon's forum for that? Well, it was more of a philosophical question, but a poll would be interesting. Using the ML for that will be horrible, although easy to do. I don't think trac supports polls out of the box. If we could have a web-based poll on the forum site we'd only have to publicize it on osg-users. What do you mean with the 4th mailing list for 64 bit, b.t.w? Paul ___ 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 mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problem with osg 2.4 stable release
I could turn the reg requirements of on the Poll/forum if folks don't won't to register Looks like only one option can be voted for, but if non registered voting is allowed you may be able to vote more than once -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jean-Sébastien Guay Sent: Wednesday, June 18, 2008 11:49 AM To: OpenSceneGraph Users Subject: Re: [osg-users] problem with osg 2.4 stable release Hi Paul, Would voting there imply registration on the forum? I think so, and I don't think there's a good way to get around that... I've tried to formulate a poll below. It's impossible to cover every possibility, of course. For OS/X there are no prebuilt packages, right? Would voting for multiple selections be allowed? I use OSG on Win32 and Linux for instance... If not, we could do multiple polls one per platform, or just concentrate on Win32 since that's where the problem is more prominent. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problem with osg 2.4 stable release
OK I have change the Poll forum http://www.vis-sim.com/3dsceneBB/viewforum.php?f=34 To aid the poll for OSG I have relaxed permissions, you don't need to be registered ( but I'll have to watch what happens ) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jean-Sébastien Guay Sent: Wednesday, June 18, 2008 11:49 AM To: OpenSceneGraph Users Subject: Re: [osg-users] problem with osg 2.4 stable release Hi Paul, Would voting there imply registration on the forum? I think so, and I don't think there's a good way to get around that... I've tried to formulate a poll below. It's impossible to cover every possibility, of course. For OS/X there are no prebuilt packages, right? Would voting for multiple selections be allowed? I use OSG on Win32 and Linux for instance... If not, we could do multiple polls one per platform, or just concentrate on Win32 since that's where the problem is more prominent. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.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] osgField / osgIntrospection
Hi, I've been looking at the osgField node kit (http://orihalcon.jp/osgfield/). It looks like it enables some really nice functionality, but hasn't been updated since 2006. Is anyone available of a similar node kit (or a tutorial on osgIntrospection), that would allow me to do animations on things like MatrixTransform nodes using properties? Thanks in advance, Jim. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenFlight exporter question
Hi Paul,
Out of curiosity I tried changing the range mode from PIXEL_SIZE_ON_SCREEN to
DISTANCE_FROM_EYE_POINT which should be the same as re-modeling the LODs using
eye distance. The model will load as an OSG file in osgViewer, however when it
is converted to an OpenFlight model, it does not appear at all. Converting the
FLT file back to an OSG produces interesting results.
While the vertices are all correct, only one of the two models is written to
the FLT file. Also, the RangeMode is correct, but the RangeList contains only
one element instead of the original two. Debugging shows that
FltExportVisitor::apply (osg::Geode node) is only called twice instead of the
expected three times (once for the first range and twice for the second.)
Confusing the issue further, the FltExportVisitor::apply(osg::LOD lodNode)
function correctly sees that lodNode should have two LODs. However, the
writePushTraverseWritePop function has no effect the first time through the
loop. Stepping into the code, I noticed that the
osg::Node::traverse(NodeVisitor ) is being called, which by default does
nothing. The second time through the loop is when the aforementioned
FltExportVisitor::apply(osg::Geode) function is reached twice.
I thought that I would see what happened if the lone Geode in the lodsample.osg
file was added to a group. While the osgviewer could view the file, the
osgconv program could not. Converting the resulting FLT file from this test
back to an OSG file resulted in a five line file:
Group {
name lod2
nodeMask 0x
cullingActive TRUE
}
Brian
On Mon Jun 16 23:03 , 'Paul Martz' [EMAIL PROTECTED] sent:
Hi Brian -- Your LOD node is configured to switch children based on screen
size. OpenFlight doesn't support this. You'll need to re-model the LODs
using eye distance.
The LOD exporter should probably display a warning in this case, but as I am
in the middle of a vacation, I won't be able to make that change
immediately. Could you please add the warning message and post to
osg-submissions? Thanks.
-Paul
Hi Paul,
Yes, I thought about the version possibly being an issue, so
I downloaded 2.5.2 but saw the same problem.
Back a few months ago, I was given a sample LOD OSG file. As
a test I ran the converter against it, but it also had the
same problem. I've attached the file that Hans Elbers
provided me and am curious as to whether its format is
correct in terms of the converter. Are there any command
line switches that I need to use with osgconv?
Thanks,
Brian
On Mon Jun 16 12:43 , 'Paul Martz' [EMAIL PROTECTED] sent:
Hi Brian -- First, make sure you're on 2.5.x, as some
important changes
were made post-2.4.
OSG LOD nodes are exported; see FltExportVisitor.cpp line 210. The
FltExportVisitor class does _not_ override apply(PagedLOD), so
PagedLOD nodes should be treated as regular LOD nodes for
purposes of
export. This means they receive no additional special
interpretation or
treatment (they don't write external reference records), and
it means they must look like
LOD nodes (they must have actual subtree children; file
names alone are
not sufficient).
I hope that helps,
-Paul
-Original Message-
From: [EMAIL PROTECTED]
[EMAIL PROTECTED]','','','')osg-users-bou
[EMAIL PROTECTED] On Behalf Of Brian
Sent: Monday, June 16, 2008 9:47 AM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] OpenFlight exporter question
Hi,
I was trying to convert some OSG models to the FLT format but ran
into a little trouble with one of the models. Only part
of the model
was converted. The model's LOD nodes were not touched by the
converter. I noticed in an earlier message that paged LOD support
does not exist yet, so is it safe to assume that what I am
seeing is
a direct result of that?
Thanks,
Brian
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce
negraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problem with osg 2.4 stable release
No I turned off the need to register for the Poll -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Melis Sent: Wednesday, June 18, 2008 11:38 AM To: OpenSceneGraph Users Subject: Re: [osg-users] problem with osg 2.4 stable release Gordon Tomlinson wrote: No problem doing a poll on http://www.vis-sim.com/3dsceneBB/, the form is setup for users to create polls... Would voting there imply registration on the forum? I've tried to formulate a poll below. It's impossible to cover every possibility, of course. For OS/X there are no prebuilt packages, right? How do you get your OpenSceneGraph binaries? (Windows) I use Mike Weiblen's precompiled binaries for both OSG and its dependencies (Windows) I compile OSG from source, but use precompiled dependencies (Windows) I compile OSG and its dependencies from source (Windows) Other (Linux) I compile OSG from source myself (Linux) I use packages provided by my distribution (Linux) Other Paul ( please note I have *.gmail.com on new account addresses disabled due to high spam attacks, I will turn this off if needed -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Melis Sent: Wednesday, June 18, 2008 11:12 AM To: OpenSceneGraph Users Subject: Re: [osg-users] problem with osg 2.4 stable release Hi J-S, Jean-Sébastien Guay wrote: Yes, the increase in size would be a downside. But disk space and memory are fairly cheap these days. I suspect only a small number of plugins would increase (jpg, png, tiff, jp2). I think we need to quantify it. Then we can evaluate if it's significant or not. If I have 16 OSG apps which all include (for example, I didn't try it) 5MB of dependencies statically linked each, that's 80MB instead of 5 (for the DLLs which could be shared). However, if I need to link to a specific version of OSG+deps, I'd need my application to include the specific DLLs in its directory anyways, so no savings there... I wasn't suggesting that _apps_ link statically, merely that the plugin DLLs link statically against their (non-OSG) dependencies. Perhaps linking to static dependencies could be an option in the CMake generation process, with the deps binary packages including static libs, and the default being static. Then if others want to compile and link to DLLs, they can switch the option in OSG's CMake config. Here I am suggesting ideas which I don't have time to implement... Shame on me. Spoken like a true open source contributor :) It would be interesting to know which users specifically are having problems: 1. using prebuilt OSG + dependencies (either Mike's deps or perhaps from the gnuwin32 project), not compiling their own app, are merely trying out the OSG 2. using prebuilt OSG + dependencies, are compiling their own app 3. using prebuilt dependencies, compiling OSG from source, compiling their own apps 4. compiling everything from source Are you suggesting a poll? Doing this on the mailing list would be a bit hard to keep track of... (Incidentally, I'm mostly in 3, though I'll have to move to 4 for 64 bit soon). Does the wiki have a poll functionality? Or perhaps we could use Gordon's forum for that? Well, it was more of a philosophical question, but a poll would be interesting. Using the ML for that will be horrible, although easy to do. I don't think trac supports polls out of the box. If we could have a web-based poll on the forum site we'd only have to publicize it on osg-users. What do you mean with the 4th mailing list for 64 bit, b.t.w? Paul ___ 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 mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Joining two types of cloths
lucas Grijander wrote: Dear all, in my application I have to model a cloth that has two regions with different properties (stiffness and bending parameters). Since we cannot specify this when creating a cloth, I tried to create two different cloths and tried to join them. From the several options for attachments of cloths, I use the attachVertexToShape function. Are you sure you are on the right mailing list? Seems more like an Ogre-related question :) http://svn.nxogre.org/branches/1.0/NxOgre/include/NxOgreCloth.h Paul One of the cloths is made by cutting a portion of the other cloth, so they will share the joining vertices. I created a small sphere in every vertex and I attached the corresponding vertices from both cloths to the same sphere, and so on... As you can see in the picture, it works quite well, both cloths move together, but there is a problem with the stiffness/bending properties on the closest vertices. Both cloths maintain their different properties but next to the frontier they behave completely wrong... Do you have any idea of why is this happening? any solution? On the other hand, any clue of doing the same cloth joining with another strategy? thanks in advance!! regards Jaime Garcia. Discover the new Windows Vista Learn more! http://search.msn.com/results.aspx?q=windows+vistamkt=en-USform=QBRE ___ 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] CMake 2.6 problem when compile with 64bit vista
huiliang yang wrote: Hi, I try to compile osg with cmake in vista 64bit pc, but it crash at beginning time and here is the error: Check for working C compiler: cl Check for working C compiler: cl -- broken CMake Error at C:/Program Files (x86)/CMake 2.6/share/cmake-2.6/Modules/CMakeTestCCompiler.cmake:32 (MESSAGE): The C compiler cl is not able to compile a simple test program. It fails with the following output: Change Dir: C:/bin/osg-bin/CMakeFiles/CMakeTmp Run Build Command:C:\PROGRA~2\MICROS~1.0\Common7\IDE\VCExpress.exe CMAKE_TRY_COMPILE.sln /build Debug /project cmTryCompileExec Microsoft (R) Visual C++ Express Edition Version 9.0.21022.8. Copyright (C) Microsoft Corp 2007. All rights reserved. The project consists entirely of configurations that require support for platforms which are not installed on this machine. The project cannot be loaded. What generator did you pick when you ran CMake? // since CMake doesn't have 64 bit version, does that means that 64 bit cannot be used for cmake? That should not be the case. -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 [EMAIL PROTECTED] http://www.kitware.com 518-371-3971 (phone and fax) ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problem with osg 2.4 stable release
HI OK the POLL is UP at http://www.vis-sim.com/3dsceneBB/viewtopic.php?t=1035 There's a slight glitch the forum software will not allow me to set voting to a non-registered user... So you need to register :(, I will see if I can hack the PHP/db tonight to allow this to happen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgViewer Custom Graphics Operations
Robert/OSG, What is the plan for OSG to grant us the ability to insert custom graphics operations in a controlled order? What I mean is, what if we want to process our own application-level callbacks immediately after makeCurrent() and immediately before swapBuffers() using osgViewer::CompositeViewer? There are too many things that we can't do using osgViewer::CompositeViewer and Camera/Cull callbacks. osgViewer::CompositeViewer doesn't permit us to do image-readPixels in order to do a screen capture. I've read all your advice on the topic in this forum. It just doesn't work. We have to roll our own render loop to the point that I never even call renderTraversals(). I made my own method that substitutes that method. Of course, I don't have access to the barriers, so my viewer must be single threaded. John Argentieri ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer Custom Graphics Operations
Hi John, I don't know what else you are trying to do, but as far as screen capturing goes, it is supported by the composite viewer. It is not explicitly supported by the osgViewer:CompositeViewer class, but it can be done through a derived osg::Camera::DrawCallback. The callback can be added to each osg::Camera in the osgViewer::CompositeViewer through the osg::Camera::setFinalDrawCallback() method. Hope this helps, Justin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Argentieri, John-P63223 Sent: Wednesday, June 18, 2008 3:37 PM To: [EMAIL PROTECTED] Subject: [osg-users] osgViewer Custom Graphics Operations Robert/OSG, What is the plan for OSG to grant us the ability to insert custom graphics operations in a controlled order? What I mean is, what if we want to process our own application-level callbacks immediately after makeCurrent() and immediately before swapBuffers() using osgViewer::CompositeViewer? There are too many things that we can't do using osgViewer::CompositeViewer and Camera/Cull callbacks. osgViewer::CompositeViewer doesn't permit us to do image-readPixels in order to do a screen capture. I've read all your advice on the topic in this forum. It just doesn't work. We have to roll our own render loop to the point that I never even call renderTraversals(). I made my own method that substitutes that method. Of course, I don't have access to the barriers, so my viewer must be single threaded. John Argentieri ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer Custom Graphics Operations
Justin, I tried the exact same thing as this, but I did a setPostDrawCallback instead of setFinalDrawCallback. Do you think that could make the difference? We are doing all sorts of things with OSG that might interfere. John From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vican, Justin E. Sent: Wednesday, June 18, 2008 4:06 PM To: OpenSceneGraph Users Subject: Re: [osg-users] osgViewer Custom Graphics Operations Hi John, I don't know what else you are trying to do, but as far as screen capturing goes, it is supported by the composite viewer. It is not explicitly supported by the osgViewer:CompositeViewer class, but it can be done through a derived osg::Camera::DrawCallback. The callback can be added to each osg::Camera in the osgViewer::CompositeViewer through the osg::Camera::setFinalDrawCallback() method. Hope this helps, Justin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Argentieri, John-P63223 Sent: Wednesday, June 18, 2008 3:37 PM To: [EMAIL PROTECTED] Subject: [osg-users] osgViewer Custom Graphics Operations Robert/OSG, What is the plan for OSG to grant us the ability to insert custom graphics operations in a controlled order? What I mean is, what if we want to process our own application-level callbacks immediately after makeCurrent() and immediately before swapBuffers() using osgViewer::CompositeViewer? There are too many things that we can't do using osgViewer::CompositeViewer and Camera/Cull callbacks. osgViewer::CompositeViewer doesn't permit us to do image-readPixels in order to do a screen capture. I've read all your advice on the topic in this forum. It just doesn't work. We have to roll our own render loop to the point that I never even call renderTraversals(). I made my own method that substitutes that method. Of course, I don't have access to the barriers, so my viewer must be single threaded. John Argentieri ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer Custom Graphics Operations
Hi John, The difference is small, but it can cause problems. The post draw callback is executed after the cameras scenegraph is rendered, but before any POST_RENDER camera nodes in the graph are rendered. POST_RENDER camera nodes are commonly used for 2D displays (i.e. HUD displays). If you are trying to capture a HUD with the post draw callback, it won't work. However, it should work for anything that is not inside a POST_RENDER camera. Robert added the final draw callback shortly after the OSG2.2 release after this issue was discovered. The final draw callback is called after everything in the scenegraph (including POST_RENDER cameras) is rendered. If you are trying to do screen captures, I would definitely use the final draw callback. Also, what arguments are you passing to the image::readPixels call? You will have to pass the x, y, width, and height values from the camera viewport to this method. -Justin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Argentieri, John-P63223 Sent: Wednesday, June 18, 2008 4:10 PM To: [EMAIL PROTECTED] Subject: Re: [osg-users] osgViewer Custom Graphics Operations Justin, I tried the exact same thing as this, but I did a setPostDrawCallback instead of setFinalDrawCallback. Do you think that could make the difference? We are doing all sorts of things with OSG that might interfere. John From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vican, Justin E. Sent: Wednesday, June 18, 2008 4:06 PM To: OpenSceneGraph Users Subject: Re: [osg-users] osgViewer Custom Graphics Operations Hi John, I don't know what else you are trying to do, but as far as screen capturing goes, it is supported by the composite viewer. It is not explicitly supported by the osgViewer:CompositeViewer class, but it can be done through a derived osg::Camera::DrawCallback. The callback can be added to each osg::Camera in the osgViewer::CompositeViewer through the osg::Camera::setFinalDrawCallback() method. Hope this helps, Justin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Argentieri, John-P63223 Sent: Wednesday, June 18, 2008 3:37 PM To: [EMAIL PROTECTED] Subject: [osg-users] osgViewer Custom Graphics Operations Robert/OSG, What is the plan for OSG to grant us the ability to insert custom graphics operations in a controlled order? What I mean is, what if we want to process our own application-level callbacks immediately after makeCurrent() and immediately before swapBuffers() using osgViewer::CompositeViewer? There are too many things that we can't do using osgViewer::CompositeViewer and Camera/Cull callbacks. osgViewer::CompositeViewer doesn't permit us to do image-readPixels in order to do a screen capture. I've read all your advice on the topic in this forum. It just doesn't work. We have to roll our own render loop to the point that I never even call renderTraversals(). I made my own method that substitutes that method. Of course, I don't have access to the barriers, so my viewer must be single threaded. John Argentieri ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
