Thank you very much for your answers, they were pretty useful!
>
> Hello,
> On Thu, 2011-09-22 at 14:56 +0200, Christian Bar wrote:
> > Hello everyone!
> > After a long time spent thinking about porting my OpenSG 1.8 application to
> > OpenSG 2.0, I decided to give it a try, mainly due to OSG2 new features like
> > stage rendering, animations, no beginEdit/endEdit, ...
> > Now I'll explain what I did, because a number of problems still remain (I'll
> > explain them later):
> >
> > - I downloaded some of the support libs (boost, zlib, glut, jpg, png, tiff),
>
> > configured them with cmake to generate the solution for MS Visual Studio
> > 2008 32 bit and compiled them.
> > - After that, I downloaded the OSG repository with git (revision dated 16
> > Sep 2011), configured them with cmake to generate the solution for MS Visual
> > Studio 2008 32 bit (I also checked the option OSGCOMPAT_ENABLE to ease the
> > transition).
> > - After almost a week of work (mailing list search for how-to guides and
> > trial-and-error approaches) I got mi project compiled with no errors (my
> > project is quite big, more or less 60k lines of code).
> > - After another 3 or 4 days of bugfixing, now almost everything work, except
> > for some problems that I am not able to solve.
> ok.
> > This is the problem list:
> >
> > ---------------------------------------------------------
> > 1) Once per frame TextTXFFace text update
> > ---------------------------------------------------------
> I'll answer the separate Mail.
Thanks, I'll try your patch asap
>
> > ---------------------------------------------------------
> > 2) Once per frame adding points to a Geometry
> > ---------------------------------------------------------
> can you give a few more hints what you try to do. There is a
> generalized example in AddOns/Compute (github.com/vossg) that
> shows how an application can update geometry in various ways
> (writing OpenSG Properties, mapping Buffers, using Cuda)
> But in order to provide good hints some ideas of what
> you try to do would be good ;)
Sorry, I forgot to include a test program showing my problem, I'll
post it in a separate mail...
> > ---------------------------------------------------------
> > 3) Updating node BoxVolume
> > ---------------------------------------------------------
> > The method someNode->getVolume() does not accept a parameters that tells to
> > update the BoxVolume (I used to use the BoundingVolume) before getting it.
> that was changed to be editVolume as it is a modifying function,
> thinking about it not the most clever choice of name, let me think
> if we can make it better named.
> > What I do now to get the right volume is:
> >
> > NodePtr parent, node;
> > ... update node core with a geometry...
> > parent->addChild(node);
> > commitChanges();
> > node->invalidateVolume();
> > node->updateVolume();
> > parent->invalidateVolume();
> > parent->updateVolume();
> > const BoxVolume &volume = parent->getVolume();
> >
> > Is this correct? Is there a faster way to get the right BoxVolume without
> > manually tell the nodes to be updated without a rendering pass or similar,
> > but RIGHT AFTER I modify the geometries inside the cores?
> in principal ok, only some of the stuff already runs in the background,
> e.g. commitChanges should invalidate the volumes correctly according to
> your changes (otherwise it is a bug). Simular the updateVolume on the
> parent should update the child volumes.
> so
> NodePtr parent, node;
> ... update node core with a geometry...
> parent->addChild(node);
> commitChanges();
> parent->updateVolume();
> const BoxVolume &volume = parent->getVolume();
> should work (if not let me know). As we do a lazy update on the volumes
> you have to explicitly tell OpenSG to update them, the invalidate part
> should be automatically tracked.
I replaced my stuff with commitChanges() and editVolume(true),
everything works fine!
> > ---------------------------------------------------------
> > 4) Invalid GraphOp name given: Stripe and SharePtr
> > ---------------------------------------------------------
> > Sometimes (also with some test programs) the osgInit() launch two warning:
> > WARNING: GraphOpSeq::setGraphOps: Invalid GraphOp name given: Stripe
> > WARNING: GraphOpSeq::setGraphOps: Invalid GraphOp name given: SharePtr
> > Why? How can I get rid of these warnings? StripeGraphOp and ShareGraphOp
> > still work?
> that is a consequence of 5 in combination with the SceneFileHandler
> being in System and the GraphOps in Util, I have to think about how to
> get rid of these warnings. As Util is pulled when OSGFileIO is loaded
> the actual graph ops should be there when needed.
Ok, no problem.
> > ---------------------------------------------------------
> > 5) preloadSharedObject ???
> > ---------------------------------------------------------
> > Why under Windows do I need to write these two lines:
> >
> > OSG::preloadSharedObject("OSGFileIO");
> > OSG::preloadSharedObject("OSGImageFileIO");
> >
> > to make OpenSG read and write the various file formats?
> that is the windows linker trying to be clever, which unfortunately
> goes wrong when exhaustively working with factory patterns.
> My take on the problem is that the linker computes the transitive
> closure of symbols needed to link the exe/dll. If it finds that a dll
> does not contribute any of its symbols to the closure it decides not to
> link and worst not to initialize the dll during startup. So the features
> of this dll are just missing. As this is beyond our control I still have
> not found a good solution. The only (small) good news I have is that
> this problems is coming up worse for embedded platforms with only
> static libs available (IOS) so my hope is that a solution there can
> be used to work around this linker feature as well.
This was simply to know the reason I must write these lines :)
>
> kind regards
> gerrit
Thank you again!
Christian
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users
