Re: [osg-users] [GL ES2] Compilation errors on master branch
Hi Terry, On 4 June 2015 at 20:37, Terry Welsh mogu...@gmail.com wrote: I'm no cmake expert, but I think you can do something like that with check_symbol_exists or check_type_size. A first step might be to add a CMake var in, then next automatically set it's value. Is there any reason the typedef needs the same name? Can you just create a unique OSGint64 and OSGuint64 instead? That might be the simplest solution if opengl headers are too inconsistent. In the past I tried to just keep the extension functions compatible with their OpenGL counterparts. Why OSGuint64 would be compile compatible it's be inconsistent what users would expect when comparing OSG code with OpenGL docs. Another workaround might be to simply put the typedef's into osg namespace. This way you could always provide the definition. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Android osgPlugins
Hi, So, I got to made it work. I re-compiled OSG with the ABI platform 15 in separate gles1 and gles2 folder, then made to linking in the Android.mk of osgAndroid. Then, I put the glider.osg from the OSG Datasets repository on the device, I removed my Backround adaptation (which seems to weirdly do foreground colour) and: abracadabra, the glider was rendered on my device, which is really cool. Thanks again for all the help. For reproducability, I think I'll write a small manual on the experience, which, when it is ready, I'd be willing to contribute to the community. Thank you all again! Cheers, Christian -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=63959#63959 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Android osgPlugins
On Fri, Jun 5, 2015 at 7:06 PM, Christian Kehl christian-k...@web.de wrote: Hi, So, I got to made it work. I re-compiled OSG with the ABI platform 15 in separate gles1 and gles2 folder, then made to linking in the Android.mk of osgAndroid. Then, I put the glider.osg from the OSG Datasets repository on the device, I removed my Backround adaptation (which seems to weirdly do foreground colour) and: abracadabra, the glider was rendered on my device, which is really cool. Thanks again for all the help. For reproducability, I think I'll write a small manual on the experience, which, when it is ready, I'd be willing to contribute to the community. That's really good news then! And, please do write your experience up, it might help someone in the future. Building things for Android is far from a smooth experience, thanks to Google's lack of love for the NDK :( All the best, Jan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] osgDB::readImageFile() chooses ffmpeg over libpng
I'm working on this today.. And I've noticed.. it's not just .png files. If
I use osgdb_ffmpeg, it takes over ALL images.
I'm attempting to walk through the call stack..
Code:
starting here...
Registry.cpp - line 992
ReadImageFunctor(const std::string filename, const Options*
options):ReadFunctor(filename,options) {}
ending up here...
ReaderWriterFFmpeg.cpp - line 136
virtual ReadResult readImage(const std::string filename, const
osgDB::ReaderWriter::Options* options) const
It appears that the plugins are iterated and FFMPEG is allways selected for
ReadImage()
I'm having a hard time locating where exactly the plugin is selected. [/code]
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=63962#63962
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Possible improvement for CullThreadPerCameraDrawThreadPerContext threading model
Hi,
I was playing around with threading models today and found something odd.
For the sake of experiment, I used a osgViewer with a master camera, a slave
camera using the same graphics context as the master camera, and the
CullThreadPerCameraDrawThreadPerContext threading model.
I found that the osgViewer does not commence the next frame until the last
camera's draw dispatch has started. That is strange. My scene has 0 dynamic
objects in it, so logically speaking the next frame could commence as soon as
all the cull threads are done and the first camera's draw dispatch starts.
I attached some pictures to illustrate what I mean. The first picture is what I
am seeing, the second picture is what I would have expected to see.
I fired up the debugger and found OSG was blocking in the _endDynamicDrawBlock.
The block gets released in Renderer::draw, but each camera needs to get there
first, i.e. start drawing.
The idea for a fix would be simple: if there are no dynamic objects in the
scene, we release the block in GraphicsContext::runOperations, for each camera,
before the cameras start drawing.
i.e., we move this piece of code from Renderer::draw to
GraphicsContext::runOperations:
state-setDynamicObjectCount(sceneView-getDynamicObjectCount());
if (sceneView-getDynamicObjectCount()==0
state-getDynamicObjectRenderingCompletedCallback())
{
// OSG_NOTICECompleted in cullstd::endl;
state-getDynamicObjectRenderingCompletedCallback()-completed(state);
}
In practice it may not be simple, for starters the GraphicsContext would need
access to the SceneView, which is a no go as the core osg can't depend on
osgViewer. Some refactoring would be needed to work around this issue, so
before I dive in head first, I want to ask if anyone has an alternative
suggestion, or done this kind of optimization before.
Thanks,
Jannik
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=63964#63964
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OT: documentation tool
Hi all. A OT question regarding documentation. What tool/pipeline do you use for building your documentation for your software? If you want to maintain documentation which contains pictures, references and you want to be able to create indexed nice printable PDF:s, online/html documentation etc. Support for version control through svn is a bonus (so don't say Microsoft Word!) Grateful for your input! /Anders -- __ Anders Backman, HPC2N 90187 Umeå University, Sweden and...@cs.umu.se http://www.hpc2n.umu.se Cell: +46-70-392 64 67 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] osgDB::readImageFile() chooses ffmpeg over libpng
My fix for this:
Upon inspection of ReaderWriterPNG.cpp
line - 371
Code:
virtual ReadResult readImage(const std::string file, const
osgDB::ReaderWriter::Options* options) const
{
std::string ext = osgDB::getLowerCaseFileExtension(file);
if (!acceptsExtension(ext)) return ReadResult::FILE_NOT_HANDLED;
.
.
.
if (!acceptsExtension(ext)) return ReadResult::FILE_NOT_HANDLED; seems to
filter the plugin's accepted extensions.
I've altered ReaderWriterFFmpeg.cpp to include this as well..
Code:
line - 135
virtual ReadResult readImage(const std::string filename, const
osgDB::ReaderWriter::Options* options) const
{
const std::string ext = osgDB::getLowerCaseFileExtension(filename);
if (!acceptsExtension(ext)) return ReadResult::FILE_NOT_HANDLED;
.
.
.
Not sure if this is the proper fix.. but it works for me.
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=63963#63963
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
