Re: [osg-users] Problem of points showing
Hi, Ismail,
I don't understand how the expanding happen?
I read all dataset into an array of P, then when it expands? and why?
and what's old array?
On Tue, Apr 14, 2009 at 2:27 PM, Ismail Pazarbasi pazarb...@gmail.comwrote:
Hi Lingyun,
std::bad_alloc is thrown when operator new cannot allocate memory,
which indicates there is not enough memory. You may reserve your array
before hand, as Paul mentioned, but it may throw as well. This could
reduce, if nothing, copy operations. It may also prevent exception,
because when expanding, std::vector will have two large copies at the
same time. That is:
e.g. old array length was 150
expand by 50
While allocating 200 elements, previous 150 elements will also
be alive/allocated, that requires room for 350 elements in total.
Resize may reduce this cost to 200 only, because vector will not
have to expand afterwards (i.e. during push_back), which requires a
copy operation. Note that C++ standard allocator doesn't do realloc().
Instead, vector will allocate a block of N * sizeof(T) items (or
little more), copy existing block into new one, then free existing
block.
// instantiate vertices normally
vertices = new osg::Vec3Array;
// if number of parts is greater than 1000,
// reserve your items before.
if (NumPart 1000)
{
try
{
vertices-reserve(NumPart);
}
catch (std::bad_alloc e)
{
// handle exception here; log and return error from this function.
// alternatively, you can rethrow here, and catch in caller.
}
}
// wrap your push_back calls in a try-catch block
try
{
vertices-push_back(...);
}
catch (std::exception)
{
}
To be on the safe side, handle your exceptions and wrap your pointers
in a smart pointer class. If an exception is thrown and you
rethrow/return from function, you need to delete your Geode, Group and
other objects. You may get all these for free, if you use a smart
pointer (osg::ref_ptrT, in this case, as osg::Node's destructor is
protected, IIRC, which prevents it to be deleted externally, but
only when its ref count reaches 0).
HTH
Ismail
2009/4/13 Paul Martz pma...@skew-matrix.com:
Hi Lingyun Yu --
You don't have a variable named 'galaxy' defined, so the
addDrawable(galaxy) is suspicious.
I'd so a resize on the vertex and color arrays, rather than a push_back,
for
efficiency reasons.
I don't think numParts100 should cause any problems. OpenGL doesn
not
place an upper limit on the number of primitives you can render with a
single glDrawArrays call.
I don't really see anything that would cause a crash so I guess you
should
use a debugger and look at the call stack, like you would any other
crash.
Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com
+1 303 859 9466
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Sent:
Monday, April 13, 2009 9:27 AM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] Problem of points showing
Hi, everybody,
I met a problem when I want to show huge amount of points, as you can see
the code below, if my NumPart is 100, no problem, it shows points
properly. But if the NumPart is 200, then it shows a lot of lines. If
NumPart is even bigger, the program complained like this：Microsoft C++
exception: std::bad_alloc at memory location 0x0030e898.
I don't know that's because the dataset is too big or not? because while
it
shows not so many points, everything goes well.
By the way, the data in P array are all right.
osg::Geode *makeGalaxy()
{
osg::Geode *geode = new osg::Geode();
osg::Geometry *geometry= new osg::Geometry();
osg::Vec3Array *vertices = new osg::Vec3Array();
osg::Vec4Array *colors = new osg::Vec4Array();
osg::Vec4 ini(1,0.1,0.55,1);
osg::Vec4 fin(0,1,0,1);
for (int i = 1; i = NumPart; i++)
{
vertices-push_back(osg::Vec3(P[i].Pos[0],P[i].Pos[1],P[i].Pos[2]));
colors-push_back(ini+(fin-ini)*(i*1/NumPart));
}
geometry-setVertexArray(vertices);
geometry-setColorArray(colors);
geometry-setColorBinding(osg::Geometry::BIND_PER_VERTEX);
geometry-addPrimitiveSet(new
osg::DrawArrays(osg::PrimitiveSet::POINTS,
0, NumPart));
geode-addDrawable(galaxy);
return geode;
}
...
Thank you.
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=10166#10166
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem of points showing
And yes,
after I did
if (NumPart 1000)
{
try
{
vertices-reserve(NumPart);
}
catch (std::bad_alloc e)
{
// handle exception here; log and return error from this function.
// alternatively, you can rethrow here, and catch in caller.
}
}
it jumps to catch part.
2009/4/15 Lingyun Yu lingyun.yu...@gmail.com
Hi, Ismail,
I don't understand how the expanding happen?
I read all dataset into an array of P, then when it expands? and why?
and what's old array?
On Tue, Apr 14, 2009 at 2:27 PM, Ismail Pazarbasi pazarb...@gmail.comwrote:
Hi Lingyun,
std::bad_alloc is thrown when operator new cannot allocate memory,
which indicates there is not enough memory. You may reserve your array
before hand, as Paul mentioned, but it may throw as well. This could
reduce, if nothing, copy operations. It may also prevent exception,
because when expanding, std::vector will have two large copies at the
same time. That is:
e.g. old array length was 150
expand by 50
While allocating 200 elements, previous 150 elements will also
be alive/allocated, that requires room for 350 elements in total.
Resize may reduce this cost to 200 only, because vector will not
have to expand afterwards (i.e. during push_back), which requires a
copy operation. Note that C++ standard allocator doesn't do realloc().
Instead, vector will allocate a block of N * sizeof(T) items (or
little more), copy existing block into new one, then free existing
block.
// instantiate vertices normally
vertices = new osg::Vec3Array;
// if number of parts is greater than 1000,
// reserve your items before.
if (NumPart 1000)
{
try
{
vertices-reserve(NumPart);
}
catch (std::bad_alloc e)
{
// handle exception here; log and return error from this function.
// alternatively, you can rethrow here, and catch in caller.
}
}
// wrap your push_back calls in a try-catch block
try
{
vertices-push_back(...);
}
catch (std::exception)
{
}
To be on the safe side, handle your exceptions and wrap your pointers
in a smart pointer class. If an exception is thrown and you
rethrow/return from function, you need to delete your Geode, Group and
other objects. You may get all these for free, if you use a smart
pointer (osg::ref_ptrT, in this case, as osg::Node's destructor is
protected, IIRC, which prevents it to be deleted externally, but
only when its ref count reaches 0).
HTH
Ismail
2009/4/13 Paul Martz pma...@skew-matrix.com:
Hi Lingyun Yu --
You don't have a variable named 'galaxy' defined, so the
addDrawable(galaxy) is suspicious.
I'd so a resize on the vertex and color arrays, rather than a push_back,
for
efficiency reasons.
I don't think numParts100 should cause any problems. OpenGL doesn
not
place an upper limit on the number of primitives you can render with a
single glDrawArrays call.
I don't really see anything that would cause a crash so I guess you
should
use a debugger and look at the call stack, like you would any other
crash.
Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com
+1 303 859 9466
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Sent:
Monday, April 13, 2009 9:27 AM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] Problem of points showing
Hi, everybody,
I met a problem when I want to show huge amount of points, as you can
see
the code below, if my NumPart is 100, no problem, it shows points
properly. But if the NumPart is 200, then it shows a lot of lines.
If
NumPart is even bigger, the program complained like this：Microsoft C++
exception: std::bad_alloc at memory location 0x0030e898.
I don't know that's because the dataset is too big or not? because while
it
shows not so many points, everything goes well.
By the way, the data in P array are all right.
osg::Geode *makeGalaxy()
{
osg::Geode *geode = new osg::Geode();
osg::Geometry *geometry= new osg::Geometry();
osg::Vec3Array *vertices = new osg::Vec3Array();
osg::Vec4Array *colors = new osg::Vec4Array();
osg::Vec4 ini(1,0.1,0.55,1);
osg::Vec4 fin(0,1,0,1);
for (int i = 1; i = NumPart; i++)
{
vertices-push_back(osg::Vec3(P[i].Pos[0],P[i].Pos[1],P[i].Pos[2]));
colors-push_back(ini+(fin-ini)*(i*1/NumPart));
}
geometry-setVertexArray(vertices);
geometry-setColorArray(colors);
geometry-setColorBinding(osg::Geometry::BIND_PER_VERTEX);
geometry-addPrimitiveSet(new
osg::DrawArrays(osg::PrimitiveSet::POINTS,
0, NumPart));
geode-addDrawable(galaxy);
return geode;
}
...
Thank you.
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=10166#10166
Re: [osg-users] Problem of points showing
Lingyun,
I strongly recommend you to read your std::vector implementation's
source code and debug it to understand its behavior.
Vector starts with 0 or room for few elements. When you push_back, it
checks for available space in its internal block. If requested size is
greater than current capacity, vector will want to grow to accomodate
new items. Because it can't realloc, it will allocate a completely new
buffer, which will be greater than or equal to new size (new size is
greater than the current size).
For instance:
std::vectorint v;
// push_back 6 items...
'v' has 6 items. that is, 6 * sizeof(int) memory for storage.
if you want to insert 7th item, vector needs to grow (how much it
grows depends on implementation; e.g. Visual C++'s, Dinkumware's
library says try to grow by 50%), because there is no room to place
7th item.
To perform this operation, library allocates a new block of memory
that can accomodate *at least* 7 items *before* destroying existing
block. Dinkumware's library expands by 50%, so it may grow by 3 items'
size (assuming it had 6 items), which makes new capacity 9 items (6 +
(6 * 0.5)).
This sums up:
6 existing items
9 new size
+--
15 items.
After new block is allocated successfully, vector copies its existing
objects (6 objects) onto new buffer (which can hold 9 items). After
copy succeeds, vector destroys previous buffer (6 items), then you
have a vector whose capacity is sizeof(int) * 9. Until 9th item,
vector will not need to reallocate memory.
2009/4/15 Lingyun Yu lingyun.yu...@gmail.com:
Hi, Ismail,
I don't understand how the expanding happen?
I read all dataset into an array of P, then when it expands? and why?
and what's old array?
On Tue, Apr 14, 2009 at 2:27 PM, Ismail Pazarbasi pazarb...@gmail.com
wrote:
Hi Lingyun,
std::bad_alloc is thrown when operator new cannot allocate memory,
which indicates there is not enough memory. You may reserve your array
before hand, as Paul mentioned, but it may throw as well. This could
reduce, if nothing, copy operations. It may also prevent exception,
because when expanding, std::vector will have two large copies at the
same time. That is:
e.g. old array length was 150
expand by 50
While allocating 200 elements, previous 150 elements will also
be alive/allocated, that requires room for 350 elements in total.
Resize may reduce this cost to 200 only, because vector will not
have to expand afterwards (i.e. during push_back), which requires a
copy operation. Note that C++ standard allocator doesn't do realloc().
Instead, vector will allocate a block of N * sizeof(T) items (or
little more), copy existing block into new one, then free existing
block.
// instantiate vertices normally
vertices = new osg::Vec3Array;
// if number of parts is greater than 1000,
// reserve your items before.
if (NumPart 1000)
{
try
{
vertices-reserve(NumPart);
}
catch (std::bad_alloc e)
{
// handle exception here; log and return error from this function.
// alternatively, you can rethrow here, and catch in caller.
}
}
// wrap your push_back calls in a try-catch block
try
{
vertices-push_back(...);
}
catch (std::exception)
{
}
To be on the safe side, handle your exceptions and wrap your pointers
in a smart pointer class. If an exception is thrown and you
rethrow/return from function, you need to delete your Geode, Group and
other objects. You may get all these for free, if you use a smart
pointer (osg::ref_ptrT, in this case, as osg::Node's destructor is
protected, IIRC, which prevents it to be deleted externally, but
only when its ref count reaches 0).
HTH
Ismail
2009/4/13 Paul Martz pma...@skew-matrix.com:
Hi Lingyun Yu --
You don't have a variable named 'galaxy' defined, so the
addDrawable(galaxy) is suspicious.
I'd so a resize on the vertex and color arrays, rather than a push_back,
for
efficiency reasons.
I don't think numParts100 should cause any problems. OpenGL doesn
not
place an upper limit on the number of primitives you can render with a
single glDrawArrays call.
I don't really see anything that would cause a crash so I guess you
should
use a debugger and look at the call stack, like you would any other
crash.
Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com
+1 303 859 9466
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Sent:
Monday, April 13, 2009 9:27 AM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] Problem of points showing
Hi, everybody,
I met a problem when I want to show huge amount of points, as you can
see
the code below, if my NumPart is 100, no problem, it shows points
properly. But if the NumPart is 200, then it shows a lot of lines.
If
NumPart is even bigger, the program complained like this：Microsoft C
Re: [osg-users] Problem of points showing
Hi Lingyun,
How much memory is installed on your computer? How much of it is
available and which operating system are you using? Do you use page
file/swap?
2009/4/15 Lingyun Yu lingyun.yu...@gmail.com:
And yes,
after I did
if (NumPart 1000)
{
try
{
vertices-reserve(NumPart);
}
catch (std::bad_alloc e)
{
// handle exception here; log and return error from this function.
// alternatively, you can rethrow here, and catch in caller.
}
}
it jumps to catch part.
2009/4/15 Lingyun Yu lingyun.yu...@gmail.com
Hi, Ismail,
I don't understand how the expanding happen?
I read all dataset into an array of P, then when it expands? and why?
and what's old array?
On Tue, Apr 14, 2009 at 2:27 PM, Ismail Pazarbasi pazarb...@gmail.com
wrote:
Hi Lingyun,
std::bad_alloc is thrown when operator new cannot allocate memory,
which indicates there is not enough memory. You may reserve your array
before hand, as Paul mentioned, but it may throw as well. This could
reduce, if nothing, copy operations. It may also prevent exception,
because when expanding, std::vector will have two large copies at the
same time. That is:
e.g. old array length was 150
expand by 50
While allocating 200 elements, previous 150 elements will also
be alive/allocated, that requires room for 350 elements in total.
Resize may reduce this cost to 200 only, because vector will not
have to expand afterwards (i.e. during push_back), which requires a
copy operation. Note that C++ standard allocator doesn't do realloc().
Instead, vector will allocate a block of N * sizeof(T) items (or
little more), copy existing block into new one, then free existing
block.
// instantiate vertices normally
vertices = new osg::Vec3Array;
// if number of parts is greater than 1000,
// reserve your items before.
if (NumPart 1000)
{
try
{
vertices-reserve(NumPart);
}
catch (std::bad_alloc e)
{
// handle exception here; log and return error from this function.
// alternatively, you can rethrow here, and catch in caller.
}
}
// wrap your push_back calls in a try-catch block
try
{
vertices-push_back(...);
}
catch (std::exception)
{
}
To be on the safe side, handle your exceptions and wrap your pointers
in a smart pointer class. If an exception is thrown and you
rethrow/return from function, you need to delete your Geode, Group and
other objects. You may get all these for free, if you use a smart
pointer (osg::ref_ptrT, in this case, as osg::Node's destructor is
protected, IIRC, which prevents it to be deleted externally, but
only when its ref count reaches 0).
HTH
Ismail
2009/4/13 Paul Martz pma...@skew-matrix.com:
Hi Lingyun Yu --
You don't have a variable named 'galaxy' defined, so the
addDrawable(galaxy) is suspicious.
I'd so a resize on the vertex and color arrays, rather than a
push_back, for
efficiency reasons.
I don't think numParts100 should cause any problems. OpenGL doesn
not
place an upper limit on the number of primitives you can render with a
single glDrawArrays call.
I don't really see anything that would cause a crash so I guess you
should
use a debugger and look at the call stack, like you would any other
crash.
Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com
+1 303 859 9466
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Sent:
Monday, April 13, 2009 9:27 AM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] Problem of points showing
Hi, everybody,
I met a problem when I want to show huge amount of points, as you can
see
the code below, if my NumPart is 100, no problem, it shows points
properly. But if the NumPart is 200, then it shows a lot of lines.
If
NumPart is even bigger, the program complained like this：Microsoft C++
exception: std::bad_alloc at memory location 0x0030e898.
I don't know that's because the dataset is too big or not? because
while it
shows not so many points, everything goes well.
By the way, the data in P array are all right.
osg::Geode *makeGalaxy()
{
osg::Geode *geode = new osg::Geode();
osg::Geometry *geometry= new osg::Geometry();
osg::Vec3Array *vertices = new osg::Vec3Array();
osg::Vec4Array *colors = new osg::Vec4Array();
osg::Vec4 ini(1,0.1,0.55,1);
osg::Vec4 fin(0,1,0,1);
for (int i = 1; i = NumPart; i++)
{
vertices-push_back(osg::Vec3(P[i].Pos[0],P[i].Pos[1],P[i].Pos[2]));
colors-push_back(ini+(fin-ini)*(i*1/NumPart));
}
geometry-setVertexArray(vertices);
geometry-setColorArray(colors);
geometry-setColorBinding(osg::Geometry::BIND_PER_VERTEX);
geometry-addPrimitiveSet(new
osg::DrawArrays(osg::PrimitiveSet::POINTS,
0, NumPart));
geode
Re: [osg-users] Problem of points showing
Hi, Ismail,
ok, jey, I really need to read it. thank you very much.
On Wed, Apr 15, 2009 at 4:11 PM, Ismail Pazarbasi pazarb...@gmail.comwrote:
Lingyun,
I strongly recommend you to read your std::vector implementation's
source code and debug it to understand its behavior.
Vector starts with 0 or room for few elements. When you push_back, it
checks for available space in its internal block. If requested size is
greater than current capacity, vector will want to grow to accomodate
new items. Because it can't realloc, it will allocate a completely new
buffer, which will be greater than or equal to new size (new size is
greater than the current size).
For instance:
std::vectorint v;
// push_back 6 items...
'v' has 6 items. that is, 6 * sizeof(int) memory for storage.
if you want to insert 7th item, vector needs to grow (how much it
grows depends on implementation; e.g. Visual C++'s, Dinkumware's
library says try to grow by 50%), because there is no room to place
7th item.
To perform this operation, library allocates a new block of memory
that can accomodate *at least* 7 items *before* destroying existing
block. Dinkumware's library expands by 50%, so it may grow by 3 items'
size (assuming it had 6 items), which makes new capacity 9 items (6 +
(6 * 0.5)).
This sums up:
6 existing items
9 new size
+--
15 items.
After new block is allocated successfully, vector copies its existing
objects (6 objects) onto new buffer (which can hold 9 items). After
copy succeeds, vector destroys previous buffer (6 items), then you
have a vector whose capacity is sizeof(int) * 9. Until 9th item,
vector will not need to reallocate memory.
2009/4/15 Lingyun Yu lingyun.yu...@gmail.com:
Hi, Ismail,
I don't understand how the expanding happen?
I read all dataset into an array of P, then when it expands? and why?
and what's old array?
On Tue, Apr 14, 2009 at 2:27 PM, Ismail Pazarbasi pazarb...@gmail.com
wrote:
Hi Lingyun,
std::bad_alloc is thrown when operator new cannot allocate memory,
which indicates there is not enough memory. You may reserve your array
before hand, as Paul mentioned, but it may throw as well. This could
reduce, if nothing, copy operations. It may also prevent exception,
because when expanding, std::vector will have two large copies at the
same time. That is:
e.g. old array length was 150
expand by 50
While allocating 200 elements, previous 150 elements will also
be alive/allocated, that requires room for 350 elements in total.
Resize may reduce this cost to 200 only, because vector will not
have to expand afterwards (i.e. during push_back), which requires a
copy operation. Note that C++ standard allocator doesn't do realloc().
Instead, vector will allocate a block of N * sizeof(T) items (or
little more), copy existing block into new one, then free existing
block.
// instantiate vertices normally
vertices = new osg::Vec3Array;
// if number of parts is greater than 1000,
// reserve your items before.
if (NumPart 1000)
{
try
{
vertices-reserve(NumPart);
}
catch (std::bad_alloc e)
{
// handle exception here; log and return error from this function.
// alternatively, you can rethrow here, and catch in caller.
}
}
// wrap your push_back calls in a try-catch block
try
{
vertices-push_back(...);
}
catch (std::exception)
{
}
To be on the safe side, handle your exceptions and wrap your pointers
in a smart pointer class. If an exception is thrown and you
rethrow/return from function, you need to delete your Geode, Group and
other objects. You may get all these for free, if you use a smart
pointer (osg::ref_ptrT, in this case, as osg::Node's destructor is
protected, IIRC, which prevents it to be deleted externally, but
only when its ref count reaches 0).
HTH
Ismail
2009/4/13 Paul Martz pma...@skew-matrix.com:
Hi Lingyun Yu --
You don't have a variable named 'galaxy' defined, so the
addDrawable(galaxy) is suspicious.
I'd so a resize on the vertex and color arrays, rather than a
push_back,
for
efficiency reasons.
I don't think numParts100 should cause any problems. OpenGL doesn
not
place an upper limit on the number of primitives you can render with a
single glDrawArrays call.
I don't really see anything that would cause a crash so I guess you
should
use a debugger and look at the call stack, like you would any other
crash.
Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com
+1 303 859 9466
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of
Sent:
Monday, April 13, 2009 9:27 AM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] Problem of points showing
Hi, everybody,
I met a problem
Re: [osg-users] Problem of points showing
vector typically doubles the size of memory it reserves when it needs more space. This is because every time it allocates new memory it must move the contents of the existing memory - it's slow to copy all the existing elements and so it makes sense to only increase as few times as possible (see http://www.ddj.com/cpp/184401375 for a discussion). Unfortunately this isn't a good stratergy when you are almost out of memory. Another problem is that the memory must be contiguous (ie in one block), so if you frequently allocate and delete memory there might not be a single free block large enough - even if you have enough overall memory. There is also a little 'trick' to reduce a vector back down to the minimum required memory - see http://www.gotw.ca/gotw/054.htm Code: vectorstuff( c ).swap( c ); (note - can someone confirm the swap() trick works with ref counting?) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10259#10259 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem of points showing
Thank you very much, Ismail and Martin, I have 3G memory installed. and 1.02G is avaible, I use windows vista. and I didn't use file page file/swap. I will read carefully about both of you suggested. If you have some source can be read for that, please tell me. Yun On Wed, Apr 15, 2009 at 5:10 PM, Martin Beckett m...@mgbeckett.com wrote: vector typically doubles the size of memory it reserves when it needs more space. This is because every time it allocates new memory it must move the contents of the existing memory - it's slow to copy all the existing elements and so it makes sense to only increase as few times as possible (see http://www.ddj.com/cpp/184401375 for a discussion). Unfortunately this isn't a good stratergy when you are almost out of memory. Another problem is that the memory must be contiguous (ie in one block), so if you frequently allocate and delete memory there might not be a single free block large enough - even if you have enough overall memory. There is also a little 'trick' to reduce a vector back down to the minimum required memory - see http://www.gotw.ca/gotw/054.htm Code: vectorstuff( c ).swap( c ); (note - can someone confirm the swap() trick works with ref counting?) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10259#10259 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Cheers, Yun ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem of points showing
no, 2G is avaible I mean On Wed, Apr 15, 2009 at 5:43 PM, Lingyun Yu lingyun.yu...@gmail.com wrote: Thank you very much, Ismail and Martin, I have 3G memory installed. and 1.02G is avaible, I use windows vista. and I didn't use file page file/swap. I will read carefully about both of you suggested. If you have some source can be read for that, please tell me. Yun On Wed, Apr 15, 2009 at 5:10 PM, Martin Beckett m...@mgbeckett.com wrote: vector typically doubles the size of memory it reserves when it needs more space. This is because every time it allocates new memory it must move the contents of the existing memory - it's slow to copy all the existing elements and so it makes sense to only increase as few times as possible (see http://www.ddj.com/cpp/184401375 for a discussion). Unfortunately this isn't a good stratergy when you are almost out of memory. Another problem is that the memory must be contiguous (ie in one block), so if you frequently allocate and delete memory there might not be a single free block large enough - even if you have enough overall memory. There is also a little 'trick' to reduce a vector back down to the minimum required memory - see http://www.gotw.ca/gotw/054.htm Code: vectorstuff( c ).swap( c ); (note - can someone confirm the swap() trick works with ref counting?) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10259#10259 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Cheers, Yun -- Cheers, Yun ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem of points showing
Hi Martin, ISO 14882:2003 (the C++03) standard doesn't clearly specify how containers must swap its contents. It's clearly specified in C++0x drafts. Most implementations simply exchange internal block (pointers) and capacity, if allocators are the same. Otherwise, each element will be copied. ref_ptr can be easily used in either case (latter case being the inefficient/different allocator case), because it satisfies the requirements (from C++03): 25.2.2 Swap [lib.alg.swap] templateclass T void swap(T a, T b); 1 Requires: Type T is CopyConstructible (20.1.3) and Assignable (23.1). 2 Effects: Exchanges values stored in two locations. ref_ptrT is CopyConstructible and Assignable; its copies are equivalent. Ismail On Wed, Apr 15, 2009 at 5:10 PM, Martin Beckett m...@mgbeckett.com wrote: vector typically doubles the size of memory it reserves when it needs more space. This is because every time it allocates new memory it must move the contents of the existing memory - it's slow to copy all the existing elements and so it makes sense to only increase as few times as possible (see http://www.ddj.com/cpp/184401375 for a discussion). Unfortunately this isn't a good stratergy when you are almost out of memory. Another problem is that the memory must be contiguous (ie in one block), so if you frequently allocate and delete memory there might not be a single free block large enough - even if you have enough overall memory. There is also a little 'trick' to reduce a vector back down to the minimum required memory - see http://www.gotw.ca/gotw/054.htm Code: vectorstuff( c ).swap( c ); (note - can someone confirm the swap() trick works with ref counting?) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10259#10259 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem of points showing
Hi Lingyun,
std::bad_alloc is thrown when operator new cannot allocate memory,
which indicates there is not enough memory. You may reserve your array
before hand, as Paul mentioned, but it may throw as well. This could
reduce, if nothing, copy operations. It may also prevent exception,
because when expanding, std::vector will have two large copies at the
same time. That is:
e.g. old array length was 150
expand by 50
While allocating 200 elements, previous 150 elements will also
be alive/allocated, that requires room for 350 elements in total.
Resize may reduce this cost to 200 only, because vector will not
have to expand afterwards (i.e. during push_back), which requires a
copy operation. Note that C++ standard allocator doesn't do realloc().
Instead, vector will allocate a block of N * sizeof(T) items (or
little more), copy existing block into new one, then free existing
block.
// instantiate vertices normally
vertices = new osg::Vec3Array;
// if number of parts is greater than 1000,
// reserve your items before.
if (NumPart 1000)
{
try
{
vertices-reserve(NumPart);
}
catch (std::bad_alloc e)
{
// handle exception here; log and return error from this function.
// alternatively, you can rethrow here, and catch in caller.
}
}
// wrap your push_back calls in a try-catch block
try
{
vertices-push_back(...);
}
catch (std::exception)
{
}
To be on the safe side, handle your exceptions and wrap your pointers
in a smart pointer class. If an exception is thrown and you
rethrow/return from function, you need to delete your Geode, Group and
other objects. You may get all these for free, if you use a smart
pointer (osg::ref_ptrT, in this case, as osg::Node's destructor is
protected, IIRC, which prevents it to be deleted externally, but
only when its ref count reaches 0).
HTH
Ismail
2009/4/13 Paul Martz pma...@skew-matrix.com:
Hi Lingyun Yu --
You don't have a variable named 'galaxy' defined, so the
addDrawable(galaxy) is suspicious.
I'd so a resize on the vertex and color arrays, rather than a push_back, for
efficiency reasons.
I don't think numParts100 should cause any problems. OpenGL doesn not
place an upper limit on the number of primitives you can render with a
single glDrawArrays call.
I don't really see anything that would cause a crash so I guess you should
use a debugger and look at the call stack, like you would any other crash.
Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com
+1 303 859 9466
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Sent:
Monday, April 13, 2009 9:27 AM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] Problem of points showing
Hi, everybody,
I met a problem when I want to show huge amount of points, as you can see
the code below, if my NumPart is 100, no problem, it shows points
properly. But if the NumPart is 200, then it shows a lot of lines. If
NumPart is even bigger, the program complained like this：Microsoft C++
exception: std::bad_alloc at memory location 0x0030e898.
I don't know that's because the dataset is too big or not? because while it
shows not so many points, everything goes well.
By the way, the data in P array are all right.
osg::Geode *makeGalaxy()
{
osg::Geode *geode = new osg::Geode();
osg::Geometry *geometry= new osg::Geometry();
osg::Vec3Array *vertices = new osg::Vec3Array();
osg::Vec4Array *colors = new osg::Vec4Array();
osg::Vec4 ini(1,0.1,0.55,1);
osg::Vec4 fin(0,1,0,1);
for (int i = 1; i = NumPart; i++)
{
vertices-push_back(osg::Vec3(P[i].Pos[0],P[i].Pos[1],P[i].Pos[2]));
colors-push_back(ini+(fin-ini)*(i*1/NumPart));
}
geometry-setVertexArray(vertices);
geometry-setColorArray(colors);
geometry-setColorBinding(osg::Geometry::BIND_PER_VERTEX);
geometry-addPrimitiveSet(new osg::DrawArrays(osg::PrimitiveSet::POINTS,
0, NumPart));
geode-addDrawable(galaxy);
return geode;
}
...
Thank you.
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=10166#10166
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem of points showing
Thank you, Paul and Ismail!
I will try Ismail's solution, and will tell you the result.
On Tue, Apr 14, 2009 at 2:27 PM, Ismail Pazarbasi pazarb...@gmail.comwrote:
Hi Lingyun,
std::bad_alloc is thrown when operator new cannot allocate memory,
which indicates there is not enough memory. You may reserve your array
before hand, as Paul mentioned, but it may throw as well. This could
reduce, if nothing, copy operations. It may also prevent exception,
because when expanding, std::vector will have two large copies at the
same time. That is:
e.g. old array length was 150
expand by 50
While allocating 200 elements, previous 150 elements will also
be alive/allocated, that requires room for 350 elements in total.
Resize may reduce this cost to 200 only, because vector will not
have to expand afterwards (i.e. during push_back), which requires a
copy operation. Note that C++ standard allocator doesn't do realloc().
Instead, vector will allocate a block of N * sizeof(T) items (or
little more), copy existing block into new one, then free existing
block.
// instantiate vertices normally
vertices = new osg::Vec3Array;
// if number of parts is greater than 1000,
// reserve your items before.
if (NumPart 1000)
{
try
{
vertices-reserve(NumPart);
}
catch (std::bad_alloc e)
{
// handle exception here; log and return error from this function.
// alternatively, you can rethrow here, and catch in caller.
}
}
// wrap your push_back calls in a try-catch block
try
{
vertices-push_back(...);
}
catch (std::exception)
{
}
To be on the safe side, handle your exceptions and wrap your pointers
in a smart pointer class. If an exception is thrown and you
rethrow/return from function, you need to delete your Geode, Group and
other objects. You may get all these for free, if you use a smart
pointer (osg::ref_ptrT, in this case, as osg::Node's destructor is
protected, IIRC, which prevents it to be deleted externally, but
only when its ref count reaches 0).
HTH
Ismail
2009/4/13 Paul Martz pma...@skew-matrix.com:
Hi Lingyun Yu --
You don't have a variable named 'galaxy' defined, so the
addDrawable(galaxy) is suspicious.
I'd so a resize on the vertex and color arrays, rather than a push_back,
for
efficiency reasons.
I don't think numParts100 should cause any problems. OpenGL doesn
not
place an upper limit on the number of primitives you can render with a
single glDrawArrays call.
I don't really see anything that would cause a crash so I guess you
should
use a debugger and look at the call stack, like you would any other
crash.
Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com
+1 303 859 9466
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Sent:
Monday, April 13, 2009 9:27 AM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] Problem of points showing
Hi, everybody,
I met a problem when I want to show huge amount of points, as you can see
the code below, if my NumPart is 100, no problem, it shows points
properly. But if the NumPart is 200, then it shows a lot of lines. If
NumPart is even bigger, the program complained like this：Microsoft C++
exception: std::bad_alloc at memory location 0x0030e898.
I don't know that's because the dataset is too big or not? because while
it
shows not so many points, everything goes well.
By the way, the data in P array are all right.
osg::Geode *makeGalaxy()
{
osg::Geode *geode = new osg::Geode();
osg::Geometry *geometry= new osg::Geometry();
osg::Vec3Array *vertices = new osg::Vec3Array();
osg::Vec4Array *colors = new osg::Vec4Array();
osg::Vec4 ini(1,0.1,0.55,1);
osg::Vec4 fin(0,1,0,1);
for (int i = 1; i = NumPart; i++)
{
vertices-push_back(osg::Vec3(P[i].Pos[0],P[i].Pos[1],P[i].Pos[2]));
colors-push_back(ini+(fin-ini)*(i*1/NumPart));
}
geometry-setVertexArray(vertices);
geometry-setColorArray(colors);
geometry-setColorBinding(osg::Geometry::BIND_PER_VERTEX);
geometry-addPrimitiveSet(new
osg::DrawArrays(osg::PrimitiveSet::POINTS,
0, NumPart));
geode-addDrawable(galaxy);
return geode;
}
...
Thank you.
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=10166#10166
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg
Re: [osg-users] Problem of points showing
The c++ standard also requires that the memory for vector is contiguous like a C array. You can try reserving the memory soon after program start and keep the array around until you load the data, the memory has the least chance of being fragmented before anything else is allocated. You can also split the data into smaller blocks and attach multiple geometries to the same geode - the 3dc plugin does this to limit the blocks to 10,000 points -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10201#10201 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem of points showing
Thanks Martin, yes, this is also a solution. thank you very much. Yun On Tue, Apr 14, 2009 at 4:04 PM, Martin Beckett m...@mgbeckett.com wrote: The c++ standard also requires that the memory for vector is contiguous like a C array. You can try reserving the memory soon after program start and keep the array around until you load the data, the memory has the least chance of being fragmented before anything else is allocated. You can also split the data into smaller blocks and attach multiple geometries to the same geode - the 3dc plugin does this to limit the blocks to 10,000 points -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=10201#10201 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Cheers, Yun ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Problem of points showing
Hi, everybody,
I met a problem when I want to show huge amount of points, as you can see the
code below, if my NumPart is 100, no problem, it shows points properly. But
if the NumPart is 200, then it shows a lot of lines. If NumPart is even
bigger, the program complained like this：Microsoft C++ exception:
std::bad_alloc at memory location 0x0030e898.
I don't know that's because the dataset is too big or not? because while it
shows not so many points, everything goes well.
By the way, the data in P array are all right.
osg::Geode *makeGalaxy()
{
osg::Geode *geode = new osg::Geode();
osg::Geometry *geometry= new osg::Geometry();
osg::Vec3Array *vertices = new osg::Vec3Array();
osg::Vec4Array *colors = new osg::Vec4Array();
osg::Vec4 ini(1,0.1,0.55,1);
osg::Vec4 fin(0,1,0,1);
for (int i = 1; i = NumPart; i++)
{
vertices-push_back(osg::Vec3(P[i].Pos[0],P[i].Pos[1],P[i].Pos[2]));
colors-push_back(ini+(fin-ini)*(i*1/NumPart));
}
geometry-setVertexArray(vertices);
geometry-setColorArray(colors);
geometry-setColorBinding(osg::Geometry::BIND_PER_VERTEX);
geometry-addPrimitiveSet(new osg::DrawArrays(osg::PrimitiveSet::POINTS, 0,
NumPart));
geode-addDrawable(galaxy);
return geode;
}
...
Thank you.
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=10166#10166
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem of points showing
Hi Lingyun Yu --
You don't have a variable named 'galaxy' defined, so the
addDrawable(galaxy) is suspicious.
I'd so a resize on the vertex and color arrays, rather than a push_back, for
efficiency reasons.
I don't think numParts100 should cause any problems. OpenGL doesn not
place an upper limit on the number of primitives you can render with a
single glDrawArrays call.
I don't really see anything that would cause a crash so I guess you should
use a debugger and look at the call stack, like you would any other crash.
Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com http://www.skew-matrix.com/
+1 303 859 9466
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org [
mailto:osg-users-boun...@lists.openscenegraph.org
mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Sent:
Monday, April 13, 2009 9:27 AM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] Problem of points showing
Hi, everybody,
I met a problem when I want to show huge amount of points, as you can see
the code below, if my NumPart is 100, no problem, it shows points
properly. But if the NumPart is 200, then it shows a lot of lines. If
NumPart is even bigger, the program complained like this：Microsoft C++
exception: std::bad_alloc at memory location 0x0030e898.
I don't know that's because the dataset is too big or not? because while it
shows not so many points, everything goes well.
By the way, the data in P array are all right.
osg::Geode *makeGalaxy()
{
osg::Geode *geode = new osg::Geode();
osg::Geometry *geometry= new osg::Geometry();
osg::Vec3Array *vertices = new osg::Vec3Array();
osg::Vec4Array *colors = new osg::Vec4Array();
osg::Vec4 ini(1,0.1,0.55,1);
osg::Vec4 fin(0,1,0,1);
for (int i = 1; i = NumPart; i++)
{
vertices-push_back(osg::Vec3(P[i].Pos[0],P[i].Pos[1],P[i].Pos[2]));
colors-push_back(ini+(fin-ini)*(i*1/NumPart));
}
geometry-setVertexArray(vertices);
geometry-setColorArray(colors);
geometry-setColorBinding(osg::Geometry::BIND_PER_VERTEX);
geometry-addPrimitiveSet(new osg::DrawArrays(osg::PrimitiveSet::POINTS,
0, NumPart));
geode-addDrawable(galaxy);
return geode;
}
...
Thank you.
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=10166#10166 http://forum.
openscenegraph.org/viewtopic.php?p=10166#10166
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
