On 04/13/2017 02:43 PM, Igor Mironchik wrote:
13.04.2017 20:36, Sean Harmer пишет:
On 13/04/2017 16:31, Igor Mironchik wrote:
Hi,
13.04.2017 17:55, Igor Mironchik пишет:
Am I right that QEntity doesn't delete its children on destruction and
just removes them from scene?
I asked this in context of QEntity::addComponent()...
Seems that entity doesn't delete anything. And documentation is unclear
in it:
voidQEntity::addComponent(QComponent <qt3dcore-qcomponent.html>*comp)
Adds a new reference to the component comp.
Note: If the Qt3DCore::QComponent <qt3dcore-qcomponent.html> has no
parent, the Qt3DCore::QEntity <qt3dcore-qentity.html> will set itself as
its parent thereby taking ownership of the component.
As I can guess it doesn't take ownership. Because of it I have few leaks
at exit but not in restart of tree...
The entity takes ownership of any components that are parentless when added.
This is done using the usual QObject ownership mechanism so the components
will be deleted by the entity when it is being destroyed just like any other
QObject parent. There may be a leaks elsewhere but I don't think this is it.
There were some leaks related to VAOs fixed around the time of the 5.8.0
release. I can't recall if they made it into 5.8.0 or not off the top of my
head. Please try with a build from the 5.9 branch in git.
Yes, you are right. QEntity really deletes all children. I checked it.
Then I have no idea what it can be. Every restart of the 5 years tree loses ~30
- 40 MB of memory.
You could use a "memory-in-use" analysis tool.
Contact UNICOM. Get an evaluation copy of Purify(Plus). :-)
1 - Call purify_clear_inuse().
2 - Do your thing.
3 - Call purify_new_inuse().
4 - Study the report and see who allocated memory.
Bill
Cheers,
Sean
Are those numbers for Linux or Windows?
13.04.2017 15:39, william.croc...@analog.com пишет:
On 04/13/2017 08:34 AM, Igor Mironchik wrote:
Hi,
Strange, I launch 3Dtree on Linux under valgrind:
==4321== HEAP SUMMARY:
==4321== in use at exit: 439,965 bytes in 6,185 blocks
==4321== total heap usage: 2,207,719 allocs, 2,201,534 frees,
1,241,469,509
bytes allocated
==4321==
==4321== LEAK SUMMARY:
==4321== definitely lost: 1,080 bytes in 10 blocks
==4321== indirectly lost: 7,609 bytes in 55 blocks
==4321== possibly lost: 416 bytes in 1 blocks
==4321== still reachable: 430,860 bytes in 6,119 blocks
==4321== suppressed: 0 bytes in 0 blocks
Check the virtual image size on Linux,
just to make sure it is not growing as well.
That is the bottom line.
But on my Windows OS after each restart of tree I receive plus
~100MB additional
memory.
As I can see this memory still reachable. But why 3Dtree allocates
more and more
memory and doesn't use freed one?
13.04.2017 9:58, Sean Harmer пишет:
Hi,
On 13/04/2017 07:09, Igor Mironchik wrote:
Hello,
3Dtree has been updated. Now autumn is animated. Removed hand-made
classes of leaf geometry and mesh. Now example uses ready mesh
prepared
in Blender. Modified a little constants of the tree. Example
looks nice.
This is a benchmark of your video card, because leafs and
branches are
stand alone objects (QEntity). For example 5 years tree has ~ 900
objects. My Intel Pentium with Intel HD graphics normally paint
only 5
years tree, 6 years tree starts to slow down.
Yes, at present each entity with a material/geometry renderer
combo gets
translated to an OpenGL draw call. We are looking to add batching
(similar to
how Qt Quick 2 works) but it's not there yet.
If you don't need to address each individual leaf/branch in your
object model.
E.g. if you're just rendering them, then you can get *much*
better performance
by using instanced rendering.
Essentially you have one entity representing all leaves. This
entity contains
the material and geometry renderer as normal. The positions and
any other
custom properties that vary between instances (rotation, leaf
size, leaf
colour etc) should be placed into an additional attribute/buffer
and provided
to the geometry renderer. On this attribute, set the divisor
property to 1
meaning that 1 piece of data maps to 1 instance of the leave in
the scene.
With this approach you will be able to render 10,000's leaves in
a single draw
call. It maps through to a call to glDrawElementsInstanced() in
case you want
to read up on it. Essentially you're moving the for loop over
each leaf on to
the GPU.
Typically, you'd have your data for the leaves in an array in C++
and use this
to populate the leaf instance buffer.
The plan is to have a batcher that uses this instancing facility.
Cheers,
Sean
And one more - now you can rotate the tree with the left mouse
button.
11.04.2017 12:15, Igor Mironchik пишет:
Hi,
I fixed a little 3Dtree. Now branches positions are correct. And I
know that not all leafs is visible (this is because leaf
geometry is
implemented as plain which renders only on one side).
10.04.2017 13:20, Igor Mironchik пишет:
Hello,
I guess that Qt3D has huge memory leaks.
You can check it on this example:
https://github.com/igormironchik/3Dtree
It's 3D tree, that grows year by year.
By default tree will grow 5 years (5 minutes).
When tree grown you can restart tree. And here I delete all
resources:
void
MainWindowPrivate::createTree()
{
if(m_tree)
{
for(constauto&e:m_rootEntity->childNodes())
e->deleteLater();
}
m_tree=newBranch(m_startPos,m_endPos,c_startBranchRadius,
true,m_rootEntity);
m_tree->setAge(0.0f);
m_tree->updatePosition();
m_tree->placeLeafs();
}
But a lot of memory are eaten.
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
