Hi Johan,

On Mon, 2005-05-02 at 18:54 +0200, Johan Grafstrom wrote:
> 
> We are using OpenSG to visualize a large model on Windows. The model
> takes about 1 GB of memory.  The model may take a while to render
> (depending of how much of it is currently visible). To keep the user
> interface responsive, rendering is therefor done in a separate thread.
> 
> The GUI-thread reads and writes the scenegraph, so we need the two
> aspects. However since there is a lot of data in the scenegraph, we
> cannot simply double its size. When the second thread starts (and the
> first changeList->applyAndClear() is called) the program locks for a
> while and the memory usage doubles, usually crashing due to memory (or
> rather, address space) overflow.

I don't think that's related to the aspects, see below.

> What happens is probably:
> 
> * The nodes and cores are created with aspects when scenegraph is read
>    from file. The data fields is initially empty.
> 
> * During reading, the geometry data (vertices etc) is assigned to the
>    current aspect data fields of the the nodes. The fields is added to
>    the changelist.
> 
> * When applyAndClear is called the first time all geometry data is
>    copied to fill the aspect of the second thread, thus consuming lots
>    of memory.

Unless there is a bug that shouldn't happen. The applyAndClear() for
MultiFields only creates a new reference to the same data, so no new
memory should be allocated.

> Some possible solutions to the problem:
> 
> A Using only one aspect and make sure only one thread at a time can
>    access the scenegraph.  We will need to be able to interrupt the
>    rendering in order to keep the application responsive (eg by calling
>    renderAction->setTravMask(0))

Well, you can run mutiple threads and a single aspect, as long as you're
careful about changing things synchronized.
 
> B Change OpenSG so that number of aspects may be set per
>    FieldContainer or FieldContainerType. Ensuring that the geometry
>    nodes (and their data) data (which is static in our application)
>    has only one aspect would solve our problem.

That would be a pretty serious issue. Right now the ChangeList manager
can just copy the data around, but what is it supposed to do, if there
is no copy of the node in the aspect it's supposed to copy to?

> Alternative B would be the "nicest" solution of these, if it is'nt too
> much work.

I don't see that happening, it's a very big change with lots of
undefined problems in my mind right now.

> Questions:
> 
> * Are there some other, better, solutions?

As I said, unless there is a bug this is not really the problem.

My guess is that the memory is consumed during the first rendering
(could you confirm that by putting a pause after the sync and before the
first render?). By default OpenSG uses Display Lists to speed up
rendering, and those take about the same amount of memory as the
geometry (somewhat more, actually). So unless you've switched them off,
that's going to be an issue. You can switch them off individually using
geocore->setDlistCache(false); or globally by calling

    FieldContainerPtr pProto = Geometry::getClassType().getPrototype();

    GeometryPtr pGeoProto = GeometryPtr::dcast(pProto);

    if(pGeoProto != NullFC)
    {
        pGeoProto->setDlistCache(false);
    }

before you start loading.

Please try that, it should at least relieve the memory pressure.

> * Otherwise, how difficult would it be to fix B above, e g by making
>    getNumAspects() a method of FieldContainer or FieldContainerType? If
>    we did, would you accept it into the OpenSG project?

I'd be hard pressed to do that, as it will involve serious changes
throughout the whole system to make this work reliably. I really hope
the abovementioned changes fix your problem. ;)

> Sorry if the mail got uneccessarily lengthy...

No problem, I prefer longer and detailed mails to the "My program
doesn't work. How do I fix it?" ones.

Yours

        Dirk


-- 
-- Dirk Reiners               OpenSG Forum             [EMAIL PROTECTED] 
-- The OpenSG Open Source Scenegraph:            http://www.opensg.org
-- Join the list at    http://lists.sf.net/lists/listinfo/opensg-users



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users

Reply via email to