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.
> ---------------------------------------------------------
> 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 ;)
> ---------------------------------------------------------
> 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.
> ---------------------------------------------------------
> 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.
> ---------------------------------------------------------
> 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.
kind regards
gerrit
------------------------------------------------------------------------------
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
