Parsing the key 'map_bump' was processed in the block, where the attributes
for 'bump' are extracted and results into having parts of the key in the
extracted filename, generating an invalid filename.
The mentioned string compare could be removed without loosing any features,
because the key 'map_bump' is parsed correctly some lines below.
It also contains a fix in the Xbase DBF parser, converting a numeric shape attribute to double instead of integer. As stated in e.g. https://en.wikipedia.org/wiki/.dbf the numeric field can contain decimals.
CMake cannot find 'pthread_getconcurrency’, ‘pthread_setconcurrency’ and ‘pthread_setaffinity_np' functions in 'pthread' library because when linking internal cmake test did’t specifed ‘-l pthread’.
when building for iOS, Xcode allows developers to specify to enable or disable the 'bitcode' compilation option. There's not a preferred way to go and the choice is really up to the developer but considering that:
1. Currently the generated project defaults the option to YES
2. There are almost 90 projects targets that should be modified if one wants to disable the bitcode option (which considerably reduces the footprint of the app)
3. Even though one can select all the 90+ targets and set the option to NO for all of them, the updates could take a few seconds and could be error prone because one could miss to select some targets
I propose to add a CMake setting that is displayed only when building for iOS. By setting this option "before" the project generation would speed up things for developers and would avoid errors at compiling time.
Code:
// Chooses the second font within the Menlo font collection
osg::ref_ptr<osgDB::Options> fontOptions = new osgDB::Options;
fontOptions->setObjectCacheHint(osgDB::Options::CACHE_OBJECTS);
fontOptions->setOptionString("index=1");
text->setFont(osgText::readFontFile("Menlo.ttc", fontOptions));
"
If your current OS where the application is running is Windows 8.1 or above it the function will exist in the dll or if its below it wont.
I checked the attached code with both a Windows 7 desktop (where the function doesn't exist) and a Windows 10 tablet (where it does and had my screen scaled to 150%) and in both cases the code worked as intended."
Applications that run on a Windows computer with desktop scaling enabled
gets scaled incorrectly since windows assumes that applications are
DPI-unaware unless declared otherwise.
This change declares the application DPI-aware, thus not automatically
scaled by the operating system.
The corresponding library call requires Windows 8.1 or later.
Added script to identify the Windows version used to compile the source.
Currently the windows version for Windows NT is hard coded into the
source. By running this CMake script the _WIN32_WINNT preprocessor
variable gets set to the corresponding windows version.
The define of _WIN32_WINNT was added to handle an error case from MinGW
,as described in commit 712ca43219
This was later giving warnings and thus undefined for MinGW by commit
3bf6fb1778
Since the two operations cancel each other out, they should be removed.
but have strange runtime errors:
0(100) : error C7623: implicit narrowing of type from "vec3" to "float"
0(108) : error C7623: implicit narrowing of type from "vec3" to "float"
Previously, the assumption was made that ilmbase and openexr were installed in a common directory and hence the header files and libs were both found in that common directory. That is not consistent with other libs and this submission makes it consistent and therefore the OSG configures out of the box. I made this work for ilmbase-2.1.0.tar.gz / openexr-2.1.0.tar.gz and ilmbase-2.2.0.tar.gz / openexr-2.2.0.tar.gz
Text improvements, introducing implementation of Signed Distance Function texture generation and new shaders for outlines and shadows replacing old multi-pass approach
--outline // enable outlne
--shadow // enable shadow
--offset ratio // set the backdrop offset
--text-color r g b a // set the text body color
--bd-color r g b a // set the shadow/outline color
--bg-color r g b a // window background color
-o filename // write create subgraph to disk using specified filename
false negatives (errors) about missing buffers, etc..
From the internet https://stackoverflow.com/questions/15335510/opengl-glvalidateprogram-error-on-mac-os-x :
« […] The purpose of glValidateProgram is not to use it as an added "check" step after linking the program, because the GL and application state is hardly ready for actually using that program at this point, probably it's even before we get around to initializing the default framebuffer (its bitdepth, its multisample buffers, etc), and that's what the error hints at.
An appropriate place to call glValidateProgram would be right before you make a real render call. »
Note that although the value_type is currently always double, using the proper typedef will open the door to implementing a float Quaternion in the future (as I have done so in my own fork)
Separately in the same file, I also needed to address the fact that the close button would not react on touch so I added to the top of the "handleNativeWindowingEvent" close button handling in case of touch events. Again this was tested on the same 2 devices.
move getTotalDataSize in CommandArrays interfaces
comply with other DrawElementsXXX removing parameters in mdi constructors and add several method ( allow use of osgUtil::DrawElementTypeSimplifer on these)
users will have to implement interfaces for their custom drawcommandarrays
add a lot of new primitive set + few defines
integration is made in osggpucull
Array::className() had fallen out of date with respect to Array::Type.
This commit updates it, and adds documentation and a debug message to
serve as a reminder for future additions of values to Array::Type.
Without the quotes around `${CPACK_GENERATOR}`, Windows CMake, generating
for VS2013, would exit with an error because the `STREQUAL` only had one arg.
c168887e5e
This commit inverted the value of the "fSign" variable, but did not update the previous code that used the variable. I've attached the change that restores the original behavior when not using the "ZUp"
Fix this build issue on VS2013:
```
\src\osg\State.cpp(99): fatal error C1017: invalid integer constant expression
```
I hope this works also on other platforms.
* Added configurable maintainer
* Added configurable dependencies and conflicts per package
* Added post install script to run ldconfig after package is installed
* Updated name of readme file in cpack configuration
The GLExtension object is now reused instead of creating a new when allocating a state on the same ContextID. The static map that stores the GLExtensions is only reset when all references to the extension object are released.
Check extensions trough extermination string - not by function pointer value.
Added a few validContext tests to ensure no functions or isExterntionSupported bool is set for an non valid context.
Remove duplicates / merge some lines.
Removed "GL_APPLE_texture_2D_limited_npot" form isNonPowerOfTwoTextureMipMappedSupported.
* updates uservalue serialization (avoid creating multie UserDataContainer for a same object)
* removes vec4ubarray specific serialization (serialization should not enforce the previous color transformation)
Documentation has been added for their default constructors. Furthermore, the consequences of different center modes have been explained. A comment regarding the setting of the radius has been fixed.
This should have been fixed in my old submission from 2012 but was probably overlooked due to an alternative way of comparing to a fix number for this feature type.
Without this fix, the plugin will only read one PointZ feature even if multiple features exist."
Added geometry.setUseVertexBufferObjects(true) to geometry set up for improved performance.
Refactored the color set up so that by default it assigns just a single color to the geometry to improve performance.
Sorry about this mixup, I was not aware that this particular directory was to be considered a separate project and must not rely on any dependencies from the rest of the OSG project. All OSGNOTIFY messages have been removed and the previous printf statements have been put back.
Adds a configuration file (.codedocs) for building the Doxygen
documentation using CodeDocs.xyz. Also, adds a badge to the README.md
to link to the documentation.
I added CTRL + RIGHT-MOUSE-CLICK to the standard manipulator as
an alternative to MIDDLE-MOUSE-CLICK because a 3 Button Mouse
not always available, e.g. on MacOS. I tested this with the
osgAtlasSimbicon example.
Added OSG_VERTEX_BUFFER_HINT env var to osg::DisplaySettings with VERTEX_BUFFER_OBJECT/VBO, VERTEX_ARRAY_OBJECT/VAO and NO_PREFERENCE to allow one to foce on VBO or VAO usage.
Restructred BufferObject assigned in osg::Geometry
Added
fix bug in SmoothingVisitor tripped by bunny.ply
after duplicating the vertices to allow for multiple normals the indices of the new mesh (with duplicated vertices) were used with the vertices of the old mesh, causing a vector subscript out of range error.
Some platforms (ARM, PowerPC, s390x) have "unsigned char" as the default
char type, and thus the build fails for certain parts of the code where
negative values are assigned to those kind of variables.
Only export the osgDB method implementations, instead of the entire
class, and hence avoid exporting symbols from the base class, which
then conflict with other compilation units when linking.
This avoids the need for /FORCE:MULTIPLE linker option with MSVC.
macOS CoreProfile, contains requested parts of #92 previous PR concerning the osgsimplegl3 sample and the selection of the correct GL Profile when compiling with GL3 or Core Profile in GraphicsWindowCocoa.mm
Update gles+osgjs.
This PR
cleans some gles coverity defects (remaining should only be false positive that need to be sorted out cleanly)
updates osgjs plugin to support serialization; the history of changes is squashed; details can still be found on cedricpinson fork if needed
As compressed animation channels are no longer part of the main repo, I added a compilation flag for the osgjs plugin. The commit is isolated and the flag is not activated by default.
I am yet to find a better solution to make this plugin entirely free from our specific code.
Note: this PR will not change the gles compilation issues. We only compile on OSX/ubuntu and did not encounter any issue with the plugin.
The logic is
* if a file is not ascii
* if its sizeis less than the expected binary size
then we can assume that the data is incomplete but still try to load it.
would trigger unnecessary redraws when there were pending file requests or active database threads
tested ok with and without IncrementalCompileOperation
Updates to osgAnimation is mainly for the gles plugint to work correctly.
adds Quaternion array
reintroduces KeyframeContainer::linearInterpolationDeduplicate
fixes MorphGeometry OSG serialization (target names)
This updates is mainly for the gles plugint to work correctly.
* adds Quaternion array
* reintroduces `KeyframeContainer::linearInterpolationDeduplicate`
* fixes MorphGeometry OSG serialization (target names)
Sometimes there is need to do cleanup with valid graphic contexts
before closing these contexts. The added operation runs a graphics
operation on each context before closing them.
It's code quality is poor and as there has been no sign that it's used in the community decided to remove it
rather than spend time trying to fix the mess it's in.
Incorrect values read from a different memory region will cause incorrect computations. In osgDB::base64_decode_value(char): Out-of-bounds read from a buffer
Objects with the same filename may be different from others based on the provided
plugin options. Using filename *and* the provided options as object cache key
helps to avoid fetching the wrong object.
Added the addtional properties (terrain, roofline and footprint) alongside with the SMC/FID attributes. Also I added the newly added IRMaterial to the per-geode properties.
Added the Texture-EffectId and the mapping index as a user-value to the texture object.
Naming scheme is the same as for the per-vertex/geode attributes.
OpenSceneGraph\src\osgPlugins\dae\daeRAnimations.cpp(470): warning C4456: declaration of 'kfCntr' hides previous local declaration
OpenSceneGraph\src\osgPlugins\dae\daeRAnimations.cpp(452): note: see declaration of 'kfCntr'
OpenSceneGraph\src\osgPlugins\dae\daeReader.cpp(202): warning C4456: declaration of 'i' hides previous local declaration
OpenSceneGraph\src\osgPlugins\dae\daeReader.cpp(188): note: see declaration of 'i'
OpenSceneGraph\src\osgPlugins\dae\daeReader.cpp(226): warning C4456: declaration of 'i' hides previous local declaration
OpenSceneGraph\src\osgPlugins\dae\daeReader.cpp(188): note: see declaration of 'i'
OpenSceneGraph\src\osgPlugins\dae\daeReader.cpp(243): warning C4456: declaration of 'i' hides previous local declaration
OpenSceneGraph\src\osgPlugins\dae\daeReader.cpp(188): note: see declaration of 'i'
OpenSceneGraph\src\osgPlugins\dae\daeReader.cpp(253): warning C4456: declaration of 'i' hides previous local declaration
OpenSceneGraph\src\osgPlugins\dae\daeReader.cpp(188): note: see declaration of 'i'
Corrected PrimitiveSet.cpp in order DrawArraysLength can be instanced.
It's the only pr missing code
if (_numInstances>=1) glDrawXXXInstanced(...,_numInstances);
else glDrawXXX();
Changed the name of OSG_USE_AGGRESSIVE_WARNINGS to OSG_AGGRESSIVE_WARNINGS to make sure it sits alongside the OSG_AGGRESSIVE_WARNINGS_FLAGS within ccmake
so that it's easier to see how the two variables are coupled.
Thanks to this simple fix it's possible to compress red/red-green channel of RGB/RGBA image to GL_COMPRESSED_RED_RGTC1_EXT/GL_COMPRESSED_SIGNED_RED_GREEN_RGTC2_EXT pixel format.
Actually, if the option "readObjectRecordData" is set, ObjectRecordData will not be read and set.
With this submission, if the option "readObjectRecordData" is set, ObjectRecordData will be read and set."
Note, from Robert, I took Philippe modifications to Viewer.cpp and reformated them slightly to avoid a double check against getSceneData()!=0 and then rolled
the changes out to CompositeViewer::checkNeedToDoFrame() to ensure that both implementations work the same.
Deferred rendering is now the de-facto standard rendering technique in many modern game engines, hence I think it is important to have this technique demonstrated in an osg code example.
This particular sample adds soft shadows as well as bump mapping into the rendering pipeline. The image files whitemetal_diffuse.jpg and whitemetal_normal.jpg from OpenSceneGraph-Data images folder are required (The OSG_FILE_PATH environment variable must be set correctly)
Two additional osgt models are included with the demo (best to also put them into OpenSceneGraph-Data, I think.
The shaders are currently defined in separate .frag and .vert files.
implementations being registered at the same time.
One usage case for this functionality to support usage of Wayland and X11 in the same version of the osgViewer.
As part of the new functionality there is now a osg::GraphicsContext::Traits::windowingSystemPreferrence string
that default to empty, but if defined will ensure that a specific WindowingSystemInterface is utilized when
you do a generic call like osg::createGraphicsContext().
Also implemented is standard proxy object for registering the new contexts and removing them automatically, and
declaration of standard graphicswindow_name() C entry point to help with static build linking.
This feature makes it easier to editor an presentation that is already running in Present3D, once the edits are done
pressing 'u' in Present3D then loads the file again.
"From I think that this piece of code in StateSet::setTextureAttributeAndModes is a copy&paste mistake:
OSG_NOTICE<<"Warning: non texture attribute '"<<attribute->className()<<"' passed to setTextureAttributeAndModes(unit,attr,value), "<<std::endl;
OSG_NOTICE<<" assuming setAttributeAndModes(attr,value) instead."<<std::endl;
OSG_NOTICE<<" please change calling code to use appropriate call."<<std::endl;
setAttribute(attribute,value);
As per the warning message it should be calling setAttributeAndModes(attribute,value); ."
The file osg-OpenSceneGraph-3.4.0\include\osg\Types
typedefs int8_t, int16_t, int32_t and int64_t
These are typedefed as signed __intX in several other places.
With VS2008, this causes an error "int8_t redifined, different basic types"
Explicitly declaring them signed fixes the error."
As for motivation behind the change, I think it makes more sense that way because only the CullVisitor cares about rendering. Say an intersection visitor or update visitor only needs to traverse the subgraph once, not once for each pass. For these visitors there is no point in traversing the subgraph more than once, since it's exactly the same graph. Another motivation is the performance improvement had when an intersection visitor tests against a multipass Technique."
Note about mods by Robert Osfield, "Changed dyanmic_cast<> and check against getTraversalType() to utilize the new asCullVisitor() instead to improve efficiency."
The change I made is to check GL_QUERY_RESULT_AVAILABLE before retrieving the query, to ensure that there won't be a stall. If the query result is not available yet, we'll leave it alone and try again in the next frame.
Had to make a few more changes than I'd liked, mostly because the TestResult mechanism wasn't designed for holding on to query objects for more than one frame. As well, I'm thinking that RetrieveQueriesCallback and ClearQueriesCallback could be merged together, if we wanted to go for more refactoring. For though now my strategy is to make as little changes as possible. Let me know what you think of the patch."
In OSG 3.4, osgText::Text( ::_quadIndices) uses DrawElementsUInt that will fail on these devices and no text will appear - tested on Samsung Galaxy Trend 2 SM-G313HN.
When DrawElementsUInt is replaced with DrawElementsUShort it works, although I'm not sure if this can cause other problems with some fonts.
Fix:
- In include\osgText\Text, line 316:
replace: "osg::ref_ptr< osg::DrawElementsUInt > _quadIndices;"
with: "osg::ref_ptr< osg::DrawElementsUShort > _quadIndices;"
- In src\osgText\Text.cpp, line 2094:
replace: "_quadIndices = new DrawElementsUInt(PrimitiveSet::TRIANGLES);"
with: "_quadIndices = new DrawElementsUShort(PrimitiveSet::TRIANGLES);"
"
Currently the code looks like this:
Code:
DrawElementsUByte* elems = new DrawElementsUByte(PrimitiveSet::TRIANGLES);
elems->push_back(0);
elems->push_back(1);
elems->push_back(2);
elems->push_back(2);
elems->push_back(3);
elems->push_back(0);
geom->addPrimitiveSet(elems);
geom->addPrimitiveSet(new DrawArrays(PrimitiveSet::QUADS,0,4));
The second condition looked really strange (note the ! sign), and results in pretty much all code paths uses the first code. The correct version should probably be that only people with GLES1 or GLES2 should use GL_TRIANGLES to simulate quads. And all others should use the native support for GL_QUADS.
"
/usr/local/include/collada-dom2.4
/usr/local/include/collada-dom2.2
/opt/local/include/collada-dom2.4
/opt/local/include/collada-dom2.2
/usr/include/collada-dom2.4
/usr/include/collada-dom2.2
To enable recent versions of the DOM to be found in their new install locations.
Font::getKerning(...), Font::getGlyph3D(...) doesn't ask for a font resolution so it uses the last font resolution requested by Font:: getGlyph(...).
This can leads to different results depending of the precedent call to Font::getGlyph(...).
See http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2016-January/271952.html for more infos.
This fix adds a font resolution parameter to Font::getKerning(...), Font::getGlyph3D(...) and to the font implementations.
This was made under the base revision r15182."
"E:\osg\osgSvnGit\OpenSceneGraph\include\osg/Callback(286): warning C4099: 'osg::DrawableUpdateCallback' : type name first seen using 'class' now seen using 'struct' (E:\osg\osgSvnGit\OpenSceneGraph\src\osgUtil\RenderBin.cpp)
E:\osg\osgSvnGit\OpenSceneGraph\include\osg/Callback(27) : see declaration of 'osg::DrawableUpdateCallback'
attached is a modified version of include/osg/Callback:
changing
- struct OSG_EXPORT DrawableUpdateCallback : public virtual Callback
- {
to
+ class OSG_EXPORT DrawableUpdateCallback : public virtual Callback
+ {
+ public:
and the same changes for DrawableEventCallback and DrawableCullCallback"
E:\osg\osgSvnGit\OpenSceneGraph\src\osg\PrimitiveSet.cpp(364): error C2039: 'min' : is not a member of 'std'
E:\osg\osgSvnGit\OpenSceneGraph\src\osg\PrimitiveSet.cpp(364): error C3861: 'min': identifier not found
E:\osg\osgSvnGit\OpenSceneGraph\src\osg\PrimitiveSet.cpp(372): error C2039: 'min' : is not a member of 'std'
E:\osg\osgSvnGit\OpenSceneGraph\src\osg\PrimitiveSet.cpp(372): error C3861: 'min': identifier not found
E:\osg\osgSvnGit\OpenSceneGraph\src\osg\PrimitiveSet.cpp(381): error C2039: 'min' : is not a member of 'std'
E:\osg\osgSvnGit\OpenSceneGraph\src\osg\PrimitiveSet.cpp(381): error C3861: 'min': identifier not found
E:\osg\osgSvnGit\OpenSceneGraph\src\osg\PrimitiveSet.cpp(436): error C2039: 'min' : is not a member of 'std'
E:\osg\osgSvnGit\OpenSceneGraph\src\osg\PrimitiveSet.cpp(436): error C3861: 'min': identifier not found
I suggest to replace std::min by osg::minimum, attached is a (zipped) modified version of src/osg/PrimitiveSet.cpp
applies to the git reposetory only (updated 1 Feb 2016 ae6bade641ee4d8436ef69e7a7a347be81195a47 )
"
Removed old code intended to check the Geode parent of a Drawable to see if it's CullingActive is true as this was broken by the change osg::Drawable being derived from osg::Node rather than osg::Object.
The uniquify() method was not checking if the new name was actually in use or not.
Collada with rename option : Added an option to Collada writer, to rename uncommon IDs (geometries, materials...) to something more compatible (especially Google Earth).
Characters which may be interpreted as an URI are replaced with '_'. Useful if you want to ensure names having spaces or slashes to behave correctly. This may be undesired if original naming must be somewhat kept (hence making it an option)."
Simplfifer::ContinueSimplificationCallback to be able to decide whether up or downsampling is required,
removing the previous hardwards reliance on getSampleRatio<1.0.
Two fixed files:
osgPlugins/osgjs/JSON_Objects
osgPlugins/stl/ReaderWriterSTL.cpp.
They did not compile with VS 2008 (recent master from Github). It looks like they defined stdint types (missing in VS 2008) but code using them also included <osg/Types> header. Errors were caused by minor differences in signed int definitions. I just removed own definitions and added include<osg/Types> instead. It solves the problem and makes the code clearer now.
forcing users to use osgDB::readRef*File() methods. The later is preferable as it closes a potential threading bug when using paging databases in conjunction
with the osgDB::Registry Object Cache. This threading bug occurs when one thread gets an object from the Cache via an osgDB::read*File() call where only
a pointer to the object is passed back, so taking a reference to the object is delayed till it gets reassigned to a ref_ptr<>, but at the same time another
thread calls a flush of the Object Cache deleting this object as it's referenceCount is now zero. Using osgDB::readREf*File() makes sure the a ref_ptr<> is
passed back and the referenceCount never goes to zero.
To ensure the OSG builds when OSG_PROVIDE_READFILE is to OFF the many cases of osgDB::read*File() usage had to be replaced with a ref_ptr<> osgDB::readRef*File()
usage. The avoid this change causing lots of other client code to be rewritten to handle the use of ref_ptr<> in place of C pointer I introduced a serious of
templte methods in various class to adapt ref_ptr<> to the underly C pointer to be passed to old OSG API's, example of this is found in include/osg/Group:
bool addChild(Node* child); // old method which can only be used with a Node*
tempalte<class T> bool addChild(const osg::ref_ptr<T>& child) { return addChild(child.get()); } // adapter template method
These changes together cover 149 modified files, so it's a large submission. This extent of changes are warrent to make use of the Object Cache
and multi-threaded loaded more robust.
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@15164 16af8721-9629-0410-8352-f15c8da7e697
OpenSceneGraph and the OpenThreads library.
The changes in the file simply remove a few ifndef's that currently
do not allow Linux systems to fully utilize the PThread real-time
scheduling API.
Since Linux now fully supports the PThread scheduling API it would
be beneficial to have it available to use as necessary. I have
been testing this change since OSG release 3.3.7 and have not seen
any ill affects.
The Priority scheduling api is further protected by another ifdef:
#ifdef ALLOW_PRIORITY_SCHEDULING
that only appears to be defined in the pthreads implementation as
well. This would make it unlikely that anyone would be affected
by this unless they are intentionally wanting to run with priority
scheduling. In which case on Linux they would need to make
these same modifications themselves to utilize it to its full extent.
Attached file is for the current trunk as of this date.
"
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@15140 16af8721-9629-0410-8352-f15c8da7e697
This approach unifies much of the code handling the clean up of OpenGL graphics data, avoids lots of local mutexes and static variables that were previously required,
and enables the clean up scheme to be easily extended by users providing their own GraphicsObjectManager subclasses.
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@15130 16af8721-9629-0410-8352-f15c8da7e697
I believe the offending lines are in the osg::Geometry copy constructor:
if ((copyop.getCopyFlags() & osg::CopyOp::DEEP_COPY_ARRAYS))
{
if (_useVertexBufferObjects)
{
// copying of arrays doesn't set up buffer objects so we'll need to force
// Geometry to assign these, we'll do this by switching off VBO's then renabling them.
setUseVertexBufferObjects(false);
setUseVertexBufferObjects(true);
}
}
Toggling the vertex buffer objects off then on again actually touches not only the arrays controlled by DEEP_COPY_ARRAYS, but also the PrimitiveSets which are controlled by DEEP_COPY_PRIMITIVES. This means if the user has copyflags of only DEEP_COPY_ARRAYS, we are modifying arrays that belong to the original const Geometry& we are copying from. I believe this shouldn't be allowed to happen because we are using a const& specifier for the original Geometry.
In my case the osgUtil::IncrementalCompileOperation was trying to compile the geometry, while in the main thread a clone operation toggled the VBO's off and on, a crash ensues.
In the attached patch, you will find a more efficient handling of VBO's in the osg::Geometry copy constructor, so that only the Arrays that were actually deep copied have their VBO assigned, and no changes are made to Arrays that already had a valid VBO assigned. In addition, the DEEP_COPY_PRIMITIVES flag is now honored so that VBO's are set up correctly should a user copy a Geometry with only that flag.
"
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@15129 16af8721-9629-0410-8352-f15c8da7e697
It should stop and wait for a signal on either of those two. Due to a few logical inversions it boils down to replacing || with &&
OLD _block->set((!_requestList.empty() || !_pager->_databasePagerThreadPaused));
NEW _block->set((!_requestList.empty() && !_pager->_databasePagerThreadPaused));//release the threads to run IF (work_to_be_done && not_paused)
This bug is present since svn rev 8663 (just before 2.6.0 release)
attached is a zip with the files:
OpenSceneGraph\include\osgDB\ImagePager
This file is valid for svn branch and stable 3.2 and 3.4
branches 2.6 - 3.0 have the same bug, but other differences in the file."
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@15125 16af8721-9629-0410-8352-f15c8da7e697
osgconv --compressed-dxt1 cow.osg cow.ive
due to different handling of the extentions in osg 3.4 and up.
attached is a zip with the files:
OpenSceneGraph\applications\osgconv\osgconv.cpp
This file is valid for svn branch and stable3.4."
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@15124 16af8721-9629-0410-8352-f15c8da7e697
setVertexAttribArrayList(array) with array containing NULL vertexAttrib.
I added a test in order to avoid it
Code:
void Geometry::setVertexAttribArrayList(const ArrayList& arrayList)
{
_vertexAttribList = arrayList;
dirtyDisplayList();
if (_useVertexBufferObjects)
{
for(ArrayList::iterator itr = _vertexAttribList.begin();
itr != _vertexAttribList.end();
++itr)
{
if(itr->get())//ADDED
addVertexBufferObjectIfRequired(itr->get());
}
}
}
"
and
"The bug i ran into is a crash reading osgt Geometry with null vertexattribs.
The only thing i added is a not nul check on array passed to setVertexAttribArrayList."
--------------------This line, and those below, will be ignored--
M src/osg/Geometry.cpp
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@15121 16af8721-9629-0410-8352-f15c8da7e697
I used osgSetGLExtensionsFuncPtr to remove the symbols. I don't know how to test this path, but it did remove the symbols from libosgViewer.so. I have also not been able yet to see if that was sufficient for our customer.
I did this by looking at other cases, and I tried to follow some of the same practices in PixelBufferX11, like using _useSGIX in a similar way to the previous _useGLX1_3."
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@15041 16af8721-9629-0410-8352-f15c8da7e697
http://www.openscenegraph.org/index.php/download-section/dependencies
but was not able to use them for a while. Attached are changes to
OsgAndroidMacroUtils.cmake that allow the deps to be found by cmake.
Specifically, all FIND_PATH commands require the
NO_CMAKE_FIND_ROOT_PATH option to actually find paths. This is odd
because if you inspect CMAKE_FIND_ROOT_PATH it appears to be empty. I
would expect it to have no effect at all.
I also needed to remove quotes from this line in order for headers to be found:
set(FREETYPE_INCLUDE_DIRS "${FREETYPE_DIR}/include
${FREETYPE_DIR}/include/freetype/config")
Assuming this script worked in the past, it seems like cmake behavior
may have changed at some point. I'm using cmake version 2.8.12.2."
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@15036 16af8721-9629-0410-8352-f15c8da7e697
On a Intel HD graphics Linux system with Mesa 10.1.3, I found that osg's Extensions::isTextureCompressionS3TCSupported() returned false, even though S3TC compressed textures *are* in fact working. I tested this by loading and rendering various DXT1, DXT3 and DXT5 compressed textures in the OSG.
"glxinfo | grep s3tc" gives:
GL_S3_s3tc
Note, if I install the package "libtxc-dxtn-s2tc0", I get in addition:
glxinfo | grep s3tc
GL_EXT_texture_compression_s3tc
GL_S3_s3tc
However, S3TC compressed textures worked correctly within the OSG even without libtxc-dxtn-s2tc0 installed.
I'm not sure what the differences between these extensions are, but based on the description at https://www.opengl.org/registry/specs/S3/s3tc.txt I would assume that both will work for OSG's purposes. The attached patch changes isTextureCompressionS3TCSupported() to accept either extension."
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@15035 16af8721-9629-0410-8352-f15c8da7e697
This gives arise to the requirement that a static initialization of a QObject cannot occur for the Android platform, as Qt incorrectly considers that first thread the “main” one before a client application has even begun executing in its second thread.
The HeartBeat in GraphicsWindowQt.cpp is a QObject static global initialized at load time, causing the above issue. This changeset changes it to be a singleton that is constructed upon first access to its “instance” method.
I have:
- added the static method “instance”,
- moved its constructor to be private, and
- changed the one place it is accessed to access it through the “instance” method.
"
Changes by Robert are to adopt QPointer<HeartBeat> rather than use a C pointer to ensure that the HeartBeat object will be cleaned up automatically rather than leaked.
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14963 16af8721-9629-0410-8352-f15c8da7e697
When an application is built with Qt4, but osgQt was built with Qt5 (or vice versa), upon #includeing osgQt users will receive an #error aborting the build.
This at least provides a proper error message rather than a crash, while we are working on better fixes for the problem."
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14918 16af8721-9629-0410-8352-f15c8da7e697
OpenSceneGraph\CMakeModules\FindOpenEXR.cmake
I introduced a bug in the previous submission pointed out by Dmitry Marakasov:
looking for IlmIlf instead of IlmImf (as the previous version did - but using variable OPENEXR_IlmIlf_LIBRARY)
For some reason google decided his message was spam, so I just noticed it, and I reply to confirm his remarks and attach a full file.
"
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14908 16af8721-9629-0410-8352-f15c8da7e697
osg::UniformCallback inherits osg::Callback now.
I don't really now if this class should be inside osgWrappers/serializers
because StateAttributeCallback is not presented there, but i've included it in the patch.
Please see archive in the attachment.
PS
DEEP_COPY_UNIFORMS works for me.
"
Note from Robert Osfield, added typedef UniformCallback Callback for backwards compatibility.
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14885 16af8721-9629-0410-8352-f15c8da7e697
I have left the Texture::generateTextureObject functions intact as I'm not sure if/how it's used outside the core OSG. If you feel that compatibility isn't important in that area feel free to drop it.
While testing the build with OSG_USE_REF_PTR_IMPLICIT_OUTPUT_CONVERSION=OFF I found a compile error in GlyphGeometry.cpp that was entirely unrelated to the changes I've made. The fix is included in the patch.
There is one thing left to fix and that is Texture2D::SubloadCallback:
class OSG_EXPORT SubloadCallback : public Referenced
{
public:
....
virtual TextureObject* generateTextureObject(const Texture2D& texture, State& state) const
{
return osg::Texture::generateTextureObject(&texture, state.getContextID(), GL_TEXTURE_2D);
}
...
}"
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14879 16af8721-9629-0410-8352-f15c8da7e697
Added osgText::Bevel::s/getRoundedConcaveJunctions(bool) to control how the bevel should be tessellated around concave junctions on the glyph boundary.
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14871 16af8721-9629-0410-8352-f15c8da7e697
the old intersect(BoundingBox&, float/double&, float/double&) method as it was inconsitent with the rest of the OSG including the intersect(BoundingSphere) method in how the ratio for the
second intersection was measure from - original from the end point, but now made consistent with other places in the OSG so be based on ration from start to end of segment.
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14859 16af8721-9629-0410-8352-f15c8da7e697
The first leak is in the lib3ds module (yeah, I know that probably should be corrected at http://code.google.com/p/lib3ds/ but I'm assuming that as no commits have happened there since 2011 that it may be better to fix the copy we have in the OSG of that project) The leak is caused by lib3d's use of realloc(ptr, 0) to free up memory allocations, but realloc, when ptr==NULL returns malloc(0) rather than NULL and thus leaks a zero byte allocation. The solution here was to adjust the 'lib3ds_util_reserve_array' function so that it realloc is not used to release a NULL pointer.
The second leak is in ReaderWriter3DS.cpp and arises when any of the created StateSet objects added to the StateSetMap don't subsequently get applied to a Node. The solution here was just to simply use the osg::ref_ptr around the raw StateSet pointer that was used in the locally defined StateSetInfo struct."
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14854 16af8721-9629-0410-8352-f15c8da7e697
If OSG_OPENGL_PROFILE="GLES3" =>
GraphicsWindowIOS will create gles3 context.
If failed, GraphicsWindowIOS will create gles2 context.
Multisampling also working.
"
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14831 16af8721-9629-0410-8352-f15c8da7e697
to compute the required matrix rather than using the NodePath provided by the NodeVistor. This is required
as in osg::computeLocalToWorld() usage case the NodeVisitor pointer is NULL, so the correct matrix isn't possible to compute.
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14828 16af8721-9629-0410-8352-f15c8da7e697
enum ResizeMask
{
RESIZE_VIEWPORT=1,
RESIZE_ATTACHMENTS=2,
RESIZE_PROJECTIONMATRIX=4,
RESIZE_DEFAULT=RESIZE_VIEWPORT|RESIZE_ATTACHMENTS
};
/** Resize, to the specified width and height, the viewport, attachments and projection matrix according to the resizeMask provided.
* Note, the adjustment of the projection matrix is done if the RESIZE_PROJECTIONMATRIX mask to set and according to the rules specified in the ProjectionResizePolicy. */
void resize(int width, int height, int resizeMask=RESIZE_DEFAULT);
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14811 16af8721-9629-0410-8352-f15c8da7e697
in the attachment (for 3.3.6 version :)
Fixes:
osg:
Unsupported associated class osg::UpdateCallback (osg_Drawable_UpdateCallback);
ComputeBoundingBoxCallback
osgAnimation:
Unsupported wrapper class osgAnimation::RigComputeBoundingBoxCallback
"
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14795 16af8721-9629-0410-8352-f15c8da7e697
OpenSceneGraph\CMakeModules\FindFBX.cmake
This version can find fbx sdk 2015.1 and will prefer it over older versions.
Tested with Visual Studio Express 2013 on 64bit windows 7"
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14782 16af8721-9629-0410-8352-f15c8da7e697
OpenSceneGraph\src\osgPlugins\sdl\JoystickDevice.cpp(42): error C2664: 'const char *SDL_JoystickName(SDL_Joystick *)' : cannot convert argument 1 from 'int' to 'SDL_Joystick *'
due to changes in the SDL api.
Tested with Visual Studio Express 2013; SDL 2.0.1"
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14776 16af8721-9629-0410-8352-f15c8da7e697
//GLbitfield mask = GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT;
This line was problematic since it produced incorrect result when let's say COLOR flag is serialized
it should be null as in Camera serializer or in a proposed BitFlagsSerializer
This line of code caused that whenever only GL_COLOR_BUFFER_BIT bit was written and on value read GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT was restored instead of GL_COLOR_BUFFER_BIT only.
//GLbitfield mask = 0; //this resolves the issue same as in camera
Also same bit-wise comparison bug was also present in write method.
-------------------------------------------------------------------------------------
As you can see there are total 3 bit mask serializers in OSG and all 3 had bugs so I decided to add ADD_BITFLAGS_SERIALIZER and replace USER serializers in osg::Camera, osg::ClearNode and osgText::TextBase. I have made sure that bitflags serializer does not break backwards-compatibility since it uses same code as user serializer does in all 3 cases. (see tester.cpp on how compatibility test was performed)"
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14752 16af8721-9629-0410-8352-f15c8da7e697
geometry is clipped as soon as it is tessellated. The clipping is
probably caused by rounding errors because it is only in one spot. The
clipping disappears when the camera is moved, and reappears when it is
moved back. Expanding the the bounding box fixed the clipping bug."
Tweaked by Robert Osfield to expand it to a -1 to 1 unit box.
Actual clipping bug is not due to rounding errors but the shaders creating vertices outside the bounding box of the original input vertices
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14747 16af8721-9629-0410-8352-f15c8da7e697
The OrbitManipulator calculates a scale to counteract the framerate dependency, but it turns out this scale wasn't used for the rotation yet."
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14744 16af8721-9629-0410-8352-f15c8da7e697
Currently if you do this you get strange looking results as the colors are calculated for values in the centre of each color step, so if your steps are large, the colors are interpolated sigificantly (see screen grab of red, green and blue colors for illustration).
I've attached a fix which just uses the original color values whenever _numColors equals the number of actual defined colors in the ColorRange. I doubt anyone would want interpolated colors in these circumstances."
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14720 16af8721-9629-0410-8352-f15c8da7e697
broken:
-- Could NOT find GStreamer (missing: GSTREAMER_BASE_INCLUDE_DIRS GSTREAMER_BASE_LIBRARIES GSTREAMER_GSTREAMER-APP_INCLUDE_DIRS GSTREAMER_GSTREAMER-APP_LIBRARIES GSTREAMER_GSTREAMER-PBUTILS_INCLUDE_DIRS GSTREAMER_GSTREAMER-PBUTILS_LIBRARIES) (found version "1.4.5")
though all required modules are installed.
There are two problems: first, module names are spelled incorrectly in root
CMakeLists.txt (e.g. gstreamer-app instead of app), so variables expected
for them are e.g. GSTREAMER_GSTREAMER-APP_INCLUDE_DIRS instead of
GSTREAMER_APP_INCLUDE_DIRS.
Second, gstreamer base component is detected as GSTREAMER while checked
later as GSTREAMER_BASE. I've uncommented the detection as
GSTREAMER_BASE, but obviously that should be revisited and only one
detection left. With this patch, gstreamer is detected properly and
the plugins is successfully built and installed."
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14719 16af8721-9629-0410-8352-f15c8da7e697
and outer tessellation. The minus key decrease both the inner and
outer tessellation. You can still use the arrow keys to control inner
and outer tessellation separately."
From Robert Osfield, clean up the code to fix warnings and make the coding style more consistent with the rest of the OSG.
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14716 16af8721-9629-0410-8352-f15c8da7e697
Introduced a new shader composition example based on the new #pragama and #define based GLSL shader/osg::StateSet::setDefine() functionality now built into the core OSG.
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14692 16af8721-9629-0410-8352-f15c8da7e697
"I have found a "bug" in the new audio decoding code (actually I think the bug is in ffmpeg, but anyway it should be wise to protect the OSG plug-in about it). I am attaching a security check in FFmpegDecoderAudio.cpp.
If anybody is curious about the problem, it happens sometimes when decoding an AAC audio stream. It eventually includes a PCE block inside the AAC audio frame and then ffmpeg audio decoding function signals a "new_frame" with 1024 samples, but a null pointer instead of the audio data. It can be easily detected because in these cases number of channels is 0. Maybe this is the intended behaviour for ffmpeg, but I find it quite weird.
"
" It seems that libav does not have a channels attribute in AVFrame structure. This new version should do."
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14676 16af8721-9629-0410-8352-f15c8da7e697
$ osgmovie --audio movie.avi.ffmpeg
FFmpegImageStream::open audio failed, audio stream will be disabled: unknown audio format
With the attached FFmpegDecoderAudio.cpp, audio sounds correctly.
I am also attaching a modified version of FindFFmpeg.cmake that allows to set as FFMPEG_DIR the ffmpeg compiled in the source directory structure. It should not break anything as it only adds some additional search paths.
"
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14654 16af8721-9629-0410-8352-f15c8da7e697
"a last submission for the obj plugin
* supports vertex color definition after vertex position by Clément Léger
* supports zbrush vertex color definition (as #MRGB comment) by Aurélien Chatelain
* adds a noReverseFace option to not mess with face definition by Aurélien Chatelain
* makes material parsing case insensitive (by Paul Cheyrou-Lagrèze and me)
* makes the plugin resilient to faulty vertex uv/normal definition (i.e. when a too big index is referenced) by Aurélien hatelain
"
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14641 16af8721-9629-0410-8352-f15c8da7e697
* quad primitives
* face definition with the "vertex_index" label (previously only "vertex_indices" was supported)
* replaces normal computation by the SmoothingVisitor to avoid code duplication
"
Submitted by Marc Helbling.
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14640 16af8721-9629-0410-8352-f15c8da7e697
This submission adds shared array duplication (and moves the SharedArrayOptimizer declaration in MeshOptimizer to make it callable from the SmoothingVisitor)."
Submitted by Marc Helbling.
Edited by Robet Osfield to retain the usual OSG coding style.
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14639 16af8721-9629-0410-8352-f15c8da7e697
* fixes vertex color support
* adds 'magics' color definition
* cleans options to make the plugin more consistent with other plugins
* adds options to not tristrip geometries"
Submitted by Marc Helbling.
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14638 16af8721-9629-0410-8352-f15c8da7e697
cmake vars weren't passed correctly to find_package_handler_args, so
while the find script didn't find a single required GStreamer lib or
include path it still reported GSTREAMER_FOUND=TRUE (and then tried to
compile the new plugin). This fixes it and correctly reports missing
components."
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14611 16af8721-9629-0410-8352-f15c8da7e697
$ osgmovie --audio movie.avi.ffmpeg
FFmpegImageStream::open audio failed, audio stream will be disabled: unknown audio format
With the attached FFmpegDecoderAudio.cpp, audio sounds correctly.
I am also attaching a modified version of FindFFmpeg.cmake that allows to set as FFMPEG_DIR the ffmpeg compiled in the source directory structure. It should not break anything as it only adds some additional search paths.
"
Note from Robert Osfield, I have found in testing that audio quality is not good for planar floating point formats, even with adding support for SDL2 to the osgmovie example. I haven't yet tracked down the cause of these audio problems or a solution.
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14609 16af8721-9629-0410-8352-f15c8da7e697
This was caused be the change in Drawable (now derived from Node) and Geode (now derived from Group).
This fix simply sticks with previous behaviour. Another change could be to adapt WriterNodeVisitor.
"
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14608 16af8721-9629-0410-8352-f15c8da7e697
Added support for ImageStream::LoopigMode variable
Fixed memory leak associtied with restarting videos
Changed Image::setData() to Image::dirty() to avoid resetting data
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14605 16af8721-9629-0410-8352-f15c8da7e697
From Robert Osfield, fixed handled of row widths so that they are padded to a 4 byte boundary as certain row widths were being rendered incorrectly.
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14604 16af8721-9629-0410-8352-f15c8da7e697
* it sorts primitives to keep "more complex" primitives first; maybe you'll prefer to have this as an option (but usually it should make more sense to pre-transform triangles before e.g. lines)
* currently, the visitor rely on TriangleIndexFunctor and does not take care of points and lines (see https://github.com/openscenegraph/osg/blob/master/include/osg/TriangleIndexFunctor#L124-130). This can lead to issues e.g. if you store the wireframe lines along with some triangles: the triangles will be reindexed but not the line. I've therefore added osg/include/TriangleLinePointIndexFunctor to index triangles, lines and points and derived VertexReorder from this class.
* to avoid issues, shared arrays are duplicated. However, in some cases (e.g. an UV channel shared in the geometry only) this is not required. I'm adding a SharedArrayOptimizer to optimize this: it looks for duplicated UVs before the array duplication and deduplicate arrays after.
"
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14603 16af8721-9629-0410-8352-f15c8da7e697
I've removed the references to DrawArrays as we should no longer produce any.
Note that:
* as the name suggest, it only works for triangle strips but could probably be easily extended to quads
* the resulting primitive is not highly optimized; we could probably sort the strips in order to minimize the number of primitive restart
* as we may merge DrawElementsUInt and DrawElementUShort, the code will only generate DrawElementsUInt"
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14602 16af8721-9629-0410-8352-f15c8da7e697
algorithm consisting of two consequent phases :
- first phase is a GLSL shader performing object culling and LOD picking ( a culling shader ).
Every culled object is represented as GL_POINT in the input osg::Geometry.
The output of the culling shader is a set of object LODs that need to be rendered.
The output is stored in texture buffer objects. No pixel is drawn to the screen
because GL_RASTERIZER_DISCARD mode is used.
- second phase draws osg::Geometry containing merged LODs using glDrawArraysIndirect()
function. Information about quantity of instances to render, its positions and other
parameters is sourced from texture buffer objects filled in the first phase.
The example uses various OpenGL 4.2 features such as texture buffer objects,
atomic counters, image units and functions defined in GL_ARB_shader_image_load_store
extension to achieve its goal and thus will not work on graphic cards with older OpenGL
versions.
The example was tested on Linux and Windows with NVidia 570 and 580 cards.
The tests on AMD cards were not conducted ( due to lack of it ).
The tests were performed using OSG revision 14088.
The main advantages of this rendering method :
- instanced rendering capable of drawing thousands of different objects with
almost no CPU intervention ( cull and draw times are close to 0 ms ).
- input objects may be sourced from any OSG graph ( for example - information about
object points may be stored in a PagedLOD graph. This way we may cover the whole
countries with trees, buildings and other objects ).
Furthermore if we create osgDB plugins that generate data on the fly, we may
generate information for every grass blade for that country.
- every object may have its own parameters and thus may be distinct from other objects
of the same type.
- relatively low memory footprint ( single object information is stored in a few
vertex attributes ).
- no GPU->CPU roundtrip typical for such methods ( method uses atomic counters
and glDrawArraysIndirect() function instead of OpenGL queries. This way
information about quantity of rendered objects never goes back to CPU.
The typical GPU->CPU roundtrip cost is about 2 ms ).
- this example also shows how to render dynamic objects ( objects that may change
its position ) with moving parts ( like car wheels or airplane propellers ) .
The obvious extension to that dynamic method would be the animated crowd rendering.
- rendered objects may be easily replaced ( there is no need to process the whole
OSG graphs, because these graphs store only positional information ).
The main disadvantages of a method :
- the maximum quantity of objects to render must be known beforehand
( because texture buffer objects holding data between phases have constant size ).
- OSG statistics are flawed ( they don't know anymore how many objects are drawn ).
- osgUtil::Intersection does not work
Example application may be used to make some performance tests, so below you
will find some extended parameter description :
--skip-dynamic - skip rendering of dynamic objects if you only want to
observe static object statistics
--skip-static - the same for static objects
--dynamic-area-size - size of the area for dynamic rendering. Default = 1000 meters
( square 1000m x 1000m ). Along with density defines
how many dynamic objects is there in the example.
--static-area-size - the same for static objects. Default = 2000 meters
( square 2000m x 2000m ).
Example application defines some parameters (density, LOD ranges, object's triangle count).
You may manipulate its values using below described modifiers:
--density-modifier - density modifier in percent. Default = 100%.
Density ( along with LOD ranges ) defines maximum
quantity of rendered objects. registerType() function
accepts maximum density ( in objects per square kilometer )
as its parameter.
--lod-modifier - defines the LOD ranges. Default = 100%.
--triangle-modifier - defines the number of triangles in finally rendered objects.
Default = 100 %.
--instances-per-cell - for static rendering the application builds OSG graph using
InstanceCell class ( this class is a modified version of Cell class
from osgforest example - it builds simple quadtree from a list
of static instances ). This parameter defines maximum number
of instances in a single osg::Group in quadtree.
If, for example, you modify it to value=100, you will see
really big cull time in OSG statistics ( because resulting
tree generated by InstanceCell will be very deep ).
Default value = 4096 .
--export-objects - write object geometries and quadtree of instances to osgt files
for later analysis.
--use-multi-draw - use glMultiDrawArraysIndirect() instead of glDrawArraysIndirect() in a
draw shader. Thanks to this we may render all ( different ) objects
using only one draw call. Requires OpenGL version 4.3 and some more
work from me, because now it does not work ( probably I implemented
it wrong, or Windows NVidia driver has errors, because it hangs
the apllication at the moment ).
This application is inspired by Daniel Rákos work : "GPU based dynamic geometry LOD" that
may be found under this address : http://rastergrid.com/blog/2010/10/gpu-based-dynamic-geometry-lod/
There are however some differences :
- Daniel Rákos uses GL queries to count objects to render, while this example
uses atomic counters ( no GPU->CPU roundtrip )
- this example does not use transform feedback buffers to store intermediate data
( it uses texture buffer objects instead ).
- I use only the vertex shader to cull objects, whereas Daniel Rákos uses vertex shader
and geometry shader ( because only geometry shader can send more than one primitive
to transform feedback buffers ).
- objects in the example are drawn using glDrawArraysIndirect() function,
instead of glDrawElementsInstanced().
Finally there are some things to consider/discuss :
- the whole algorithm exploits nice OpenGL feature that any GL buffer
may be bound as any type of buffer ( in our example a buffer is once bound
as a texture buffer object, and later is bound as GL_DRAW_INDIRECT_BUFFER ).
osg::TextureBuffer class has one handy method to do that trick ( bindBufferAs() ),
and new primitive sets use osg::TextureBuffer as input.
For now I added new primitive sets to example ( DrawArraysIndirect and
MultiDrawArraysIndirect defined in examples/osggpucull/DrawIndirectPrimitiveSet.h ),
but if Robert will accept its current implementations ( I mean - primitive
sets that have osg::TextureBuffer in constructor ), I may add it to
osg/include/PrimitiveSet header.
- I used BufferTemplate class writen and published by Aurelien in submission forum
some time ago. For some reason this class never got into osg/include, but is
really needed during creation of UBOs, TBOs, and possibly SSBOs in the future.
I added std::vector specialization to that template class.
- I needed to create similar osg::Geometries with variable number of vertices
( to create different LODs in my example ). For this reason I've written
some code allowing me to create osg::Geometries from osg::Shape descendants.
This code may be found in ShapeToGeometry.* files. Examples of use are in
osggpucull.cpp . The question is : should this code stay in example, or should
it be moved to osgUtil ?
- this remark is important for NVidia cards on Linux and Windows : if
you have "Sync to VBlank" turned ON in nvidia-settings and you want to see
real GPU times in OSG statistics window, you must set the power management
settings to "Prefer maximum performance", because when "Adaptive mode" is used,
the graphic card's clock may be slowed down by the driver during program execution
( On Linux when OpenGL application starts in adaptive mode, clock should work
as fast as possible, but after one minute of program execution, the clock slows down ).
This happens when GPU time in OSG statistics window is shorter than 3 ms.
"
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14531 16af8721-9629-0410-8352-f15c8da7e697
The mac os sdk version is recognized by the current CMAKE script as 10.1 instead of 10.10 since it cuts the version string from the 4th place. I introduced a more reliable version checking based on splitting the returned version code into MAJOR MINOR and PATCH parts and reassemble the OSG sdk version afterwards.
I replaced the existing CMake code against the following (returning now version 10.10 as expected):
# Determine the canonical name of the selected Platform SDK
EXECUTE_PROCESS(COMMAND "/usr/bin/sw_vers" "-productVersion"
OUTPUT_VARIABLE OSG_OSX_SDK_NAME
OUTPUT_STRIP_TRAILING_WHITESPACE)
STRING(REPLACE "." ";" MACOS_VERSION_LIST ${OSG_OSX_SDK_NAME})
LIST(GET MACOS_VERSION_LIST 0 MACOS_VERSION_MAJOR)
LIST(GET MACOS_VERSION_LIST 1 MACOS_VERSION_MINOR)
LIST(GET MACOS_VERSION_LIST 2 MACOS_VERSION_PATCH)
SET(OSG_OSX_SDK_NAME "macosx${MACOS_VERSION_MAJOR}.${MACOS_VERSION_MINOR}")
Also i added the check for the new Version to some more find scripts.
Additionally the nil object in Objective C now seems to be equivalent with a null_ptr that cannot be passed as GLInt anymore. So i switched this in the PixelBufferCocoa.mm to pass a zero instead of nil.
"
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14527 16af8721-9629-0410-8352-f15c8da7e697
a way that when CMAKE_INSTALL_PREFIX contains something along the lines
of
/usr/x86_64-linux-gnu/
it gets substituted as
/usr/x86_64-1-gnu/
that is, the string is preprocessed again, thereby making changes to
anything that matches any defined symbol, as "linux" in this example
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763816).
Quoting that path directly in CMake scripts solves that problem.
"
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14522 16af8721-9629-0410-8352-f15c8da7e697
My changes:
-------------------
- I changed the cmake files and added a toolchain for building OSG in Android. The toolchain is based on the one used at OpenCV. For building OSG for android you just need to do:
mkdir build_android_static_gles2 && cd build_android_static_gles2
cmake .. -DANDROID_NDK=<path-to-the-android-ndk>
-DCMAKE_TOOLCHAIN_FILE=../PlatformSpecifics/Android/android.toolchain.cmake
-DOPENGL_PROFILE="GLES2"
-DDYNAMIC_OPENTHREADS=OFF
-DDYNAMIC_OPENSCENEGRAPH=OFF
-DANDROID_NATIVE_API_LEVEL=15 # optional
-DANDROID_ABI=armeabim #optional
-DCMAKE_INSTALL_PREFIX=<path-to-the-install-path> #optional
make -j 8
make install
The OPENGL_PROFILE works as expected, changing it to "GLES1" it builds and links OSG using GLES1.
The DYNAMIC_OPENTHREADS/DYNAMIC_OPENSCENEGRAPH parameters also allows to build the dynamic libraries
- I also added some build fixes for android related to the texture formats and added some missing USE_OSG_SERIALIZER_WRAPPER in the osg serializer library to support loading osgb files in static."
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14514 16af8721-9629-0410-8352-f15c8da7e697
lists when drawing lots of batches and noticed that my program
generated a lot of unneeded glClientActiveTexture calls. Digging
deeper I found out it came from State::disableTexCoordPointer where
the function would call glClientActiveTexture but not
glDisableClientState because the geometry didn't have texture
coordinates for that channel. This is because in our scene there are
some geometries that have move than one uv channels making
State::_texCoordArrayList grow. Then the method
State::applyDisablingOfVertexAttributes() will call
disableTexCoordPointer multiple times.
I rearrange the method a little to combat this. Now the logic has the
same ordering as disableTexCoordPointersAboveAndIncluding which
already combats this."
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14508 16af8721-9629-0410-8352-f15c8da7e697
The submission therefore only contains a test on the size of the vertex array for the VertexCacheMissVisitor and the VertexAccessOrderVisitor visitors."
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14503 16af8721-9629-0410-8352-f15c8da7e697
osgviewer "ProxyNode { FileNameList { cow.osgt } num_children 1 }".osgs
The proxy node reader wrongly assumes options to be non NULL.
fixed in attached zip:
src\osgWrappers\deprecated-dotosg\osg\ProxyNode.cpp
applies to both the 3.2 branch and svn trunk"
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14484 16af8721-9629-0410-8352-f15c8da7e697
The problem is that the readObjectFields method will add the object to the _identifierMap. So all the other instances of that image in the same file will be replaced by the created dummy object. In my fix this was an dummy image and I didn't notice it in our scene's, probably because it covered a small part of an object. In your fix the dummy object was not an image and that leads to a crash when something tries to use it as an image. I have attached a small fix for this bug.
"
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14471 16af8721-9629-0410-8352-f15c8da7e697
Requires shader files place in OpenSceneGraph-Data/shaders from OpenSceneGraph-Data's svn/trunk to function.
Run osgterrain example with --shader command line option to select displacement mapping shader approach.
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14458 16af8721-9629-0410-8352-f15c8da7e697
To enable the sync of swap buffers set the env var OSG_SYNC_SWAP_BUFFERS to ON or 1, to switch off set to OFF or 0.
One can also use the --sync command line option for application that pass on command line options to the osg::DisplaySettings::instance().
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14456 16af8721-9629-0410-8352-f15c8da7e697
Introduced a new Widget::computeExtentsPositionInLocalCoordinates() method that intersects with a ray through mouse pointer and the extents of the widget.
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14429 16af8721-9629-0410-8352-f15c8da7e697
- the issue here is that the plugin is removing group nodes if
that group node only has one child. becuase transforms are also
group nodes, there were cases when the transform would have only
one child under it and would cause it to remove the translation
portion. this would cause all the vertex data to be loaded around
the last matrix operation, which in our case was the origin (0,0,0).
We work off of OSG 2.8.1 but see that this has not been addressed on latest yet. I’ve tested this against 2.8.1 and have cleanly applied it to my local repository off of latest."
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14407 16af8721-9629-0410-8352-f15c8da7e697
It is caused by line 991 in RenderStage.cpp:
Code:
fbo_ext->glBlitFramebuffer(
0, 0, static_cast<GLint>(_viewport->width()), static_cast<GLint>(_viewport->height()),
0, 0, static_cast<GLint>(_viewport->width()), static_cast<GLint>(_viewport->height()),
blitMask, GL_NEAREST);
which is not taking into account the viewport x and y when performing the blit. It probably should be:
Code:
fbo_ext->glBlitFramebuffer(
static_cast<GLint>(_viewport->x()), static_cast<GLint>(_viewport->y()),
static_cast<GLint>(_viewport->width()) + static_cast<GLint>(_viewport->x()), static_cast<GLint>(_viewport->height()) + static_cast<GLint>(_viewport->y()),
static_cast<GLint>(_viewport->x()), static_cast<GLint>(_viewport->y()),
static_cast<GLint>(_viewport->width()) + static_cast<GLint>(_viewport->x()), static_cast<GLint>(_viewport->height()) + static_cast<GLint>(_viewport->y()),
blitMask, GL_NEAREST);
"
Note from Robert Osfield, made small tweak to above on merge, changing the width+x to x+width to make it read more naturally.
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14405 16af8721-9629-0410-8352-f15c8da7e697
The issue with current code is that arrays are collected *before* duplicating shared arrays which leads to arrays that are correctly duplicated but that are not reordered.
Also the submitted patch contains a small cleaning in GeometryArrayGathrer as the _useDrawElements variable is not used; it is only set in the GeometryArrayGathrer constructor and VertexAccessOrderVisitor already checks that primitives have indexed type."
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14403 16af8721-9629-0410-8352-f15c8da7e697
The State::AppliedProgramObjectSet wasn't ever being used actively in the current rev of the OSG so populating and clearing was no longer neccessary, allowing the code to be removed completely.
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14377 16af8721-9629-0410-8352-f15c8da7e697
pushModelViewMatrix or pushProjectionMatrix will already keep the
reference when adding it to the MatrixStack. In CullVisitor::apply
methods for the billboard and the camera you already take a pointer
instead of a ref_ptr."
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14375 16af8721-9629-0410-8352-f15c8da7e697
the scene tree contains (large) 2D textures from images with STRIDE.
============================================================================
#0 0x00007fffe8ea4350 in __memmove_ssse3 () from /lib64/libc.so.6
#1 0x00007fffe52ced76 in ?? () from /usr/lib64/libnvidia-glcore.so.310.44
#2 0x00007fffe52d8e86 in ?? () from /usr/lib64/libnvidia-glcore.so.310.44
#3 0x00007fffe53dd8be in ?? () from /usr/lib64/libnvidia-glcore.so.310.44
#4 0x00007fffe53c2643 in ?? () from /usr/lib64/libnvidia-glcore.so.310.44
#5 0x00007fffe53c7fdd in ?? () from /usr/lib64/libnvidia-glcore.so.310.44
#6 0x00007fffe53cbabf in ?? () from /usr/lib64/libnvidia-glcore.so.310.44
#7 0x00007fffe53cc1fa in ?? () from /usr/lib64/libnvidia-glcore.so.310.44
#8 0x00007ffff30092fd in osgText::GlyphTexture::apply (this=0x1bb8cf0, state=
...)
at /d43/jaap/dev/jaapOSG/build/OpenSceneGraph3.3.1/src/osgText/Glyph.cpp:234
#9 0x00007ffff56c30b6 in osg::State::applyAttributeOnTexUnit (this=0x125f180,
unit=0, attribute=0x1bb8cf0, as=...)
at /d43/jaap/dev/jaapOSG/build/OpenSceneGraph3.3.1/include/osg/State:1713
#10 0x00007ffff56c2f3f in osg::State::applyTextureAttribute (this=0x125f180,
unit=0, attribute=0x1bb8cf0)
at /d43/jaap/dev/jaapOSG/build/OpenSceneGraph3.3.1/include/osg/State:411
#11 0x00007ffff30204da in osgText::Text::drawTextWithBackdrop (this=0x1baed70,
state=..., colorMultiplier=...)
==============================================================================
The crash disappears if I either (1) disable the use of images with stride
in the (public) osgGeo-library, or (2) add the following bugfix to Glyph.cpp.
This combination gives me the confidence that I understand where this problem
originates from, without trying to understand the full OpenGL details.
===============================================================================
@@ -221,7 +223,12 @@
imageData[i] = 0;
}
+ glPixelStorei(GL_UNPACK_ALIGNMENT,1);
+ #if !defined(OSG_GLES1_AVAILABLE) && !defined(OSG_GLES2_AVAILABLE)
+ glPixelStorei(GL_UNPACK_ROW_LENGTH,getTextureWidth());
+ #endif
+
// allocate the texture memory.
glTexImage2D( GL_TEXTURE_2D, 0, GL_ALPHA,
getTextureWidth(), getTextureHeight(), 0,
================================================================================
I have copied (and adapted) the added lines above from the same source file,
where they were used in front of a similar call to glTexSubImage2D(.) around
line 515.
"
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14372 16af8721-9629-0410-8352-f15c8da7e697
The warning is (14 times):
include\osgViewer/ViewerEventHandlers(542): warning C4250: 'osgViewer::InteractiveImageHandler' : inherits 'osgGA::EventHandler::osgGA::EventHandler::run' via dominance (src\osgViewer\StatsHandler.cpp)
include\osgGA/EventHandler(45) : see declaration of 'osgGA::EventHandler::run'
attached a zipped version of include\osgViewer\ViewerEventHandlers"
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14343 16af8721-9629-0410-8352-f15c8da7e697
databasePager->setUpThreads(16, 1);
We experienced problems with multiple databasepagers loading files in parallel, when two threads start to load the same file (usually a texture referenced by multiple models). The second thread to add the file to the cache (sometimes) manages to do so while the refcount from the cached object still is zero, causing the object loaded to be destroyed.
Sometimes the second thread manages to ref() the object before Referenced::signalObserversAndDelete does the final recount check, causing a warning:
"Warning Referenced::signalObserversAndDelete(,,) doing delete with _refCount=1"
With a deleted object added to the scenegraph we get some undesired results, I think the program only crashes if the object was a Node, and just has some untextured surfaces if it was a texture, but I'm not completely sure.
Attached is a modified version of the Registry.cpp, returning the object in cache and let the duplicate loaded object to be destroyed.
A more efficient option would be to add some sort of blocking entry to the objectcache to stop the second thread from reading the file, and just wait until the first thread added it to the cache. If you think that's worthwile we would be happy to implement that version. A bit tricky to implement and test, that's why I submit a simple version that stops my program from crashing."
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14300 16af8721-9629-0410-8352-f15c8da7e697
"I noticed that Text3D objects would change there z alignment depending on the alignment mode. I'm not sure if this was intentional or just a simple mistake. My expectation was that the front of the object would always stay aligned to the 0 z-plane, regardless of the alignment mode. I've attached an updated version that retains a consistent z-alignment."
"I just now noticed another issue with Text3D objects. It was not properly computing the bounding box when non-axis aligned rotations were being applied. In this case all corners of the bounding box need to be transformed in order to get the correct containing box. I've attached the updated file."
"The incorrect bounding box problem also applies to regular Text objects. I've attached the fix for that as well as the original Text3D fix."
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14296 16af8721-9629-0410-8352-f15c8da7e697
optimizations to reduce cpu overhead:
1) Avoid a load-hit-store in UpdateBone. b->getMatrixInBoneSpace()
returns the same matrix that was just stored with b->setMatrix()
2) Avoid calling element->isIdentity() for the whole transform stack
(can be expensive is element is a matrix)
3) Make the key frame interpolator use binary search instead of a
linear one. This is very noticeable in scenes where some geometry has
long repeating animations that start at the same time, you will see
the update time grow then reset and grow again."
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14294 16af8721-9629-0410-8352-f15c8da7e697
debug message it prints out on the console.
Around line 1040 of Registry.cpp (see code below) the method returns
"simpleFileName" but prints about returning "filename".
In attachment the modified file, based on osg 3.2.0
ricky
<code>
if(fileExists(simpleFileName))
{
OSG_DEBUG << "FindFileInPath(" << filename << "): returning " <<
filename << std::endl;
return simpleFileName;
}
</code>
"
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14285 16af8721-9629-0410-8352-f15c8da7e697
The osg 3ds plugin modify the exported materials name in the same way it modifies the node names.
I've added an option to preserve originals materials names, with the assurance of unique material names are preserved."
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14283 16af8721-9629-0410-8352-f15c8da7e697
Initially I described issue in message:
http://forum.openscenegraph.org/viewtopic.php?t=13820
It solves issue with compiling texture using ico from image with mipmaps
I added enviroment variable OSG_GL_TEXTURE_STORAGE_ENABLE to control usage of glTexStorage2d. Initially it is disabled.
It used only if image have mipmaps.
Another issue is converting from internalFormat + type to sized internal format. I created sizedInternalFormats[] struct where sized internal formats are ordered from worse->best.
also this struct have commented lines. Commented formats are listed in
http://www.opengl.org/wiki/GLAPI/glTexStorage2D
but looks like not using in osg."
Note from Robert Osfield. Changed the env var control to OSG_GL_TEXTURE_STORAGE and made it's value true by default when the feature is supported by the OpenGL driver. To disable to
use of glTexStorage2D use OSG_GL_TEXTURE_STORAGE="OFF" or "DISABLE"
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14275 16af8721-9629-0410-8352-f15c8da7e697
If Drawable::getBoundingBox would compute an invalid bounding box (if it was for example empty) it would make a bounding sphere with a infinite radius which counts as a valid sphere in osg.
Attached is a small fix."
- Added apply(Drawable) and apply(Geometry) to NodeVisitor
- Added accept(NodeVisitor) method to Drawable/Geometry
- Added traverse(NodeVisitor) to Geode which calls accept(NodeVisitor) on all Drawables
- Updated CullVisitor to use new apply(Drawable) to handle drawables. The apply(Billboard) method still manually handles the drawables since it is depends on the billboard settings. I needed to disable the traverse within billboard to prevent duplicate traversal of drawables.
- Update other osgUtil node visitors (GLObjectsVisitor, IncrementalCompileOperation, ..) to use new apply(Drawable) method.
"
pd->tid.set( (void*)_beginthreadex(NULL,static_cast<unsigned>(pd->stackSize),ThreadPrivateActions::StartThread,static_cast<void *>(this),0,&ID));
the method "pd->tid.set" sets the thread id, however via the startup function "ThreadPrivateActions::StartThread" that thread id is used (see further down the call hierarchy the line "int status = SetThreadPriority( pd->tid.get(), prio);".
Until now I never ran into any problem in debug or release builds, though. It seems that furtunately the tid.set method was executed always before the tid.get method in the startup code. However, this may make trouble in the furture. A simple solution is the following: just replace the line above with following two lines:
pd->tid.set( (void*)_beginthreadex(NULL,static_cast<unsigned>(pd->stackSize),ThreadPrivateActions::StartThread,static_cast<void *>(this),CREATE_SUSPENDED,&ID));
ResumeThread(pd->tid.get());
The trick is just starting the thread in suspended mode so the StartThread function does not get executed and we can safely store the tid by pd->tid.set. Then start the Thread by calling ResumeThread."
ran into two issues.
At first you get a bunch of warnings that osg::ComputeBoundCallback
and osg::UpdateCallback were unsupported wrapper classes when
converting fbx models with skeletal animation to osg(t/b).
The second issue was that when reading, the readers fail to read the
ComputeBoundCallback and UpdateCallback and set them to NULL which
messes up the RigGeometry.
Because a RigGeometry makes his own classes in the constructor it
might be preferable to not write them at all, because now those
classes are being made two times when reading a RigGeometry. But after
thinking about this that would place too much limits on them (you
won't be able to share or name them and save that information or make
a new inherited class from them and write that one) So I ended up
thinking the best way was to just write the files.
"
attributes in vec3b format. It looks like my compiler takes the wrong
overload and outputs integers instead of characters. The problem is
that vec3b is of type signed char and that is not the same as char (
see http://stackoverflow.com/questions/436513/char-signed-char-char-unsigned-char
) and visual studio 2013 will promote it to integer when choosing an
overload.
It looks like that the InputStream class already takes care of this
issue (if it didn't it would have read everything ok and I would have
not even stumbled upon this bug. :) )"
Currently this submission is Windows-only. I don't think OSX or Linux require any help in locating gl/glcorearb.h. But if they do, this submission can be easily modified.
Files:
- "CMakeLists.txt" is the top-level file.
- FindGLCORE.cmake" and "OsgMacroUtils.cmake" go in CMakeModules.
"
We were running into issues occasionally in osgEarth where multiple threads were writing out files like /1/2/3.jpg and /1/3/4.jpg. Both threads would try to create the /1 directory and only one of them would succeed. So the first thread would write out the full /1/2/3.jpg while the second thread wouldn't create the /1/3 directory b/c /1 was already created and the writing of /1/3/4.jpg would fail.
"
There was code in the osgViewer/Viewer.cpp and osgViewer/CompositeViewer.cpp that transformed the Y-coordinates of an event. The code in the composite viewer did however miss the touch-data of the event. I thought that it should really be the GUIEventAdapter that should know about this, and hence I added the
GUIEventAdapter::setMouseYOrientationAndUpdateCoords which is re-computing the coordinates. First I simply added a boolean to the setMouseYOrientation function:
setMouseYOrientation( MouseYOrientation, bool updatecooreds=false );
but then the serializer complained.
This function is called from both the Viewer and the CompositeViewer. We have not tested from the viewer, but I cannot see it would not work from visual inspection.
The other change is in MultiTouchTrackballManipulator::handleMultiTouchDrag. I have removed the normalisation. The reason for that is that it normalised into screen coordinates from 0,0 to 1,1. The problem with that is that if you have a pinch event and you keep the distance say 300 pixels between your fingers, these 300 pixels represent 0.20 of the screen in the horizontal domain, but 0.3 of the screen in the vertical domain. A rotation of the pinch-fingers will hence result in a zoom in, as the normalised distance is changing between them.
A consequence of this is that I have changed the pan-code to use the same algorithm as the middle-mouse-pan.
The rest of it is very similar from previous revision, and there has been some fine-tuning here and there.
"
says that modules that are found and ran from cmake modules dir should
prefer cmake-provided modules. find_package() and include() still look
in CMAKE_MODULE_PATH first.
After some investigating I've come up with a proposal examplified in
the attached FindGDAL.cmake script. It simply calls the cmake provided
FindGDAL.cmake if it exists and returns if it succeeds in finding GDAL
using that, otherwise continue with our local cmake code.
Pro: Wont clutter our root CMakeLists.txt
Con: If we begin to write more advanced Findxxx modules (using
COMPONENTS, REQUIRED etc.) we may have to revise this scheme.
"
To select standard OpenGL 1/2 build with full backwards and forwards comtability use:
./configure
make
OR
./configure -DOPENGL_PROFILE=GL2
To select OpenGL 3 core profile build using GL3/gl3.h header:
./configure -DOPENGL_PROFILE=GL3
To select OpenGL Arb core profile build using GL/glcorearb.h header:
./configure -DOPENGL_PROFILE=GLCORE
To select OpenGL ES 1.1 profile use:
./configure -DOPENGL_PROFILE=GLES1
To select OpenGL ES 2 profile use:
./configure -DOPENGL_PROFILE=GLES2
Using OPENGL_PROFILE will select all the appropriate features required so no other settings in cmake will need to be adjusted.
The new configuration options are stored in the include/osg/OpenGL header that deprecates the old include/osg/GL header.
- ReaderWriterFBX.cpp: add "z up scene axis" support: FBX provides facility to convert model scene axis during conversion. Currently fbx plugin convert axis to fbx:opengl axis system (which is arbitrarily at Y up, as opengl is in reality axis agnostic) and sometimes what is needed is Z up so added an option for Z up conversion
- FindFBX.cmake: add support for latest fbx sdk ( 2014.2 )"
Using the trunk together with osgEarth 2.5 will fail to build, due to the missing type.
Attached is the file forward declaring osgGA::GUIEventAdapter."
format. Turned out that the serializer didn't handle bone names with
spaces very well (the 3ds studio max biped for instance has spaces by
default). Here is a small fix for the problem."
- materialName used to be not stripped of whitespace, making number of models
fail to load materials; now fixed
- stripping was considering spaces only, thus models using tabs had problems
to load correctly; fixed
- fixed references to textures; they did not performed conversion to native
directory separators
- make d (dissolve) takes precedence over Tr (transparency); there seems to be
a confusion about the Tr item - some claiming 1 to be opaque and 0
transparent, while number of models uses exactly the opposite. d (dissolve),
if present in the model, does not suffer from this confusion, thus using it
instead fixes the problem for many many models.
I put many comments to the file concerning d and Tr item as others may further
investigate. Let me know in the case of any problems."
This behavior is also described in the pthreads man page (http://man7.org/linux/man-pages/man3/pthread_create.3.html):
>
> Linux-specific details
> The new thread inherits copies of the calling thread's capability
> sets (see capabilities(7)) and CPU affinity mask (see
> sched_setaffinity(2)).
>
To prevent this behaviour I wrote a patch that explicitly sets the affinity mask to all cores of the system, if no specific affinity was defined with PThread::setProcessorAffinity(unsigned int) .
Thank you!
"
* Changes are made against trunk
* Reason: crashes when using specific constructor from RayIntersector
* Info: Line 42: added in constructor
RayIntersector::RayIntersector(const Vec3d& start, const Vec3d&
direction) missing initialisation of _parent
"
osg/GL2Extensions was incorrectly defining GL_RED_SNORM and GL_RG_SNORM as part of the definitions for OpenGL v3.1. However, a quick review of the 3.1 spec indicates that these are not part of the 3.1 standard.
My attached change moves these definitions out of the #ifndef GL_VERSION_3_1 conditional block, and defines them conditionally if not already defined. This allows the DDS plugin to build for GL3.
"
My fix was to rename the standard request handler to a specialized user-event-handler which handles only requests for "/user-event“
So fonts should work on iOS when loaded remotely, even when a local file is available and with the resthttp-plugin serving the presentation.
"
Added the Cmake option OSG_USE_LOCAL_LUA_SOURCE to control whether to build and use the Lua source code in the lua plugin, or look for lua as an external dependency.
To the Lua plugin added support for assigned lua functions to C++ osg::Objects via the new osg::CallbackObject mechanism. To invoke the scripts function from C++ one must get the CallbackObject and call run on it.
Renamed ScriptCallback to ScriptNodeCallback to avoid possibly confusion between osg::CallbackObject and the ScriptNodeCallback.
From Robert Osfield, changed the example so that the vertical and horizon scalar bars are rotated to the XZ plane so you can see them with the default viewer's camera orientation.
Tweaked the positioning of title text of vertic scalar bar to avoid overlap of text.
There are two problems:
1> for DrawElementsUShortPrimitiveType (and UInt) the source_pindex still equals -1 and causes a crash
in DrawElementsUBytePrimitiveType source_pindex is incremented, and in DrawElementsU(Short/Int)PrimitiveType primitiveNum is incremented, but never used
2> The drawelements need to be rewritten as the vertices are reordered.
created a patch for osg stable branch(r14038): attached as Geometry-osg-3.2.zip
and for svn brach(r14044): attached as Geometry_osg_svn.zip"
This can lead to inconsistency if you bind a framebuffer with multiple attachments in DRAW mode and then a framebuffer with different attachment count in READ mode (for example to manually "blit" from a FBo to another).
On some ATI cards (at least RADEON HD) this also leads to an "incomplete " FBO status
I've added a test to enable drawbuffers only if target is "DRAW" or "READ_DRAW", this solves my problems on ATI cards."
* forwarded touch-events do have a correct input-range from 0 .. 1
* I refactored sending touch-events per osc so the receiver can detect a TOUCH_ENDED better"
One solution is naturally to create a new class that would inherit the osg::ComputeBoundVisitor, and use that. I don't like that idea as the ComputeBoundVisitor does actually have what I need - it is only hidden in a protected function.
I am therefor suggesting a slight generalization of the ComputeBoundVisitor with the attached patch, which is tested.
The patch has two parts:
we add applyBBox() so that one can use that in a customized traverse-function and add a bbox to the visitor. I considered calling this function expandByBBox(), but I though applyBBox was better.
The MatrixStack is made available to the outside world. That enables a traverse-function to do whatever it wishes.
I do actually only need one of the two, as I can implement what I wish either way, but adding getMatrixStack() will make more generic expansions possible.
"
From Robert Osfield, changed the name of the new applyBBox(..) method to applyBoundingBox(..) to keep it's naming more consistent with the rest of the OSG.
I added a new tag to p3d called forward_touch_event_to_device and renamed the existing forward_event_to_device to forward_mouse_event_to_device. This new tag will transmit touches to the virtual trackpad as touch events. I added the MultitouchTrackball to the p3d-app so zooming and moving a model remotely should now work, if you use forward_touch_event_to_device. I kept (and fixed) forward_mouse_event_to_device for background compatibility, so old presentations works as in previous versions, without the ability to zoom + scale. of course.
forward_touch_event_to_device needs some more testing, (e.g. with image-streams and keystone, afaik there’s no support for touch-events...) but for a first version it works nice.
"
Examples of supported matches are:
<Slide> and <slide> will be treated the same
<bgcolor>WHITE</bgcolor> and <bgcolor>White</bgcolor> will be treated the same
<text alignment="TOP_LEFT"</text> and <text alignment="top left"</text>, <text alignment="TopLeft"</text> will all be treated the same
with the --write-to-source-file-directory added to allow one to have the original behaviour
of writing to the same directory as the original source file.
From Robert Osfield, changed Roni's code to use a #define GETDEVICEPIXELRATIO to access the versioned Qt devicePixelRatio() method to avoid duplication of the Qt version checking.
I have tested this on:
mac/qt5.2
linux/qt5.2
windows/qt5.2, and
mac/qt5.1
All platforms perform as expected.
The previous fix removed the -f flag to the moc-pre-processor, but on windows, it turned out that -f "osgQt/QGraphicsViewer" was needed.
This becomes an include-statement in the file generated by moc which is needed for compiling it. I ask you consider this patch for the trunk and the 3.2 branch.
Secondly, I wonder if it would be possible to apply my patch for FindRSVG.cmake from 22nd November in the 3.2 branch.
In short, the version of librsvg must be equal or higher to 2.35:
PKG_CHECK_MODULES(RSVG librsvg-2.0>=2.35)
"
....
GUIEventHandler: In copy constructor 'osgGA::GUIEventHandler::GUIEventHandler(const osgGA::GUIEventHandler&, const osg::CopyOp&)':
/include/osgGA/GUIEventHandler:56:9: error: base class 'class osg::Object' should be explicitly initialized in the copy constructor [-Werror=extra]
It seems the diamond problem:
A = osg::Object
/ \
/ \--> Virtual inheritance
B C
\ /
\ /
D = EventHandler
|
|
E = GUIEventHandler
The most derived class(E) handles the instantiation of A (osg::Object), but all have to be responsible in case they are the ones instantiated.
In case A is not initialized in the copy constructor of derived classes the default constructor will be called, which seems a bug.
I've added osg::Object to the initalization list of EventHandler and GUIEventHandler copy constructors, because both classes are instantiables.
"
Updated lua plugin to use new osgDB::PropertyInterface to run methods.
Added addChild/removeChild() etc to Group.cpp, and addDrawable/removeDrawable() etc. to Geode.cpp serializers.
Hence, moc will complain when osg throws in a -f without anything after it. Hence I propose removing the -f on Qt5 builds. I have tested building without -f on both qt520 and qt511, and that works well.
The attached src/osgQt/CMakeLists.txt that can be patched into 3.2 safely. For the trunk, I would consider dropping the check on the version, and simply remove the option on qt5. I have tested that on qt5.1.1, and that worked fine. Question is however if it works on qt5.0. Probably it does, so the question is simplicity of CMakeList.txt vs safety."
Undefined symbols for architecture x86_64:
"lua::LuaScriptEngine::pushValue(osg::Quat const&) const", referenced from:
PushStackValueVisitor::apply(osg::Quat const&) in LuaScriptEngine.o
"lua::LuaScriptEngine::pushValue(osg::Plane const&) const", referenced from:
PushStackValueVisitor::apply(osg::Plane const&) in LuaScriptEngine.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Looks like LuaScriptEngine was missing implementation of those 2 member functions. Fixed src/osgPlugins/lua/LuaScriptEngine.cpp file in attachment.
"
* a new command-line-option to present3d and a new option to the p3d-plugin to suppress any found <env> tags
* a new command-line-option to present3d to forward mouse-events via osgGA::Device (defaults to off) so we can test the interface-files with present3d better
* I added a new attribute forward_to_devices for click_to_event to forward the event to all attached devices instead of handling the event locally. This will fix the annoyance with the new interface-files when toggling polygon-mode or switching light on/off.
Here’s an example:
<click_to_event forward_to_devices="true">0x72</click_to_event>
"
* osgDB::FileUtils uses now the Cocoa-API to determine the paths of the application-support-folder
* DarwinUtils uses now modern functions of the quartz-api to get and set screen-resolutions. Removed some of the osg-deprecated stuff.
"
I'm not sure if the IVE was simply generated incorrectly, or if the Image::getTotalSizeInBytesIncludingMipmaps() was modified since the file was generated. Either way, I added a simple check in the IVE loader so that it clears the mipmap offsets if the actual data size does not match the computed data size. This seems like a safe fallback since the mipmap data can be automatically generated, and it fixes the problem in my case.
Also, while looking into this issue, I noticed that the osgDB::InputStream class applies the serialized image allocation mode. However, since the serializer is allocating the image data itself, it seems like it should force the allocation mode to USE_NEW_DELETE.
"
I'm not sure if the IVE was simply generated incorrectly, or if the Image::getTotalSizeInBytesIncludingMipmaps() was modified since the file was generated. Either way, I added a simple check in the IVE loader so that it clears the mipmap offsets if the actual data size does not match the computed data size. This seems like a safe fallback since the mipmap data can be automatically generated, and it fixes the problem in my case.
Also, while looking into this issue, I noticed that the osgDB::InputStream class applies the serialized image allocation mode. However, since the serializer is allocating the image data itself, it seems like it should force the allocation mode to USE_NEW_DELETE.
"
* force _OPENTHREADS_ATOMIC_USE_BSD_ATOMIC for IOS device + simulator as the test does not pick the right implementation
* fixed a small compile-bug for iphone-example
* added a check to prevent multiple realization of a GraphicsWindowIOS-object
"
* MultiTouchTrackball: some code cleanup and support for normalized touch-points
* oscdevice: receiving and sending multi-touch-events via the Cursor2D-profile from TUIO
* added some documentation
Added new WindowSystemInterface::setDisplaySettings() method to provide a mechanism for passing settings onto the WindowSystemInterface so it can then set up the system appropriately.
Added assignment of the DisplaySettings to the WindowSystemInterface in Viewer/ComppsiteViewer::realize().
set to "SCENE" in the file header. But if the file is stored and
then extracted again from an osga archive this header info is lost,
and the resulting file is just an "OBJECT". Possibly other plugin
operations would have the same effect. The osgt/osgb plugin won't
then return the scenegraph contents.
I have updated the osgt/osgb plugin to return a node from an "OBJECT"
file."
But the nested stream implementation for osga archive files doesn't
support seeking. So osgb files can't currently be used in an osga
archive e.g. if osgdem is used to output a osgb format database it
can't be packaged in an archive file, in the same manner that ive
files could.
I've added seek support to the osga nested stream implementation."
include(${CMAKE_MODULE_PATH}/FindPackageHandleStandardArgs.cmake)
in CMakeModules/FindLua52.cmake
changing to a more common
include(FindPackageHandleStandardArgs)
solves my problem."
* fixed a bug with multi-touch and touch-id-generation on iOS and OS X. (will fix a bug reported by Colin Cochran, without ditching the existing logic)
* removed unnecessary warning-flagss when generating xcode-projects via cmake, will enable the usage of OSG_AGGRESSIVE_WARNING_FLAGS
* added support for 10.9 (OS X)
* new cmake-variable: IPHONE_VERSION_MIN, this will set the deployment-target (previously hard-coded) If you set the IPHONE_VERSION_MIN to something like 7.0 osg gets compiled also for 64bit (amd64)
* cmake defaults now to the clang compiler if IPHONE_VERSION_MIN > 4.2
* cmake now sets some xcode-settings so the compiler uses the c++98-standard (clang defaults to c++11, w/o this I got a lot of linking errors)
* removed include-dir for avfoundation-plugin as not needed on OSX/IOS.
* enhanced the ios-example, will now show multitouch-information on a hud (similar to the osgmultitouch-example), and more importantly, will compile + link out of the box
* small enhancements for the osc-device-plugin (send only one msg for MOVE/DRAG, even if multiple msgs/event is enabled)
* better memory-handling for the zeroconf-plugin
* fixed a possible bug in the rest-http-plugin when receiving mouse-events.
* incorporated a fix from Colin Cochran "forwarded touch events are not transformed into the GL UIView“
"
the wrappers it contains. The registration creates a prototype
object for all of the wrapped classes. For some of the higher-level
classes this can be a bit heavy.
I noticed a problem with a model which required a single class from
osgSim. When osgdb_serializers_osgsim.so was loaded it registered
wrappers and created prototype objects for all of the osgSim classes,
including osgSim::ScalarBar. The constructor for that class creates
several drawables, and loads arial.ttf using the freetype plugin. I
don't need that, and don't even ship the font or plugin with my
application, resulting in an unexplained warning message loading
the model.
I've modified the ObjectWrapper class to defer the prototype object
creation until if & when actually required."
required to build newever OSG on this OS. Also corrects file name
in the error message - I was confused not to find OSCHostEndianness.h
after I've got this error.
Tested by successfully building OSG 3.2.0 with this patch on FreeBSD
9.1."
To make easier "lazy apply" on the customer OpenGL shaders, the easiest way was to add an accessor to current OSG state's UniformMap.
I've also added accessors for modes and texture, since it could be usefull in the same way.
All methods are const, so I think there is no side-effects."
loading multiple VRML files in parallel. Christopher R. Baker has
detected this bug and crafted a patch. In addition, libcoin has to be
also built with the "--enable-threadsafe" option.
I copy here his report, extracted from
(https://bugs.launchpad.net/ubuntu/+source/openscenegraph/+bug/1211993)
and attach his fix. All credit is due to him:
«
There are three instances of a classical method-local-static
multithreaded initialization bug in the Inventor plugin for OSG that
trigger various memory faults when reading multiple VRML files in
parallel via osgDB::readNodeFile. These bugs are of the form:
static std::map<Stuff,OtherStuff> myHandyMap;
static bool once = true;
if(once) { ...fill myHandyMap; once = false }
... use myHandyMap;
To repeat: try loading multiple VRML files from multiple threads. The
liklihood of the bug depends on many factors, but my application, which
parallel-loads some dozens of small (<100K) VRML files on startup,
triggers this problem 25% of the time or more.
The attached patch (inventor-plugin-multithread.patch) rectifies this
problem by:
1 - Inheriting MyHandyMap from std::map, then
2 - Moving the map initialization into the derived constructor, which
3 - Is intrinsically protected from multithread issues by g++ (and is
part of the C++ standard), unless you pass -fno-threadsafe-statics,
which is strongly discouraged by the man page.
»
"
The delay between the 2 types of messages is more noticeable on Windows 8 and leads to serious disruptions in our application.
Mouse messages generated by touch input are only present for legacy support. I think they should be filtered out by OSG (real click events originating from a physical mouse will of course still go through).
This is what this patch does, according to this suggestion: http://msdn.microsoft.com/en-us/library/dd693088%28v=VS.85%29.aspx (third issue in this page)."
In CMakeList.txt there is a case sensitivity issue which a fix was posted by Robert Osfield in the users forum.
I also had to rename the files OSXAvFoundationCoreVideoTexture.h and OSXAvFoundationCoreVideoTexture.cpp to OSXAVFoundationCoreVideoTexture.h and OSXAVFoundationCoreVideoTexture.cpp
Finally in OSXAvFoundationCoreVideoTexture.cpp the include OSXAVFoundationVideo.H was updated to OSXAVFoundationVideo.h"
I found a bug on DDS ReaderWriter that generates a false positive on a guard for the size check on writing operation. This is due to a wrong imageSize computation that uses img->getImageSizeInBytes() method instead of img->getTotalSizeInBytes(), that actually ignores the r() dimension, contrariwise taken into account by the function ComputeImageSizeInBytes() later.
The line 1062 on file ReaderWriterDDS.cpp should be fixed with:
[code]unsigned int imageSize = img->getTotalSizeInBytes();[/code]
"
available. But this just checks if the fbo functions can be called.
It doesn't check if the OpenGL renderer supports fbos. For indirect
rendering on linux the client side capability may be different from
the display server, which can lead to mipmapped textures failing to
render. I've added a fbo extension check.
"
1> osgmultiplemovies example does not use SDL so needs no link to SDL
2> Added header files to "Plugins osg" project, so visual studio can find the source of
OSG_WARN << "AsciiInputIterator::readProperty(): Unmatched property "
"
I've also checked the modified files still build ok with other
compilers (Linux gcc, Windows Visual Studio).
osgDB/OutputStream.cpp and osgPlugins/lws/SceneLoader.cpp require
stdlib.h for atoi use.
In osg/Uniform.cpp the compiler complains that base_class is unknown
unless I add a class name qualifier.
Not a build fix, but I spotted a typo in osgUtil/SceneView."
Provided are lua, python and V8 (for javascript) plugins that just open up enough of a link to the respective libs to run a script, there is no scene graph <-> script communication in current implementation.
You can check with the tester2.flt provided earlier and check with the result image.
I double checked this with OpenFlight creator, and it seems the yaw is broken.
With my initial quaternion version is seems correct and if I change the
float cos_yaw = cosf(osg::inDegrees(yaw));
float sin_yaw = sinf(osg::inDegrees(yaw));
to be
float cos_yaw = cosf(osg::inDegrees(-yaw));
float sin_yaw = sinf(osg::inDegrees(-yaw));
it seems to work as well."
functional again for some libraries:
Find3rdPa..: Fix to find libxml2
FindCollada: Rearranged to handle different MSVC versions more effective.
This file is already prepared for the upcoming VS 2013.
FindNVTT: introduced management of debug libraries (also auto detected).
"
"Name and email address of the package maintainer, e.g., 'Jon Doe <jon.doe@superawesomemail.com>'"
)
SET(CPACK_LIBOPENSCENEGRAPH_DEPENDENCIES
"libopenthreads"
CACHESTRING
"Dependend packages for the openscenegraph library package (uses deb dependecy format), e.g., 'libc6, libcurl3-gnutls, libgif4, libjpeg8, libpng12-0'"
)
SET(CPACK_LIBOPENSCENEGRAPH-DEV_DEPENDENCIES
"libopenscenegraph"
CACHESTRING
"Dependend packages for the openscenegraph development package (uses deb dependecy format), e.g., 'libc6, libcurl3-gnutls, libgif4, libjpeg8, libpng12-0'"
)
SET(CPACK_LIBOPENTHREADS_DEPENDENCIES
""
CACHESTRING
"Dependend packages for the openthreads library package (uses deb dependecy format), e.g., 'libc6, libcurl3-gnutls, libgif4, libjpeg8, libpng12-0'"
)
SET(CPACK_LIBOPENTHREADS-DEV_DEPENDENCIES
"libopenthreads"
CACHESTRING
"Dependend packages for the openthreads development package (uses deb dependecy format), e.g., 'libc6, libcurl3-gnutls, libgif4, libjpeg8, libpng12-0'"
)
SET(CPACK_OPENSCENEGRAPH_DEPENDENCIES
"libopenscenegraph"
CACHESTRING
"Dependend packages for the openscenegraph main package (uses deb dependecy format), e.g., 'libc6, libcurl3-gnutls, libgif4, libjpeg8, libpng12-0'"
)
SET(CPACK_OPENSCENEGRAPH-ALL_DEPENDENCIES
""
CACHESTRING
"Dependend packages for the openscenegraph package with all components (uses deb dependecy format), e.g., 'libc6, libcurl3-gnutls, libgif4, libjpeg8, libpng12-0'"
)
SET(CPACK_LIBOPENSCENEGRAPH_CONFLICTS
""
CACHESTRING
"Conflicting packages for the openscenegraph library package (uses deb dependecy format), e.g., 'libc6, libcurl3-gnutls, libgif4, libjpeg8, libpng12-0'"
)
SET(CPACK_LIBOPENSCENEGRAPH-DEV_CONFLICTS
""
CACHESTRING
"Conflicting packages for the openscenegraph development package (uses deb dependecy format), e.g., 'libc6, libcurl3-gnutls, libgif4, libjpeg8, libpng12-0'"
)
SET(CPACK_LIBOPENTHREADS_CONFLICTS
""
CACHESTRING
"Conflicting packages for the openthreads library package (uses deb dependecy format), e.g., 'libc6, libcurl3-gnutls, libgif4, libjpeg8, libpng12-0'"
)
SET(CPACK_LIBOPENTHREADS-DEV_CONFLICTS
""
CACHESTRING
"Conflicting packages for the openthreads development package (uses deb dependecy format), e.g., 'libc6, libcurl3-gnutls, libgif4, libjpeg8, libpng12-0'"
)
SET(CPACK_OPENSCENEGRAPH_CONFLICTS
""
CACHESTRING
"Conflicting packages for the openscenegraph main package (uses deb dependecy format), e.g., 'libc6, libcurl3-gnutls, libgif4, libjpeg8, libpng12-0'"
)
SET(CPACK_OPENSCENEGRAPH-ALL_CONFLICTS
""
CACHESTRING
"Conflicting packages for the openscenegraph package with all components (uses deb dependecy format), e.g., 'libc6, libcurl3-gnutls, libgif4, libjpeg8, libpng12-0'"
"Dependend packages for the ${PACKAGE_COMPONENT} package with all components (uses deb dependecy format), e.g., 'libc6, libcurl3-gnutls, libgif4, libjpeg8, libpng12-0'"
)
SET(CPACK_${UPPER_PACKAGE_COMPONENT}_CONFLICTS
""
CACHESTRING
"Conflicting packages for the ${PACKAGE_COMPONENT} package (uses deb dependecy format), e.g., 'libc6, libcurl3-gnutls, libgif4, libjpeg8, libpng12-0'"
= OpenSceneGraph 3.2.1 stable release provides a number of bug and build fixes to the 3.2.0 stable release
OpenSceneGraph 3.6 release
PERTHSHIRE, Scotland - 7th April 2018 - OpenSceneGraph Professional Services announces the release of OpenSceneGraph 3.6.0, the industry's leading open-source scene graph technology, designed to accelerate application development and improve 3D graphics performance. The OpenSceneGraph is written entirely in Standard C++ and built upon OpenGL (1.2 to 4.6) and OpenGL ES (1.0 to 3.0), and offers developers working in the visual simulation, game development, virtual reality, scientific visualization and modelling markets. OpenSceneGraph 3.6 runs on all Microsoft Windows platforms, Apple OS/X, iOS, GNU/Linux, Android, Solaris, HP-UX, AIX and FreeBSD operating systems.
PERTHSHIRE, Scotland - 4th July 2014 - OpenSceneGraph Professional Services announces the release of OpenSceneGraph 3.2.1, the industry's leading open-source scene graph technology, designed to accelerate application development and improve 3D graphics performance. OpenSceneGraph 3.2 written entirely in Standard C++ and built upon OpenGL, offers developers working in the visual simulation, game development, virtual reality, scientific visualization and modeling markets - a real-time visualization tool which eclipses commercial scene graph toolkits in functionality, stability and performance. OpenSceneGraph 3.2 runs on all Microsoft Windows platforms, Apple OS/X, IOS, GNU/Linux, Android, IRIX, Solaris, HP-UX, AIX and FreeBSD operating systems.
Updates include:
=== Open-source development delivers industry-leading features and performance ===
The OpenSceneGraph 3.2.1 stable release is the culmination of 15 years of work by the open-source community that has grown up around the project. This point release is fully binary compatible with the 3.2.0 stable release. The changes made are focused on addressing bugs and improving build support for latest compilers, OS updates and 3rd changes to Party Libraries.
* OpenThreads::Affinity introduced to enable setting of processor affinity on viewer and database threads
* osgText rewritten to improve visual quality, add signed distance field support and full GLES2/3 and GL3/4 support
* Added VertexArrayObject support, enable full OpenGL Core Profile support under OSX.
* Added OpenCASCADE plugin
* Added STEP (.stp) plugin
* Improvements to FBX and COLLADA loaders
* Improvements to gles plugin to provide better Sketchfab support
* Added osgemscripten example
* Improvements to osgAnimation
* NodeVisitor ValueMap for storing values that can be stored and accessed across frames, such as update, event and cull traversals
* ShapeDrawable rewritten as an osg::Geometry to improve performance and flexibility
* Added osg::MultiDrawArrays support
* Added osgdeferred example that illustrates how to implement deferred rendering
* Added MultiDrawIndirect support
* Moved glDispatchCompute control out of osg::Program into a dedicated osg::DispatchCompute class to improve control of compute shaders
* KdTree support added for PolytopeIntersector, and ability to work with points, lines and polygons
* osgQt has been moved out to it's own dedicated osgQt github repository
* CMake build support for iOS bitcode builds
* CoverityScan testing introduced, fixes bring defect density to 0.0 per 1,0000 lines of code!
* Support for Codedoc automated documentation
* Support for Travis automated build system
=== Downloads and Licensing ===
OpenSceneGraph is open-source, so full source code is provided, and can be copied, modified and used free of charge for commercial and non-commercial use. Access to the source allows end users greater flexibility in how they develop, debug and deploy their applications. They gain productivity and freedom by being able to leverage the tool chain in accordance with their own release cycles. Downloads of binaries and source can be found in the [http://www.openscenegraph.org/index.php/download-section/stable-releases Downloads] section of the openscenegraph.org website.
OpenSceneGraph is released under the [http://www.openscenegraph.org/projects/osg/wiki/Legal OpenSceneGraph Public License], which is based on the Lesser GNU Public License (LGPL), permitting the software to be used free of charge across the full spectrum of commercial and open-source applications. Furthermore, it allows both static and dynamic linking of the OpenSceneGraph libraries without restricting the licensing of the user's software.
Downloads and Licensing:
=== Professional support and services ===
OpenSceneGraph project is backed up with professional services by [http://www.openscenegraph.com OpenSceneGraph Professional Services], based in Scotland, and [http://www.skew-matrix.com Skew-Matrix] and [http://www.alphapixel.com AlphaPixel] both based in the USA, and a range of [wiki:Community/Contractors Contractors] from around the world. Services available include:
OpenSceneGraph is open-source, so full source code is provided, and can be copied, modified and used free of charge for commercial and non-commercial use. Access to the source allows end users greater flexibility in how they develop, debug and deploy their applications. They gain productivity and freedom by being able to leverage the tool chain in accordance with their own release cycles. Downloads of binaries and source can be found at http://www.openscenegraph.org/index.php/download-section/stable-releases and at our github repository https://github.com/openscenegraph/OpenSceneGraph/.
* Confidential Professional Support
* Bespoke development
* Consultancy
* Training
OpenSceneGraph is released under the OpenSceneGraph Public License, which is based on the Lesser GNU Public License (LGPL), permitting the software to be used free of charge across the full spectrum of commercial and open-source applications. Furthermore, it allows both static and dynamic linking of the OpenSceneGraph libraries without restricting the licensing of the user's software. Further details http://www.openscenegraph.org/index.php/about/licensing
Professional support and services:
OpenSceneGraph project is backed up with professional services by OpenSceneGraph Professional Services, based in Scotland, and a range of Contractors from around the world http://www.openscenegraph.org/index.php/support/professional-support. For enquires email robert@openscenegraph.com. Services available include:
Confidential Professional Support
Bespoke development
Consultancy
Training
Community support and contributions:
=== Community support and contributions ===
The diverse and growing community of over 5000 developers is centred around the public osg-users mailing list/forum, where members discuss how best to use OpenSceneGraph, provide mutual support, and coordinate development of new features and bug fixes. Members of this community come from many different countries with backgrounds ranging from some of the world's largest aerospace companies, game companies, and visual simulation specialists to university researchers, students and hobbyists.
The OpenSceneGraph project owes a great deal to the community for its development and support, in particular we wish to thank the [http://www.openscenegraph.org/index.php/about/56-contributors/162-contributors-to-openscenegraph-3-2-1 individuals] from around the world that have directly contributed to the development and refinement of the OpenSceneGraph code base.
The OpenSceneGraph project owes a great deal to the community for its development and support, in particular we wish to thank the 568 individuals from around the world that have directly contributed to the development and refinement of the OpenSceneGraph code base.
OpenSceneGraph 3.4 release introduces shader composition, new osgUI library, displacement mapping, volume rendering, lua scripting support and much more
PERTHSHIRE, Scotland - 12th August 2015 - OpenSceneGraph Professional Services announces the release of OpenSceneGraph 3.4, the industry's leading open-source scene graph technology, designed to accelerate application development and improve 3D graphics performance. OpenSceneGraph 3.4 written entirely in Standard C++ and built upon OpenGL, offers developers working in the visual simulation, game development, virtual reality, scientific visualization and modelling markets - a real-time visualization tool which eclipses commercial scene graph toolkits in functionality, stability and performance. OpenSceneGraph 3.4 runs on all Microsoft Windows platforms, Apple OS/X, iOS, GNU/Linux, Android, IRIX, Solaris, HP-UX, AIX and FreeBSD operating systems.
Updates include:
* New #pragma(tic) composition shader functionality built into the core OSG that provides a easy to use yet flexible scheme for controlling and composing shaders at runtime levering GLSL support for #define and #pragma.
* New osgTerrain::DisplacementMappingTechnique to uses vertex, geometry and fragment shader based displacement mapping technique that dramatically lowers the CPU and GPU memory footprint and bandwidth needs for the same visual quality. The new scheme enables paged terrain that work robustly on smaller hardware, or with far higher loads without framedrops. This new technique levels #pragma(tic) shader composition to enable one to toggle on/off features in the shaders at runtime in a way that is as convenient to use as toggle modes in a fixed function pipeline scene graph.
* New osgVolume::MultipassTechique that uses multipass rendering and shaders to enable seamless mixing of traditional 3D geometry and volumes, support for geometry hulls that constrain where the volume should be rendered as well as improving the ray tracing shaders so that they are both faster and have higher visual quality than the previous generation of ray traced shaders supported by OSG-3.2 releases and before.
* New osgDB::Classiterface class that provides an easy to use mechanism for introspection of scene graph classes, allowing one to get, set properties and invoke methods in a generic way, making the task of integrating 3rd prarty tools such as scripting languages straight forward.
* New Lua scripting support via a plugin that integrates Lua 5.2.3 and the OSG via the OSG's native serialization codes.
* New osgUI NodeKit, that enables User Interface elements to be placed directly into 3D scene graph. The classes are fully scriptable so you create create UI and behaviours all within lua scripts.
* Improvements to OpenGL ES 1.1, ES 2.0 and ES3.0 support, including platform specific extensions
* Improvements to OpenGL 4.x support with a range of new extensions support
* Updates to osgQt to support Qt5 and provide better support for Qt4
Downloads and Licensing:
OpenSceneGraph is open-source, so full source code is provided, and can be copied, modified and used free of charge for commercial and non-commercial use. Access to the source allows end users greater flexibility in how they develop, debug and deploy their applications. They gain productivity and freedom by being able to leverage the tool chain in accordance with their own release cycles. Downloads of binaries and source can be found in the Downloads section of the openscenegraph.org website.
OpenSceneGraph is released under the OpenSceneGraph Public License, which is based on the Lesser GNU Public License (LGPL), permitting the software to be used free of charge across the full spectrum of commercial and open-source applications. Furthermore, it allows both static and dynamic linking of the OpenSceneGraph libraries without restricting the licensing of the user's software.
Professional support and services
OpenSceneGraph project is backed up with professional services by OpenSceneGraph Professional Services, based in Scotland, and a range of Contractors from around the world. Services available include:
Confidential Professional Support
Bespoke development
Consultancy
Training
Community support and contributions:
The diverse and growing community of over 5000 developers is centred around the public osg-users mailing list/forum, where members discuss how best to use OpenSceneGraph, provide mutual support, and coordinate development of new features and bug fixes. Members of this community come from many different countries with backgrounds ranging from some of the world's largest aerospace companies, game companies, and visual simulation specialists to university researchers, students and hobbyists.
The OpenSceneGraph project owes a great deal to the community for its development and support, in particular we wish to thank the 550 individuals from around the world that have directly contributed to the development and refinement of the OpenSceneGraph code base.
= !OpenSceneGraph 3.2 release improves support iOS and Android, supports a range of new OpenGL features much more.
PERTHSHIRE, Scotland - 24th July 2013 - !OpenSceneGraph Professional Services announces the release of !OpenSceneGraph 3.2, the industry's leading open-source scene graph technology, designed to accelerate application development and improve 3D graphics performance. !OpenSceneGraph 3.2 written entirely in Standard C++ and built upon OpenGL, offers developers working in the visual simulation, game development, virtual reality, scientific visualization and modeling markets - a real-time visualization tool which eclipses commercial scene graph toolkits in functionality, stability and performance. !OpenSceneGraph 3.2 runs on all Microsoft Windows platforms, Apple OS/X, IOS, GNU/Linux, Android, IRIX, Solaris, HP-UX, AIX and FreeBSD operating systems.
PERTHSHIRE, Scotland - 24th July 2013 - !OpenSceneGraph Professional Services announces the release of !OpenSceneGraph 3.2, the industry's leading open-source scene graph technology, designed to accelerate application development and improve 3D graphics performance. !OpenSceneGraph 3.2 written entirely in Standard C++ and built upon OpenGL, offers developers working in the visual simulation, game development, virtual reality, scientific visualization and modelling markets - a real-time visualization tool which eclipses commercial scene graph toolkits in functionality, stability and performance. !OpenSceneGraph 3.2 runs on all Microsoft Windows platforms, Apple OS/X, iOS, GNU/Linux, Android, IRIX, Solaris, HP-UX, AIX and FreeBSD operating systems.
=== Open-source development delivers industry-leading features and performance ===
The !OpenSceneGraph 3.2 release is the culmination of 14 years of work by the open-source community that has grown up around the project. The real-time graphics industry and academia embraced it from the very beginning, deploying it in real-world applications, and actively participating in its development, testing and refinement. The end result is a high-quality library with a feature set relevant to application developers' needs in both the desktop and mobile space.
@@ -46,7 +106,7 @@ The !OpenSceneGraph 3.2 release is the culmination of 14 years of work by the op
* New OpenGL extensions support including compute shaders, tessellation shaders, integer array formats and associated Vec* classes, primitive restart
* Improvements to osgManipulator NodeKit that introduce new manipulators and improve flexibility and customizability
* Updates to osgQt to support Qt5 and provide better support for Qt4
* New osgGA::Device base class for recieving from and sending events to both real and virtual devices in a generic, extensible way
* New osgGA::Device base class for receiving from and sending events to both real and virtual devices in a generic, extensible way
* New ZeroConf, RestHTTP and OSC plugins to enable remote control of applications such as controlling desktop systems from tablets and phones
* Improvements to osgVolume NodeKit and DICOM plugin for better medical visualization
* New TrackVis .trk track files plugin for the visualization of brain scans.
@@ -83,7 +143,7 @@ The !OpenSceneGraph project owes a great deal to the community for its developme
= !OpenSceneGraph 3.0 release adds support OpenGL ES 1.1, OpenGL ES 2.0, OpenGL 3.x to 4.0, support for Andoid and IOS platforms and much more.
PERTHSHIRE, Scotland - 28th June 2011 - !OpenSceneGraph Professional Services announces the release of !OpenSceneGraph 3.0, the industry's leading open-source scene graph technology, designed to accelerate application development and improve 3D graphics performance. !OpenSceneGraph 3.0 written entirely in Standard C++ and built upon OpenGL, offers developers working in the visual simulation, game development, virtual reality, scientific visualization and modeling markets - a real-time visualization tool which eclipses commercial scene graph toolkits in functionality, stability and performance. !OpenSceneGraph 3.0 runs on all Microsoft Windows platforms, Apple OS/X, IOS, GNU/Linux, Android, IRIX, Solaris, HP-UX, AIX and FreeBSD operating systems.
PERTHSHIRE, Scotland - 28th June 2011 - !OpenSceneGraph Professional Services announces the release of !OpenSceneGraph 3.0, the industry's leading open-source scene graph technology, designed to accelerate application development and improve 3D graphics performance. !OpenSceneGraph 3.0 written entirely in Standard C++ and built upon OpenGL, offers developers working in the visual simulation, game development, virtual reality, scientific visualization and modelling markets - a real-time visualization tool which eclipses commercial scene graph toolkits in functionality, stability and performance. !OpenSceneGraph 3.0 runs on all Microsoft Windows platforms, Apple OS/X, iOS, GNU/Linux, Android, IRIX, Solaris, HP-UX, AIX and FreeBSD operating systems.
=== Open-source development delivers industry-leading features and performance ===
The !OpenSceneGraph 3.0 release is the culmination of 12 years of work by the lead developers and the open-source community that has grown up around the project. The real-time graphics industry and academia embraced it from the very beginning, deploying it in real-world applications, and actively participating in its development, testing and refinement. The end result is a high-quality library with a feature set relevant to application developers' needs.
@@ -138,7 +198,7 @@ The !OpenSceneGraph project owes a great deal to the community for its developme
= !OpenSceneGraph 2.8 release adds osgAnimation and osgVolume libraries, DICOM support, LispSM shadowing and much more. =
PERTHSHIRE, Scotland - 12th February 2009 - !OpenSceneGraph Professional Services announces the release of !OpenSceneGraph 2.8, the industry's leading open-source scene graph technology, designed to accelerate application development and improve 3D graphics performance. !OpenSceneGraph 2.8 written entirely in Standard C++ and built upon OpenGL, offers developers working in the visual simulation, game development, virtual reality, scientific visualization and modeling markets - a real-time visualization tool which eclipses commercial scene graph toolkits in functionality, stability and performance. !OpenSceneGraph 2.8 runs on all Microsoft Windows platforms, Apple OS/X, GNU/Linux, IRIX, Solaris, HP-UX, AIX and FreeBSD operating systems.
PERTHSHIRE, Scotland - 12th February 2009 - !OpenSceneGraph Professional Services announces the release of !OpenSceneGraph 2.8, the industry's leading open-source scene graph technology, designed to accelerate application development and improve 3D graphics performance. !OpenSceneGraph 2.8 written entirely in Standard C++ and built upon OpenGL, offers developers working in the visual simulation, game development, virtual reality, scientific visualization and modelling markets - a real-time visualization tool which eclipses commercial scene graph toolkits in functionality, stability and performance. !OpenSceneGraph 2.8 runs on all Microsoft Windows platforms, Apple OS/X, GNU/Linux, IRIX, Solaris, HP-UX, AIX and FreeBSD operating systems.
=== Open-source development delivers industry-leading features and performance ===
The !OpenSceneGraph 2.8 release is the culmination of 10 years of work by the lead developers and the open-source community that has grown up around the project. The real-time graphics industry and academia embraced it from the very beginning, deploying it in real-world applications, and actively participating in its development, testing and refinement. The end result is a high-quality library with a feature set relevant to application developers' needs.
@@ -209,7 +269,7 @@ About !OpenSceneGraph Professional Services:[[BR]]
= !OpenSceneGraph 2.6 release adds osgWidget library, KdTree intersections, Anti-aliased FBOsand much more. =
PERTHSHIRE, Scotland - 5th August 2008 - !OpenSceneGraph Professional Services announces the release of !OpenSceneGraph 2.6, the industry's leading open-source scene graph technology, designed to accelerate application development and improve 3D graphics performance. !OpenSceneGraph 2.6 written entirely in Standard C++ and built upon OpenGL, offers developers working in the visual simulation, game development, virtual reality, scientific visualization and modeling markets - a real-time visualization tool which eclipses commercial scene graph toolkits in functionality, stability and performance. !OpenSceneGraph 2.6 runs on all Microsoft Windows platforms, Apple OS/X, GNU/Linux, IRIX, Solaris, HP-UX, AIX and FreeBSD operating systems.
PERTHSHIRE, Scotland - 5th August 2008 - !OpenSceneGraph Professional Services announces the release of !OpenSceneGraph 2.6, the industry's leading open-source scene graph technology, designed to accelerate application development and improve 3D graphics performance. !OpenSceneGraph 2.6 written entirely in Standard C++ and built upon OpenGL, offers developers working in the visual simulation, game development, virtual reality, scientific visualization and modelling markets - a real-time visualization tool which eclipses commercial scene graph toolkits in functionality, stability and performance. !OpenSceneGraph 2.6 runs on all Microsoft Windows platforms, Apple OS/X, GNU/Linux, IRIX, Solaris, HP-UX, AIX and FreeBSD operating systems.
=== Open-source development delivers industry-leading features and performance ===
The !OpenSceneGraph 2.6 release is the culmination of 9 years of work by the lead developers and the open-source community that has grown up around the project. The real-time graphics industry and academia embraced it from the very beginning, deploying it in real-world applications, and actively participating in its development, testing and refinement. The end result is a high-quality library with a feature set relevant to application developers' needs.
@@ -278,7 +338,7 @@ About !OpenSceneGraph Professional Services:[[BR]]
= !OpenSceneGraph 2.4 release adds geometry shaders, multiple render targets, support for terrabyte scale terrain databases, writing to !OpenFlight and much more. =
PERTHSHIRE, Scotland - 25th April 2008 - !OpenSceneGraph Professional Services announces the release of !OpenSceneGraph 2.4, the industry's leading open-source scene graph technology, designed to accelerate application development and improve 3D graphics performance. !OpenSceneGraph 2.4 written entirely in Standard C++ and built upon OpenGL, offers developers working in the visual simulation, game development, virtual reality, scientific visualization and modeling markets - a real-time visualization tool which eclipses commercial scene graph toolkits in functionality, stability and performance. !OpenSceneGraph 2.4 runs on all Microsoft Windows platforms, Apple OS/X, GNU/Linux, IRIX, Solaris, HP-UX, AIX and FreeBSD operating systems.
PERTHSHIRE, Scotland - 25th April 2008 - !OpenSceneGraph Professional Services announces the release of !OpenSceneGraph 2.4, the industry's leading open-source scene graph technology, designed to accelerate application development and improve 3D graphics performance. !OpenSceneGraph 2.4 written entirely in Standard C++ and built upon OpenGL, offers developers working in the visual simulation, game development, virtual reality, scientific visualization and modelling markets - a real-time visualization tool which eclipses commercial scene graph toolkits in functionality, stability and performance. !OpenSceneGraph 2.4 runs on all Microsoft Windows platforms, Apple OS/X, GNU/Linux, IRIX, Solaris, HP-UX, AIX and FreeBSD operating systems.
=== Open-source development delivers industry-leading features and performance ===
The !OpenSceneGraph 2.4 release is the culmination of 9 years of work by the lead developers and the open-source community that has grown up around the project. The real-time graphics industry and academia embraced it from the very beginning, deploying it in real-world applications, and actively participating in its development, testing and refinement. The end result is a high-quality library with a feature set relevant to application developers' needs.
@@ -334,7 +394,7 @@ About !OpenSceneGraph Professional Services:[[BR]]
= OpenSceneGraph 2.2 release adds support for advanced displays, soft and parallel split shadow maps and easier builds =
PERTHSHIRE, Scotland - 4th October 2007 - !OpenSceneGraph Professional Services announces the release of !OpenSceneGraph 2.2, the industry's leading open-source scene graph technology, designed to accelerate application development and improve 3D graphics performance. !OpenSceneGraph 2.2 written entirely in Standard C++ and built upon OpenGL, offers developers working in the visual simulation, game development, virtual reality, scientific visualization and modeling markets - a real-time visualization tool which eclipses commercial scene graph toolkits in functionality, stability and performance. !OpenSceneGraph 2.2 runs on all Microsoft Windows platforms, Apple OS/X, GNU/Linux, IRIX, Solaris, HP-UX, AIX and !FreeBSD operating systems.
PERTHSHIRE, Scotland - 4th October 2007 - !OpenSceneGraph Professional Services announces the release of !OpenSceneGraph 2.2, the industry's leading open-source scene graph technology, designed to accelerate application development and improve 3D graphics performance. !OpenSceneGraph 2.2 written entirely in Standard C++ and built upon OpenGL, offers developers working in the visual simulation, game development, virtual reality, scientific visualization and modelling markets - a real-time visualization tool which eclipses commercial scene graph toolkits in functionality, stability and performance. !OpenSceneGraph 2.2 runs on all Microsoft Windows platforms, Apple OS/X, GNU/Linux, IRIX, Solaris, HP-UX, AIX and !FreeBSD operating systems.
=== Open-source development delivers industry-leading features and performance ===
The !OpenSceneGraph 2.2 release is the culmination of 8 years of work by the lead developers and the open-source community that has grown up around the project. The real-time graphics industry and academia embraced it from the very beginning, deploying it in real-world applications, and actively participating in its development, testing and refinement. The end result is a high-quality library with a feature set relevant to application developers' needs.
@@ -391,7 +451,7 @@ About !OpenSceneGraph Professional Services:[[BR]]
!!![=OpenSceneGraph=] 2.0 release improves ease-of-use and scalability, introducing new osgViewer, osgShadow and osgManipulator libraries, new build system, improved multi-core, multi-GPU support.
PERTHSHIRE, Scotland - 15th June 2007 - [=OpenSceneGraph=] Professional Services announces the release of [=OpenSceneGraph=] 2.0, the industry's leading open-source scene graph technology, designed to accelerate application development and improve 3D graphics performance. [=OpenSceneGraph=] 2.0, written entirely in Standard C++ and built upon [=OpenGL=], offers developers working in the visual simulation, game development, virtual reality, scientific visualization and modeling markets a real-time visualization tool which rivals established commercial scene graph toolkits in functionality and performance. [=OpenSceneGraph=] 2.0 runs on all Microsoft Windows platforms, Apple OS/X, GNU/Linux, IRIX, Solaris, HP-UX, AIX and [=FreeBSD=] operating systems.
PERTHSHIRE, Scotland - 15th June 2007 - [=OpenSceneGraph=] Professional Services announces the release of [=OpenSceneGraph=] 2.0, the industry's leading open-source scene graph technology, designed to accelerate application development and improve 3D graphics performance. [=OpenSceneGraph=] 2.0, written entirely in Standard C++ and built upon [=OpenGL=], offers developers working in the visual simulation, game development, virtual reality, scientific visualization and modelling markets a real-time visualization tool which rivals established commercial scene graph toolkits in functionality and performance. [=OpenSceneGraph=] 2.0 runs on all Microsoft Windows platforms, Apple OS/X, GNU/Linux, IRIX, Solaris, HP-UX, AIX and [=FreeBSD=] operating systems.
!!!Open-source development delivers industry-leading features and performance
The [=OpenSceneGraph=] 2.0 release is the culmination of 8 years of work by the lead developers and the open-source community that has grown up around the project. The real-time graphics industry and academia embraced it from the very beginning, deploying it in real-world applications, and actively participating in its development, testing and refinement. The end result is a high-quality library with a feature set relevant to application developers' needs.
@@ -449,7 +509,7 @@ Project Lead and Proprietor [=OpenSceneGraph=] Professional Services
!!![=OpenSceneGraph=] 1.2 release introduces Windows 64bit and AIX support, COLLADA support, processor affinity and texture atlas builder.
PERTHSHIRE, Scotland - 12th September 2006 - [=OpenSceneGraph=] Professional Services announces the release of [=OpenSceneGraph=] 1.2, the industry's leading open source scene graph technology, designed to accelerate application development and improve 3D graphics performance. [=OpenSceneGraph=] 1.2, written entirely in Standard C++ and built upon [=OpenGL=], offers developers working in the visual simulation, game development, virtual reality, scientific visualization and modeling markets a real time visualization tool which rivals established commercial scene graph toolkits in functionality and performance. [=OpenSceneGraph=] 1.2 runs on all Microsoft Windows platforms, Apple OS/X, GNU/Linux, IRIX, Solaris, HP-UX, AIX and [=FreeBSD=] operating systems.
PERTHSHIRE, Scotland - 12th September 2006 - [=OpenSceneGraph=] Professional Services announces the release of [=OpenSceneGraph=] 1.2, the industry's leading open source scene graph technology, designed to accelerate application development and improve 3D graphics performance. [=OpenSceneGraph=] 1.2, written entirely in Standard C++ and built upon [=OpenGL=], offers developers working in the visual simulation, game development, virtual reality, scientific visualization and modelling markets a real time visualization tool which rivals established commercial scene graph toolkits in functionality and performance. [=OpenSceneGraph=] 1.2 runs on all Microsoft Windows platforms, Apple OS/X, GNU/Linux, IRIX, Solaris, HP-UX, AIX and [=FreeBSD=] operating systems.
The [=OpenSceneGraph=]-1.2 release introduces:
@@ -474,7 +534,7 @@ Project Lead and Proprietor [=OpenSceneGraph=] Professional Services
!!!OpenSceneGraph 1.1 release introduces peformance and scalability improvements, full OpenGL Shading Language support and new OpenFlight 16.1, TerrPagea2.2 and Quake3 loaders.
AYRSHIRE, Scotland - July 19th 2006 - [=OpenSceneGraph=] Professional Services announces the release of [=OpenSceneGraph=] 1.1,
the industry's leading open-source graphics library with [=OpenGL=] 2.0 and [=OpenGL=] Shading Language support. [=OpenSceneGraph=] is designed to accelerate application development and improve 3D graphics performance. [=OpenSceneGraph=] 1.1, written entirely in Standard C++ and built upon [=OpenGL=], offers developers working in the visual simulation, game development, virtual reality, scientific visualization and modeling markets a real time visualization tool which rivals established commercial scene graph toolkits in functionality and performance. [=OpenSceneGraph=] 1.1 runs on all Microsoft Windows platforms, Apple OS/X, GNU/Linux, IRIX, Solaris and [=FreeBSD=] operating systems.
the industry's leading open-source graphics library with [=OpenGL=] 2.0 and [=OpenGL=] Shading Language support. [=OpenSceneGraph=] is designed to accelerate application development and improve 3D graphics performance. [=OpenSceneGraph=] 1.1, written entirely in Standard C++ and built upon [=OpenGL=], offers developers working in the visual simulation, game development, virtual reality, scientific visualization and modelling markets a real time visualization tool which rivals established commercial scene graph toolkits in functionality and performance. [=OpenSceneGraph=] 1.1 runs on all Microsoft Windows platforms, Apple OS/X, GNU/Linux, IRIX, Solaris and [=FreeBSD=] operating systems.
The OpenSceneGraph-1.1 release introduces:
@@ -501,7 +561,7 @@ Project Lead and Proprietor [=OpenSceneGraph=] Professional Services
AYRSHIRE, Scotland - December 9th, 2005 - [=OpenSceneGraph=] Professional Services announces the release of [=OpenSceneGraph=] 1.0, the industry's leading open-source graphics library with [=OpenGL=] 2.0 and [=OpenGL=] Shading Language support. [=OpenSceneGraph=] is designed to accelerate application development and improve 3D graphics performance. [=OpenSceneGraph=] 1.0, written entirely in Standard C++ and built upon [=OpenGL=], offers developers working in the visual simulation, game development, virtual reality, scientific visualization and modeling markets a real time visualization tool which rivals established commercial scene graph toolkits in functionality and performance. [=OpenSceneGraph=] 1.0 runs on all Microsoft Windows platforms, Apple OS/X, GNU/Linux, IRIX, Solaris and [=FreeBSD=] operating systems.
AYRSHIRE, Scotland - December 9th, 2005 - [=OpenSceneGraph=] Professional Services announces the release of [=OpenSceneGraph=] 1.0, the industry's leading open-source graphics library with [=OpenGL=] 2.0 and [=OpenGL=] Shading Language support. [=OpenSceneGraph=] is designed to accelerate application development and improve 3D graphics performance. [=OpenSceneGraph=] 1.0, written entirely in Standard C++ and built upon [=OpenGL=], offers developers working in the visual simulation, game development, virtual reality, scientific visualization and modelling markets a real time visualization tool which rivals established commercial scene graph toolkits in functionality and performance. [=OpenSceneGraph=] 1.0 runs on all Microsoft Windows platforms, Apple OS/X, GNU/Linux, IRIX, Solaris and [=FreeBSD=] operating systems.
->''"3Dlabs congratulates the [=OpenSceneGraph=] development community on the release of [=OpenSceneGraph=] 1.0. [=OpenSceneGraph=] is a shining example of how open-source projects can deliver commercial-quality products with outstanding performance and a ton of cutting-edge features. 3Dlabs committed engineering resources to [=OpenSceneGraph=] to help implement full support of programmable shader technology through [=OpenGL=] Shading Language. It is gratifying to see the excitement that developers have for this important cross-platform, real-time visualization library."'''\\
Randi Rost, director of developer relations at 3Dlabs, http://developer.3Dlabs.com/
@@ -628,7 +688,7 @@ osgpbuffer also example now uses Producer's pbuffer support making it portable a
API refinements, bug fixes and performance improvements:
There have been many bug fixes, a number of performance improvements and API cleanups that have occured throughout the 0.9.8 - 0.9.9, too many separate items to enumerate here. Together with the above new features they all go to making the OpenSceneGraph-0.9.9 the most robust, high performance and feature rich version so far, and sets the stage for the upcoming 1.0.
There have been many bug fixes, a number of performance improvements and API cleanups that have occurred throughout the 0.9.8 - 0.9.9, too many separate items to enumerate here. Together with the above new features they all go to making the OpenSceneGraph-0.9.9 the most robust, high performance and feature rich version so far, and sets the stage for the upcoming 1.0.
We would like to thank the following engineers for their contributions in the 0.9.8 - 0.9.9.9 time frame (in alphabetic order):
Alberto Farre, Bob Kuehne, Brede Johansen, Carlo Camporesi, Chris Hanson, Don Burns, Donn Mielcarek, Don Tidrow, Farshid Lashkari, Frederic Marmond, Garrett Potts, Igor Kravtchenko, James French, Jan Ciger, John Grant, Joakim Simonsson, Joran Jessurun, Jason Daly, Kevin Moiule, Leandro Motta Barros, Marco Jez, Mason Menninger, Mike Weiblen, Nathan Monteleone, Norman Vine, Olaf Flebbe, Paul Melis, Per Fahlberg, Rainer Oder, Randall Hopper, Reinhard Sainitzer, Robert Osfield, Ruben, Sebastien Grignard, Stephan Huber, Terry Welsh, Thom DeCarlo, Tony Horrobin, Tree, Tugkan Calapoglu, Vivek Rajan, Waltice and Yuzhong Shen
For up-to-date information on the project, in-depth details on how to compile and run libraries and examples, see the documentation on the OpenSceneGraph website:
For support subscribe to our public mailing list or forum, details at:
http://www.openscenegraph.org/index.php/support
For the impatient, we've included quick build instructions below, these are are broken down is three parts:
1) General notes on building the OpenSceneGraph
2) macOS release notes
3) iOS release notes
If details below are not sufficient then head over to the openscenegraph.org to the Documentation/GettingStarted and Documentation/PlatformSpecifics sections for more indepth instructions.
Robert Osfield.
Project Lead.
7th April 2018.
---
## Section 1. How to build OpenSceneGraph
The OpenSceneGraph uses the CMake build system to generate a platform-specific build environment. CMake reads the `CMakeLists.txt` files that you'll find throughout the OpenSceneGraph directories, checks for installed dependencies and then generates files for the selected build system.
If you don't already have CMake installed on your system you can grab it from http://www.cmake.org, use version 2.8.0 or later. Details on the OpenSceneGraph's CMake build can be found at:
Under Unix-like systems (i.e. Linux, IRIX, Solaris, Free-BSD, HP-UX, AIX, macOS) use the `cmake` or `ccmake` command-line utils. Note that `cmake .` defaults to building Release to ensure that you get the best performance from your final libraries/applications.
cd OpenSceneGraph
cmake .
make
sudo make install
Alternatively, you can create an out-of-source build directory and run cmake or ccmake from there. The advantage to this approach is that the temporary files created by CMake won't clutter the OpenSceneGraph source directory, and also makes it possible to have multiple independent build targets by creating multiple build directories. In a directory alongside the OpenSceneGraph use:
mkdir build
cd build
cmake ../OpenSceneGraph
make
sudo make install
Under Windows use the GUI tool CMakeSetup to build your VisualStudio files. The following page on our wiki dedicated to the CMake build system should help guide you through the process:
Under macOS you can either use the CMake build system above, or use the Xcode projects that you will find in the OpenSceneGraph/Xcode directory. See release notes on macOS CMake build below.
For further details on compilation, installation and platform-specific information read "Getting Started" guide:
## Section 2. Release notes on macOS build, by Eric Sokolowski et al.
There are two ways to compile OpenSceneGraph under macOS. The recommended way is to use CMake to generate Xcode project files and then use Xcode to build the library. The default project will be able to build Debug or Release libraries, examples, and sample applications.
The alternative is to build OpenSceneGraph from the command line using `make` or `ninja` using the instructions for Unix-like systems above.
Here are some key settings to consider when using CMake:
- BUILD_OSG_EXAMPLES - By default this is turned off. Turn this setting on to compile many great example programs.
- CMAKE_OSX_ARCHITECTURES - Xcode can create applications, executables, libraries, and frameworks that can be run on more than one architecture. Use this setting to indicate the architectures on which to build OSG. x86_64 is the only supported value for OS versions > 10.7.
- OSG_BUILD_APPLICATION_BUNDLES - Normally only executable binaries are created for the examples and sample applications. Turn this option on if you want to create real macOS .app bundles. There are caveats to creating `.app` bundles, see below.
- OSG_DEFAULT_IMAGE_PLUGIN_FOR_OSX - By default macOS uses the `imageio` plugin instead of the plugins for the individual file types (e.g. `jpg`, `gif`, etc.) to load image file types. The `imageio` plugin can handle all popular file formats through the ImageIO framework.
- OSG_WINDOWING_SYSTEM - You have the choice to use Cocoa, Carbon, or X11 when building applications on macOS. Cocoa is the default for OS versions >= 10.5. Carbon and X11 are no longer actively supported, either by Apple or the OSG community.
### APPLICATION BUNDLES (.app bundles)
The example programs when built as application bundles only contain the executable file. They do not contain the dependent libraries as would a normal bundle, so they are not generally portable to other machines.
They also do not know where to find plugins. An environmental variable OSG_LIBRARY_PATH may be set to point to the location where the plugin .so files are located. OSG_FILE_PATH may be set to point to the location where data files are located. Setting OSG_FILE_PATH to the OpenSceneGraph-Data directory is very useful when testing OSG by running the example programs.
Many of the example programs use command-line arguments. When double-clicking on an application (or using the equivalent "open" command on the command line) only those examples and applications that do not require command-line arguments will successfully run. The executable file within the .app bundle can be run from the command-line if command-line arguments are needed.
## Section 3. Release notes on iOS build, by Thomas Hogarth
With CMake, XCode and the iOS sdk installed you can generate an iOS XCode project using the following command line:
Be sure to set the THIRDPARTY_PATH to the path containing your thirdparty dependencies. Set IPHONE_SDKVER to the version of the iOS sdk you have installed, in this instance 10.2. IPHONE_VERSION_MIN controls the base sdk used by xcode, and lastly set OPENGL_PROFILE to the version of GLES you want to use.
Once this completes an XCode project will have been generated in the osg root folder. Open the generated Xcode project, select the example_osgViewerIPhone target. In 'General' tab set a development team. In the 'Build Settings' tab search for 'Other Linker Flags', then for each target type (debug, release etc) that you want to use open the list of arguments and delete the 'OpenGL' line and the '-framework' line above it. This is because cmake has tried to add the desktop OpenGL library which we don't want.
Once this is done you should be able to build and deploy the `example_osgViewerIPhone` target on your device.
arguments.getApplicationUsage()->setDescription(arguments.getApplicationName()+" is an application for collecting a set of separate files into a single archive file that can be later read in OSG applications..");
arguments.getApplicationUsage()->setDescription(arguments.getApplicationName()+" is an application for collecting a set of separate files into a single archive file that can be later read in OSG applications..");
@@ -412,21 +415,21 @@ int main( int argc, char **argv )
arguments.getApplicationUsage()->addCommandLineOption("-e level minX minY maxX maxY","Read down to <level> across the extents minX, minY to maxY, maxY. Note, for geocentric datase X and Y are longitude and latitude respectively.");
arguments.getApplicationUsage()->addCommandLineOption("-c directory","Shorthand for --file-cache directory.");
arguments.getApplicationUsage()->addCommandLineOption("--file-cache directory","Set directory as to place cache download files.");
@@ -439,7 +442,7 @@ int main( int argc, char **argv )
std::cout<<"No path to the file cache defined, please set OSG_FILE_PATH env var, or use --file-cache <directory> to set a suitable directory for the file cache."<<std::endl;
arguments.getApplicationUsage()->setDescription(arguments.getApplicationName()+" is a utility for converting glsl shader files into char arrays that can be compiled into applications.");
arguments.getApplicationUsage()->addCommandLineOption("--shader <filename>","Shader file to create a .cpp file for.");
arguments.getApplicationUsage()->addCommandLineOption("--write-to-source-file-directory","Use the path to the source filename as the directory to write to.");
arguments.getApplicationUsage()->addCommandLineOption("-h or --help","Display command line parameters");
arguments.getApplicationUsage()->setDescription(arguments.getApplicationName()+" is the standard OpenSceneGraph example which loads and visualises 3d models.");
arguments.getApplicationUsage()->addCommandLineOption("--image <filename>","Load an image and render it on a quad");
arguments.getApplicationUsage()->addCommandLineOption("--dem <filename>","Load an image/DEM and render it on a HeightField");
arguments.getApplicationUsage()->addCommandLineOption("--login <url> <username> <password>","Provide authentication information for http file access.");
arguments.getApplicationUsage()->addCommandLineOption("-p <filename>","Play specified camera path animation file, previously saved with 'z' key.");
arguments.getApplicationUsage()->addCommandLineOption("--speed <factor>","Speed factor for animation playing (1 == normal speed).");
arguments.getApplicationUsage()->addCommandLineOption("--device <device-name>","add named device to the viewer");
//init the data array somehow, this way all is stored in one BufferObject. maybe better using multiple buffers instead? not sure what is faster and better for threading
computeNode->setUpdateCallback(newComputeNodeUpdateCallback(computeNode.get()));// on-the-fly reloading the shaders if shader source on disk is changed
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
