topic Re: MultiPatchShapeBuffer Materials in File Geodatabase API Questions

MultiPatchShapeBuffer Materials

claudevuattoux — Tue, 06 Dec 2011 08:19:07 GMT

I am trying to import    MultPatchShapebuffer in Rhino with the sdk
I have no problem to decode the geometry   building the appropriate meshes , normals , textures coordinates but   when i use

MultiPatch.GetMaterials ( nummaterial, compression,*&part , *&material)

( see the code below ) i get garbage with nummaterial   ( huge number)   and compression    even if MultiPatch.HasMaterials () return true
Is the method GetMaterials fully implemented ?
Is there a workaround ?

Second Question

How to interpret the content of the material pointer

( an array of bytes for each material ) , is it just a binary content of a jpg file , tif ?
I need to get an image file ( jpg, tiff ) to pass as a texture file to rhino
Or a special representation of the image ( how to get resolution , colors )

I made the test on the shape.gdt who contain a multipatch object with texture , and other gdb
i always get garbage on this function call
Thanks for explanations.

sample code :
if   ( geo ==    geometryMultiPatch )
{
MultiPatchShapeBuffer MultiPatch;

if ( hr =row.GetGeometry(MultiPatch) != S_OK ) {

   RhinoApp().Print ( " erreur geometry \n");

} else {
   int NumParts;
   int NumPoints;
   MultiPatch.GetNumParts(NumParts);
   MultiPatch.GetNumPoints( NumPoints);
   RhinoApp().Print ( "MultiPatch: numpoint %d   numparts %d   textures: %d    material :%d \n",
    NumPoints, NumParts,MultiPatch.HasTextures(shapeType), MultiPatch.HasMaterials(shapeType) );

   if ( MultiPatch.HasTextures(shapeType) == true ) {
    int numTextures;
    int textureDimension;
    int *textureParts;
    float   *texturesCoords;
    fgdbError error;
    error = MultiPatch.GetTextures( numTextures, textureDimension, *&textureParts, *&texturesCoords);
    RhinoApp().Print ( " Number of texture %d Dimension: %d \n", numTextures, textureDimension);
   } // end textures test

   if ( MultiPatch.HasMaterials(shapeType) == true ) {
    int   nummaterial = 0;
    int   compression = 0;
    int *part = NULL;
    unsigned char *material = NULL;
    fgdbError error;
    error = MultiPatch.GetMaterials( nummaterial, compression, *&part,    *&material) ;

    if ( error != S_OK ) {
     RhinoApp().Print ( " Error reading material \n");

    } else {
     RhinoApp().Print (" nummaterial %d \n", nummaterial);
     int n;
     for ( n = 0; n < nummaterial; n++ ) {
      RhinoApp().Print ( "Compression:%d part:%d     material %d \n", compression, part, material);
     }
    }
   } // end material

}
}

Re: MultiPatchShapeBuffer Materials

ArturRedzko — Tue, 28 Feb 2012 09:11:19 GMT

I'm facing the same problem. GetMaterials returns memory garbage. I also cannot find any info about how many elements is returned using GetNormals (NumNormals is missing), GetTextures and GetMaterials (number of xxxParts data). Looking at extended shapefile record format from March 30, 2011 I can assume that they are equal to NumParts. Is there any new documentation fixed with these information?

BTW. I don't like to ask about that but are there any plans about next SDK update? It's been a long time since the last release. I hope this project is still alive.

Regards
Artur

Re: MultiPatchShapeBuffer Materials

DavidSousa — Tue, 28 Feb 2012 14:42:32 GMT

These issues and others have been addressed in version 1.2 of the API, which is going through the release certification process as we speak. I don't know the exact release date, but it will be very soon.

Don't be concerned - this project is very much alive.

Re: MultiPatchShapeBuffer Materials

ArturRedzko — Tue, 28 Feb 2012 18:03:21 GMT

Thanks. Waiting with patience.

Re: MultiPatchShapeBuffer Materials

ArturRedzko — Thu, 08 Mar 2012 08:15:47 GMT

I checked the version 1.2 but the problems remain. Tested with Shapes sample data. Also there is new bug, now GetTextures returns invalid values comparing with version 1.1. numTextures returns 2, textureDimension returns 0. GetMaterials still returns trash.
I also don't get any difference in speed comparing with 1.1 when viewing larger datasets. Should NIM071538 and NIM078028 solve these problems ?

Re: MultiPatchShapeBuffer Materials

LanceShipman — Thu, 08 Mar 2012 14:48:59 GMT

NIM071538 makes a huge difference in performance when using a spatial search. We tested against a feature class containing over 30 million features. The performance went from 70 seconds to under one second. If you are not using a spatial search you will see no change in performance. The "extended shape buffer format" document (renamed from "extended shapefile format") has been updated, including the section on multipatch geometries, which was previously incomplete.

Re: MultiPatchShapeBuffer Materials

DavidSousa — Thu, 08 Mar 2012 19:40:38 GMT

I don't know if the multipatch helper functions have a problem or not. But, I would like to point out that there is a simple solution: don't rely on them. They don't do much of anything all that useful anyway. You should be able to 'roll your own' very effectively by reading and understanding the doc. Especially with multitpatches, a thorough understanding the doc is essential.

Re: MultiPatchShapeBuffer Materials

ArturRedzko — Fri, 20 Apr 2012 11:08:21 GMT

Thank you. This has motivated me to make it manually using the updated documentation. Now I can display it in 3D like ArcGis does, but I found a problem with materials performance and logic. The test data is Shapes.gdb database from SDK, multipatch layer and there we have building number 26. This shape has 1734 part descriptors and 699 materials. From descriptors it looks like parts use all of the materials, sometimes repeating the id.

Now my problem - I don't know why these textures are multiplied with context? I dumped all textures on disc (jpeg files) and from 700 there are ~20 different images only. Why the same texture maps are repeated for each material instead of using shared texture as material type and just referencing to existing map? Instead I have 500 jpeg files with the same window. The files are even identical when comparing binary.

I can think of a texture map that is shared among materials (by using shared texture with id) and we have many materials but e.g. we use different colors or transparency for this map, etc. Why it's not done this way in this case? Is it the problem with SDK or it's just bad sample data from you? I tested other samples and they behave correctly, parts point to the same material without duplicates in context, although some data have unused materials (like additional images of the feature) and I didn't find an example of using shared texture material type.

Can you please help me with this?

Thanks.
Artur

Re: MultiPatchShapeBuffer Materials

DavidSousa — Fri, 20 Apr 2012 20:30:37 GMT

Are you saying that textures are not shared within the same multipatch, or across different multipatches?

One thing about multipatches is that each multipatch is self contained. If you have 100 individual multipatches, and each one uses the same texture, that texture will be stored separately in each of those 100 features. There is no provision for them to be stored externally and then accessed by reference.

However, within a single multipatch, it is possible to have multiple references to an individual texture. For example, the same window can be reused on each side of a building. But I believe it is contingent upon the author of the multipatch do make sure that this is done.

Re: MultiPatchShapeBuffer Materials

ArturRedzko — Mon, 23 Apr 2012 08:18:09 GMT

I meant textures within one multipatch. So it's up to a user how he defines materials and use them as shared or not. Thanks.