Re: [osg-users] osgDotNet : Nodes adding to scene graph outside main()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] mailto:[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 blocked::blocked::http://www.seismicmicro.com
___
CONTACT US TODAY for more information.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christophe Medard
Sent: Tuesday, September 25, 2007 7:59 AM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] osgDotNet : Nodes adding to scene graph outside
main()function scope
Hi everyone,
I don't know if I was very clear in my last post. My problem is to implement in
C# small sfx in nodes in the scenegraph...
The fact is that as soon as the Osg.Node (in the example the _root
Osg.PositionAttitudeTransform) that is added to the scene is enterily monitored
by a C# class (and not statically or locally defined in the main loop
function), there seems to occur destruction on that Node being nonetheless
regular in term of OSG reference count (the _root is held by the MySfxInstance,
added to the sceneGraph, and therefore its ref count is 1).
Of course, in osgDotNet (managed code), ref_ptr and
osg::Referenced::ref()/unref() aren't ported.
I'm assuming that reference count managing is done according CLR behaviour (as
long as a reference on your instance is held by someone, the CLR doesn't invoke
Dispose on that instance).
Am I missing something obvious ?
Am I the only one using osgDotNet having this problem ?
{ Hereafter follow the same code I sent on friday, focusing on the important
class and functions and simplified of #regions and unsignicant comments : }
file MySfx.cs
public class MySfx
{
protected Osg.PositionAttitudeTransform _root;
protected Osg.Group _psScene;
public MySfx(float fFar)
{
_root = null;
_psScene = null;
// Sub scenegraph creation
_root = new Osg.PositionAttitudeTransform();
_root.setName(SkyModel_Root);
//_root.setDataVariance(Osg.Object.DataVariance.DYNAMIC);
// Init update callback
_root.setUpdateCallback(new Oktal.OvOsg.MySfxUpdateCallback(this));
}
public void setScene(Osg.Group psScene)
{
if (psScene != null)
{
_psScene = psScene;
_psScene.addChild(_root);
}
}
public void update()
{
// Place update code here
}
}
internal class MySfxUpdateCallback: Osg.NodeCallback
{
protected Oktal.OvOsg.MySfx _mySfx;
public MySfxUpdateCallback(Oktal.OvOsg.MySfx mysfx)
{
_mySfx = mysfx;
}
public override void op_FunctionCall(Osg.Node node, Osg.NodeVisitor nv)
{
if (_mySfx != null)
{
_mySfx.update();
}
traverse(node, nv);
}
}
file Program.cs
static void Main(string[] args)
{
// (...)
// load the data
Osg.Node loadedModel =
OsgViewerExe.OsgDotNetGlobals.osgDBReadNodeFiles(arguments, new
OsgDB.ReaderWriter.Options());
// (...)
// optimize the scene graph, remove redundant nodes and state etc.
OsgUtil.Optimizer optimizer = new OsgUtil.Optimizer();
optimizer.optimize(loadedModel);
// DEDICATED CODE HERE
Osg.Group root = new Osg.Group();
Osg.BoundingSphere info = loadedModel.computeBound();
root.addChild(loadedModel);
Oktal.OvOsg.MySfx sfx = new Oktal.OvOsg.MySfx(info.radius());
sfx.setScene(root); // equals root.addChild(skyModel);
// END DEDICATED CODE
// Comment that (default view is away from the scene) shows the bug
better...
//viewer.getCameraManipulator().setHomePosition(new Osg.Vec3d(0.0, -10.0,
50.0), new Osg.Vec3d(0.0, 0.0, 50.0), new Osg.Vec3d(0.0, 0.0, 1.0));
viewer.setSceneData(root);
viewer.run();
}
Thx for any advice !
--
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: osg-users@lists.openscenegraph.org
Sent: Friday, September 21, 2007 5:47 PM
Subject: osgDotNet : Nodes adding to scene graph outside main() function scope
Hi all,
If I can still think straight (after such a long week), there seems to be a
major problem for people that want to code
Re: [osg-users] osgDotNet : Nodes adding to scene graphoutsidemain()function scope
Hi Christophe, The dependency on camera position is an interesting and potentially important insight. There may be some location-related conditional behavior within the native code that osgDotNet is not handling properly. Can you tell me generally what is contained in the scene graphs of the models that you are loading? That may have some bearing on the problem. -Mike From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christophe Medard Sent: Tuesday, September 25, 2007 9:43 AM To: OpenSceneGraph Users Subject: Re: [osg-users] osgDotNet : Nodes adding to scene graphoutsidemain()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 mailto:[EMAIL PROTECTED] To: OpenSceneGraph Users mailto:osg-users@lists.openscenegraph.org 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] mailto:[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 blocked::blocked::http://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-openscenegraph.org
Re: [osg-users] osgDotNet : Nodes adding to scene graphoutsidemain()function scope
Hi Jason, I expect this is a pretty deep problem related to the way reference counting is handled by osgDotNet. I'd recommend reviewing the RefCount Deletion Statechart diagram in the GeneratedCode.uml file, which gives insight into the (intended) reference counting strategy. Also I found the book CLR via C# extremely helpful in understanding how the CLR GC works. I do intend to look into this more when I have the time, but I'm not sure how soon that will happen. If you figure it out in the mean time I'll be happy to accept a patch. :) -Mike From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Beverage Sent: Tuesday, September 25, 2007 10:06 AM To: OpenSceneGraph Users Subject: Re: [osg-users] osgDotNet : Nodes adding to scene graphoutsidemain()function scope Hi Mike, I tried to do some debugging with regards to the PAT issue I added and it has something to do with the finalizer being run a NodeVisitor object, but that's about as far as I got. I couldn't understand why it would be an issue for nodes containing particle systems, but other nodes are fine. I think it has something to do with the adapter pattern being used that allows a user to subclass Nodes in C#, but I haven't gotten any further. Jason On 9/25/07, Christophe Medard [EMAIL PROTECTED] wrote: 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 mailto:[EMAIL PROTECTED] To: OpenSceneGraph Users mailto:osg-users@lists.openscenegraph.org 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] mailto:[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-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Error with current osgDotNet wrapper generators
On 9/20/07, Robert Osfield [EMAIL PROTECTED] wrote: On 9/20/07, Jason Beverage [EMAIL PROTECTED] wrote: The error was because OSG is apparently installing the osgwrapper_*.dll files in the osgplugins directory instead of in the bin directory like normal. Copying them to bin generates the wrappers. Haven't tried building them yet though. I think this might be already fixed... There's logic in the generator to handle the bin vs. plugins directory change, and it's been working fine for me with 2.1.9. It's gated in the preprocessor based on OSG version, so it could be that you're picking up old OSG headers when building the generator. The logic in question is in AugmentedTypesFactory::loadIntrospectionLibraries; I'd try dumping preprocessed source and/or stepping through in the debugger to see what's happening. -Mike ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Error with current osgDotNet wrapper generators
Hi Jason, I don't see anything special about the osg::Texture::allocateMipmap function interface that should cause that problem, and it sounds like other pure virtual Texture functions are handled appropriately. Possibly it could be due to a mismatch in OSG versions between headers and wrapper DLLs. I'll look into it when I have the chance. -Mike From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Beverage Sent: Thursday, September 20, 2007 10:22 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Error with current osgDotNet wrapper generators Hi Mike, I'll try to take a look at it this evening if I get a chance. The only issue I had with building the wrappers after I copied the dlls to the bin folder was the fact that it didn't like the allocatemipmap was pure virtual b/c osgDotNet was trying to create an instance of the Texture class and it was abstract. Jason On 9/20/07, Mike Wittman [EMAIL PROTECTED] wrote: On 9/20/07, Robert Osfield [EMAIL PROTECTED] wrote: On 9/20/07, Jason Beverage [EMAIL PROTECTED] wrote: The error was because OSG is apparently installing the osgwrapper_*.dll files in the osgplugins directory instead of in the bin directory like normal. Copying them to bin generates the wrappers. Haven't tried building them yet though. I think this might be already fixed... There's logic in the generator to handle the bin vs. plugins directory change, and it's been working fine for me with 2.1.9. It's gated in the preprocessor based on OSG version, so it could be that you're picking up old OSG headers when building the generator. The logic in question is in AugmentedTypesFactory::loadIntrospectionLibraries; I'd try dumping preprocessed source and/or stepping through in the debugger to see what's happening. -Mike ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Use of osgDotNet Wrappers
Hi Christophe, Public variable support is definitely simpler than general operator support, and I'm working on an implementation. Currently it's mostly complete; it's just the C++/CLI code generation for the property functions that remains to be done... I can't predict when it'll be finished though as I don't have much time to devote to osgDotNet in the near future. Mike Wittman [EMAIL PROTECTED] mailto:[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 blocked::blocked::http://www.seismicmicro.com ___ CONTACT US TODAY for more information. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christophe Medard Sent: Wednesday, September 19, 2007 2:59 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Use of osgDotNet Wrappers The non wrapping of public variables is an issue too, that necessitates modification by hand too (for dynamic use of LightPoints for example). Is that evolution (maybe less tricky than the operator issue) planned for the future ? Christophe - Original Message - From: Mike Wittman mailto:[EMAIL PROTECTED] To: OpenSceneGraph Users mailto:osg-users@lists.openscenegraph.org Sent: Tuesday, September 18, 2007 6:08 PM Subject: Re: [osg-users] Use of osgDotNet Wrappers Hi Jason and Christophe, Operator overloading is a known deficiency. But it's unlikely to be resolved in an automated fashion in the near future due to extensive changes necessary in osgIntrospection. The solution for now is ad-hoc support on a per-type basis, added to the generator. If you know how to patch the generated files to support the operators you're using, then it's only a small step to add that same information to the generator configuration so that it is added to the generated code automatically in the future. Just modify GeneratorConfiguration.cpp, send a patch, and I can integrate it into osgDotNet SVN. On the general question of osgDotNet use, I'm actually only using the wrappers intermittently at this point due to some changes in project direction. But I still intend to support osgDotNet releases on top of stable OSG releases in the future. Mike Wittman [EMAIL PROTECTED] mailto:[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 blocked::blocked::http://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-openscenegraph.org
Re: [osg-users] Use of osgDotNet Wrappers
Hi Jason and Christophe, Operator overloading is a known deficiency. But it's unlikely to be resolved in an automated fashion in the near future due to extensive changes necessary in osgIntrospection. The solution for now is ad-hoc support on a per-type basis, added to the generator. If you know how to patch the generated files to support the operators you're using, then it's only a small step to add that same information to the generator configuration so that it is added to the generated code automatically in the future. Just modify GeneratorConfiguration.cpp, send a patch, and I can integrate it into osgDotNet SVN. On the general question of osgDotNet use, I'm actually only using the wrappers intermittently at this point due to some changes in project direction. But I still intend to support osgDotNet releases on top of stable OSG releases in the future. Mike Wittman [EMAIL PROTECTED] mailto:[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 blocked::blocked::http://www.seismicmicro.com ___ CONTACT US TODAY for more information. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Beverage Sent: Tuesday, September 18, 2007 10:49 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Use of osgDotNet Wrappers Hi Christophe, Its good to hear you're using the new wrappers. I believe the operator overloading was something that Mike was taking a look at. Thanks! Jason On 9/18/07, Christophe Medard [EMAIL PROTECTED] wrote: We are, for a use from C# projects. The fact is that some accessor functions are lacking of some important classes (example Osg.NodeCallback.operator()()). The solution adopted for instance - which isn't satisfying for will raise problem when the osg API evolves - is to patch manually the header and source files generated by the osgDotNet Generator from the osgwrapper_*.dll ... Regards -- 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: Jason Beverage mailto:[EMAIL PROTECTED] To: osg users mailto:osg-users@lists.openscenegraph.org Sent: Tuesday, September 18, 2007 5:27 PM Subject: [osg-users] Use of osgDotNet Wrappers Hi everyone, I'm just curious to see how many people are currently using or are interested in using the new osgDotNet wrappers with their applications? My company is currently using our own custom .NET wrappers for OSG but we're interested in transitioning to Mike's wrappers and I wanted to get a feel for the number of people in the OSG community that would be using the new osgDotNet wrappers. Thanks! Jason ___ 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgdotnet Generator
Hi Wolfgang,
This is fixed in osgDotNet SVN -- I have successfully built it against
2.1.9. Beware though that there are some unresolved runtime stability
issues with regard to object destruction and the garbage collector with
the OSG 2.1.x versions. If you're not doing anything terribly complex
though you may not observe the problem.
-Mike
-Original Message-
From: [EMAIL PROTECTED] [mailto:osg-users-
[EMAIL PROTECTED] On Behalf Of Eschner Wolfgang Dr.
Sent: Tuesday, September 11, 2007 2:55 AM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] osgdotnet Generator
Hi,
I used the osgdotnet Generator to generate osgDotNet.sln from
OpenSceneGraph-2.1.9.
When compiling the solution I got the error
'Osg::___GraphicsOperation_adapter' : cannot instantiate abstract
class
..\osgDotNet-generator\output\src\Osg\GraphicsOperation.cpp
from the lines
GraphicsOperation::GraphicsOperation(System::String ^ name, bool keep)
:
Osg::Operation(___WS::InitializedSentinel())
{
___init(new ___AdapterType(___WS::toStdString(name), keep));
}
Any ideas ?
Wolfgang
-
IABG mbH
Sitz der Gesellschaft: Ottobrunn, Registergericht: Amtsgericht
Muenchen,
HRB 5499
Geschaeftsfuehrung: Prof. Dr.-Ing. Rudolf F. Schwarz (Vorsitz),
Dipl.-Ing.
Thomas Dittler, MBA
Vorsitzender des Aufsichtsrats: General a. D. Wolfgang Altenburg
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g
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
___
Seismic through Simulation with KINGDOM, (RC)2, and SURE! - CONTACT US
TODAY for more information.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Time to default to using OSG_MSVC_VERSIONED_DLL?
Hi Robert, If OSG_MSVC_VERSIONED_DLL becomes the standard, it would be very useful to add an option in osgversion to spit out the OSG SOVERSION (and one for OpenThreads, if different). Otherwise scripted manipulation of OSG binaries across releases will be difficult to do with precision. I'll see if I can't take a crack at this. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Friday, September 07, 2007 4:41 AM To: Public OpenSceneGraph Users discussion list. Subject: [osg-users] Time to default to using OSG_MSVC_VERSIONED_DLL? Hi All, Would it be possible for us to now move across to defaulting to use OSG_MSVC_VERSIONED_DLL under Windows? I'd like this set up to be the way that 2.2 goes out the door as it should simplify things for end users. If people are up for it I'll cut across today. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g 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 ___ Seismic through Simulation with KINGDOM, (RC)2, and SURE! - CONTACT US TODAY for more information. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Flipping the normals
Hi Mike, Take a look at OpenGL's two-sided lighting support via glLightModel/GL_LIGHT_MODEL_TWO_SIDE (and exposed in OSG with osg::LightModel). I think that's the more elegant solution your looking for. Mike Wittman [EMAIL PROTECTED] mailto:[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 blocked::blocked::http://www.seismicmicro.com ___ Seismic through Simulation with KINGDOM, (RC)2, and SURE! - CONTACT US TODAY for more information. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michele Bosi Sent: Tuesday, August 28, 2007 4:45 PM To: osg-users@lists.openscenegraph.org Subject: [osg-users] Flipping the normals Hello, I've a relatively easy task to accomplish, that is to render a mesh both from inside and outside. To do this i put the mesh under two different Geodes, in one i set the front face to clock wise on the other I set the front face to counter clock wise turning on the backface culling (or putting the object into a single Geode turning off the backface culling). The problem is that in one case (when I render the interior of the mesh) the polygons are not lit since the normals are (of course) not flipped, that is they remain oriented outward. My question is: how can I flip the normals? should I create two distinct meshes, one with the original normals and the other with inverted normals (modifying manually the normal buffers, and doubling the memory usage) or there is a more elegant way to do that, for example a node/state like GL_PLEASE_FLIP_MY_NORMALS that can take care of this task automatically? Cheers, Mike ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgDotNet : Used from C#
Hi Christophe, Well in fact, I didn't pay attention to the osgwrapper_osgxxx.dlls since I thought the input for the Generator was the cpp source files of the wrappers and not the built dlls. You're perfectly right about the CMake built .sln (make sure to call Rebuild Wrapper osgSim and not simply Build, since I left OFF the BUILD_OSG_WRAPPERS in CMake), anyway that's what I did yesterday, and had that DLL rebuilt indeed. I don't understay what goes wrong since I see - using Depends.exe for example - my additions' symbols inside the native osgSim.dll. The OPENSCENEGRAPH_X86_DIR variable is okay too. I don't get it for now... It sounds like the generator may be picking up an old or wrong osgwrapper_osgSim.dll for some reason. If you set the environment variable OSG_NOTIFY_LEVEL to DEBUG before executing the generator it'll cause the OSG DLL loader to tell you exactly which wrapper DLLs are being loaded. Also, the symbols in osgSim.dll are not used for the introspection information; all of that is contained in the osgwrapper_osgSim.dll. In crude ASCII art form, the basic information flow looks something like this: doxygen OSG headers - genwrapper XML interface description MSVC++ osgWrapper source osgDotNet Generator osgwrapper_*.dll - MSVC++ osgDotNet wrapper source osg*.NET.dll assemblies -Mike From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christophe Medard Sent: Friday, August 17, 2007 4:14 AM To: osg-users@lists.openscenegraph.org Subject: [osg-users] osgDotNet : Used from C# Hi again, Thanks for all those answers ! Did you rebuild the osgWrappers/osgSim DLL? If that builds without error the osgDotNet generator should see your additions. Note that the build of the osgWrappers DLLs is not enabled in the default CMake configuration; you need to turn on BUILD_OSG_WRAPPERS. Well in fact, I didn't pay attention to the osgwrapper_osgxxx.dlls since I thought the input for the Generator was the cpp source files of the wrappers and not the built dlls. You're perfectly right about the CMake built .sln (make sure to call Rebuild Wrapper osgSim and not simply Build, since I left OFF the BUILD_OSG_WRAPPERS in CMake), anyway that's what I did yesterday, and had that DLL rebuilt indeed. I don't understay what goes wrong since I see - using Depends.exe for example - my additions' symbols inside the native osgSim.dll. The OPENSCENEGRAPH_X86_DIR variable is okay too. I don't get it for now... Virtual function invocation among wrappers, user-defined subclasses of wrappers, and native code works in all directions by virtue of the design of osgDotNet. This support also extends to hand-coded virtual function wrappers if their implementations mimic the auto-generated support code for virtual functions. Ok, that soothe my mind on that !! Knowing that, solving the operator wrapping problem becomes the right point to work on.. Take a look at the custom code items in the GeneratorConfiguration.cpp file in the osgDotNet generator source. That mechanism is used to insert arbitrary code into osgDotNet-generated wrapper classes, so hand-coded wrapper functions to support NodeCallback::operator() could be added there. I see, you're talking about the getCustomCode() thing. I may try something there... if I get to something clean enough I may submit it to the team. Thanks very much for giving those clues ! -- 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgDotNet : Used from C#
Hi Christophe (again),
You're part of the way there: that code will handle calls from C# to C++.
You'll need to add code to the adapter and unknown object classes in the same
file to complete the support. Take a look at, for example, the generated
wrapper code for osg::Group::replaceChild for a model of what the code should
look like.
The GeneratedCode.uml file in the doc directory has some class and sequence
diagrams covering the design of the virtual function support if you'd like more
background. It can be viewed with StarUML.
-Mike
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christophe Medard
Sent: Friday, August 17, 2007 8:32 AM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] osgDotNet : Used from C#
Continuing on that second issue (still trying to uderstand the first one) :
Virtual function invocation among wrappers, user-defined subclasses of
wrappers, and native code
works in all directions by virtue of the design of osgDotNet. This support
also extends to hand-coded
virtual function wrappers if their implementations mimic the auto-generated
support code for virtual
functions.
Well I managed to add the following code in osgDotNet's Osg's NodeCallback.cpp :
void NodeCallback::operator()(Osg::Node ^ node, Osg::NodeVisitor ^ nv)
{
___vtnp(this)-operator()(___vtnp(node), ___vtnp(nv));
}
and of course this one in osgDotNet's Osg's NodeCallback.h :
virtual void operator()(Osg::Node ^ node, Osg::NodeVisitor ^ nv);
Everything builds right and I can see the following addition :
Osg.NodeCallback.op_FunctionCall(Osg.Node node, Osg.NodeVisitor nv) from my C#
application which allows me to write my UpdateCB inherited from
Osg.NodeCallback, but in real time my UpdateCB.op_FunctionCall(...) isn't
called.
In fact, I don't see the mecanics that'd allow in the first place the osgDotNet
NodeCallback.operator()() to be called when native NodeCallback.operator()()
is...
Are you sure this use case works ?
Sorry for bothering with that, but I don't see any other way to manage to do
scenegraph update without having it colliding with cull and draw (at least in
osg = 2.0.0).
--
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
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgDotNet : Used from C#
Hi Christophe,
(B) Well in fact I tried this afternoon the local OSG copy patching
idea, but it doesn't seem to work. I can't see why... taking the
LightPoint issue :
{a} I've added two accessor methods in include/osgSim/LightPoint and
src/osgSim/LightPoint.cpp - that 'updates' native osg dll and library
{b} I've added those through I_Method and I_Method macros in
src/osgWrappers/LightPoint.cpp - that should be taken into account by
Generator when generating again
Generator/output/src/osgSim/LightPoint.cpp and .h
{a} worked perfecly but not {b} : the osgDotNet solution generation
still works but doesn't provide anything new into LightPoint class
definition...
For instance I don't understand why.
Did you rebuild the osgWrappers/osgSim DLL? If that builds without
error the osgDotNet generator should see your additions. Note that the
build of the osgWrappers DLLs is not enabled in the default CMake
configuration; you need to turn on BUILD_OSG_WRAPPERS.
If you've got a Linux box handy, genwrapper is pretty trivial to get
started with. Just make sure you've got boost, doxygen, and libxml2
packages installed, and the follow the example at
http://www.openscenegraph.org/projects/osg/wiki/GenWrapper. On Windows
it's a pain because you need to set up all the dependencies yourself.
Currently there is a rudimentary mechanism in the code generator to
add custom support code to
classes. In the absence of support for operator functions in
osgIntrospection, this could be used
to handle the NodeCallback issue, including virtual calls from C++
to C#.
I don't really understand what you mean by that ; can you tell me a
little more ?
Sorry... too many thoughts into too few sentences. :) Let me try to be
more explicit:
Take a look at the custom code items in the GeneratorConfiguration.cpp
file in the osgDotNet generator source. That mechanism is used to
insert arbitrary code into osgDotNet-generated wrapper classes, so
hand-coded wrapper functions to support NodeCallback::operator() could
be added there.
Currently genwrapper/osgIntrospection ignores operator functions, and
adding proper support for them is non-trivial, so this one-off
hand-coded approach is the best way to support them in osgDotNet right
now.
Virtual function invocation among wrappers, user-defined subclasses of
wrappers, and native code works in all directions by virtue of the
design of osgDotNet. This support also extends to hand-coded virtual
function wrappers if their implementations mimic the auto-generated
support code for virtual functions.
-Mike
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ??: A simple question from an learner.
Hi Bingli,
I suspect you've got pure CLR support (/clr:pure) selected in your project
configuration, which tells the compiler you're only using managed code. You
need to have standard CLR support (/clr) selected to compile against the native
code of OSG. The setting is in the General section of your project's
Configuration Properties.
-Mike
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ijustfu
Sent: Thursday, August 02, 2007 8:57 PM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] ??: A simple question from an learner.
Dear Mike,
Thanks for you help. There are so many warnings and errors. Following are
some statements:
1-- Build started: Project: VGEForPRDAirPollution, Configuration: Debug
Win32 --
1Compiling...
1VGEForPRDAirPollution.cpp
1C:\OpenSceneGraph2.0\OpenSceneGraph\include\OpenThreads/Mutex(40) : warning
C4272: 'OpenThreads::Mutex::Mutex' : is marked __declspec(dllimport); must
specify native calling convention when importing a function.
OpenThreads::Mutex::`vftable'' : per-appdomain symbol should not be marked with
__declspec(dllimport)
1C:\OpenSceneGraph2.0\OpenSceneGraph\include\osg/Referenced(64) : warning
C4272: 'osg::Referenced::ref' : is marked
..
1VGEForPRDAirPollution.obj : error LNK2028: unresolved token (0A0C)
public: void __clrcall osg::Referenced::ref(void)const ([EMAIL
PROTECTED]@osg@@$$FQBMXXZ) referenced in function public: __clrcall
osg::ref_ptrclass osg::Referenced::ref_ptrclass osg::Referenced(class
osg::ref_ptrclass osg::Referenced const ) ([EMAIL
PROTECTED]@osg@@@osg@@[EMAIL PROTECTED]@@Z)
1VGEForPRDAirPollution.obj : error LNK2028: unresolved token (0A0D)
public: void __clrcall osg::Referenced::unref(void)const ([EMAIL
PROTECTED]@osg@@$$FQBMXXZ) referenced in function public: __clrcall
osg::ref_ptrclass osg::Referenced::~ref_ptrclass osg::Referenced(void)
([EMAIL PROTECTED]@osg@@@osg@@[EMAIL PROTECTED])
1VGEForPRDAirPollution.obj : error LNK2028: unresolved token (0A11)
public: __clrcall osg::CopyOp::CopyOp(unsigned int) ([EMAIL
PROTECTED]@@[EMAIL PROTECTED]@Z) referenced in function public: __clrcall
osg::RefMatrixd::RefMatrixd(class osg::RefMatrixd const ) ([EMAIL
PROTECTED]@@[EMAIL PROTECTED]@@Z)
1VGEForPRDAirPollution.obj : error LNK2028: unresolved token (0A12)
public: virtual __clrcall osg::CopyOp::~CopyOp(void) ([EMAIL
PROTECTED]@@[EMAIL PROTECTED]) referenced in function public: __clrcall
osg::RefMatrixd::RefMatrixd(class osg::RefMatrixd const ) ([EMAIL
PROTECTED]@@[EMAIL PROTECTED]@@Z)
1VGEForPRDAirPollution.obj : error LNK2028: unresolved token (0A13)
public: __clrcall osg::Object::Object(void) ([EMAIL PROTECTED]@@[EMAIL
PROTECTED]) referenced in function public: __clrcall
osg::StateAttribute::Callback::Callback(void) ([EMAIL PROTECTED]@osg@@[EMAIL
PROTECTED])
1VGEForPRDAirPollution.obj : error LNK2028: unresolved token (0A14)
public: __clrcall osg::Object::Object(bool) ([EMAIL PROTECTED]@@[EMAIL
PROTECTED]@Z) referenced in function public: __clrcall
osg::RefMatrixd::RefMatrixd(void) ([EMAIL PROTECTED]@@[EMAIL PROTECTED])
..
1Build log was saved at
file://d:\VGEForPRDAirPollution\TestNet\VGEForPRDAirPollution\VGEForPRDAirPollution\Debug\BuildLog.htm
1VGEForPRDAirPollution - 1227 error(s), 4507 warning(s)
== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==
Thanks and regards
Bingli
The Institute of Space and Earth Information Science,
The Chinese university of Hong Kong, Shatin, N.T., Hong Kong, P.R.China
-邮件原件-
发件人: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 代表 Mike Wittman
发送时间: 2007年8月2日 22:23
收件人: osg-users@lists.openscenegraph.org
主题: Re: [osg-users] A simple question from an learner.
OSG can definitely be used with WinForms. It sounds like you're running
into some project configuration issue though. If you can post your
error messages we might be able to provide better help.
-Mike
-Original Message-
From: [EMAIL PROTECTED] [mailto:osg-users-
[EMAIL PROTECTED] On Behalf Of ijustfu
Sent: Thursday, August 02, 2007 4:25 AM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] A simple question from an learner.
Dear Robert.
I build a simple OSG program with visual studio2005.net. I use c++
language , and select window forms application, then get the
following
codes:
#include stdafx.h
#include Form1.h
#include osgViewer/Viewer
#include osgDB/ReadFile
using namespace VGEForPRDAirPollution;
[STAThreadAttribute]
int main(arraySystem::String ^ ^args)
{
// Enabling Windows XP visual effects before any controls are
created
Application::EnableVisualStyles();
Application::SetCompatibleTextRenderingDefault(false);
// Create the main window and run it
Application::Run(gcnew Form1());
osgViewer::Viewer viewer
Re: [osg-users] A simple question from an learner.
I build a simple OSG program with visual studio2005.net. I use c++ language , and select window forms application, then get the following codes: Doesn't look like you're doing anything to bridge the gap between managed and unmanaged code. If I remember correctly, someone created a .NET wrapper for OSG recently. You might search the archives or the wiki to see if you can find any information regarding it. http://www.openscenegraph.org/projects/osgDotNet It works well stand alone, but embedding the viewer in a WinForms form is likely to be a non-trivial exercise at this point. I believe one of the osgDotNet users got it to work, but he had to use the Tao OpenGL bindings for .NET to set up the graphics contexts. 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 ___ Seismic through Simulation with KINGDOM, (RC)2, and SURE! - CONTACT US TODAY for more information. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.1.3 dev release made
Hi Robert, The source package link for this release is broken, apparently because the source package is not present. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Monday, July 30, 2007 10:55 AM To: osg users Subject: [osg-users] OpenSceneGraph-2.1.3 dev release made Hi All, Weekly dev release has been tagged, details on DeveloperReleases page: http://www.openscenegraph.org/projects/osg/wiki/Downloads/DeveloperRelea se s SVN tag: http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph - 2.1.3/ Please consider this a 1st release candidate for 2.2 and test as such, Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g 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 ___ Seismic through Simulation with KINGDOM, (RC)2, and SURE! - CONTACT US TODAY for more information. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
