[osg-users] example of porting of scenegraph to native client, possible OSG port
Hi I thought someone at Google had already done this last year? this was work in progress and few things were added to support this, but as far as I remember not finished. but anyway API has changed so new effort is needed. Regards Sergey On Fri, Sep 16, 2011 at 8:15 AM, Chris 'Xenon' Hanson xe...@alphapixel.comwrote: On 9/15/2011 9:20 PM, Sergey Kurdakov wrote: Hi All, for quite a while I thought that porting OSG to Nacl would open many interesting opportunities I thought someone at Google had already done this last year? Regards Sergey ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://www.alphapixel.com/ Digital Imaging. OpenGL. Scene Graphs. GIS. GPS. Training. Consulting. Contracting. There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Image origin and scale
Hi Clement, The offsetAndScale image is for scaling the RGBA values rather than it's location is space. The Locator object is what determines the position in space. Robert. On Fri, Sep 16, 2011 at 6:06 AM, clement@csiro.au wrote: Hi, I have a problem to set the origin and the scale of the image. I am using osgVolume to render an image. Here is my code: osg::ref_ptrosg::Image osgImage = new osg::Image; osgTile = new osgVolume::VolumeTile; osgTile-setVolumeTechnique(new osgVolume::RayTracedTechnique()); osgLayer= new osgVolume::ImageLayer(osgImage.get()); osgVolume = new osgVolume::Volume; osgVolume-addChild(osgTile.get()); /// the size of the image int nx = 350; int ny = 350; int nz = 60; osg::RefMatrix* matrix = new osg::RefMatrix(nx, 0.0, 0.0, 0.0, 0.0, ny, 0.0, 0.0, 0.0, 0.0, nz, 0.0, 0.0, 0.0, 0.0, 1.0); osgVolume::Locator* locator = new osgVolume::Locator(*matrix); osgLayer-setLocator(locator); osgLayer-offsetAndScaleImage(osg::Vec4(-nx/2, -ny/2, -nz/2, 1.0), osg::Vec4(1.0, 1.0, 1.0, 1.0)); osgTile-setLocator(locator); osgTile-setLayer(osgLayer.get()); When I exxcute the above code, the image is located at somewhere, I need to use the mouse to zoom out until I saw the image. Also the rotation point is at image of bottom left. I would like to set the rotating point at the center of the image and it can show the right scale at startup. Anyone knows how to do it? Many thanks. Regards, Clement ___ 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] RenderBin implementation not found
HI Cory, I haven't heard of this specific problem before so you may well be the first! The RenderBin is effectively the default RenderBin, it's registered during the static construction of the RenderBinPrototypeList, see the top of src/osgUtil/RenderBin.cpp. The way it's written should ensure that the relevant bins are all registered before they are accessed, and from the error you see it look like this isn't happening. I guess it's possible that multiple threads might call renderBinPrototypeList() static method in a parallel and have the static constructed in an implement way in one of the threads. Could you try running osgviewer single threaded to see if that makes a difference. Robert. On Thu, Sep 15, 2011 at 5:51 PM, Cory Riddell c...@codeware.com wrote: A customer is having trouble running our OSG-based application on his computer. I sent him osgviewer.exe and when he runs osgviewer.exe cow.osg it works, but this message is printed on the console: Warning: RenderBin RenderBin implementation not found, using default RenderBin as a fallback. It's just a warning and he does see the cow, but I'm wondering if this message is a symptom of some other problem? FWIW, his workstation-class laptop has a FirePro m8900 video card with up to date drivers. Cory ___ 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] Image origin and scale
Hi Robert, If I placed all the codes before started to run the viewer, it is no problem. The scale and locator are correct. In my program, it allows to change the dimension of the image. Then it will render the image again. Because the dimension is changed, I used the same code as before to relocate and rescale the image. Unfortunately, it doesn't work this time. I guess the problem may be on how to let osg known the locator and scale is changed. Any idea? Regards, Clement From: osg-users-boun...@lists.openscenegraph.org [osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield [robert.osfi...@gmail.com] Sent: Friday, 16 September 2011 5:03 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Image origin and scale Hi Clement, The offsetAndScale image is for scaling the RGBA values rather than it's location is space. The Locator object is what determines the position in space. Robert. On Fri, Sep 16, 2011 at 6:06 AM, clement@csiro.au wrote: Hi, I have a problem to set the origin and the scale of the image. I am using osgVolume to render an image. Here is my code: osg::ref_ptrosg::Image osgImage = new osg::Image; osgTile = new osgVolume::VolumeTile; osgTile-setVolumeTechnique(new osgVolume::RayTracedTechnique()); osgLayer= new osgVolume::ImageLayer(osgImage.get()); osgVolume = new osgVolume::Volume; osgVolume-addChild(osgTile.get()); /// the size of the image int nx = 350; int ny = 350; int nz = 60; osg::RefMatrix* matrix = new osg::RefMatrix(nx, 0.0,0.0,0.0, 0.0,ny, 0.0,0.0, 0.0,0.0,nz, 0.0, 0.0,0.0,0.0,1.0); osgVolume::Locator* locator = new osgVolume::Locator(*matrix); osgLayer-setLocator(locator); osgLayer-offsetAndScaleImage(osg::Vec4(-nx/2, -ny/2, -nz/2, 1.0), osg::Vec4(1.0, 1.0, 1.0, 1.0)); osgTile-setLocator(locator); osgTile-setLayer(osgLayer.get()); When I exxcute the above code, the image is located at somewhere, I need to use the mouse to zoom out until I saw the image. Also the rotation point is at image of bottom left. I would like to set the rotating point at the center of the image and it can show the right scale at startup. Anyone knows how to do it? Many thanks. Regards, Clement ___ 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] How can I check which GLExtension is supported?
Hello, I would like check the hardware, so which extension is supported. I found the function isGLExtensionSupported(unsigned int contextID, const char *extension). What does the first parameter mean? Is this the graphics context id? And why do I need this? Thanks Martin -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How can I check which GLExtension is supported?
Ok I've got it! See the comment of the class documentation : Note: Must only be called within a valid OpenGL context, undefined behavior may occur otherwise. Thanks Martin Original-Nachricht Datum: Fri, 16 Sep 2011 11:56:17 +0200 Von: Martin Großer grosser.mar...@gmx.de An: osg-users@lists.openscenegraph.org Betreff: [osg-users] How can I check which GLExtension is supported? Hello, I would like check the hardware, so which extension is supported. I found the function isGLExtensionSupported(unsigned int contextID, const char *extension). What does the first parameter mean? Is this the graphics context id? And why do I need this? Thanks Martin -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] wrong values returned from getOceanSurfaceHeight in OsgOcean
hi,Jean-Sebastien Guay ,
Thank you for your quick reply, and sorry for my delayed response.
Maybe I got the values from the previous frame, but I dont know how to
correct it. Because I just know to use getOceanSurfaceHeightAt to get the
surface height.
I modified the oceanExample source directly. I make an example as follows:
1. query the heights around the specifed point as the z position of
particles, and draw the particles
2 use a updatecallback to update the new height by VBO
That is the code:
create and add the particle node to scene group:
Code:
osg::Node* particles = queryAndCreateParticles(pos,
scene-getOceanScene());
particles-setNodeMask(scene-getOceanScene()-getNormalSceneMask()|
scene-getOceanScene()-getReflectedSceneMask() |
scene-getOceanScene()-getRefractedSceneMask() |
CAST_SHADOW | RECEIVE_SHADOW );
particles-setUpdateCallback(new myParticleCallBack(pos,
scene-getOceanScene()));
scene-getOceanScene()-addChild(particles);
that's the function body:
Code:
osg::Vec3Array* particleVerts = new osg::Vec3Array;
osg::Vec3Array* particleNormls = new osg::Vec3Array;
class myParticleCallBack : public osg::NodeCallback
{
public:
myParticleCallBack() {}
myParticleCallBack(osg::Vec3f* pos, osgOcean::OceanScene*
oceanScene):_pos(pos), _oceanScene(oceanScene){}
virtual void operator()(osg::Node* node, osg::NodeVisitor* nv)
{
osg::Node* particles = dynamic_castosg::Node*(node);
osg::Geode* geode = particles-asGeode();
osg::Geometry* geom = (osg::Geometry*)geode-getDrawable(0);
osg::Vec3Array* verts = (osg::Vec3Array*)
geom-getVertexArray();
osg::Vec3Array* normls = (osg::Vec3Array*)
geom-getNormalArray();
static int start =0;
static int count = 0;
verts-clear();
normls-clear();
float foamBottom = _oceanScene-getOceanFoamBottom();
int num =0;
for(int i = -128; i128; i+=1){
for(int j = -128; j 128; j+=1) {
osg::Vec3f tempNormal;
float temp =
_oceanScene-getOceanSurfaceHeightAt(_pos-x()+i, _pos-y()+j, tempNormal);
verts-push_back(osg::Vec3f(_pos-x()+i,
_pos-y()+j, temp));
normls-push_back(tempNormal);
}
}
verts-dirty();
normls-dirty();
}
protected:
osg::Vec3f *_pos;
osgOcean::OceanScene* _oceanScene;
};
osg::Node* queryAndCreateParticles(osg::Vec3f* shipPos, osgOcean::OceanScene*
oceanScene)
{
particleVerts-clear();
particleNormls-clear();
for(int i = -128; i128; i+=1)
{
for(int j = -128; j 128; j+=1)
{
osg::Vec3f tempNormal;
float temp =
oceanScene-getOceanSurfaceHeightAt(shipPos-x()+i, shipPos-y()+j,
tempNormal);
particleVerts-push_back(osg::Vec3f(shipPos-x()+i,
shipPos-y()+j, temp));
particleNormls-push_back(tempNormal);
}
}
osg::VertexBufferObject* vertexVBO = new osg::VertexBufferObject;
vertexVBO-setUsage( GL_DYNAMIC_DRAW ); // data will be changed
frequently (specified and used repeatedly)
osg::VertexBufferObject* normalVBO = new osg::VertexBufferObject;
normalVBO-setUsage( GL_DYNAMIC_DRAW );
// assign vbos to the master arrays
particleVerts-setVertexBufferObject( vertexVBO );
particleNormls-setVertexBufferObject( normalVBO );
osg::Vec4Array* colors = new osg::Vec4Array;
colors-push_back(osg::Vec4f(1.f, 1.f, 1.f, 1.f));
osg::Geometry* geom = new osg::Geometry;
osg::Geode* geode = new osg::Geode;
geode-addDrawable(geom);
geom-setVertexArray(particleVerts);
geom-setNormalArray(particleNormls);
geom-setNormalBinding(osg::Geometry::BIND_PER_VERTEX);
geom-setColorArray(colors);
geom-setColorBinding(osg::Geometry::BIND_OVERALL);
geom-setUseDisplayList(false);
geom-setUseVertexBufferObjects(true);
geom-addPrimitiveSet(new osg::DrawArrays(GL_POINTS, 0,
particleVerts-getNumElements()));
osg::StateSet* set = geode-getOrCreateStateSet();
set-setMode(GL_BLEND, osg::StateAttribute::ON);
osg::BlendFunc *fn = new osg::BlendFunc();
fn-setFunction(osg::BlendFunc::SRC_ALPHA, osg::BlendFunc::DST_ALPHA);
set-setAttributeAndModes(fn, osg::StateAttribute::ON);
/// Setup the point sprites
osg::PointSprite *sprite = new osg::PointSprite();
[osg-users] osgjs - osgUtil.ShaderParameterVisitor
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I added in osgjs a new visitor to help to fine tune shader parameters. The visitor look for program in the scenegraph and extract uniforms. Then it bind html slider (chrome) to modify uniform value. For more convenience uniform value are stored in localStorage and reloaded. It misses some part like looking for existing uniform instead of creating new one... see a simple example http://osgjs.org/osgjs/examples/fog/index.html The visitor is in early development and guess some bugs :) Cedric - -- Cedric Pinson Provide OpenGL, WebGL and OpenSceneGraph services +33 659 598 614 - cedric.pin...@plopbyte.com http://plopbyte.com - http://osgjs.org - http://showwebgl.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5zO8EACgkQs6ZHzVQN0IivVwCfUAGcIgrn5VdgD6DgTNKLcfqA ruoAmgK4z3Q/604WOWQw0A8XN89vObw3 =0Bp4 -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] help with osgVolume
Hi Robert, I'm really sorry. It's my fault, my dicom files contain inconsistent files they are from different parts of body. Actually osgVolume example program can correctly parse my dicom files when I manually put those associated dicoms in one folder. I downloaded a free software named dicomviewer, it can automatically identify associated dicoms and extract them for rendering. Attachments are two rendering results from osgVolume and dicomViewer. Can one of osgVolume's command-lines make the rendering result achieve the effect of dicomViewer(looks like more transparent)? In this project my teacher wants to build program kind like dicomViewer in first phase. So I want how many features osgVolume can achieve dealing with dicom. Thank you for your time and consideration! Allen Wang 2011/9/15 Robert Osfield robert.osfi...@gmail.com Hi Allen, On Thu, Sep 15, 2011 at 3:28 AM, Allen Wing wanglinse...@gmail.com wrote: In my case, osgVolume cannot render CT dicom files correctly(they can be rendered by other software). Does that mean the dicom plugin cannot parse my dicom files? I really can't say as I don't know what problems you are having other than they don't render correctly. Could you post an example dicom datasets that illustrates the problem? Also post screenshots of the problems. Or it is because the dicom plugin uses ITK but not DCMTK? How can I know whether the plugin use ITK or DCMTK, How can I switch between them? I don't know whether you've built the dicom plugin, or whether it's built against ITK or DCMTK. Both ITK and DCMTK are libraries that won't be installed by default so you have to go and aquire them, be it from repositories such as on Linux or from published 3rd party binaries, or just by building the source yourself. Do you have either one or both installed? Is the OSG's CMake system finding these dependencies correctly? Robert. ___ 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] Cameras View Matrix - I am perplexed
(I want to correct my own post here, because, as this thread has shown, things I say in the distant past stick around in search engines forever...) On 9/15/2011 2:33 PM, Paul Martz wrote: The OpenGL FFP projection matrix transforms from eye coordinates into clip coordinates. Those two coordinate systems are defined in the spec (see section 2.11 / figure 2.6 in the 2.1 spec). +x = right, +y = up, +z = into the screen, and eye = origin are already the eye coordinate definition prior to transform by the projection matrix. This is wrong on two points. 1. A close read of the spec shows that it doesn't actually define these coordinate systems, and where the +y = up convention comes from might be a good topic for discussion in the OpenGL forums. I'm sure I knew the full story back in 1994, but it's lost in the fog of my memory. Perhaps it stems from simple Cartesian math: origin in lower-left corner of the window, +x = right, +y = up, and everything else is inferred from back-transforming. (Regardless, I still think the getLookAt code is correct, as it is just performing the inverse of osg::Matrix::lookat.) 2. The projection matrix usually performs a negative scale on z, to support right-handed world coordinates in conjunction with a +z = into the screen depth buffer convention. So I was wrong about eye coordinates above. Eye coordinates generally have -z = into the screen, not +z. The projection performs a negative scale on z, producing clip coordinates with +z = into the screen. I don't see where the spec actually prohibits setting up a different convention, though. Again, it might just be implicit in the math. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] RenderBin implementation not found
Hi Robert, I got the customer to run with --SingleThreaded and the warning disappeared. The warning seems to be somewhat sporadic. Cory On 9/16/2011 2:02 AM, Robert Osfield wrote: HI Cory, I haven't heard of this specific problem before so you may well be the first! The RenderBin is effectively the default RenderBin, it's registered during the static construction of the RenderBinPrototypeList, see the top of src/osgUtil/RenderBin.cpp. The way it's written should ensure that the relevant bins are all registered before they are accessed, and from the error you see it look like this isn't happening. I guess it's possible that multiple threads might call renderBinPrototypeList() static method in a parallel and have the static constructed in an implement way in one of the threads. Could you try running osgviewer single threaded to see if that makes a difference. Robert. On Thu, Sep 15, 2011 at 5:51 PM, Cory Riddell c...@codeware.com wrote: A customer is having trouble running our OSG-based application on his computer. I sent him osgviewer.exe and when he runs osgviewer.exe cow.osg it works, but this message is printed on the console: Warning: RenderBin RenderBin implementation not found, using default RenderBin as a fallback. It's just a warning and he does see the cow, but I'm wondering if this message is a symptom of some other problem? FWIW, his workstation-class laptop has a FirePro m8900 video card with up to date drivers. Cory ___ 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] RenderBin implementation not found
Sounds like this could be the static initialization order fiasco - http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.14 - or perhaps just a plain old race condition. Ryan On Fri, Sep 16, 2011 at 9:42 AM, Cory Riddell c...@codeware.com wrote: Hi Robert, I got the customer to run with --SingleThreaded and the warning disappeared. The warning seems to be somewhat sporadic. Cory On 9/16/2011 2:02 AM, Robert Osfield wrote: HI Cory, I haven't heard of this specific problem before so you may well be the first! The RenderBin is effectively the default RenderBin, it's registered during the static construction of the RenderBinPrototypeList, see the top of src/osgUtil/RenderBin.cpp. The way it's written should ensure that the relevant bins are all registered before they are accessed, and from the error you see it look like this isn't happening. I guess it's possible that multiple threads might call renderBinPrototypeList() static method in a parallel and have the static constructed in an implement way in one of the threads. Could you try running osgviewer single threaded to see if that makes a difference. Robert. On Thu, Sep 15, 2011 at 5:51 PM, Cory Riddell c...@codeware.com wrote: A customer is having trouble running our OSG-based application on his computer. I sent him osgviewer.exe and when he runs osgviewer.exe cow.osg it works, but this message is printed on the console: Warning: RenderBin RenderBin implementation not found, using default RenderBin as a fallback. It's just a warning and he does see the cow, but I'm wondering if this message is a symptom of some other problem? FWIW, his workstation-class laptop has a FirePro m8900 video card with up to date drivers. Cory ___ 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 -- Ryan Pavlik HCI Graduate Student Virtual Reality Applications Center Iowa State University rpav...@iastate.edu http://academic.cleardefinition.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [osgPlugins] Revisions plugin class name oddity.
Hi, Just for info really: I'm not sure if it affects anything, but I just noticed what seems to be a plugin class name clash. It looks as though ReaderWriterRevisions.cpp started its life as ReaderWriterFreeType.cpp, but class name and registration were not changed to suit the repurposing. I'm guessing this class name conflict is harmless when plugins are used as independent dlls, but not 100% sure about effect on plugin registration. Probably still worth correcting in any case, if only to avoid future puzzlement. I could submit a correction, but as I've never used the revisions plugin, not sure I'd be a good person to test the result. Cheers, Chris Denham -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42836#42836 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Release builds with gcc-llvm on Mac (Xcode 4), cosf/sinf recursion
Hi James, thanks for that impressive bit of detective work; I recently ran into that problem again but didn't have the nerve/time to look into it more closely. FWIW I've switched to clang/llvm on OS X and that works too (and supposedly produces better code), so it seems to be the gcc-llvm frontend that's at fault. Cheers, /ulrich On 15/09/11 0:47 , James Turner wrote: I've encountered a problem with the osg/Math header, which a few previous emails on this list have alluded to (based on searching the recent archives), but which has an interesting explanation. osg/Math defines the 'f' versions of cos/sin/floor/etc in terms of the double versions, on various platforms, including Mac. The implementation is an inline function, which casts the input argument, and calls the 'base' version from math.h Unfortunately, LLVM (or the GCC frontend) is smart enough to turn the cast + call of the base version back into the floating point version - but the symbol look-up then resolves to the osg wrapper - and hence the problem we're seeing. Since osg/Math was created, OS-X does define the 'f' versions - but I'm not sure which version started doing so - the 10.6 SDK math.h includes the 'f' variants, but plain gcc 4.2 wasn't smart enough to turn the cast-to-double + call pattern into the float version. The local workaround is simply to remove the __APPLE__ case around line 48 of osg/Math, but really it would be changed to a MAC_OS_X_VERSION_10_z, if someone can identify what value 'z' should have. If anyone still has a 10.5 SDK, they could check '/usr/include/architecture/i386/math.h' and see if the 'f' variants of the math functions are present. (What's the minimum version OSG claims to support at this time? 10.5 or still holding out with 10.4?) (Potentially this affects iOS too, though I'm not sure if Apple have enabled gcc-llvm for ARM yet, by de default) James ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Please remove me from distribution
___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please remove me from distribution
You can do it yourself, using the link at the bottom of all e-mails you receive from the list. Hope this helps, J-S -- __ Jean-Sébastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgPango text always black (even the examples)
Hi all, I've used osgPango successfully in the past on a different system, but am facing a strange problem now. All text renders black including in all the out-of-box examples (osgpangoanimation, etc), regardless of what the color is set to in the markup. Anyone else run into this? My system/version info is below. Fedora 15 / Gnome3 with proprietary nvidia drivers (280.13) osg version: 3.0.0 osgPango and osgCairo 1.0.0 tag versions pango 1.28.4 cairo 1.10.2 I've tried updating to the latest versions of osgPango/Cairo as well, no difference. Thank you! Cheers, Trystan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=42841#42841 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
