Memory problem

[greenivy]

hi, everyone.
I created a demo through "Structured hexahedron mesh template" (%OIVHOME%\src\MeshVizDataMapping\MeshTemplates\My VolumeMeshHexahedronIjk.h) to render a pillar grid.
It worked, but the question is so many memory used up, just for a method called getCellNodeIndices in class MyHexahedronTopologyExplicitIjk.
I tried to delete the scene root node, and the memory used didn't reduce clearly. If render a big mesh many times, the routine must be crashed!
Who is familiar with MeshViz Interface? Can you tell me how to correctly use "Structured hexahedron mesh template".

[mikeheck]

I created a demo through "Structured hexahedron mesh template" (%OIVHOME%\src\MeshVizDataMapping\MeshTemplates\My VolumeMeshHexahedronIjk.h) to render a pillar grid.
It worked, but the question is so many memory used up, just for a method called getCellNodeIndices in class MyHexahedronTopologyExplicitIjk.
I tried to delete the scene root node, and the memory used didn't reduce clearly. If render a big mesh many times, the routine must be crashed!
Who is familiar with MeshViz Interface? Can you tell me how to correctly use "Structured hexahedron mesh template".

I've attached a simple example using MiVolumeMeshHexahedronIjk. It's actually a basic test program starting point, so the mesh is completely regular and many things (for example a cell's node indices) can simply be computed from the cell index. But it may be helpful.

I can't really speculate about memory usage in the getCellNodeIndices() method because this method is effectively part of your application's code and the implementation that you need depends on the requirements of your mesh.

[greenivy]

I've attached a simple example using MiVolumeMeshHexahedronIjk. It's actually a basic test program starting point, so the mesh is completely regular and many things (for example a cell's node indices) can simply be computed from the cell index. But it may be helpful.

I can't really speculate about memory usage in the getCellNodeIndices() method because this method is effectively part of your application's code and the implementation that you need depends on the requirements of your mesh.

hi, mikeheck.
I modified ExampleHexaIjk.cxx and had some test, the memory once created couldn't be released completely. If I want to completely control the memory, what should I do?

void doRender( int argc, char** argv )
{
  // Init viewer
  Widget my_window = SoXt::init(argv[0]);
  if (my_window == NULL) exit(1) ;

  MoMeshViz::init();

  SoSeparator* root = new SoSeparator();
  root->ref();

  // Enable two-sided lighting
  SoShapeHints* shapeHints = new SoShapeHints();
  shapeHints->vertexOrdering.setValue(SoShapeHints::CLOCKWISE);
  root->addChild( shapeHints );

  SoSeparator* meshSep = new SoSeparator();
  root->addChild( meshSep );

  // Create my mesh and data objects
  MyVolumeMeshHexahedronIjk* mesh  = new MyVolumeMeshHexahedronIjk();
  MyScalarSetIjk_IxJ* scalarSetIjk = new MyScalarSetIjk_IxJ;

  // Mesh data
  MoMesh* moMesh = new MoMesh();
  moMesh->setMesh( mesh );
  meshSep->addChild(moMesh);

  // Scalar set (per cell) = cell_i * cell_j
  MoScalarSet* moScalarSet = new MoScalarSet();
  moScalarSet->setScalarSet( scalarSetIjk );
  meshSep->addChild( moScalarSet );

  // Define color map
  MoPredefinedColorMapping* moColorMap = new MoPredefinedColorMapping();
  // Adjust range to IJK scalar set 0
  moColorMap->minValue = (float)scalarSetIjk->getMin();
  moColorMap->maxValue = (float)scalarSetIjk->getMax();
  moColorMap->predefColorMap = MoPredefinedColorMapping::STANDARD;
  meshSep->addChild(moColorMap);

  // Display edges (faces are on by default)
  MoDrawStyle* moDrawStyle = new MoDrawStyle();
  moDrawStyle->displayEdges = TRUE;
  meshSep->addChild( moDrawStyle );

  // Make edges single color
  MoMaterial* moMaterial = new MoMaterial();
  moMaterial->lineColoring = MoMaterial::COLOR;
  moMaterial->lineColor    = SbColor(0,0,0);
  meshSep->addChild( moMaterial );

  // Tell rendering nodes to look in the scalarIJK list for data sets...
  MoDataBinding* moDataBinding = new MoDataBinding();
  moDataBinding->dataBinding = MoDataBinding::PER_CELL;
  meshSep->addChild( moDataBinding );

  // Skin to render cell faces
  MoMeshSkin* moMeshSkin = new MoMeshSkin();
  moMeshSkin->colorScalarSetId = 0;
  meshSep->addChild( moMeshSkin );

  // Create and display viewer
  SoXtExaminerViewer* viewer = new SoXtExaminerViewer(my_window);
  viewer->setSceneGraph( root );
  viewer->setBackgroundColor( SbColor(0,0.1f,0.1f) );
  viewer->show();
  SoXt::show(my_window);

  // Loop then cleanup
  SoXt::mainLoop();

  //////////////////////////////////////////////////////////////////////////
  root->unref();
  delete viewer;
  //////////////////////////////////////////////////////////////////////////

  MoMeshViz::finish();
  SoXt::finish();
}

int main( int argc, char** argv )
{
  int flag = 1;
  while( flag ) {
    doRender( argc, argv );
    scanf( "%d", &flag );
  }

  return 0;
}

[mikeheck]

I modified ExampleHexaIjk.cxx and had some test, the memory once created couldn't be released completely. If I want to completely control the memory, what should I do?

Note there is a tiny memory leak in this code because the doRender() function does not free the memory allocated for the variables 'mesh' and 'scalarSetIjk'. In this case, because it's a test program mesh that computes all its data on-the-fly, there is very little memory involved. But you might need to fix that for a real mesh.

What I see in TaskManager with a release build is:
- Before first doRender(): about 4 MB
- While mesh is displayed: about 30 MB
- After doRender(): about 20 MB
- While mesh is displayed: about 30 MB
- After doRender(): about 20 MB
- etc

The residual 20 MB is larger than the memory for this process before doRender() is called for the first time. I don't know specifically what is responsible for the extra memory, but the memory used by Open Inventor consistently goes up then comes back down to this same value. So there doesn't appear to be a memory "leak". A "leak" would imply that the peak memory used keeps increasing every time doRender() is called. That doesn't seem to be the case.

One possibility is that the extra memory is allocated by the graphics driver the first time the mesh is rendered. It's common for the driver to allocate some memory for internal purposes and keep reusing that memory until the process exits.

[greenivy]

Well, thanks mikeheck.