CID 11441: Non-array delete for scalars (DELETE_ARRAY)
"_dwobj::readOpenings(_iobuf *, int)" allocates "obj.fc1". [show details]
"_dwobj::~_dwobj()" uses delete on "obj.fc1" which is an array. It should be deleted with operator delete[]. [show details]
CID 11394: Resource leak in object (CTOR_DTOR_LEAK)
Allocating memory by calling "new osg::IntArray".
Assigning: "this->colorindices" = "new osg::IntArray".
The constructor allocates field "colorindices" of "struct vertexInfo" but there is no destructor.
CID 11395: Resource leak in object (CTOR_DTOR_LEAK)
Allocating memory by calling "new osg::IntArray".
Assigning: "this->coordindices" = "new osg::IntArray".
The constructor allocates field "coordindices" of "struct vertexInfo" but there is no destructor.
CID 11396: Resource leak in object (CTOR_DTOR_LEAK)
Allocating memory by calling "new osg::IntArray".
Assigning: "this->normindices" = "new osg::IntArray".
The constructor allocates field "normindices" of "struct vertexInfo" but there is no destructor.
CID 11397: Resource leak in object (CTOR_DTOR_LEAK)
Allocating memory by calling "new osg::IntArray".
Assigning: "this->txindices" = "new osg::IntArray".
The constructor allocates field "txindices" of "struct vertexInfo" but there is no destructor.
CID 11398: Resource leak in object (CTOR_DTOR_LEAK)
Allocating memory by calling "new osg::Vec2Array".
Assigning: "this->txcoords" = "new osg::Vec2Array".
The constructor allocates field "txcoords" of "struct vertexInfo" but there is no destructor.
CID 11399: Resource leak in object (CTOR_DTOR_LEAK)
Allocating memory by calling "new osg::Vec3Array".
Assigning: "this->norms" = "new osg::Vec3Array".
The constructor allocates field "norms" of "struct vertexInfo" but there is no destructor.
CID 11400: Resource leak in object (CTOR_DTOR_LEAK)
Allocating memory by calling "new osg::Vec3Array".
Assigning: "this->coords" = "new osg::Vec3Array".
The constructor allocates field "coords" of "struct vertexInfo" but there is no destructor.
CID 11401: Resource leak in object (CTOR_DTOR_LEAK)
Allocating memory by calling "new osg::Vec4Array".
Assigning: "this->colors" = "new osg::Vec4Array".
The constructor allocates field "colors" of "struct vertexInfo" but there is no destructor.
CID 11402: Resource leak in object (CTOR_DTOR_LEAK)
Allocating memory by calling "new osg::Vec4Array".
Assigning: "this->polycols" = "new osg::Vec4Array".
The constructor allocates field "polycols" of "struct vertexInfo" but there is no destructor.
CID 11389: Resource leak in object (CTOR_DTOR_LEAK)
Allocating memory by calling "new bsp::VBSPData".
Assigning: "this->bsp_data" = "new bsp::VBSPData".
The constructor allocates field "bsp_data" of "struct bsp::VBSPReader" but the destructor and whatever functions it calls do not free it.
ID 11390: Resource leak in object (CTOR_DTOR_LEAK)
Allocating memory by calling "new osg::Vec3Array".
Assigning: "this->vertices" = "new osg::Vec3Array".
The constructor allocates field "vertices" of "struct prims" but the destructor and whatever functions it calls do not free it.
CID 11391: Resource leak in object (CTOR_DTOR_LEAK)
Allocating memory by calling "new osg::Vec3Array".
Assigning: "this->normals" = "new osg::Vec3Array".
The constructor allocates field "normals" of "struct prims" but the destructor and whatever functions it calls do not free it.
CID 11392: Resource leak in object (CTOR_DTOR_LEAK)
Allocating memory by calling "new osg::Vec3Array".
Assigning: "this->txc" = "new osg::Vec3Array".
The constructor allocates field "txc" of "struct prims" but the destructor and whatever functions it calls do not free it.
CID 11393: Resource leak in object (CTOR_DTOR_LEAK)
Allocating memory by calling "new osg::Vec3Array".
Assigning: "this->txcoords" = "new osg::Vec3Array".
The constructor allocates field "txcoords" of "struct prims" but the destructor and whatever functions it calls do not free it.
CID 11747: Uninitialized pointer field (UNINIT_CTOR)
Non-static class member gset is not initialized in this constructor nor in any functions that it calls.
CID 11851: Unused pointer value (UNUSED_VALUE)
Pointer "gfd" returned by "gr->getField(26)" is never used.
CID 11850: Unused pointer value (UNUSED_VALUE)
Pointer "gfd" returned by "gr->getField(80)" is never used.
CID 11849: Unused pointer value (UNUSED_VALUE)
Pointer "gfd" returned by "gr->getField(3)" is never used.
CID 11848: Unused pointer value (UNUSED_VALUE)
Pointer "gfd" returned by "grec->getField(3)" is never used.
/** Get the file name which represents the archived file.*/
virtual std::string getArchiveFileName() const = 0;
/** return type of file. */
virtual FileType getFileType(const std::string& filename) const = 0;
/** return the contents of a directory.
* returns an empty array on any error.*/
virtual DirectoryContents getDirectoryContents(const std::string& dirName) const = 0;
Added implementations of these new methods into src/osgPlugins/osga/OSGA_Archive.h src/osgPlugins/osga/OSGA_Archive.cpp
The pvr format which can be used as a wrapper for different compressed and uncompressed formats supports this compression algorithm. The original pvr compression uses the pvrtc format. The handling of pvrtc is already implemented in the pvr plugin. PVR provides wrapper functionality for some formats, e.g. etc or even dxt/dds.
Our target system (gles2) is able to use the etc compression format. With minor changes in the submitted files, there is no need to write a separate plugin. However the original pvr texture compression formats are not supported on our target, which is the reason for this extension.
The changes mainly consist in the definition on new enum values in the classes and headers of ReaderWriterPVR,Image and Texture. I also found some locations where the handling of the original pvr textures was not implemented. These are also part of this submission."
of empty node:
if (GetFloat4Param(cot->getParam()->getRef(), f4)) {...}
in the model I have tested cot->getParam()->getRef() return 0x0 and make
it crahes inside GetFloat4Param.
I have added a test before calling GetFloat4Param
if (cot->getParam()->getRef() != 0 &&
GetFloat4Param(cot->getParam()->getRef(), f4)) {...}
"
supportsOption("dds_dxt1_rgb","set the pixel format of DXT1 encoded images to be RGB");
supportsOption("dds_dxt1_rgba","set the pixel format of DXT1 encoded images to be RGBA");
supportsOption("dds_dxt1_detect_rgba","For DXT1 encode images set the pixel format according to presence of transparent pixels.");
And set the default not to modify and detect the RGB or RGBA pixel format for DXT images.
One can override this value via the sampleDensityWhenMoving="value" property in the volume tag, i.e.
<volume sampleDensityWhenMoving="0.01">CardiacCT</volume>
To switch the feature off set the value to 0, i.e.
<volume sampleDensityWhenMoving="0">CardiacCT</volume>
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.
"
"- 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."
- 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."
