Re: [osg-users] osgDotNet and exceptions
Hi Christoffer, Which version of OSG are you using with osgDotNet? There are still known problems with versions post 2.0. I wouldn't recommend using it in a production capacity with 2.2 or later until those are resolved. -Mike On Sun, Nov 18, 2007 at 09:30:42AM +0100, Christoffer Markusson wrote: > Hi, > > I'm using osgDotNet in a Visual Studio project and are getting lots of > exceptions thrown when running a release build of this project. > > The exceptions seems to happen at random but are always caused by > calls to osg methods. > > Typically the error message is "tried to read or write write protected > memory". If I ignore the exceptions and just continue, the application > still functions, but this is not a desirable solution. > > I know that it is a fuzzy question, but does anyone have any idea what > could cause this? Is it OK to use the provided osgDotNet dll's in a > release build? Are there some special considerations I should know > about? > > I can provide more detailed info if anyone wants it. > > Christoffer > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgDotNet : Nodes adding to scene graph outsidemain()function scope
Hi Christophe, Unfortunately I don't have any more info on this problem. This and the member variable support are the highest priority items to fix for osgDotNet. But since I've changed jobs recently my osgDotNet development has been on hold. I'm in the process of getting a Windows development environment set up at home, so I hope to get back to it before too long. With regard to the threading, if you're on a multi-core machine you may want to try forcing OSG's single-threaded mode (using OSG_THREADING=SingleThreaded) and see if that makes a difference. -Mike On Mon, Nov 12, 2007 at 05:32:36PM +0100, Christophe Medard wrote: > Hi all, > > I just wanted to know if someone had some news about the very cause of the > crash in memory inside osgDotNet reported by Jason Beverage on a PAT and by > me with any type of node (see my exchanges with Mike Wittman in late > september). > > Coming back on that, I just noted that, having compiled my C# sample showing > the bug in Release configuration rather than Debug, the application does > continue to run after the Exception Dialog Box apperance (raised by the CLR), > if the user ignore it (does not click on OK). > > However, black flashes occur from time to time, as if the culling or another > useful task wasn't carried out properly anymore. Surely the crash/exception > occur in a non-absolutely-necessary thread, which explains why on Release the > application continue to run, with those flashes... I'm not aware of the > multithreading scheme of OpenSceneGraph implementation (in my samples I > didn't do anything explicitly about that, so I assume I remained in the > default mutlithreading mode), but maybe this constatation can help ? Is the > manipulator execution confined in a particular thread ? > > Thanks for any news, if one has. > > -- > Christophe Médard > Société OKTAL (http://www.oktal.fr) > 2 impasse Boudeville > 31100 Toulouse (France) > Tél. : (+33) 5 62 11 50 10 > Fax : (+33) 5 62 11 50 29 > > > - Original Message - > From: Christophe Medard > To: OpenSceneGraph Users > Sent: Tuesday, September 25, 2007 3:43 PM > Subject: Re: [osg-users] osgDotNet : Nodes adding to scene graph > outsidemain()function scope > > > Hi Mike, > > Thanks for telling me the same kind of thing was already reported ! > I understand passin in OSG 2.1.12 would do no good. > > Thanks also for confirming the OSG reference count management being done by > the wrapper layer in a .NET Managed-fashion... > > It's quite hard to find the root cause indeed, since it seems to depend on > independant factor, like where the camera is -initially- positionned : I only > get the problem when letting osgViewer set it away from the scene (no > osgViewer.getCameraManipulator().setHomePosition() call in my mainloop). > There's something about an intersect visitor apparently (a culling pass ?). > One could think it's only where the AccessViolation first occur. I'm not sure > : if I initialize the camera close to the scene geometry, not only does my > AccessViolation vanish, but I don't have the OSG Notice warning about a > possible problem anymore either. That whether I leave space between my point > of the scene and scene geometry through manipulator's behaviour afterwards in > the run time of my application... > > Anyway, if anyone happen to lock the root cause, please don't hesitate to > post ! > > -- > Christophe Médard > Société OKTAL (http://www.oktal.fr) > 2 impasse Boudeville > 31100 Toulouse (France) > Tél. : (+33) 5 62 11 50 10 > Fax : (+33) 5 62 11 50 29 > > > - Original Message - > From: Mike Wittman > To: OpenSceneGraph Users > Sent: Tuesday, September 25, 2007 3:58 PM > Subject: Re: [osg-users] osgDotNet : Nodes adding to scene graph > outsidemain()function scope > > > Hi Christophe, > > > > This sounds like a bug that Jason reported where a particle system under a > PAT node gives the same symptoms - > http://www.openscenegraph.org/projects/osgDotNet/ticket/1. I've dug into > that problem some, but only enough to know that it will take quite a bit more > time to track down the root cause. > > > > You're correct about the reference count management; it's intended to be > completely handled by the wrappers and transparent to the C# user. Obviously > something is going wrong in this particular case. > > > > Mike Wittman > > [EMAIL PROTECTED] > > ___ > > Seismic Micro-Technology, Inc. > > 8584 Katy Freeway, Suite 400 / Houston, Texas 77024 > > Tel. +1 (713) 464-6188 > > Fax. +1 (713) 464-6440 > > Web: www.seismicmicro.com > > ___ > > CONTACT US TODAY for more information. > > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-ope
Re: [osg-users] OSG .net readerwriterOBJ
Hi Dave,
Apologies for the long delay on this reply. I haven't had the chance
to keep up with OSG in the last couple weeks.
I think you should be fine passing the default-constructed
OsgDB::ReaderWriter::Options. It may be that this is just a problem
with VS 2008. Also if you haven't rebuilt the osgDotNet wrappers for
that version, I could easily see that causing problems.
If you're able I'd recommend trying it with VS 2005 and/or straight
native OSG to see if either of those will work.
-Mike
On Mon, Oct 29, 2007 at 11:58:26PM -0400, Dave Fouts wrote:
> I attempted:
> Osg::Node ^ model = OsgDB::Globals::readNodeFile("corner1.obj");
> Compiler (& intellisense) says that a ReaderWriter::Options parameter is
> required
>
> So I added:
>OsgDB::ReaderWriter::Options ^ myOpts = gcnew OsgDB::
> ReaderWriter::Options();
> And also with Options("CACHE_NONE");
> And also just ..Options ^ myOpts;
>Then readNodeFile(fn, myOpts);
>
> I assume I need to create an instance of Options, since with only a pointer
> I get past the compiler, but no model created (no errors either).
>
> But, the compiler gives error C1001 - an internal compiler error &
>Suggests I simplify the myOpts = gcnew statement or try /P...
>
>
> Thanks
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG .net readerwriterOBJ
Hi Dave,
Questions are fine, although it's best to post to the osg-users mailing
list so that everyone can benefit. (Also you're likely to get a quicker
answer.)
It's good to hear that osgDotNet is running with VS 2008; you're the first
person I've heard from that's tried it.
You should be able to load your Maya models in a very similar way to what
you would do in unmanaged code:
Osg.Node model = OsgDB.Globals.readNodeFile("file.obj");
You can then set the scene of the viewer to the model. All of the magic
for the .obj loader happens under the covers in unmanaged code, so you
don't need to worry about it.
-Mike
> Hi, sorry if you'd prefer to NOT hear questions from the OSG website.
>
> I am new to OSG without much experience bridging managed & unmanaged code.
>
> I have the .net wrappers working with VS 2008 beta C++, creating a cone in
> a
> window.
>
> I need to be able to load .obj models I created in Maya. I see the
> unmanaged code for this plugin in the full OSG source I downloaded, but
> can't seem to figure out how to access this from my managed project.
>
> Thanks for any help, or referrals.
>
> Dave
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] dynamic_cast equivalent in osgDotNet
On Thu, Oct 04, 2007 at 08:56:55AM +0100, Robert Osfield wrote: > osgGA knows about core osg wher osg::View is defined, so could this work? Yes, actually that would work well in this case as it would provide a pointer to an object in the leftmost inheritance branch of osgViewer::Viewer. The output from the wrapped function would be of static type Osg.View and dynamic type OsgViewer.Viewer, so it could be downcasted without a problem. If you're comfortable with that change, please do go ahead and make it. It would definitely be helpful to osgDotNet users as a workaround. -Mike ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] dynamic_cast equivalent in osgDotNet
Hi Robert, On Wed, Oct 03, 2007 at 09:11:21AM +0100, Robert Osfield wrote: > On 10/3/07, Michael Wittman <[EMAIL PROTECTED]> wrote: > > It's possible to add support to osgDotNet for upcasts along non-leftmost > > inheritance branches. But downcasting in the same situation is a much > > harder problem, and I don't know of a good solution for it at the moment. > > Perhaps we could add a GUIActionAdapter:asView() virtual function that > returns a osg::View pointer. > > Another possibility would be to have a asViewer() and > asCompositeViewer() methods too, but we'd have to forward declare > osgViewer::Viewer and osgViewer::CompositeViewer to achieve this. I'm > not sure what the consequences for the wrappers would be with this > though. Unfortunately I don't think those approaches would help, as there's no analogue to C++'s incomplete types in the CLR. And having knowledge of full osgViewer wrapper types in the osgGA wrappers would necessitate a circular dependency between the two assemblies, which is not permitted (nor wise, in any case). I'm not entirely sure it would work, but best approach I can think of would be implemented completely within the wrappers. It would involve a registry of downcast conversion functions for every inheriting type from all the types in its inheritance tree, indexed off the CLR's type IDs for the inheriting and inherited types. A separate function would then be provided to index into the registry and apply the correct conversion function based on the CLR type IDs. The invoking code would look something like this: OsgGA.GUIActionAdapter aa; OsgViewer.Viewer v = OsgWrapper.Convert.Downcast(aa.GetType(), typeof(OsgViewer.Viewer)) as OsgViewer.Viewer; One thing that's not clear to me currently is how to reliably construct a unified conversion function registry across multiple wrapper assemblies. -Mike ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] dynamic_cast equivalent in osgDotNet
Hi Christophe, I think Christoffer is trying to do a downcast of OsgGA.GUIActionAdapter to Osg.Viewer, rather than the other way around. Downcasts are supported in osgDotNet, but only along the "leftmost" branch of the inheritance tree of the runtime type. This is a limitation of the single inheritance model of the CLR. osgGA::GUIActionAdapter is not on the leftmost branch of osgViewer::Viewer's inheritance tree, so that's the reason behind the error message. It's possible to add support to osgDotNet for upcasts along non-leftmost inheritance branches. But downcasting in the same situation is a much harder problem, and I don't know of a good solution for it at the moment. -Mike On Tue, Oct 02, 2007 at 01:50:27PM +0200, Christophe Medard wrote: > That's just because what you do is strange : OsgGA.GUIActionAdapter isn' a > child class of OsgViewer.Viewer. > > OsgViewer.View aa; > OsgViewer.Viewer viewer = aa as OsgViewer.Viewer; > > as a valid example perfectly works. > Not only does the 'as' cast your aa OsgViewer.View reference to an > OsgViewer.Viewer reference, but it also test the validity of such a cast, > making viewer as null is something goes wrong. > > Hope that helps. > > -- > Christophe Médard > Société OKTAL (http://www.oktal.fr) > 2 impasse Boudeville > 31100 Toulouse (France) > Tél. : (+33) 5 62 11 50 10 > Fax : (+33) 5 62 11 50 29 > > > - Original Message - > From: "Christoffer Markusson" <[EMAIL PROTECTED]> > To: > Sent: Tuesday, October 02, 2007 1:24 PM > Subject: Re: [osg-users] dynamic_cast equivalent in osgDotNet > > > > Hi Christophe, > > > > That gives error message > > > > "Cannot convert type 'OsgGA.GUIActionAdapter' to 'OsgViewer.Viewer' > > via a built-in conversion". > > > > Doing a direct cast, "viewer = (OsgViewer.Viewer)aa", also gives a > > error message when compiling in Visual Studio 2005. > > > > Christoffer > > > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
