"There is a redundant cmake code at the end of osgViewer cmake script. The install command is issued in SETUP_LIBRARY macro."
"I spotted this when i tried a make install on the android port :) I saw some weird copy commands of osgViewer headers.
I managed to get all osg headers copied to cmake_install_prefix/include upon make install, but i can't (yet) get the libraries to be copied to cmake_install_prefix/lib (see attached files)"
2. Removed unecessary code. Also made sure the images names are not truncated in the middle of an UTF8 character. You'll find there a function called utf8TruncateBytes(), which may be moved in core OSG (osgDB/ConvertUTF I guess). Feel free to do it if you feel it that way.
"
(I'll omit osgWidget namespace from now on). It seems to me that there
are some inconsistency in the code. In Style there are multiple
applyStyle method overloads, applying style for different
widgets/windows built-in in osgWidget. Plus you can do overrides. It's
good so far.
The problem lies in StyleManager::_applyStyleToObject (which calls
_coearceAndApply, which calls _applySpecificStyle, which calls
Style::applyStyle). With current implementation Style::applyStyle
variants for Input, Window, Frame::Corner, Frame::Border,
Window::EmbeddedWindow are never called, because their classes' names
are omitted in methods' if/else if block, making it impossible to use
styles with most than half of built-in widget/window types.
My fix simply adds couple else if blocks, making each
Style::applyStyle variant callable. By the way, I think that next
update should add Style::applyStyle overload for Table class and add
proper className overloads for Input and Window."
This happens because RenderStage::_bufferAttachmentMap is updated only for the number of buffers the camera has when runCameraSetUp is called.
For example if there were 4 attachments and now only 3, only the first three elements of _bufferAttachmentMap are changed. The fourth is just as before - however it shouldn't be there.
Calling _bufferAttachmentMap.clear() before resolves this problem.
"
"- In order to build against GLES1 we execute:
$ mkdir build_android_gles1
$ cd build_android_gles1
$ cmake .. -DOSG_BUILD_PLATFORM_ANDROID=ON -DDYNAMIC_OPENTHREADS=OFF
-DDYNAMIC_OPENSCENEGRAPH=OFF -DANDROID_NDK=<path_to_android_ndk>/
-DOSG_GLES1_AVAILABLE=ON -DOSG_GL1_AVAILABLE=OFF
-DOSG_GL2_AVAILABLE=OFF -DOSG_GL_DISPLAYLISTS_AVAILABLE=OFF -DJ=2
-DOSG_CPP_EXCEPTIONS_AVAILABLE=OFF
$ make
If all is correct you will have and static OSG inside:
build_android_gles1/bin/ndk/local/armeabi.
- GLES2 is not tested/proved, but I think it could be possible build
it with the correct cmake flags.
- The flag -DJ=2 is used to pass to the ndk-build the number of
processors to speed up the building.
- make install is not yet supported."
SETUP_EXE, in order to have a unique entry point to build the
libraries. With this changes the android integration will be less
painful (currently is a big IF(ANDROID) for each CMakeLists.txt) and
more maintainable in the future. I hope next submissions will be for
supporting android from my colleague Jorge.
"
/** Convenience method for setting up multiple slave cameras that depth partition the specified camera.*/
bool setUpDepthPartitionForCamera(osg::Camera* cameraToPartition, DepthPartitionSettings* dps=0);
/** Convenience method for setting up multiple slave cameras that depth partition each of the view's active cameras.*/
bool setUpDepthPartition(DepthPartitionSettings* dsp=0);
- contributor
- author
- authoring_tool
- comments
- copyright
- source_data
- created
- keywords
- modified
- revision
- subject
- title
- unit
- name
- meter
- up_axis
With this support, users are able to include additional information in their models. Additionally, tools such as sketchup that support asset tags use the values appropriately within their imported models."
1. daeRGeometry.cpp (rev 12132). A tiny sumbission which fixes a quite important bug: a parameter was forgotten in Collada ReaderWriter, and texture coordinates could not be loaded properly. So:
"
Added missing paramter when calling createGeometryData(). Fixes missing texture coordinates (in "bind_vertex_input").
"
2. ReaderWriterDAE.cpp (rev 12132):
"
Added "baseImageDir" as a plugin string data, in order to manually specify base directory to use when relativising image file names. This is used to properly write files, when images are not located in a subdirectory (like "../images" for some software).
"
The reason is that the .osgt text files do not provide size information about the contained binary shader hence leading to a bad allocation when reading the shader data, probably size 0 ? The reader method in the responsible serializer class (serializers/osg/BinaryShader) is correct and does not need to be changed as it queries the size as expected. The writer method supports two paths(binary output .osgb and text output .osgt/.osgx). Only the text path is affected as the binary path writes the size.
I extended the writer in the text path by the size information. The results before and after the fix are shown below:
Erroneous code for binary shader in osgt file before fix:
Data {
0a
0d
0
...
}
Corrected code for binary shader in osgt file after fix:
Data 524 {
0a
0d
0
...
}
After my fix the the thrown error disappeared."
I included binary shaders into an osgt model file. These shaders only consists of the binary shader code, I did not supply the text version additionally. When loading the model the osg::Optimizer threw away all shaders except the first one. In the current trunk version of the file two shader objects are identical despite differing _shaderBinary members as the compare method of the Shader class does not include the comparison of that member.
The fix in this submission adds the check for identity of the referenced binary shaders to the shader class.
When comparing two shader objects with text source shaders the new lines of comparison are not even executed as the comparison returns false in the previous lines when the text shaders differ.
With this fix I get expected behavior, the Optimizer handles the different shaders correctly."
and the modified key as requested. Can other OS X developers please test
the attached file, to make sure it works for everybody?
I fixed the problem with the caps-lock-key, too."
The current setAnchorHorizontal() command doesn't center the center of the object, it just center's the object's origin. The following change to osgWidget::Window::update() will correct that behavior so that it is consistent with setAnchorVertical() behavior.
"
1. DAE submission:
DAE plugin now correctly writes images URI in Collada file, when images are used twice.
I also greatly improved readability and maintenability of geometry reading (mainly daeRGeometry.cpp), by factorizing code, templatizing it (for double/single precision), and removing ugly macros.
2. osgDB submission:
I updated osgDB::getPathRelative(): it is now far more readable, it handles more cases (especially when you want to relativise "a/c" from "a/b", which results in "../c"), and I added comments to make it clearer to maintain."
and another problem is:
example osgkeyboard is not work (keys not highlight) if user have 2 keyboard layout native and english and current user layout is native
I try to explain my changes
we need something that is identify key without modifier keys and layout -> this is UnmodifedKey
I think osg must have its own UnmodifiedKeys table. Code must be run same on different platforms. This can de guaranteed by UnmodifiedKeys table.
Mikhail Izmestev helped me. He implemented VirtualKey changes in GraphicsWindowX11"
to read fonts: only the first character of a whole text is correctly
shown and others are disappeared. I haven't got into the font
implementation so can't explain why this happened and how it should
work under other platforms, but it seems to be fixed by specifying
width and height of the glyph object. The source file is attached for
future developments. At present it just works for my own project. :-)
"
DAE plugin was linking ORIGINAL images in the Collada file, using image->getName() as a path (even if images were modified in memory!). As the behaviour was not the one of other plugins (3DS, FBX, and such), I made the plugin relativise images filenames (as those plugins) and write the image which is in memory. However, in order to avoid removing features, I kept the previous behaviour but moved it in an option. Here are the options of the plugin I changed:
- daeForceTexture was unclear in this new context and removed in favor of two new options
- daeLinkOriginalTexturesNoForce: Writes reference to the original image if found, instead of writing the image in memory
- daeLinkOriginalTexturesForce: Writes reference to the original image even if not found, instead of writing the image in memory
Of course, if you specify no option, images are written as for other plugins.
Other thing I changed is the UTF8 support as I told you in a previous conversation. Now there is a simple option, "daeNamesUseCodepage", which makes all names except filenames (materials, animation, geometries...) be considered as encoded using current codepage. If so, they'll be converted to UTF8 when writing; else they are written directly. Of course, filenames follow OSG_USE_UTF8_FILENAME as usual.
I did "
to protect against accessing while writing which was segfaulting in VPB
specifically in void ThreadPool::run(osg::Operation* op)
in the waiting loop
while (_operationQueue->getNumOperationsInQueue() >= _maxNumberOfOperationsInQueue)
"
1. It did not support normals applied to individual vertices.
2. It would only support red / green / blue colour triples, but the pmvs models are generated with diffuse colours. (The PLY format, http://local.wasp.uwa.edu.au/~pbourke/dataformats/ply/, lists specular and ambient colour forms as well.)
To partially overcome these limitations, please find attached modified versions of
src/osgPlugins/ply/vertexData.cpp
src/osgPlugins/ply/vertexData.h
The changes I've made are:
1. I have changed the boolean hasColor flag to a vertexField (which is a boolean operation on an enum) to indicate what fields are present in the ply file. (This is required because Turk's ply reader spits out warnings for every line where you try to read fields which do not exist.)
2. I have modified the code to apply valid normals to either triangles or vertices.
3. I have kludged in "support" for the various colour variants. Specifically, all the colour specified can be read from the file. However, they are all applied in the same way (namely as a colour array, bound to each vertex)."
I have attached a patch, against the trunk from 13:30 today, which consists of the following:
1. CMakeModules/FindOpenEXR.cmake: Look for libIlmThread and libIex as well. 2. src/osgPlugins/CMakeList.txt: Only include the exr subdirectory if both the OpenEXR and zip libraries were found. 3. src/osgPlugins/exr/CMakeLists.txt: Add ZIP_LIBRARY to TARGET_EXTERNAL_LIBRARIES."
