Jeremy Friesner (jfriesne++at++sdchemw1.ucsd.edu)
Sun, 15 Sep 96 20:15:04
With some good advice from a certain Timothy Moore,
I finally got the asychronous scenery paging to work.
Tim suggested that I forward our emails on the subject
to this mailing list, so here they are!
-Jeremy :)
Date: Sat, 14 Sep 1996 04:05:35 GMT
From: jaf (Jeremy Friesner)
Message-Id: <199609140405.EAA13035++at++large.ucsd.edu>
Apparently-To: info-performer++at++sgi.com
X-Status: OR
Hi All,
We finally got our RE2 Onyx upgraded to IRIX6.2 and Performer 2.0.2, so
once again I'm trying to get scenery paging from the DBASE process to
work, via pfBuffer's and merge().
I can create objects in the DBASE process, in a separater pfBuffer,
and merge them into the main buffer, that works fine.
But--what I want to do is create a "library pfBuffer", in which
I keep reference copies of common objects, and then page in instances
of the copies as necessary.
In my setup, I have two pfBuffers (besides the default/main pfBuffer),
one that holds the "library" objects, and one paging pfBuffer to hold
objects that are about to be merged in to the main pfBuffer.
The pfBuffer man page gives two example techniques for library
paging. The second one, using bufferClone(), seems useless,
as bufferClone() still crashes whenever I try to use it to clone
across pfBuffers.
The first example, using bufferAddChild(), is the one I am trying
to get working. My problem is, after the merge() call, the main
pfBuffer contains all the nodes that were created in the paging
pfBuffer, but it does not contain any of the scenery that was
bufferAddChild()'d from the library pfBuffer.
My code is essentially the same as their example (which I'll
include at the bottom for reference), so does anyone know what
might be going on here? Or perhaps someone can show me some
example code of a working library-paging system?
Thanks in advance,
Jeremy
------pfBuffer example below-----------
libraryBuffer = new pfBuffer;
libraryBuffer->select();
loadLibraryObjects();
pagingBuffer = new pfBuffer;
pagingBuffer->select();
while (!done)
{
pfNode *newStuff;
pfSCS *treeLocation;
/* Load new terrain tile or whatever */
newStuff = loadStuff();
/* Create pfSCS which is location of tree */
treeLocation = new pfSCS(treeMatrix);
/* Add library model of a tree to treeLocation */
treeLocation->bufferAddChild(libraryTree); // libraryTree is in libraryBuffer?
// if so, how is it merged into the
// main pfBuffer if we only select()
// and merge on the pagingBuffer?
// does bufferAddChild() make a copy of it?
/* Add instanced tree to newly loaded stuff */
newStuff->addChild(treeLocation);
}
=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
Submissions: info-performer++at++sgi.com
Admin. requests: info-performer-request++at++sgi.com
From: Timothy Moore <moore++at++WOLFENET.com>
Received: (from moore++at++localhost) by gonzo.wolfenet.com (8.7/8.7) id NAA08908; Sat, 14 Sep 1996 13:37:16 -0700 (PDT)
Date: Sat, 14 Sep 1996 13:37:16 -0700 (PDT)
Message-Id: <199609142037.NAA08908++at++gonzo.wolfenet.com>
To: jaf
In-Reply-To: Jeremy Friesner's message of Sat, 14 Sep 1996 04:05:35 GMT <199609140405.EAA13035++at++large.ucsd.edu>
X-Status: ORA
Date: Sat, 14 Sep 1996 04:05:35 GMT
From: jaf++at++chem.ucsd.edu (Jeremy Friesner)
Apparently-To: info-performer++at++sgi.com
I can create objects in the DBASE process, in a separater pfBuffer,
and merge them into the main buffer, that works fine.
And that's the major part of the battle, in my experience.
But--what I want to do is create a "library pfBuffer", in which
I keep reference copies of common objects, and then page in instances
of the copies as necessary.
In my setup, I have two pfBuffers (besides the default/main pfBuffer),
one that holds the "library" objects, and one paging pfBuffer to hold
objects that are about to be merged in to the main pfBuffer.
The pfBuffer man page gives two example techniques for library
paging. The second one, using bufferClone(), seems useless,
as bufferClone() still crashes whenever I try to use it to clone
across pfBuffers.
But if you don't do pfBufferClone () (I'll use the C notation, because
that's what I used in my pager) on things that are in your library
buffer, then they get merged into the main buffer by pfMergeBuffers
(). There's little point in keeping a seperate library buffer, then;
all the library objects might as well be in the main buffer from the
getgo. Or you do the buffer clone thing. I chose to keep all library
objects in the main buffer (they're actually loaded by the App process
on initialization) and add them to terrain patches using
pfBufferAddChild ().
It's best not to think of the buffers as seperate address spaces;
they're not. Rather, the buffers are a mutual exclusion mechanism
such that you are only allowed to modify pfNodes that are in the
buffer that is current. pfMergeBuffers () doesn't do much more than
execute all the deferred pfBufferAdds and Deletes and make the main
buffer consistant with adds and deletes done other buffers. I think
that actively trying to keep objects alive in other buffers across
calls to pfMergeBuffers () is an uphill battle and bound to be buggy.
Tim
From: Timothy Moore <moore++at++WOLFENET.com>
Received: (from moore++at++localhost) by gonzo.wolfenet.com (8.7/8.7) id MAA31436; Sun, 15 Sep 1996 12:10:57 -0700 (PDT)
Date: Sun, 15 Sep 1996 12:10:57 -0700 (PDT)
Message-Id: <199609151910.MAA31436++at++gonzo.wolfenet.com>
To: jfriesne++at++UCSD.EDU
In-Reply-To: Jeremy Friesner's message of Sat, 14 Sep 96 21:28:09
Subject: Re: your mail
X-Status: O
Reply-To: jfriesne++at++UCSD.EDU
From: jfriesne++at++sdchemw1.ucsd.edu (Jeremy Friesner)
Hi Timothy,
> And that's the major part of the battle, in my experience.
At least under Performer 2.0 it was! ;)
Under 2.0.1 also. I haven't found a case yet where the buffer
functions didn't work as advertised, but Performer is very vulnerable
to small mistakes in using them. If you inadvertently do a pfAddChild
or pfDeleteChild on a node that is not in the current buffer (parent
or child) then you can apparently corrupt the node. The failure mode
is that you get a segmentation violation with the program counter way
off in the weeds: in the zero page or some other weird place. Very
frustrating.
> But if you don't do pfBufferClone () (I'll use the C notation, because
> that's what I used in my pager) on things that are in your library
> buffer, then they get merged into the main buffer by pfMergeBuffers
> (). There's little point in keeping a seperate library buffer, then;
> all the library objects might as well be in the main buffer from the
> getgo.
I see your point. Do you know any tricks to get bufferClone() to
work? Every time I call it with a pointer to a pfNode that is not
in the currently selected pfBuffer, it dumps core. :( This happens
even in "trivial" test cases. It works fine if the source pfNode is in
the current pfBuffer, but in that case I could just use regular clone().
I haven't used pfBufferClone (). Are you modifying the source node or
its children before you call pfMergeBuffers ()? Calling pfDelete ()
(not pfAsyncDelete ()) on the node would certainly be a bad thing...
> Or you do the buffer clone thing. I chose to keep all library
> objects in the main buffer (they're actually loaded by the App process
> on initialization) and add them to terrain patches using
> pfBufferAddChild ().
I may end up doing this, although it doesn't seem as intuitive to me.
This stuff isn't particularly intuitive :)
> It's best not to think of the buffers as seperate address spaces;
> they're not. Rather, the buffers are a mutual exclusion mechanism
> such that you are only allowed to modify pfNodes that are in the
> buffer that is current. pfMergeBuffers () doesn't do much more than
> execute all the deferred pfBufferAdds and Deletes and make the main
> buffer consistant with adds and deletes done other buffers. I think
> that actively trying to keep objects alive in other buffers across
> calls to pfMergeBuffers () is an uphill battle and bound to be buggy.
Does merge() only change the state of the currently selected pfBuffer?
Or, if a node from another pfBuffer is bufferAddChild'd into the currently
selected pfBuffer, will that node be moved from its pfBuffer into the main
pfBuffer as well?
I'm not at work, so I can't look at the man pages. Is merge the same
as pfMergeBuffers (), as far as you can tell? pfMergeBuffers makes
the main buffer consistant with all the pfBufferAdds and
pfBufferRemoves that involve nodes in the main buffer. It at least
moves all nodes in those requests into the main buffer (and all their
children too, I think). Maybe it can't transitively merge nodes from
more than one buffer e.g., you've added a node from your library buffer to
node in the terrain buffer, and then add that node to the main buffer.
If you don't want to use pfBufferClone() for library nodes, remember
to pfRef them if you're keeping them in a table; otherwise they'll get
deleted out from under you when the terrain patch gets deleted (if you
don't clean that node yourself).
Hope this helps... we should probably forward some of this exchange
to info-performer.
Tim
From: Timothy Moore <moore++at++WOLFENET.com>
Received: (from moore++at++localhost) by gonzo.wolfenet.com (8.7/8.7) id RAA21982; Sun, 15 Sep 1996 17:29:20 -0700 (PDT)
Date: Sun, 15 Sep 1996 17:29:20 -0700 (PDT)
Message-Id: <199609160029.RAA21982++at++gonzo.wolfenet.com>
To: jaf
In-Reply-To: Jeremy Friesner's message of Sun, 15 Sep 1996 15:40:37 -0700 (PDT) <199609152240.WAA04489++at++sdchemw1.ucsd.edu>
Subject: Re: your mail
X-Status: O
From: jaf++at++chem.ucsd.edu (Jeremy Friesner)
Date: Sun, 15 Sep 1996 15:40:37 -0700 (PDT)
Anyway, I changed my scheme to work like how you said yours
does--keeping the all the "library" objects in the main pfBuffer
and doing bufferAddChild()'s in the paging buffer when I want to
add new scenery. And guess what, it works great! :) :) Thanks
for all your help. (Of course, it seems to have mysteriously
broken our Flybox controller code, but I think some other factor
is at work there ;))
Cool! Glad to help.
> If you don't want to use pfBufferClone() for library nodes, remember
> to pfRef them if you're keeping them in a table; otherwise they'll get
> deleted out from under you when the terrain patch gets deleted (if you
> don't clean that node yourself).
Okay, I put the pfRef() call in, but the weird thing is that
the page-out mechanism seemed to be working okay even without this
call!
Without the pfRef() call, after I loaded the library object,
getRef() returned 0. With it, it returns 1. However, I could
pfDelete old scenery and the new scenery would still come in
fine (if the library objects were being pfDeleted() you'd think
the new scenery would be referencing dangling pointers, leading
to crash city). Weird. I guess I won't complain though. :)
Maybe you always had one instance of each library object still in the
scene graph somewhere. By the way, I don't know how you're loading
pfTextures and pfMaterials, but the same advice applys to them too.
> Hope this helps... we should probably forward some of this exchange
> to info-performer.
Would you like to do that, or shall I?
You should, because I haven't saved any of my messages to you :)
Tim
---------- end exchange! ---------------
Jeremy Friesner | Sorry, no clever quotation today.
jfriesne++at++ucsd.edu | Random .sig generator works, tho!
=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
Submissions: info-performer++at++sgi.com
Admin. requests: info-performer-request++at++sgi.com
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:53:32 PDT