Re: [osg-users] osgDotNet : Nodes adding to scene graphoutsidemain()function scope
I'll make the try to see what happen. Here I just wanted to point out that the problem origin may be in a function called in a thread when no particular setting on the osgviewer instance is done. If the try succeed, I guess I will have an unrecoverable crash even with the Release executable (main thread exception). Anyway it may be interesting, even to pinpoint the very cause (silmpler in a single thread mode). Good luck with your new job !! ;) -- 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: Michael Wittman [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Tuesday, November 13, 2007 7:52 AM Subject: Re: [osg-users] osgDotNet : Nodes adding to scene graphoutsidemain()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 ___ 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 have the very same problem : having to implement a new visual application, I must now choose between a C# implementation and a C++ unmanaged one. As you can bet, I'd largely prefer the first option (for instance I've prototyped some special effects in both languages/versions of the OSG librairies) but that problem is very blocking since it prevents me to build a constructed application (object-oriented classes for my effects, in a two-three layered/dlls architecture). What I noticed is that the problem remains unnoticeable if the camera used in the osgviewer stay close to the world geometry it looks (at least it is if you don't use personal manipulators, which I am to do next because of particular 'viewing modes'). So I think it's confined within a visitor pass of culling or one in touch with camera positioning's outcome, probably one being set in a thread of a secondary importance (at least in the default threading mode of osg). Here, I'm reaching the limits of my current knowledge of the API implementation. I'd like to have time to deepen it, unfortunaly I'm running out of time to begin my development... Dilemna, hard dilemna. Anyway, I'll make some other testings today. If anyone has some news about this problem, please post abundantly !!! ;) Thanks -- 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 To: OpenSceneGraph Users Sent: Tuesday, November 13, 2007 4:06 AM Subject: Re: [osg-users] osgDotNet : Nodes adding to scene graphoutsidemain()function scope Hi Christophe, I've tried quite a few times to debug the problem, but I've had no luck. I believe it has something to do with the incorrect finalization of a NodeVisitor at some point, but I can't pinpoinit *why* it happens. If I get some time next week, I can give it another go. I would love to see these problems fixed b/c I really want to move our applications over to using a more feature complete and *official* .NET binding. Thanks! Jason ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSGExp 0.9.4 and nb of vertices
Hi all, Until now working under Autodesk 3DSMax 8 and OSGExp version 0.9.3, I've just tryed OsgExp 0.9.4 under 3DSMax 9. Exporting the same object with the same options (see cap below), I notice that the number of vertices exported (as well as the number of normal) is multiplied by two and a half. Benchmarking in my application(s) shows naturally that that is not neutral considering performance. Reading OSGExp history, I see for the 8-Nov-2007 (stable) version : Nathan Hanish: Fix for normal generation with the 'use indices' flag set. I've not taken time to dig into the exporter's code, but is that bug fixing in relation with the constated growth of number of Vertices (maybe OSGExp 0.9.3 fusioned too easily same vertices with different normals - even if it's not noticable looking to my exported model in osgviewer - ?) Thanks for any clearing. -- 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 DefaultsOSGExp.PNG___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Transparency problem
Yes. At least those kind of problems appearing on a dababase exported using OSGExp is solved by a clear segregation of transparent(semi-transparent) faces from opaque ones. -- 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: André Rocha To: OpenSceneGraph Users Sent: Friday, October 19, 2007 2:20 PM Subject: Re: [osg-users] Transparency problem So the solution to the transparency sorting problem is simply to separate the objects with transparency and those without? In example, I have a opaque building with transparent windows in one single object, so I need to make the windows a separate object before exporting? [ ]´s ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Transparency problem
For your information my problem of transparency was dut to a point graphists must be careful of in 3DSMax : the OSGEXp exporter places a drawable or a geode in the TRANSPARENT_BIN as soon as at least one face has transparency. It's a perfeclty reasonable behaviour. In my case, trees (transparent) and some terrain (opaque) parts were in the same object : that give rise to sorting problems between the trees and the very parts of terrain. Having the graphist look over and rectify it, the order of rendering is perfect now. Thanks to Robert for pointing out that direction of verification ! ;) -- 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: Robert Osfield [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Friday, September 28, 2007 9:34 AM Subject: Re: [osg-users] Transparency problem Hi Christophe, I have seem problems like in your screenshot when items like roads and grass are placed incorrectly into the transparent bin, or the items like the trees are placed in the opaque bin. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] RenderingHint vs binNumber(RenderBinDetails)
Hi all,
Generalizing my 3 pass logic on a group of models, it seems I don't get the
expected result.
Let me ask a question. In the following case :
am I correct if I assume the rendering order will be A1-A2-...-An-B-A1(with B
context)-A2(with B context)-...-An(with B context)-C-A1(with C context)-A2(with
C context)-...-An(with C context) , in each {A1-A2-...-An} sequence, precise
order being unassumable ?
By with B context I mean having stateset attributes inherited from B
stateset ones.
If not, what would be a correct way to give rise to this render order ??
Thanks for any teaching about this.
--
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: Friday, October 05, 2007 3:55 PM
Subject: Re: [osg-users] RenderingHint vs binNumber(RenderBinDetails)
Yop,
All right, Tim's right.
So to conclude :
- setRenderingHint is just a shortcut for setRenderBinDetails, it allows not to
have to specify the name of bin type, and _renderingHint is useless (for those
making inquiries on the OSG source)
- indeed, the binNumber is the draw order number against other children in the
parent Group, evaluated in a left-first traversall logic.
The draw order for this case (3 pass on an geode) is A-B-C. It works well, one
just have to beware of z-fighting, through the reuse of the depth buffer of the
1st pass (via setAttributeAndModes(new
osg::Depth(osg::Depth::EQUAL,0.0,1.0,false) for example).
|
osg::Group Root
|
---
| | |
| | |
|osg::Group B osg::Group C
|[binNumber = 20] [binNumber = 30]
| ||
--
|
osg::Geode A
[binNumber = 15]
Thanks to all.
Question_about_bins.jpg___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] RenderingHint vs binNumber(RenderBinDetails)
Hi all, There's something I can't get a clear vision of despite my efforts. To parameterize order of drawing, there are two levers : renderingHint (set on a node or drawable through it's stateset osg::StateSet::setRenderingHint()) and binnumber (set on a node or drawable through it's stateset osg::StateSet::setRenderBinDetails()). I still have two interrogations : - what is the difference (or should i say level of priority) between renderingHint and binnumber ? * - there seems to be no notion of inheritance (like there is on a stateattribute typically) for those renderhint or renderbindetail features : if you set a rendering order (through one or the other feature) on a group node, does that rendering order affect the whole subgraph (understand children and children of children) ? What happens if a renderhint or renderdindetail is set again on one child ? Thanks to anyone capable of clearing that because after different attemps for different purposes, in some cases I succeded to obtain what I wanted, in some cases I didn't, and I'm ending kinda confused on that. Cheers, -- 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 * There must be a difference between the two since they aren't linked together : setting TRANSPARENT_BIN isn't equivalent to binDetails = 10 because you can do osg::StateSet::setRenderingHint(OPAQUE_BIN) and osg::StateSet::setRenderBinDetails(10), it's valid. Saying that I point out that the order of those two calls is important for if you make osg::StateSet::setRenderBinDetails(10) and osg::StateSet::setRenderingHint(OPAQUE_BIN) your binnumber is 0 !! Is that a bug ? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] RenderingHint vs binNumber(RenderBinDetails)
Sorry for the mailer redisposing of things. Here are the examples I wanted to submit : | | | osg::Group Aosg::Group B [binNumber = 8] dft, so binNumber = 0 | - | || osg::Geode Cosg::Geode Dosg::Geode E [binNumber = 5] [binNumber = 1] | | | | osg::Drawable E0 osg::Drawable E1 dft, so binNumber = 0[binNumber=6] Is it B/E0 - D - C - A - E1 ? Another example, closer to my current purpose test, practical to make multi pass drawings : | osg::Group | - | | | | | | | osg::Group B osg::Group C | [binNumber = 20] [binNumber = 30] | osg::Geode A [binNumber = 15] Is it A - B - C ? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] RenderingHint vs binNumber(RenderBinDetails)
To react to what says Robert, I'm under the impression that renderingHint in fact isn't used internally, is it ? Why is there two informations in fact redundant (an order of draw), renderingHint and binNumber ? So if I'm correct, things must only be thought of in 'binNumber' terms. To react to what says Tim, I'm passing through stateset on group nodes indeed, but I'm not sure to perfecly understand well what you're saying. Let's take a over simple example, if I have the following three, what will be the order of draw ? | | | osg::Group A osg::Group B [binNumber = 8] dft, so binNumber = 0 | | | | osg::Geode C osg::Geode D osg::Geode E [binNumber = 5] [binNumber = 1] | | --- | | osg::Drawable E0 osg::Drawable E1 dft, so binNumber = 0[binNumber = 6] Is it B/E0 - D - C - A - E1 ? Another example, closer to my current purpose test, practical to make multi pass drawings : | osg::Group | -- | | | | osg::Group B osg::Group C | [binNumber = 20][binNumber = 30] | osg::Geode A [binNumber = 15] Is it A - B - C ? I think exploring a concrete example like that clear things. Thanks - Original Message - From: Tim Moore [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Thursday, October 04, 2007 2:00 PM Subject: Re: [osg-users] RenderingHint vs binNumber(RenderBinDetails) Robert didn't answer your second question; I'll have a go because I think I understand it. First of all, there aren't a fixed number of render bins. You can assign a StateSet to any integer, positive or negative. This turns out to be quite useful. When you say set a rendering order on a group node, you mean that you've set the render bin in a state set in that node. There is an inheritance effect, but it may not be what you expect. Render bins can contain other render bins! If the children of your group node have state sets that also set the render bin detail, their render bins are stored inside the group state set's render bin, and they will be rendered in order when that render bin is traversed. This can give you unexpected results, when for example you assign a state sets with TRANSPARENT_BIN or OPAQUE_BIN to nodes up and down the scene graph :) On the other hand you can get very precise control of the ordering of drawables with it. In FlightGear I just used this feature to order cloud layers. The layers are too big for normal transparency sorting to work well, and you want to draw the cloud layer tops from low altitude to high and the bottoms from high to low. I used the altitudes of the layers as render bin numbers to get the right order: // Force the cloud layers into recursive bins of bin 4. osg::StateSet *rootSet = layer_root-getOrCreateStateSet(); rootSet-setRenderBinDetails(4, RenderBin); Child 0 has the bottom layers and child 1 has the tops: layer_root-getChild(0)-getStateSet()-setRenderBinDetails(-(int)layer_asl, RenderBin); layer_root-getChild(1)-getStateSet()-setRenderBinDetails((int)layer_asl, RenderBin); I hope someone will correct me if I've gotten this all wrong! Tim ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] RenderingHint vs binNumber(RenderBinDetails)
Sorry if the drawing isn't clear (do the images pass the mails submitted in the mailing list ? If so, I could quickly make a quick drawing, more clearer that this verbatim presentation...) yes E is child of A in my diagram, so the answer is B-A-E0-D-C-E1. I understand that in fact you're saying than the binNumber is the draw order number against other children in the parent Group, evaluated in a left-first traversall logic. However binNumber inside drawable list of Geode are evaluated at once (otherwise the answer would have be B-A-E0-E1-D-C). If can submit small pictures I may ask a last case where B as children. I'm sorry I missed something in my second diagram (there is no multipass in the one I submitted). In fact I'm wondering about that situation (encountered in a personnal shadowMap implementation) : | osg::Group Root | - | | | | | | |osg::Group B osg::Group C |[binNumber = 20] [binNumber = 30] | || -- | osg::Geode A [binNumber = 15] A is child of Root, B and C simultaneously (therefore A is rendered three times, with stateset context successivley of Root, B, and C). Is the draw order A-B-C ? Thanks for those explanations, -- 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] RenderingHint vs binNumber(RenderBinDetails)
OK, but why introducing a _renderingHint member variable not used and therefore confusing (_binNum is the one taken into account, once again if I'm correct..) ?? It's not really exclusively an implementation matter : those member variables are both clearly saved in the .osg format - readable format highly appreciable to infer problem origins when encountered with a complex scene -. A newcomer examining his scene graph naturally infer they both have a different implication on rendering order... Anyway thanks for clearing that : binNumber is the important data. -- 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: Robert Osfield [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Thursday, October 04, 2007 3:13 PM Subject: Re: [osg-users] RenderingHint vs binNumber(RenderBinDetails) StateSet::setRenderingHint is merly a convenience function for setting the bin number and bin name it has no function beyond this. ___ 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
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 To: osg users 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
Re: [osg-users] TexMat and Multitexturing
Right, I didn't see the TexMat could be specified texture unit by texture unit, through Osg.StateSet.setTextureAttributeAndModes(). Until now, I did : geode.getOrCreateStateSet().setAttributeAndModes(currentTexMatrix, (uint)Osg.StateAttribute.Values.ON); but geode.getOrCreateStateSet().setTextureAttributeAndModes(0, currentTexMatrix, (uint)Osg.StateAttribute.Values.ON); geode.getOrCreateStateSet().setTextureAttributeAndModes(1, currentTexMatrix, (uint)Osg.StateAttribute.Values.ON); is also valid, and allow to specify things for each texture channel. So please forget my question ! :} Thanks. - Original Message - From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Sent: Friday, August 24, 2007 09:49:34 Subject: TexMat and Multitexturing Hi Christophe, I am not aware of any bugs with setting TexMat on multiple textures. Are you setting the tex mat on each texture unit separately? Robert.___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Transparency problem
Hi Paul and Robert, What you are saying makes sense indeed, I didn't think about that. I will check that inferring (the database is large and exported from 3DSMax using OSGExp) : maybe OSGEXp suffer of some lackings concerning transparency issues indeed. Maybe I have after loading of the .osg (or .ive) to make a quick pass on the scenegraph to isolate the TRANSPARENT_BIN affected geometries to associate some of them to another (of greater number) bin. I'll make further inquiries to check that point and see. I'll keep the mailing list informed of the conclusion cos it may be of interest for others. Thanks -- 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: Paul Melis [EMAIL PROTECTED] Are you sure that the ground geometry isn't also in the transparent bin? I seem to recall this kind of behaviour in the max exporter, where it would put everything exported in the transparent bin as soon as there is transparency in the scene. Paul - Original Message - From: Robert Osfield [EMAIL PROTECTED] Hi Christophe, I have seem problems like in your screenshot when items like roads and grass are placed incorrectly into the transparent bin, or the items like the trees are placed in the opaque bin. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[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 special Effects in osgDotNet in C#
:
If you want to add to your main scenegraph osg::Nodes that are held by (because
created, updated and modified by) an SFX class, you quickly have memory
corruption problems due to the fact that Dispose calls are done on those nodes
whose reference count is greater than 0.
This problem doesn't occur in a similar code written in C++ - using native osg
dlls - in which a destructor is implementable for the SFX class, and
osg::Referenced::ref() (resp. unref()) methods can be called when osg::Nodes
are created (resp. inside SFX class' destructor).
I'm attaching a very short C# example illustrating that.
The application crashes rapidly, in Release or Debug. The shallow Debug trace
is :
I must say to be complete that for instance I'm using version 2.0.0 of OSG and
osgWrappers.
If there's is a way to avoid those Dispose calls on regular Nodes I'm
interested to know !!
(My preceeding attemps of sfx implementation in C# where done roughly entirely
in the main() function, which doesn't raise problems...)
--
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
Re: [osg-users] Trackball and view question
Trackball and view questionHi, The trackballManipulator recomputes the home position (should be called home positions in fact since there are three of them) when the scene is set on the osgViewer if you don't call TrackballManipulator::setAutoComputeHomePosition(false). The View Matrix you'll get the first time is highly dependent of the TrackballManipulator::_homeCenter value (among others). Since it's a lookAt Matrix that is computed, you can have the impression your point of view is the same when looking your window even if you get different values in your code (if the direction of sight is the same, unnormalized, for example). Hope it 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: Poirier, Guillaume To: osg-users@lists.openscenegraph.org Sent: Tuesday, September 18, 2007 4:19 PM Subject: [osg-users] Trackball and view question Hello everyone, I am using a SimpleViewer. I set up a post draw callback on its main camera. In it I read the camera eye, center, and up vectors. Initially, this give me (0, 0, 0), (0, 0, -1), and (0, 1, 0) respectively. This is what I expect and it gives me a particular view of my scene. Now I add a trackball manipulator to the main camera and set up the view similar to what I had previously. When I read back the data it is quite different. I would have expected the same camera position / orientation than before since what I see is similar. Unless the trackball affects the model position / orientation and not just the view ? How can I use a trackball and read back in the post draw callback the values I want ? sincerely, Bill ___ 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] Lighting behavior and osgViewer::osgViewer
In fact I was puzzled by the fact that if no directional Light is set in the scene graph, the one set transversally onto the draw traversal by the osgViewer (through the cull visitor, ie not in the scenegraph) becomes active. I was unsure about that indeed, but as you say it's not as soon as at least one light is present in the scene graph (GL_LIGHT0 == Viewer's HEADLIGHT if and only if no LightSource is present in the scene). Debugging a light effect where you can have to deactivate diffuse lights appear tricky not knowing that. Maybe a default behaviour of the viewer where lighting is OFF would have been clearer. Now I have the whole picture thanks to you and Robert, thanks. - Effectively, you can merely work into the scenegraph with osgViewer, since viewer.getCamera()-getOrCreateStateSet()-setMode(..) only activate things on attributes and modes not encountered in the loaded scenegraph ; those who are set in the scenegraph aren't reset by osgViewer. So does the osglight example work. - Debugging peacefully an ambient effect can be done : passing through viewer.getCamera()-getOrCreateStateSet()-setMode(..) works to disable the 'transversal' diffuse light established by the viewer. - viewer.setLightingMode() doesn't seem too work well, in v.2.0.0 nor 2.1.10 (it's not vital to me). Christophe - Original Message - From: Paul Martz To: 'OpenSceneGraph Users' Sent: Thursday, September 13, 2007 4:41 PM Subject: Re: [osg-users] Lighting behavior and osgViewer::osgViewer Hi Christophe -- If I'm reading your email right, you have two concerns: 1. You don't understand how SceneView uses its _light member variable. Without digging into the code, I'm not sure either. But I suspect it circumvents the typical update/cull traversals and slaps the light state directly into the positional state of the draw traversal. As _light just controls GL_LIGHT_0, you don't need to access _light or even its StateSet -- you just need to specify your own alternate values for GL_LIGHT_0. 2. You seem to be unsure that you can fully control lighting and simultaneously use osgViewer. This is not the case, and again I direct you to the osglight example program, which uses osgViewer and overrides lighting effects directly in the scene graph. Hope that helps, -Paul - Original Message - From: Robert Osfield [EMAIL PROTECTED] To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Thursday, September 13, 2007 3:28 PM Subject: Re: [osg-users] Lighting behavior and osgViewer::osgViewer Hi Christophe, I wouldn't recommended messing with SceneView unless you really have to. osgViewer now honours the Camera's StateSet, and this acts as the global StateSet. You can simply sets modes and attributes you want on the camera i.e. viewer.getCamera()-getOrCreateStateSet()-setMode(..); Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Lighting behavior and osgViewer::osgViewer
Hi all, I'm stuck with an issue that should be extremely simple, but anyway I don't get it. - How is running the default Lighting Mode set in osgViewer ? That class contains an osg::Light _light member that is instanciated but I can find anywhere its linking to the scene graph !? - What is the difference between HEADLIGHT and SKY_LIGHT ? The question is raised because I don't see indeed the _light member use... - Isn't it strange that osgViewer::setLightingMode(NO_LIGHT) doesn't unref and free the _light member ? The default is HEADLIGHT when the users instanciates his osgViewer : if right after he chooses setLightingMode(NO_LIGHT) before calling run(), _light is allocated even if it is not in use... - How can I deactivate the lighting set by default by the osgViewer ? I've been trying : osgViewer::Viewer viewer(arguments); viewer.addEventHandler(new osgViewer::XXXHandler); osg::ref_ptrosg::Node loadedModel = osgDB::readNodeFiles(arguments); skyModel-setScene(loaded.get()); viewer.setLight(NULL); // 1 viewer.setLightingMode(NO_LIGHT); // 2 viewer.getCamera()-getOrCreateStateSet()-setMode(GL_LIGHTING, osg::StateAttribute::OFF); // 3 viewer.setSceneData( root.get() ); 1, 2 or 3 seems to be of no use , the default lighting coming with osgViewer adds itself to the one contained in my scene (loadedModel), which harass me to debug my scene content... Any help or explanation would be great, maybe I missed something obvious...? -- 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] Reference Guide
I did buy it (well, let's say, I had oktal do). The Getting Started book is much more interesting than the Reference Guide, however. The thing with the getting started is that it is meant for newbie programmers that never used scene graph API's. There is a need for a guide thought of this way (written with the same spirit), but on OSG internal aspects, intended for experienced programmers that are interested in developping new Node kits. Not necessarily long, but on vitals points (I mentioned the three ones I see in my first mail) That's usually called a Programming Guide (see the extremely well written one for OpenGL Performer). The Reference Guide as-is is only useful for developpers coding on vacation, not necessarily having access to the net. -- 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: Paul Martz To: osg-users@lists.openscenegraph.org Sent: Thursday, August 23, 2007 3:57 PM Subject: Re: [osg-users] Reference Guide Hello, Has anyone bought the OSG Reference Guide? I wanted to know if you thought it was better than the reference guide that you download from the OSG website. I thinking about buying it, but I wanna make sure it is complete. By that I mean, does it really explain what each function does? The description for the OSG Reference Manual states pretty clearly that it covers osg, osgUtil, and osgDB, and is created directly from the source code using Doxygen files. So, it is incomplete at this time. Additional books in the series will cover other OSG modules, and future versions of these books will contain more complete descriptions of functions. Buying the current book will provide funding to help ensure that future documentation efforts proceed forward. I know this probably sounds like I'm saying, the book stinks now, but if you don't buy it, it won't get any better :-) In actuality, the current Reference Manual has many benefits over what you can obtain with standard Doxygen files, including TOC, index, introduction, overview of changes from v1.2 to v2.0, and improved formatting for print publication. So, I do think it's worth the purchase price. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com 303 859 9466 -- ___ 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] 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
[osg-users] osgDotNet : Used from 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. oops... I missed the ___NodeCallback_adapter and ___NodeCallback_unknown_object_ classes... The first one seems to deal with what puzzled me. Right on : it works !! 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. Again you're right : the generator took the osgwrapper_osgSim.dll in the location pointed by my Windows Path, not by the OPENSCENEGRAPH_X86_DIR. Since I have multiple versions of OSG on the computer, you see the mistake... However that local OSG copy patching is just a a quick-and-ugly solution, as you wrote. I'll keep an eye on osgIntrospection roadmap and even try to see if I can help (even if I'm much more familiar with .NET System.Reflection and System.Attribute classes -- not responding portability issues, even if Mono exists -- to deal with interface discovering issues). Everything works perfectly well knowing that, thanks a bunch !! I think I get the whole thing now. Thanks a lot again. -- 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
[osg-users] osgDotNet : Used from C#
The osgIntrospection+osgWrapper and osgDotNet-generator work very well together. (See http://www.openscenegraph.org/projects/osgDotNet/wiki/GettingStartedWithTheWrappersGenerator). Thanks to the osg team for such taht interesting release ! After a bunch of tests, the generated Managed C++ DLLs work perfeclty well referenced in a C# solution and porting a native osg program to osgDotNet in C# is quick since names of classes, methods and stay the same through the osgDotNet API. Yet, two problems remain for the programmer that wants to build an interactive application in .NET (C# in my case) : (A) Debugger use. As is, it seems impossible to examine the unmanaged C++ content (native osg) carried by osgDotNet instances, even if the Enable unmanaged code debugging option is set active in the Debug properties of the projects. (B) Update vs Draw. Some fundamental methods of classes (ie Osg.NodeCallback.operator()()) aren't wrapped. Also, some classes interface become very static in osgDotNet compared to native osg because their fundamental members were set public and accessed directly in the native API (limitation of osgIntrospection, as explained among the last points of http://www.openscenegraph.org/projects/osgDotNet/wiki/DifferencesWithNativeAPI ). An example is OsgSim.LightPoint and _on member. Regarding (A)... The Generator builds an osgDotNet solution that only links with the release versions of the native osg libraries (which stays in phase with the fact that using osgDotNet dlls, you have to copy aside your osg.NET dlls - on set in the Windows Path - release versions of the native osg Dlls as explained at http://www.openscenegraph.org/projects/osgDotNet/wiki/GettingStartedWithTheWrappers). Question A1 Is that the main explanation of (A), or is there something else ? Question A1bis Can we modify the osgDotNet solution produced by the generator to link with debug version of the native osf librairies to solve the (A) problem ? Regarding (B)... Solving the issue with for example the lightpoint is easy : I only have to make a few accessor add in (native) osgSim as well as in osgWrappers/osgSim and rebuild OpenSceneGraph. In other words a quickly coded litlle patch on the osg native release. Question B1 There, just one question : is it useful to submit to the OSG community those patches as we introduce them or will the release to com (2.2.0) include those or an osgIntrospection improvement that will render this obsolete ? Concerning the more important NodeCallback issue, it may be embarassing : it is a callback method called from the native osg internals that have to impact the overriden method coded in C#. Question B2 Will the mere patching of the osg release (as for the LightPoint) work in that case ? The macros used inside osgWrappers/xxx (osgIntrospection macros) include virtualstate assesment, but will it work on that case where the caller is the osg native core, not a .NET call coming from inside the C# application ? Thanks for comments or answers. -- 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
[osg-users] osgDotNet : Used from C#
Hi Mike
Regarding (A1): you'll need to build the Debug osgDotNet assemblies and use
them with the
Debug OSG DLLs. (...) Unfortunately you can't see the native state when
stepping through
the managed code. Also, debugging across the managed/unmanaged boundary only
works
for 32 bit code, not 64 bit, due to a CLR/Visual Studio limitation.
(A1) That's what I planned to do : link Debug Configuration os osgDotNet.sln
with Debug version of the native osg librairies (and run it aside native osg
Debug dlls) ; link Release Configuration os osgDotNet.sln with Release version
of the native osg librairies (and run it aside native osg Release dlls).
I'm currently working with 32 bit code ; I'll see to what extent I can see
what's going on on the unmanaged side...
(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.
I totally agree with you the fact that local patches aren't ideal, it can only
be a temporary solution.
I wish I'd have understood the main fundamentals of osgIntrospection and
genwrapper (for in fact source files in osgWrappers aren't supposed to be
editted, gloups !) but just getting in touch with osg it's not the case yet.
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
?
Thanks a lot for your answer !
--
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
