Memory overflow with BuildNgon (NgonBase)
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 18/04/2011 at 01:50, xxxxxxxx wrote:
User Information:
Cinema 4D Version: R12.043
Platform: Windows ;
Language(s) : C++ ;---------
hi !
I have a setup with around 100k ngons. When I try to build them by using the BuildNgon function of the ngonbase class (passing only the inner edges of tris and quads) my memory usage gets out of control. Any suggestions?Here is the code. The given vector contains the indices of the polys which build the ngon.
Bool BuildNgon(std::vector<LONG> &nGon;)
{
NgonBase *ngonBase = m_pobj->GetNgonBase();
if(!ngonBase) {
m_pobj->GetAndBuildNgon();
ngonBase = m_pobj->GetNgonBase();
if(!ngonBase) return FALSE;
}const CPolygon* vadr = m_pobj->GetPolygonR();
std::vector<LONG> innerEdges;
for (LONG iFace = 0; iFace < nGon.size(); ++iFace)
{
for (LONG iSide = 0; iSide < 4; iSide++)
{
if (iSide==2 && vadr[nGon[iFace]].c==vadr[nGon[iFace]].d) continue;
LONG a1 = 0, b1 = 0;
switch (iSide)
{
case 0: a1 = vadr[nGon[iFace]].a; b1 = vadr[nGon[iFace]].b; break;
case 1: a1 = vadr[nGon[iFace]].b; b1 = vadr[nGon[iFace]].c; break;
case 2: a1 = vadr[nGon[iFace]].c; b1 = vadr[nGon[iFace]].d; break;
case 3: a1 = vadr[nGon[iFace]].d; b1 = vadr[nGon[iFace]].a; break;
}
Bool neighborFound = FALSE;
for (LONG jFace = 0; jFace < nGon.size(); ++jFace)
{
if (iFace == jFace) continue;
if (neighborFound) break;
for (LONG jSide = 0; jSide < 4; jSide++)
{
if (jSide==2 && vadr[nGon[jFace]].c==vadr[nGon[jFace]].d) continue;
LONG a2 = 0, b2 = 0;
switch (jSide)
{
case 0: a2 = vadr[nGon[jFace]].a; b2 = vadr[nGon[jFace]].b; break;
case 1: a2 = vadr[nGon[jFace]].b; b2 = vadr[nGon[jFace]].c; break;
case 2: a2 = vadr[nGon[jFace]].c; b2 = vadr[nGon[jFace]].d; break;
case 3: a2 = vadr[nGon[jFace]].d; b2 = vadr[nGon[jFace]].a; break;
}
// nGon[iFace] and nGon[jFace] are neighbors
if ((a1 == a2 && b1 == b2) || (a1 == b2 && a2 == b1))
{
innerEdges.push_back(nGon[iFace] * 4 + iSide);
neighborFound = TRUE;
break;
}
}
}
}
}
if (!innerEdges.empty()) ngonBase->BuildNgon(&innerEdges;[0], NULL, (LONG)innerEdges.size(), 0, vadr, m_pobj->GetPointR());
return TRUE;
} -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 18/04/2011 at 06:08, xxxxxxxx wrote:
Hello Satara,
What happend if you build only 100 ngons or 1000, 10000?
100k ngons are very much...
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 18/04/2011 at 06:25, xxxxxxxx wrote:
10.000 are okay but it takes a few times longer than without ngons (and uses a lot more memory)
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 19/04/2011 at 09:35, xxxxxxxx wrote:
according to this post... https://developers.maxon.net/forum/topic/3542/2962_ngon-performace
I also pass the outline now to the BuildNgon function but the memory usage is still too high. Create function didn't help either.
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 20/04/2011 at 02:21, xxxxxxxx wrote:
Is the high memory consumption caused by the code or by the ngons themselves?
cheers,
Matthias -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 20/04/2011 at 03:15, xxxxxxxx wrote:
The Code seems to be alright. When I leave out the call to BuildNgons the memory consumption is okay.
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 02/05/2011 at 07:55, xxxxxxxx wrote:
still hoping for a solution..
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 25/01/2012 at 01:49, xxxxxxxx wrote:
We're facing this as well for a bunch of cases. We have numerous plugins generating relatively big pieces of geometry with just a few ngons. The geometry is far from causing problems with it doesn't use ngons, but as soon as we have even just a single ngon in it, the memory usage explodes.
Really bad situation, especially in cases in which ngons aren't just a nice addition, but in which they actually change the look of the object (e.g. if the geometry is meant to be subdivided by a HyperNURBS).
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 26/01/2012 at 03:35, xxxxxxxx wrote:
Originally posted by xxxxxxxx
We're facing this as well for a bunch of cases. We have numerous plugins generating relatively big pieces of geometry with just a few ngons. The geometry is far from causing problems with it doesn't use ngons, but as soon as we have even just a single ngon in it, the memory usage explodes.
Really bad situation, especially in cases in which ngons aren't just a nice addition, but in which they actually change the look of the object (e.g. if the geometry is meant to be subdivided by a HyperNURBS).
Without a scene and code to debug it is difficult to know what the problem might be.
Could send a scene to [email protected] that has been converted with your code ? So that developers can check the ngon structure.
You could also manually check this by looking at the Pgon data (which is just edge data) and check it has the correct edges. Ngons are just a layer over the polygons that stores the edges that form the ngons, the object still has all the polygons so you not only have the ngon edges but all the polygons (tris/quads) that form them.You should start with a few ngons and check these are correct, also checking how much memory they use and the Pgon data.
Is it a specific ngon that causes a problem ? Possibly some 'bad' edge data causes the ngon build function to go wrong.If you supply a plugin and example scene developers can debug them internally.
Other possible ideas:
The build function is just a helper, it should (AFAIR) be possible to do this manually and build the Pgon (edges) with the API.
It is also possible to use the modeling library to directly form the ngons with polygons (just from the points) and this will create the ngons and polys (but is slower).