Permalink
Switch branches/tags
OpenSceneGraph_1_2_release_revision_2 OpenSceneGraph_1_2_release_revision_1 OpenSceneGraph_1_1_release_revision_1 OpenSceneGraph_1_0_0_release_revision_1 OpenSceneGraph_0_9_9_release_revision_1 OpenSceneGraph_0_9_8_release_revision_2 OpenSceneGraph_0_9_8_release_revision_1 OpenSceneGraph_0_9_7_release_revision_2 OpenSceneGraph_0_9_7_release_revision_1 OpenSceneGraph-3.5.6 OpenSceneGraph-3.5.5 OpenSceneGraph-3.5.4 OpenSceneGraph-3.5.3 OpenSceneGraph-3.5.2 OpenSceneGraph-3.5.1 OpenSceneGraph-3.5.0 OpenSceneGraph-3.4.1 OpenSceneGraph-3.4.1-rc3 OpenSceneGraph-3.4.1-rc2 OpenSceneGraph-3.4.1-rc1 OpenSceneGraph-3.4.0 OpenSceneGraph-3.4.0-rc11 OpenSceneGraph-3.4.0-rc10 OpenSceneGraph-3.4.0-rc9 OpenSceneGraph-3.4.0-rc8 OpenSceneGraph-3.4.0-rc7 OpenSceneGraph-3.4.0-rc6 OpenSceneGraph-3.4.0-rc5 OpenSceneGraph-3.4.0-rc4 OpenSceneGraph-3.4.0-rc3 OpenSceneGraph-3.4.0-rc2 OpenSceneGraph-3.4.0-rc1 OpenSceneGraph-3.3.9 OpenSceneGraph-3.3.8 OpenSceneGraph-3.3.7 OpenSceneGraph-3.3.6 OpenSceneGraph-3.3.5 OpenSceneGraph-3.3.4 OpenSceneGraph-3.3.3 OpenSceneGraph-3.3.2 OpenSceneGraph-3.3.1 OpenSceneGraph-3.3.0 OpenSceneGraph-3.2.2 OpenSceneGraph-3.2.2-rc3 OpenSceneGraph-3.2.2-rc2 OpenSceneGraph-3.2.2-rc1 OpenSceneGraph-3.2.1 OpenSceneGraph-3.2.1-rc7 OpenSceneGraph-3.2.1-rc6 OpenSceneGraph-3.2.1-rc5 OpenSceneGraph-3.2.1-rc4 OpenSceneGraph-3.2.1-rc3 OpenSceneGraph-3.2.1-rc2 OpenSceneGraph-3.2.1-rc1 OpenSceneGraph-3.2.0 OpenSceneGraph-3.2.0-rc4 OpenSceneGraph-3.2.0-rc3 OpenSceneGraph-3.2.0-rc2 OpenSceneGraph-3.2.0-rc1 OpenSceneGraph-3.1.10 OpenSceneGraph-3.1.9 OpenSceneGraph-3.1.8 OpenSceneGraph-3.1.7 OpenSceneGraph-3.1.6 OpenSceneGraph-3.1.5 OpenSceneGraph-3.1.4 OpenSceneGraph-3.1.2 OpenSceneGraph-3.1.1 OpenSceneGraph-3.1.0 OpenSceneGraph-3.0.1 OpenSceneGraph-3.0.1-rc3 OpenSceneGraph-3.0.1-rc2 OpenSceneGraph-3.0.1-rc1 OpenSceneGraph-3.0.0 OpenSceneGraph-3.0.0-rc7 OpenSceneGraph-3.0.0-rc6 OpenSceneGraph-3.0.0-rc5 OpenSceneGraph-3.0.0-rc4 OpenSceneGraph-3.0.0-rc3 OpenSceneGraph-3.0.0-rc2 OpenSceneGraph-3.0.0-rc1 OpenSceneGraph-2.9.16 OpenSceneGraph-2.9.15 OpenSceneGraph-2.9.14 OpenSceneGraph-2.9.13 OpenSceneGraph-2.9.12 OpenSceneGraph-2.9.11 OpenSceneGraph-2.9.10 OpenSceneGraph-2.9.9 OpenSceneGraph-2.9.8 OpenSceneGraph-2.9.7 OpenSceneGraph-2.9.6 OpenSceneGraph-2.9.5 OpenSceneGraph-2.9.4 OpenSceneGraph-2.9.3 OpenSceneGraph-2.9.2 OpenSceneGraph-2.9.1 OpenSceneGraph-2.9.0 OpenSceneGraph-2.8.5 OpenSceneGraph-2.8.5-rc4
Nothing to show
Commits on Jan 28, 2011
  1. From Ulrich Hertlein, "I adapted the Cocoa implementation so that it …

    robertosfield committed Jan 28, 2011
    …reports the unmodified key
    
    and the modified key as requested. Can other OS X developers please test
    the attached file, to make sure it works for everybody?
    
    I fixed the problem with the caps-lock-key, too."
  2. Fixed size of default font

    robertosfield committed Jan 28, 2011
  3. From Mathias Froehlich, "Driven by the last qfontimplementation chang…

    robertosfield committed Jan 28, 2011
    …es, I realized, that I never
    
    contributed my testcase/demo for the original implementation.
    This attached change is similar to osgtext but uses the QFontImplementation in
    a Qt based viewer.
    With that, it should be easier for all of us to test changes in
    qfontimplementation"
  4. From Ulrich Hertlien, "the changes from r12126 (see below) in dae/dom…

    robertosfield committed Jan 28, 2011
    …SourceReader.h cause compiler errors on OS X
    
    with gcc-4.2.1:
    
    In file included from
    /Users/uli/Projects/osg/OpenSceneGraph/src/osgPlugins/dae/daeRAnimations.cpp:3:
    /Users/uli/Projects/osg/OpenSceneGraph/src/osgPlugins/dae/domSourceReader.h:43: error:
    explicit specialization in non-namespace scope 'class osgDAE::domSourceReader'
    /Users/uli/Projects/osg/OpenSceneGraph/src/osgPlugins/dae/domSourceReader.h:45: error:
    explicit specialization in non-namespace scope 'class osgDAE::domSourceReader'
    /Users/uli/Projects/osg/OpenSceneGraph/src/osgPlugins/dae/domSourceReader.h:47: error:
    explicit specialization in non-namespace scope 'class osgDAE::domSourceReader'
    /Users/uli/Projects/osg/OpenSceneGraph/src/osgPlugins/dae/domSourceReader.h:49: error:
    explicit specialization in non-namespace scope 'class osgDAE::domSourceReader'
    /Users/uli/Projects/osg/OpenSceneGraph/src/osgPlugins/dae/domSourceReader.h:51: error:
    explicit specialization in non-namespace scope 'class osgDAE::domSourceReader'
    ...
    
    The attached file fixes this."
Commits on Jan 27, 2011
  1. From Eric Buehler, "I believe that the osgWidget::Window::HA_CENTER a…

    robertosfield committed Jan 27, 2011
    …lignment should be center aligned rather than by the origin, as the osgWidget::Window::VA_TOP causes.
    
    The current setAnchorHorizontal() command doesn't center the center of the object, it just center's the object's origin.  The following change to osgWidget::Window::update() will correct that behavior so that it is consistent with setAnchorVertical() behavior.
    "
  2. From Sukender, "I found the bug I was chasing! Here is my "twin" subm…

    robertosfield committed Jan 27, 2011
    …ission, from latest trunk rev: 12124.
    
    1. DAE submission:
    DAE plugin now correctly writes images URI in Collada file, when images are used twice.
    I also greatly improved readability and maintenability of geometry reading (mainly daeRGeometry.cpp), by factorizing code, templatizing it (for double/single precision), and removing ugly macros.
    
    2. osgDB submission:
    I updated osgDB::getPathRelative(): it is now far more readable, it handles more cases (especially when you want to relativise "a/c" from "a/b", which results in "../c"), and I added comments to make it clearer to maintain."
  3. From Alexander Sinditskiy, "reason of this changes described in http:…

    robertosfield committed Jan 27, 2011
    …//forum.openscenegraph.org/viewtopic.php?t=7596
    
    and another problem is:
    example osgkeyboard is not work (keys not highlight) if user have 2 keyboard layout native and english and current user layout is native
    
    I try to explain my changes
    
    we need something that is identify key without modifier keys and layout  -> this is UnmodifedKey
    
    I think osg must have its own UnmodifiedKeys table. Code must be run same on different platforms. This can de guaranteed by UnmodifiedKeys table.
    
    Mikhail Izmestev helped me. He implemented VirtualKey changes in GraphicsWindowX11"
Commits on Jan 26, 2011
  1. From Mourad Biyfarguine, "This is a fix to some 'potentially uninitia…

    robertosfield committed Jan 26, 2011
    …lized local variable' warnings in src/osg/glu/libutil/mipmap.cpp."
  2. From Wang Rui, "I've found a problem when using QFont (osgQt/QFontImp…

    robertosfield committed Jan 26, 2011
    …lementation.cpp)
    
    to read fonts: only the first character of a whole text is correctly
    shown and others are disappeared. I haven't got into the font
    implementation so can't explain why this happened and how it should
    work under other platforms, but it seems to be fixed by specifying
    width and height of the glyph object. The source file is attached for
    future developments. At present it just works for my own project. :-)
    "
Commits on Jan 25, 2011
  1. Fixed warnings

    robertosfield committed Jan 25, 2011
Commits on Jan 24, 2011
  1. Added osggraphicscost example as a base of for developing and testing…

    robertosfield committed Jan 24, 2011
    … the new osgUtil::GraphicsCostEsimator class.
  2. From Michael Platings, Fix animation duration when adding channel to …

    Cedric Pinson committed Jan 24, 2011
    …animation
Commits on Jan 21, 2011
  1. From Sukender, "

    robertosfield committed Jan 21, 2011
    DAE plugin was linking ORIGINAL images in the Collada file, using image->getName() as a path (even if images were modified in memory!). As the behaviour was not the one of other plugins (3DS, FBX, and such), I made the plugin relativise images filenames (as those plugins) and write the image which is in memory. However, in order to avoid removing features, I kept the previous behaviour but moved it in an option. Here are the options of the plugin I changed:
    - daeForceTexture was unclear in this new context and removed in favor of two new options
    - daeLinkOriginalTexturesNoForce: Writes reference to the original image if found, instead of writing the image in memory
    - daeLinkOriginalTexturesForce: Writes reference to the original image even if not found, instead of writing the image in memory
    Of course, if you specify no option, images are written as for other plugins.
    
    Other thing I changed is the UTF8 support as I told you in a previous conversation. Now there is a simple option, "daeNamesUseCodepage", which makes all names except filenames (materials, animation, geometries...) be considered as encoded using current codepage. If so, they'll be converted to UTF8 when writing; else they are written directly. Of course, filenames follow OSG_USE_UTF8_FILENAME as usual.
    
    I did "
  2. From Sukender: I had to call code from the FBX plugin (to relativise …

    Michael PLATINGS committed Jan 21, 2011
    …paths). I thus extracted it from FBX and moved it in osgDB (FileNameUtils)
Commits on Jan 20, 2011
  1. From Matthew Johnson-Roberson, "Small fix for operation thread to pro…

    robertosfield committed Jan 20, 2011
    …tect the access to _operations vector by functions getNumOperationsInQueue() and empty(). It is simply an addition of OpenThreads::ScopedLock<OpenThreads::Mutex> lock(_operationsMutex);
    
    to protect against accessing while writing which was segfaulting in VPB
    specifically in void ThreadPool::run(osg::Operation* op)
    in the waiting loop
    
    while (_operationQueue->getNumOperationsInQueue() >= _maxNumberOfOperationsInQueue)
    "
  2. From Simon Julier, "I have been using the ply plugin to read files cr…

    robertosfield committed Jan 20, 2011
    …eated by bundler and pmvs2 (http://grail.cs.washington.edu/software/pmvs/). This program generates models in the form of vertices only. However, the existing ply reader implementation was not able to handle the models generated in a satisfactory manner for two reasons:
    
    1. It did not support normals applied to individual vertices.
    2. It would only support red / green / blue colour triples, but the pmvs models are generated with diffuse colours. (The PLY format, http://local.wasp.uwa.edu.au/~pbourke/dataformats/ply/, lists specular and ambient colour forms as well.)
    
    To partially overcome these limitations, please find attached modified versions of
    
    src/osgPlugins/ply/vertexData.cpp
    src/osgPlugins/ply/vertexData.h
    
    The changes I've made are:
    
    1. I have changed the boolean hasColor flag to a vertexField (which is a boolean operation on an enum) to indicate what fields are present in the ply file. (This is required because Turk's ply reader spits out warnings for every line where you try to read fields which do not exist.)
    2. I have modified the code to apply valid normals to either triangles or vertices.
    3. I have kludged in "support" for the various colour variants. Specifically, all the colour specified can be read from the file. However, they are all applied in the same way (namely as a colour array, bound to each vertex)."
Commits on Jan 19, 2011
  1. From Simon Julier, "I ran across linking errors with osgdb_exr. Speci…

    robertosfield committed Jan 19, 2011
    …fically, I found it was necessary to link against libImlIlf, libImlThread, libHalf, libIex and libzip.
    
    I have attached a patch, against the trunk from 13:30 today, which consists of the following:
    
    1. CMakeModules/FindOpenEXR.cmake: Look for libIlmThread and libIex as well. 2. src/osgPlugins/CMakeList.txt: Only include the exr subdirectory if both the OpenEXR and zip libraries were found. 3. src/osgPlugins/exr/CMakeLists.txt: Add ZIP_LIBRARY to TARGET_EXTERNAL_LIBRARIES."