MultiPatchShapeBuffer Materials

[claudevuattoux]

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

  }
}

[ArturRedzko]

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

[DavidSousa]

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.

[ArturRedzko]

Thanks. Waiting with patience.

[ArturRedzko]

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 ?

[LanceShipman]

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.

[DavidSousa]

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.

[ArturRedzko]

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

[DavidSousa]

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.

[ArturRedzko]

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.