I am working with the method, findUnit(), within the class Processor and I have come across something very strange:
In the program, osgppu.cpp using the header hdrppu.h, I do the following in osgppu.cpp/Viewer::initialize():

findUnit() in both cases returns NULL or 0 but I know for a fact that the firstUnit is the "HDRBypass" Unit or UnitBypass with the name "HDRBypass".
However, when I issue this same findUnit command for this same unit within the KeyboardEventHandler::handle() method, it works. Here is my code snippet:

the problem in the first case, is that the unit graph is still not correctly initialised before you call findUnit. When keyboard event handle runs, there is already an update/init call on the unit graph which initialize the whole pipeline.

I could take a look in that, you are right. So that next time nobody get confused about the method. One just have to write a visitor which is able to find a unit also in an unitialized graph.

As simple workaround would be to use osg's internal find node methods (I am pretty sure there must be such) and to look for a node with the given name. Units are derived from nodes, hence it should work in that way too.

Aaaaaah, I understand. I was hoping I was missing something obvious and something simple.

In OSG there is a "node" visitor find type thing one can do. Below is some example code I found. I have not implemented this code and I hope to find an even easier method.

I agree, though, I should be able to search osg's node tree. But you brought up a very good point I was totally unaware of: the pipeline is not completely instantiated until runtime.

What I was attempting to do was to change a shader value that is sent into my blur shader (the blur shader I got from your examples ) and now I have learned that I must change that blur shader variable at runtime because the pipeline is not fully allocated until then. That is very good to know.

// check to see if we have a valid (non-NULL) node.
// if we do have a null node, return NULL.
if ( !currNode)
{
return NULL;
}

// We have a valid node, check to see if this is the node we
// are looking for. If so, return the current node.
if (currNode->getName() == searchName)
{
return currNode;
}

// We have a valid node, but not the one we are looking for.
// Check to see if it has children (non-leaf node). If the node
// has children, check each of the child nodes by recursive call.
// If one of the recursive calls returns a non-null value we have
// found the correct node, so return this node.
// If we check all of the children and have not found the node,
// return NULL
currGroup = currNode->asGroup(); // returns NULL if not a group.
if ( currGroup )
{
for (unsigned int i = 0 ; i < currGroup->getNumChildren(); i ++)
{
foundNode = findNamedNode(searchName, currGroup->getChild(i));
if (foundNode)
return foundNode; // found a match!
}
return NULL; // We have checked each child node - no match found.
}
else
{
return NULL; // leaf node, no match
}
}

I just corrected the findUnit method to also find units on unitialized pipelines, however I haven't submited it yet, since I want to correct another bug first. You should always use the processor's findUnit method, because in the osgPPU pipeline graph there might be potentially loops (see motion blur or hdr example). So using osg's find node method it might not terminate. After the unit pipeline is initialized the loops are resolved and hence afterwards a simple node visitor should be also able to find any unit.

The bug you encounter is not a bug. There was an API change in osg main core from 2.8.1 to 2.8.2 I think. Current svn version of osgPPU is working only with osg version greater than 2.8.2, I think. At least it works with the current osg svn version.

I have already update the svn repository and solved the findUnit issue.

allensaucier wrote:

I understand the term, initialize, means when the application is running and not after the line of code: osgPPU::Processor *processor = new osgPPU::Processor();
Am I correct?

Yes, when there was a first call of Processor::traverse method with an UpdateVisitor. This usually happens when first frame is drawn, so after main application rendering loop is started (osgViewer::run() )

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou cannot download files in this forum