Re: [osg-users] Possible bug in the position of the osg::Cone

[Aitor Moreno]

Hi Mike, all,

In fact, before sending the mail to the mailing list, I searched in the code
where was the "rendering of the cone"

I found it in the ShapeDrawable.cpp >> line 578 (checkout OSG tag 2.2.0)

void DrawShapeVisitor::apply(const Cone& cone)
...

In that function there is only a glTranslate ... at the very beginning ...

glTranslatef(cone.getCenter().x(),cone.getCenter().y(),cone.getCenter
().z());

I thought that the cone.getCenter() would return the center I passed in the
cone constructor... but, I guess it is not.

Now that it seems that the code is doing was it is expected, i.e, it is a
feature :), I found that in the line

float topz=cone.getHeight()+cone.getBaseOffset();

The getBaseOffset is defined in the include file Shape, just in the
declaration of the Cone class.

(line 287 of Shape)
inline float getBaseOffsetFactor() const { return 0.25f; }

And there it is the 0.25 factor

I would suggest to document it a little bit, at least in the cone class
declaration, so the auto documentation would include that the center of the
cone is the Centroid, instead of the tip, the center of the base, or
whatever...

Bye.




On Thu, Feb 14, 2008 at 11:47 PM, Mike Weiblen <[EMAIL PROTECTED]>
wrote:

> Hi,
>
> The origin of the cone is at its center of mass, not its geometric base.
>
> osgShapes are internally defined parametrically, rather than in terms of
> triangles, so as to be used as intersection volumes, etc.  The fact that
> they are also drawable is just a convenience overload of their primary
> purpose.
>
> This is a recurring misconception/FAQ, and deserves to be documented
> clearly. Could you have a look at the code, and if it's not clearly
> documented, pls submit a code change that puts comments where you would
> have found them.
>
> Thanks
> -- mew
>
>
>
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:osg-users-
> > [EMAIL PROTECTED] On Behalf Of Aitor Moreno
> > Sent: Thursday, February 14, 2008 8:13 AM
> > To: osg-users@lists.openscenegraph.org
> > Subject: [osg-users] Possible bug in the position of the osg::Cone
> >
> > Hi osg-users,
> >
> > I am trying to do a very simple application, and when I was required
> to
> > add some cones, I added a new osg::Cone with the desired parameters.
> > Unfortunatelly, the cone didn't appeared where it was suppossed to.
> >
> > I clean up the code and I copy here a snipset of the code I used and a
> > screenshot.
> >
> > This code adds a Cone and a Box.
> > Both objects with the same origin. The box is only for reference (it
> > represents the XY plane at z=0).
> >
> > As you can see in the attached screenshot, the cone is displaced 25%
> > below the XY plane (100 units). Its size is 400.
> >
> > I was expected to that the bottom of the cone at z=0. Or, as in other
> > API's, the center of the cone at z=0.
> >
> > Any ideas? is it a bug?
> >
> > Thanks
> >
> >
> > === CODE ===
> >
> >ViewerQT* viewerWindow = new ViewerQT;
> >
> > //create a group and add the loaded model => terrain
> > osg::ref_ptr groupRoot = new osg::Group;
> >
> > //Add the Cone
> > osg::Geode* geo = new osg::Geode();
> > geo->addDrawable(new osg::ShapeDrawable(new
> > osg::Cone(osg::Vec3(0,0,0), 50, 400)));
> > geo->addDrawable(new osg::ShapeDrawable(new osg::Box(
> > osg::Vec3(0,0,0) , 100, 100, 0.05f )));
> > groupRoot->addChild ( geo);
> >
> > //set camera and set the root node.
> > viewerWindow->setCameraManipulator(new
> > osgGA::TrackballManipulator);
> >
> > osg::ref_ptr updateText = new osgText::Text;
> > // add the HUD subgraph.
> > groupRoot->addChild(createHUD(updateText.get()));
> > viewerWindow->addEventHandler(new
> > PickHandler(updateText.get()));
> >
> > viewerWindow->setSceneData(groupRoot.get());
> >
> > === CODE ===
> >
> > --
> > Aitor Moreno
> > aitormoreno [EMAIL PROTECTED] gmail.com 
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



-- 
Aitor Moreno
[EMAIL PROTECTED]
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] traversal question w/latest developer release-blacknodes

[sherman wilcox]

mew - Didn't realize there was a potential shader connection till a
tad later. Anyway, I spent more time on this yesterday and managed to
build a sample app that is much smaller and less complicated than the
app I originally found the problem in. There's a bit of propriety code
in this sample app - nothing I wouldn't mind sharing with you if you
want to take a peek.

The thing that bugs me is why is this shader effecting other osg
nodes. Now, there could most certainly be a bug in my code somewhere -
but I'm using OSG code - I don't *think* I'm going outside of OSG and
doing messing with OpenGL states. So, if I'm using all OSG code then I
would think that even if I've got a bad shader, or doing something I
shouldn't be - then that error should be confined to that node and its
children and should NOT travel to its siblings.

You can email me privately if you want and I'll be happy to share the
code with you.

On Thu, Feb 14, 2008 at 5:04 PM, Mike Weiblen <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Usually try to keep an eye out for shader questions, but this title did
> not attract my attention.  I'm leaving the title unmodified so you'll
> see this response, but if there's still an open question, pls start a
> new appropriately-titled thread with the current state of your
> investigation.
>
> Way way back, there was an issue of OSG shader state leakage.  It's been
> fixed a long time (years?), 'course that doesn't preclude another
> failure mode.
>
> Cheers
> -- mew
>
>
>
>
>
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:osg-users-
> > [EMAIL PROTECTED] On Behalf Of Paul Martz
> > Sent: Wednesday, February 13, 2008 10:07 AM
> > To: 'OpenSceneGraph Users'
> > Subject: Re: [osg-users] traversal question w/latest developer
> release-
> > blacknodes
> >
> > (Hm, shaders. Maybe someone with more experience with shaders in OSG
> > can
> > read and post an opinion?)
> >
> > Hi Sherman -- Interesting issue.
> >
> > OpenGL is a state machine, and if you're just using raw OpenGL, then
> > you
> > could enable blending, for example, never change blending state again,
> > and
> > blending would be enabled for all subsequent geometry.
> >
> > OSG adds a new level of functionality on top of that. As you traverse
> a
> > scene graph, state changes are pushed and popped hierarchically, which
> > is
> > what most apps expect. If blending is off in a parent Node but on in
> > the
> > first child, blending is restored to a disabled state before
> processing
> > the
> > other children.
> >
> > Not all state: Color, as I mentioned previously, is not pushed and
> > popped.
> > So, if you change the color in a Drawable, and then a subsequent
> > sibling (or
> > even a distant cousin) Geometry is missing its color array, the
> > previous
> > color persists (due to OpenGL's state machine nature). I'm not sure
> why
> > OSG
> > intentionally doesn't push/pop color, but it simply doesn't, and if
> you
> > always specify color for Drawables that require specific colors, this
> > is not
> > an issue.
> >
> > When it comes to shaders, though, I'm not sure how they behave. If a
> > Node
> > binds a Program, does OSG unbind it before processing sibling Nodes?
> > This is
> > a question better posed to someone like Mike W. or Bob K...
> >=Paul
> >
> >
> > > I've found a few clues this evening. Not sure why things are
> > > behaving the way they are - I'm probably abusing the OSG in
> > > my overridden
> > > traverse(...) function. My node has a shader attached. If I
> > > do NOT attach that shader to the stateset, no problems. Read on
> > >
> > > On Feb 12, 2008 3:40 PM, Paul Martz <[EMAIL PROTECTED]> wrote:
> > > > > I have a class that inherits from osg::Group. In this class I'm
> > > > > overriding the traverse function. It is written in such a
> > > way that
> > > > > the CULL_VISITOR doesn't have an opportunity to call
> > > > > osg::Group::traverse(nv). When I add this object to the
> > > scenegraph
> > > > > all the nodes in my scene go black. Even if this class is
> > > a child -
> > > > > all the nodes (including parent nodes) appear black.
> > > >
> > > > The presence of this custom Node is changing the color of your
> > > > geometry so that they render black? E.g., against a non-black
> > > > background, you see them render? Or, by "appear black", do
> > > you mean they just don't show up?
> > > >
> > > > What color is your Geometry supposed to render?
> > >
> > > The only other node is a bluemarble ellipsoid produced by
> > > osgdem. It's entirely black when I intrdouce my node into the
> > > scenegraph. If the node (my custom node) is a sibling, the
> > > bluemarble node goes black.
> > >
> > > >
> > > > Does your custom Node support the .osg file format? If so, have
> you
> > > > dumped your scene to a .osg file to see if anything is amiss?
> > > >
> > >
> > > No - doesn't support OSG.
> > >
> > > > Have you tried to reproduce the problem with a very simple
> > > scene, like
> > > > just a single triang

Re: [osg-users] traversal question w/latest developer release-blacknodes

[Mike Weiblen]

Hi,

Usually try to keep an eye out for shader questions, but this title did
not attract my attention.  I'm leaving the title unmodified so you'll
see this response, but if there's still an open question, pls start a
new appropriately-titled thread with the current state of your
investigation.

Way way back, there was an issue of OSG shader state leakage.  It's been
fixed a long time (years?), 'course that doesn't preclude another
failure mode.

Cheers
-- mew




> -Original Message-
> From: [EMAIL PROTECTED] [mailto:osg-users-
> [EMAIL PROTECTED] On Behalf Of Paul Martz
> Sent: Wednesday, February 13, 2008 10:07 AM
> To: 'OpenSceneGraph Users'
> Subject: Re: [osg-users] traversal question w/latest developer
release-
> blacknodes
> 
> (Hm, shaders. Maybe someone with more experience with shaders in OSG
> can
> read and post an opinion?)
> 
> Hi Sherman -- Interesting issue.
> 
> OpenGL is a state machine, and if you're just using raw OpenGL, then
> you
> could enable blending, for example, never change blending state again,
> and
> blending would be enabled for all subsequent geometry.
> 
> OSG adds a new level of functionality on top of that. As you traverse
a
> scene graph, state changes are pushed and popped hierarchically, which
> is
> what most apps expect. If blending is off in a parent Node but on in
> the
> first child, blending is restored to a disabled state before
processing
> the
> other children.
> 
> Not all state: Color, as I mentioned previously, is not pushed and
> popped.
> So, if you change the color in a Drawable, and then a subsequent
> sibling (or
> even a distant cousin) Geometry is missing its color array, the
> previous
> color persists (due to OpenGL's state machine nature). I'm not sure
why
> OSG
> intentionally doesn't push/pop color, but it simply doesn't, and if
you
> always specify color for Drawables that require specific colors, this
> is not
> an issue.
> 
> When it comes to shaders, though, I'm not sure how they behave. If a
> Node
> binds a Program, does OSG unbind it before processing sibling Nodes?
> This is
> a question better posed to someone like Mike W. or Bob K...
>=Paul
> 
> 
> > I've found a few clues this evening. Not sure why things are
> > behaving the way they are - I'm probably abusing the OSG in
> > my overridden
> > traverse(...) function. My node has a shader attached. If I
> > do NOT attach that shader to the stateset, no problems. Read on
> >
> > On Feb 12, 2008 3:40 PM, Paul Martz <[EMAIL PROTECTED]> wrote:
> > > > I have a class that inherits from osg::Group. In this class I'm
> > > > overriding the traverse function. It is written in such a
> > way that
> > > > the CULL_VISITOR doesn't have an opportunity to call
> > > > osg::Group::traverse(nv). When I add this object to the
> > scenegraph
> > > > all the nodes in my scene go black. Even if this class is
> > a child -
> > > > all the nodes (including parent nodes) appear black.
> > >
> > > The presence of this custom Node is changing the color of your
> > > geometry so that they render black? E.g., against a non-black
> > > background, you see them render? Or, by "appear black", do
> > you mean they just don't show up?
> > >
> > > What color is your Geometry supposed to render?
> >
> > The only other node is a bluemarble ellipsoid produced by
> > osgdem. It's entirely black when I intrdouce my node into the
> > scenegraph. If the node (my custom node) is a sibling, the
> > bluemarble node goes black.
> >
> > >
> > > Does your custom Node support the .osg file format? If so, have
you
> > > dumped your scene to a .osg file to see if anything is amiss?
> > >
> >
> > No - doesn't support OSG.
> >
> > > Have you tried to reproduce the problem with a very simple
> > scene, like
> > > just a single triangle plus your custom Node? Then you could step
> > > through in the debugger and determine what's going on.
> > >
> > > Have you tried capturing the OpenGL output with GLIntercept?
> > >
> > > In the past, whenever I've seen state bleed from one Node
> > to a sibling
> > > Node, it is usually because the sibling Node's Geometry
> > lacks a color array.
> > >
> >
> > I suspect either one of (at least) two things:
> >
> > 1) I'm abusing OSG some manner and the code is responding in
> > kind. In other words, I'm doing something I shouldn't be and
> > I'm getting undefined behavior.
> >
> > OR
> >
> > 2) There is some sort of state leakage (of my shader) issue
> > between sibling nodes. If this is leakage - is it a bug or not?
> >
> > > > What I did to patch things is to hack my class such that the
> > > > CULL_VISITOR is allowed to call osg::Group::traverse(nv);
> > at least
> > > > once at the start. This seems to address the problem, albeit in
a
> > > > kludgy sort of way. I'd like to know if:
> > > >
> > > > - this is a new OSG bug?
> > >
> > > Are you saying you tried this same thing in v2.2 and the problem
> > > didn't occur?
> >
> > I thought this was new - but went back and tried older

Re: [osg-users] CompositeViewer remove View with Eventhandler crash

[Steve Schneider]

Well I thought I'd post my conclusions on the off chance that someone else 
wants to build a user interface with OSG, AND is as ignorant as I am about 
OpenGL and 3D graphics.
   
  Let's start off by saying that OSG is a low-level graphics package - quite a 
good one in my opinion.  The expertise to understand all the 'clip space' 
'DelaunayTriangulator' and all the other real-time 3D graphic techno-wizardry 
that I rely on OSG to provide - doesn't really carry over into supporting a 
fancy GUI (graphical user interface).  Further - someone that can argue the 
nuances of quaternion multiplication - which I cannot - probably isn't going to 
be really gifted in event handling to any fancy degree.  If someone *can* do 
both - then they probably don't need to wear a life vest since they can 
probably walk on water!
   
  So - using the excellent CompositeViewer and using an osgViewer::View to 
present a menu and with the requisite event handler to handle menu picks.  (See 
examples osgHUD, osgPICK, and osgCompositeViewer for the basics.)
   
  The Rules
  (1) Thou shalt not remove a view with an event handler.  The logic of the 
processing assumes that the number of views doesn't change from start to 
finish, and I can't fix it without making things worse.
  (2) Thou shalt use the viewer with osgViewer::ViewerBase::SingleThreaded.  It 
appears to my testing that popping GUI menus (aka Views) in and out while it's 
multithreading works _most_ of the time.  I want my project to work _all_ of 
the time - hence The Rule.
   
  You can add a view (popup a GUI menu) in an event, but the trick is to remove 
a view (close a GUI menu).  You can't do that when you run OSG with the simple 
viewer.run call.  You must run the viewer one frame at a time.  
   
  This is what I've done.  Make a boolean global variable something link 
RemoveGUI.
   
  Then implement OSG with the 'old school':
  do while() 
  {
viewer.frame
  }
  type loop.  In the appropriate event handler(s) - "schedule" the view to be 
removed by setting your global variable.  You'll need logic after the 
viewer.frame call to check this variable and remove the view.  Something like:
   
  do while()
  {
viewer.frame
if (RemoveGUI)
{
  viewer.removeView
  RemoveGUI = false
}
  }
   
   
  I've not tried to use the available OpenGL eye-candy (slider bars and all 
that) - is the technical term widgets? - to create a full on GUI experience.  
In my own case I'm not sure I need to.
   
  So: Elegant? No.  Spiffy? No.  That's not what OSG is about. 
  Effective?  You bet.


-Steve Schneider
   
-
Never miss a thing.   Make Yahoo your homepage.___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Update scene while moving window

[Frank Bergmann]

Actually, depending on the version of windows that you are running it might
also be a windows setting that prevents the window to be redrawn while
moving. Have a look at (under XP): 

 

Control Panel\System Properties\Advanced\Visual Effects …Settings\Visual
Effects

 

In that checked listbox, look for an entry saying “Show window contents
while dragging”. With that enabled I see the scene updated while dragging
the window … 

 

Cheers

Frank

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of jw
Sent: Thursday, February 14, 2008 9:42 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Update scene while moving window

 

Hi,

you are right, i'm running on Windows platform. 
Right now i'm converting my application from osgProducer::Viewer to
osg::CompositeViewer.
Using osgProducer::Viewer it was possible to move the window without any
problems. 
The scene was updated in contrast to osg::CompositeViewer (OSG 2.2).

But what is the difference between these two viewers?

Thanks in anticipation
J-W


Jean-Sébastien Guay wrote: 

Hello André,
 
  

There might be a way to avoid this by using a separate thread for message
dispatching in the GraphicsWindowWin32 class, but that remains to be
explored.


 
And in fact, I imagine that's what video players like Windows Media 
Player do, since you can move the window while video is playing and it 
will not pause.
 
Not suggesting anything be done about it, just adding a point to consider...
 
J-S
  

 


-- 
This message has been scanned for viruses and 
dangerous content by   MailScanner, and is 
believed to be clean. 

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Update scene while moving window

[jw]

Hi,

you are right, i'm running on Windows platform.
Right now i'm converting my application from osgProducer::Viewer to 
osg::CompositeViewer.
Using osgProducer::Viewer it was possible to move the window without any 
problems.

The scene was updated in contrast to osg::CompositeViewer (OSG 2.2).

But what is the difference between these two viewers?

Thanks in anticipation
J-W


Jean-Sébastien Guay wrote:

Hello André,

  

There might be a way to avoid this by using a separate thread for message
dispatching in the GraphicsWindowWin32 class, but that remains to be
explored.



And in fact, I imagine that's what video players like Windows Media 
Player do, since you can move the window while video is playing and it 
will not pause.


Not suggesting anything be done about it, just adding a point to consider...

J-S
  


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] HELP: Pick point in Point Cloud

[Trajce Nikolov]

I have done this in the past. All depends of the amount of data you have. If
there is not too much of it you can do it with Polytope, otherwise consider
using selection buffer. It performs well for point and line picking

Nick

On Thu, Feb 14, 2008 at 5:52 PM, Jean-Sébastien Guay <
[EMAIL PROTECTED]> wrote:

> Hello Samuele,
>
> > i am newbie for OSG; my initial goal is write a program
> > to load point could file and pick a point.
> > I tried to use the example osgpick with .3dc file format.
> > The program osgpick reads the file and displays the point cloud
> > but does not select any point.
>
> In addition to what Adrian said (that osgpick focuses on triangles), I
> believe (but have never done it, so I might be wrong) that you can pick
> points using a PolytopeIntersector. Unfortunately this is not very
> documented. Have a look at how the osgpick example's source sets up a
> LineSegmentIntersector, and try to do the same thing for a
> PolytopeIntersector (setting up a valid polytope for what you want).
>
> Hope this helps,
>
> J-S
> --
> __
> Jean-Sebastien Guay[EMAIL PROTECTED]
>http://www.cm-labs.com/
> http://whitestar02.webhop.org/
>  ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



-- 
- Nick
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] ANN: osgPython (SWIG) 2.2.0

[Luigi Calori]

Thank you very much... it worked!!

 either

%inline %{
osg::Geode *NodeToGeode2(osg::Node *b) {
   return dynamic_cast(b);
}
%}

or

%extend osg::Node {
virtual osg::Geode* asGeode() {return dynamic_cast(self);}
};

The Cmake projects worked fine (just some mods to standard FindOSG), I 
spent some time to find out how to install correctly into site_packages
If I' m correct, the dll must be renamed .pyd and the generated py must 
be copied inside the site_packages
I noticed the compile time of the _osg project is quite slow (at least 
on my machine) do you think it would be possible to split the big osg 
wrapper into smaller pieces to
both speed up build time and separate original (yours) and added (mine)

Do you plan to insert your CMake files into the osgswig svn?
Having things in svn will really help a lot the development
I' m planning to experiment further and then try to  add site_packages 
installation to cmake if do not find a better way to work

thanks again
 Luigi
René Molenaar wrote:

> I read this in the swig manual:
>
> If you need to cast a pointer or change its value, consider writing 
> some helper functions instead.
> see: http://www.swig.org/Doc1.3/Python.html
>
>%inline %{
>
>/* C++-style cast */
>Foo *BarToFoo(Bar *b) {
>   return dynamic_cast(b);
>}
>
>%}
>
>  
>
> You can also create the member function node.asGeode() in a similar 
> way with swig. This is a safe and handy method. There might be other 
> options... this way you would need to use swig, and can't use the 
> binary version.
>
> René
>
>
>
> 2008/2/13, Luigi Calori <[EMAIL PROTECTED] >:
>
> René Molenaar wrote:
>
> > Swig wrappers for OpenSceneGraph Python and Perl
> >
> > These files are part of: The VRmeer Library - Delft University of
> > Technology
> >
> > The files are based on osgswig (http://code.google.com/p/osgswig/)
> > with some additions and CMake files.
> >
> Thanks for the post, I' ll try them as soon as possible, I' m
> currently
> try to learn python and osgswig using the binary version under
> windows XP
> I stumbled upon a problem:
>
> I would like to parse the one scene, so willing to use  something
> like:
>
>
> node = osgDB.readNodeFile('cow.osg')
>
> while node.className() == 'Group':
> print node.className()
> node = node.asGroup().getChild(0)
> print node.className()
>
> The problem arise when getChild() returns a Geode.
> There is no  --- node.asGeode()  method so I have no idea of
> how to
> get the handle of a Geode in the scene.
>
> Sorry for my dumbness, any help really appreciated,
>
> Luigi
> ___
> 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

[osg-users] extension for OGR plug-in to handle COLLADA models

[Christoph Ehrler]

Dear Cedric Pinson,
dear all

in the scope of a student research project I developed 2 plug-ins for 
OGR and OpenSceneGraph to load COLLADA 3d models from KML files and to 
visualise them with OpenSceneGraph (using the existing dae plug-in).

Now I have permission to post my results to the open-source community.


Both, the current releases GDAL/OGR-1.5.0 and OpenSceneGraph-2.3.4 
contain new plug-ins, supporting readout of spatial vector data from KML 
files and connection to the OGR abstract data model for spatial vector 
data retrieval respectively.

Thus, in my opinion, the next step is to integrate my work into this 
projects mentioned above since both newly released plug-ins lack the 
ability to handle the 3d geometry of COLLADA models (exactly what was 
achieved by my student research project) rendering them to a more or 
less complete solution for KML file handling in OpenSceneGraph and GDAL/OGR.


I would like to start working together with Cedric to achieve the fusion 
of our work since this should be an easy task as far as I can conclude 
from a look into his source code...

Would be happy about a response  :)

Cheers
Christoph

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] HELP: Pick point in Point Cloud

[Jean-Sébastien Guay]

Hello Samuele,

> i am newbie for OSG; my initial goal is write a program
> to load point could file and pick a point.
> I tried to use the example osgpick with .3dc file format.
> The program osgpick reads the file and displays the point cloud
> but does not select any point.

In addition to what Adrian said (that osgpick focuses on triangles), I 
believe (but have never done it, so I might be wrong) that you can pick 
points using a PolytopeIntersector. Unfortunately this is not very 
documented. Have a look at how the osgpick example's source sets up a 
LineSegmentIntersector, and try to do the same thing for a 
PolytopeIntersector (setting up a valid polytope for what you want).

Hope this helps,

J-S
-- 
__
Jean-Sebastien Guay[EMAIL PROTECTED]
http://www.cm-labs.com/
 http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] another one - osg and C#

[hesicong2006]

Hi,
You should try OSG.NET project, but the project does not contains every 
feature OSG could provide. A much better solution will be use of 
C++/CLI, this language can create mix native C++ and managed code. The 
main C# UI design benefit is also contained in C++/CLI. I have use 
C++/CLI to integrate OSG and .NET, very well, you should try it. But the 
plain will be the much lower compile speed due to lots of inline code of 
OSG.

sherman wilcox wrote:
> I've read a few posts and I'm a bit fuzzy on the subject. I have an
> OSG app wrapped up in a C++ library. Now I need a UI. I can attach
> this and drive this libarary from a console app, MFC GUI, or even the
> standard Windows API, etc. - All in C++. However, I'm considering
> using C#. I've heard lots of good things about C# from a UI
> development perspective. From an OSG/C# point of view - there seems to
> be lots of pain.
>
> I'm not a C# developer - it's all Greek to me - so what I'm imagining
> may not be practical in reality hence this post. Is it possible to
> link in my OSG app wrapped up in a C++ blanket and use my own API from
> with a C# GUI? Is it painful? What would I lose by going this route?
> Is possible that at some point I won't be able to take advantage of
> some latest OSG feature due to some unforeseen incapability? My
> current UIs (I'm thinking of one MFC UI in particular) don't really
> interact with the OSG - that's all handled by my own C++ API. I'm just
> not sure how well all this would glue together using C#.
>
> Can some of the veterans comment?
>
>   

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] another one - osg and C#

[Brian]

Hi Sherman,

I have added C# to some existing existing C++ apps.  I really don't
recommend trying this.  We found that wrapping our C++ in COM objects worked
best but it took alot time for a small gain.  Have you consider using
wxWidgets?  It has a nicer UI then MFC especially if you use wxAUI, and
there is a nice GUI tool wxFormBuilder for quickly creating Dialogs and
other UI.


Brian
osgscenemaker.googlepages.com
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Back from holidays...

[Robert Osfield]

On Thu, Feb 14, 2008 at 4:08 PM, Paul Martz <[EMAIL PROTECTED]> wrote:
> Cayman Islands! We were almost in the same time zone. You should've came out
>  to Colorado for some skiing while you were over in this hemisphere.

Skiing in Colorado is a big pull, but... didn't have the clothing for
it this time around, only shorts and t-shirts and sun block!


>
>  J=S says:
>  > Please don't overwork yourself trying to get back on track in
>  > a single day... Take it easy for the first few days :-)
>
>  Second that. I hope 16 days has nearly eliminated your RSI symptoms.; They
>  do creep back easily, though, if you're not careful.

Didn't suffer from RSI at all while away, but... typing today I can
feel it already, even after just a few hours :-|

So will certainly be taking it easy.  Jet lag is playing tricks on me
today so I'm now heading offline.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] HELP: Pick point in Point Cloud

[Adrian Egli OpenSceneGraph (3D)]

Hi
the osgpick is working on triangles, (if am right). So if you don't have any
triangles (or surfce mesh) it doesn't hit any surface area. and points
can no be picked because it's not clear how you like to pick a point. so
first you have to define how a point can be picked. May you choose the
closest
point to the camera, or ... One of the fastest algorithm for that is a
kdTree-based closest point search. have a look in google ask for closest
point search.

/Adegli

2008/2/14, Samuele Pierattini <[EMAIL PROTECTED]>:
>
> Hi all,
> i am newbie for OSG; my initial goal is write a program
> to load point could file and pick a point.
> I tried to use the example osgpick with .3dc file format.
> The program osgpick reads the file and displays the point cloud
> but does not select any point.
>
> Thanks to those who can help me
>
>
> --
> Samuele Pierattini
> ENEA
> E-Mail [EMAIL PROTECTED]
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



-- 

Adrian Egli
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] HELP: Pick point in Point Cloud

[Samuele Pierattini]

Hi all,
i am newbie for OSG; my initial goal is write a program
to load point could file and pick a point.
I tried to use the example osgpick with .3dc file format.
The program osgpick reads the file and displays the point cloud
but does not select any point.

Thanks to those who can help me

-- 
Samuele Pierattini
ENEA
E-Mail [EMAIL PROTECTED]
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Back from holidays...

[Paul Martz]

Cayman Islands! We were almost in the same time zone. You should've came out
to Colorado for some skiing while you were over in this hemisphere.

J=S says:
> Please don't overwork yourself trying to get back on track in 
> a single day... Take it easy for the first few days :-)

Second that. I hope 16 days has nearly eliminated your RSI symptoms.; They
do creep back easily, though, if you're not careful.

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

Re: [osg-users] osgpick strange behavior

[Carlo Camporesi]

Hi Jean,
thanks for the reply. I have seen the related submission just now.
We have found that there is no correlation between osgText and the
disappearing of HUD in osgPick.
This strange behavior is caused by the missing of the CoordinateSystem Node
in the osgdem generation.
Thanks again
Carlo


2008/2/14, Jean-Sébastien Guay <[EMAIL PROTECTED]>:
>
> Hello Carlo,
>
>
> > 1 - osgText (osgfreetype plugin): The plugin doesn't free memory
> > correctly, I think there are a massively memory leak.
>
>
> There is a submission in the queue for a crash on exit related to the
> freetype plugin. It's not a memory leak, it's a use of a pointer after
> it's been freed. Not sure it's the same issue you're seeing, but maybe
> you should wait until this fix is in SVN and then re-test.
>
> Though this probably has no relation to your osgpick problem. I never
> used osgpick on a terrain model, so I can't help you there.
>
> J-S
> --
> __
> Jean-Sebastien Guay[EMAIL PROTECTED]
> http://www.cm-labs.com/
>  http://whitestar02.webhop.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] Back from holidays...

[Jean-Sébastien Guay]

Hi Robert, welcome back!

> You'll be seeing a scattering of emails from me today as I slowly make
> my way through my email backlog.  I'm a bit jet lagged am not fully
> functioning so if I write more nonsense than I usually do then put it
> down to 5 hour shift in time of day...

Please don't overwork yourself trying to get back on track in a single 
day... Take it easy for the first few days :-)

J-S
-- 
__
Jean-Sebastien Guay[EMAIL PROTECTED]
http://www.cm-labs.com/
 http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] another one - osg and C#

[Paul Martz]

Hi Sherman -- 

At my previous employer, we had a C++ app using ZAF, a cross-platform UI
toolkit that was no longer supported and kind of buggy. We decided to
modernize our app about the time VS2005 came out, and replace ZAF with
Windows Forms and C#. The idea was to write an isolated UI that would
interface with the C++ core module.

We found this to be a very painful process. As ZAF was C/C++-based, it
interfaced easily with our app. However, C# has very different data types
for things like String and even arrays (called Containers in C#). The bulk
of our work consisted of writing routines that would reformat C# data types
into C++ data types (and vice versa). Microsoft refers to this as
"marshaling", which is a euphemism for "data copy" in our experience. Bottom
line: it was a lot of work to produce code that ended up running
sub-optimally.

And don't even get me started on managed C++.

After 6 months of development, 1 developer fulltime on this and 5 others
parttime, we abandoned the project, having produced little more than a
simple prototype.

Our developer staff of C++ experts were all new to C#. Perhaps it's the case
that most of this pain was caused by our own inexperience, but most of the
C# and managed C++ documentation available did not address the issues we
were encountering, so developing expertise was very difficult.

If your app is C++-based, I encourage you to stick with C or C++ APIs.
   -Paul


> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf 
> Of sherman wilcox
> Sent: Wednesday, February 13, 2008 9:33 PM
> To: OpenSceneGraph Users
> Subject: [osg-users] another one - osg and C#
> 
> I've read a few posts and I'm a bit fuzzy on the subject. I 
> have an OSG app wrapped up in a C++ library. Now I need a UI. 
> I can attach this and drive this libarary from a console app, 
> MFC GUI, or even the standard Windows API, etc. - All in C++. 
> However, I'm considering using C#. I've heard lots of good 
> things about C# from a UI development perspective. From an 
> OSG/C# point of view - there seems to be lots of pain.
> 
> I'm not a C# developer - it's all Greek to me - so what I'm 
> imagining may not be practical in reality hence this post. Is 
> it possible to link in my OSG app wrapped up in a C++ blanket 
> and use my own API from with a C# GUI? Is it painful? What 
> would I lose by going this route?
> Is possible that at some point I won't be able to take 
> advantage of some latest OSG feature due to some unforeseen 
> incapability? My current UIs (I'm thinking of one MFC UI in 
> particular) don't really interact with the OSG - that's all 
> handled by my own C++ API. I'm just not sure how well all 
> this would glue together using C#.
> 
> Can some of the veterans comment?
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce
negraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Back from holidays...

[Jeremy Moles]

On Thu, 2008-02-14 at 14:35 +, Robert Osfield wrote:
> Hi All,
> 
> I'm now back from my trip to the Cayman Islands, much sailing,
> snorkeling and family time was enjoyed.  16 days without touching a
> computer is the longest I've gone for 9 years, and not a single
> withdraw symptom, just had too fund stuff to distract me :-)
> 
> You'll be seeing a scattering of emails from me today as I slowly make
> my way through my email backlog.  I'm a bit jet lagged am not fully
> functioning so if I write more nonsense than I usually do then put it
> down to 5 hour shift in time of day...

Woot, good times. :)

It's been 16 days, wow...

> Robert.
> ___
> 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] Back from holidays...

[Robert Osfield]

Hi All,

I'm now back from my trip to the Cayman Islands, much sailing,
snorkeling and family time was enjoyed.  16 days without touching a
computer is the longest I've gone for 9 years, and not a single
withdraw symptom, just had too fund stuff to distract me :-)

You'll be seeing a scattering of emails from me today as I slowly make
my way through my email backlog.  I'm a bit jet lagged am not fully
functioning so if I write more nonsense than I usually do then put it
down to 5 hour shift in time of day...

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] trouble with flattening static transforms

[Robert Osfield]

Hi Terry,

A glatten static transforms that have duplicates shared subgraphs
would be a useful addition to osgUtil::Optimizer so if you are willing
to tidy up and submit it'd be appreciated.

Cheers,
Robert.

On Thu, Jan 31, 2008 at 9:56 PM, Terry Welsh <[EMAIL PROTECTED]> wrote:
> I went ahead and wrote a visitor that really does remove all static
>  transforms.  If nodes underneath transforms have multiple parents, it
>  makes copies so that each child subgraph can be properly transformed.
>  On my big test case, I remove 911 out of 911 transforms, my model
>  takes up 10x the memory, and it runs 25-30% faster.  It's a good
>  tradeoff for the app I'm working on.
>
>  There's probably plenty of refinement necessary for corner cases since
>  I have only tested with 2 models, but if this sounds worthwhile to
>  anyone else I can fix up a few things and submit it.
>  - Terry
>  >
>  > Message: 16
>  > Date: Tue, 29 Jan 2008 19:28:24 +
>  > From: "Robert Osfield" <[EMAIL PROTECTED]>
>  > Subject: Re: [osg-users] trouble with flattening static transforms
>  > To: "OpenSceneGraph Users" 
>  > Message-ID:
>  > <[EMAIL PROTECTED]>
>  > Content-Type: text/plain; charset=ISO-8859-1
>  >
>  > Hi Terry,
>  >
>  > You can't flatten a static transform when anything it its subgraph is
>  > shared with other transforms, if you do flatten it the the object is
>  > the trying to be in two places at one time, something it can't do,
>  > what happens to these objects is undefined, in fact quite rightly
>  > disallowed until you hacked away at it...
>  >
>  > The only way to flatten these objects shared beneath multiple
>  > transforms is to duplicate the subgraph so that each transform has its
>  > own unique subgraph.  This itself has its own penalties in terms of
>  > performance.
>  >
>  > Robert.
>  >
>  > On Jan 29, 2008 7:14 PM, Terry Welsh <[EMAIL PROTECTED]> wrote:
>  > > So I have a big city database that I built in Creator with lots of
>  > > external models loaded under transform nodes.  I assumed that
>  > > Optimizer could flatten this out for me with
>  > > FLATTEN_STATIC_TRANSFORMS.  Unfortunately, I only end up flattening 35
>  > > out of 911 transforms.
>  > >
>  > > Tracing through the code, I find that line 804 of Optimizer.cpp is
>  > > where things go bad for me:
>  > >
>  > > if (_firstMatrix!=matrix) _moreThanOneMatrixRequired=true;
>  > >
>  > > This line rejects most of my flattening because later on
>  > > _moreThanOneMatrixRequired seems to be used to decide whether or not
>  > > to flatten.  If I comment this line out, then all but the first
>  > > instance of each model disappears from my scene.
>  > >
>  > > Understanding all the logic in Optimizer.cpp could take me a long
>  > > time.  Is there some fundamental reason why having more than one
>  > > matrix makes it impossible to flatten a model, or is this just
>  > > incomplete code that I could extend to give me a more thorough
>  > > flattening?  Any tips on how to try and extend it would be great
>  > > too
>  > > --
>  > > Terry Welsh - mogumbo 'at' gmail.com
>  > > www.reallyslick.com  |  www.mogumbo.com
>  > > ___
>  > > 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] osgViewer config files ???

[Robert Osfield]

Hi Brian,

In OSG-2.2 there is the beginnings of osgViewer config file support,
and isn't yet as capable as Producer .cfg files, but it'll end up more
general purpose than Producer .cfg as you will eventually be able
embed scene graphs in the config files to set up things like
distortion corrections etc.

In the SVN version/2.3.x version of the OSG there is a cfg plugin that
allows you read Producer .cfg files directly just as you can with
osgProducer, this will allow you to reuse all your existing .cfg
without changes.

Robert.

On Tue, Feb 12, 2008 at 11:19 PM, Brian R Hill <[EMAIL PROTECTED]> wrote:
> Folks,
>
>  I'm upgrading from 1.2 to 2.2 and Producer to osgViewer. I see notes in the
>  subversion log for osgViewer Viewer.cpp that mention reading configuration
>  files, but I can't figure out what the format is.
>
>  Is there an equivalent to the Producer config files?
>  Is the format described anywhere?
>
>  Thanks,
>
>  
> Brian
>
>  This is a PRIVATE message. If you are not the intended recipient, please
>  delete without copying and kindly advise us by e-mail of the mistake in
>  delivery. NOTE: Regardless of content, this e-mail shall not operate to
>  bind CSC to any order or other contract unless pursuant to explicit written
>  agreement or government initiative expressly permitting the use of e-mail
>  for such purpose.
>  
> 
>
>  ___
>  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] osgpick strange behavior

[Jean-Sébastien Guay]

Hello Carlo,

> 1 - osgText (osgfreetype plugin): The plugin doesn't free memory 
> correctly, I think there are a massively memory leak.

There is a submission in the queue for a crash on exit related to the 
freetype plugin. It's not a memory leak, it's a use of a pointer after 
it's been freed. Not sure it's the same issue you're seeing, but maybe 
you should wait until this fix is in SVN and then re-test.

Though this probably has no relation to your osgpick problem. I never 
used osgpick on a terrain model, so I can't help you there.

J-S
-- 
__
Jean-Sebastien Guay[EMAIL PROTECTED]
http://www.cm-labs.com/
 http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] osgpick strange behavior

[Carlo Camporesi]

Hi OSGUsers,
I have found some strange behaviors using osgpick example in latest
development revision.
When I load a terrain using osgpick It doesn't show anything. If I move away
the hud disappeares and the terrain pops up.
I have tried to run the instance through vs debugger and I haven't found the
reason but the application crash on exit.
I think that bugs are involved:
1 - osgText (osgfreetype plugin): The plugin doesn't free memory correctly,
I think there are a massively memory leak.
2 - osgDB::Options. If there are an external option setted (included in
ref_ptr) the application crash on exit for multiple deallocation.
Cheers
Carlo

EXAMPLE: osgpick
http://3d.cineca.it/storage/terrain/demo/terreni/prove_utm_wgs/utm/utm.ive
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] how to read GeoTIFF files using osgdem?

[Robert Osfield]

Hi Linh,

On Wed, Feb 13, 2008 at 2:42 AM, Linh Phan <[EMAIL PROTECTED]> wrote:
>  1. Is the "-d DEM_1m_VictoriaCrater.tif" argument to osgdem all I need
>  for a GeoTIFF file?

Yes, that's all that is required.  Your osgdem command line looks just
fine so I'm suprised the generated database is working fine out of the
box.

>  2. Is there a way for osgviewer to put the object in the center so I can
>  see it or do
>I have to ask the USGS to generate the GeoTIFF DEM that has the DEM
>  in the center so I can see?

osgviewer will place the viewpoint so that the center of rotation is
at the center of the loaded object.

Robert.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Tiled textures on osg::Box

[Jean-Sébastien Guay]

Hello Frans,

> m_osg_shape = new osg::ShapeDrawable( new osg::Box( 
> osg::Vec3f( 0, 0, -0.005f ),  29.7f, 21.0f, 0.01f ) );
> osg::Image* image = osgDB::readImageFile( "gras.jpg" );
> osg::Texture2D* tex2d = new osg::Texture2D( image );
> tex2d->setWrap( osg::Texture::WRAP_S, osg::Texture::REPEAT );
> tex2d->setWrap( osg::Texture::WRAP_T, osg::Texture::REPEAT );
> m_osg_shape->getOrCreateStateSe
> t()->setTextureAttributeAndModes( 0, tex2d, osg::StateAttribute::ON );
> 
> but the setWrap() command doesn't seem to have any effect for me. I 
> guess I have to specify the relative alignment for the texture manually 
> but I have no clue how I do this for a osg::Box. The examples only deal 
> with manuallly built geoms.

The wrap modes only take effect if your geometry has texture coordinates 
outside the 0.0 - 1.0 range. In the case of the osg::Box shapedrawable, 
it generates texcoords that go from 0.0 to 1.0 on each face, in both the 
s and t directions. So you'll never see wrapping on that.

You'll have to make your own box, and specify the texture coordinates 
you want. For example 0.0 - 2.0 on each axis for each face will give you 
a texture repeated twice (assuming you set up your texture as above). 
It's not hard... Oh heck, I have the code here to create a basic box, so 
here it is:

osg::Geometry* createBox()
{
 osg::Geometry* box = new osg::Geometry;

 // Vertices
 osg::Vec3Array* vertices = new osg::Vec3Array;
 vertices->push_back(osg::Vec3(-.5, -.5, -.5)); // 0
 vertices->push_back(osg::Vec3( .5, -.5, -.5)); // 3
 vertices->push_back(osg::Vec3( .5, -.5,  .5)); // 5
 vertices->push_back(osg::Vec3(-.5, -.5,  .5)); // 1

 vertices->push_back(osg::Vec3(-.5, -.5,  .5)); // 1
 vertices->push_back(osg::Vec3( .5, -.5,  .5)); // 5
 vertices->push_back(osg::Vec3( .5,  .5,  .5)); // 7
 vertices->push_back(osg::Vec3(-.5,  .5,  .5)); // 4

 vertices->push_back(osg::Vec3(-.5, -.5, -.5)); // 0
 vertices->push_back(osg::Vec3(-.5, -.5,  .5)); // 1
 vertices->push_back(osg::Vec3(-.5,  .5,  .5)); // 4
 vertices->push_back(osg::Vec3(-.5,  .5, -.5)); // 2

 vertices->push_back(osg::Vec3( .5, -.5, -.5)); // 3
 vertices->push_back(osg::Vec3( .5,  .5, -.5)); // 6
 vertices->push_back(osg::Vec3( .5,  .5,  .5)); // 7
 vertices->push_back(osg::Vec3( .5, -.5,  .5)); // 5

 vertices->push_back(osg::Vec3( .5,  .5, -.5)); // 6
 vertices->push_back(osg::Vec3(-.5,  .5, -.5)); // 2
 vertices->push_back(osg::Vec3(-.5,  .5,  .5)); // 4
 vertices->push_back(osg::Vec3( .5,  .5,  .5)); // 7

 vertices->push_back(osg::Vec3( .5, -.5, -.5)); // 3
 vertices->push_back(osg::Vec3(-.5, -.5, -.5)); // 0
 vertices->push_back(osg::Vec3(-.5,  .5, -.5)); // 2
 vertices->push_back(osg::Vec3( .5,  .5, -.5)); // 6
 box->setVertexArray(vertices);

 // Normals
 osg::Vec3Array* normals = new osg::Vec3Array;
 normals->push_back(osg::Vec3( 0, -1,  0));
 normals->push_back(osg::Vec3( 0, -1,  0));
 normals->push_back(osg::Vec3( 0, -1,  0));
 normals->push_back(osg::Vec3( 0, -1,  0));

 normals->push_back(osg::Vec3( 0,  0,  1));
 normals->push_back(osg::Vec3( 0,  0,  1));
 normals->push_back(osg::Vec3( 0,  0,  1));
 normals->push_back(osg::Vec3( 0,  0,  1));

 normals->push_back(osg::Vec3(-1,  0,  0));
 normals->push_back(osg::Vec3(-1,  0,  0));
 normals->push_back(osg::Vec3(-1,  0,  0));
 normals->push_back(osg::Vec3(-1,  0,  0));

 normals->push_back(osg::Vec3( 1,  0,  0));
 normals->push_back(osg::Vec3( 1,  0,  0));
 normals->push_back(osg::Vec3( 1,  0,  0));
 normals->push_back(osg::Vec3( 1,  0,  0));

 normals->push_back(osg::Vec3( 0,  1,  0));
 normals->push_back(osg::Vec3( 0,  1,  0));
 normals->push_back(osg::Vec3( 0,  1,  0));
 normals->push_back(osg::Vec3( 0,  1,  0));

 normals->push_back(osg::Vec3( 0,  0, -1));
 normals->push_back(osg::Vec3( 0,  0, -1));
 normals->push_back(osg::Vec3( 0,  0, -1));
 normals->push_back(osg::Vec3( 0,  0, -1));
 box->setNormalArray(normals);
 box->setNormalBinding(osg::Geometry::BIND_PER_VERTEX);

 // Faces
 box->addPrimitiveSet(new osg::DrawArrays(GL_QUADS, 0, 
vertices->size()));

 // Colors
 osg::Vec4Array* colors = new osg::Vec4Array;
 colors->push_back(osg::Vec4(1,1,1,1));
 box->setColorArray(colors);
 box->setColorBinding(osg::Geometry::BIND_OVERALL);

 return box;
}

Just add the returned geometry as drawable to a geode. This code does 
not specify texcoords, so I have left you a bit of work... :-) But you 
should be able to figure it out. Check the doxygen for 
Geometry::setTexCoordArray(unsigned int unit, Array* array). You need 
one texcoord (Vec2) per vertex, btw.

Hope this helps,

J-S
-- 
__
Jean-Sebastien Guay[EMAIL PROTECTE

[osg-users] Possible bug in the position of the osg::Cone

[Aitor Moreno]

Hi osg-users,

I am trying to do a very simple application, and when I was required to add
some cones, I added a new osg::Cone with the desired parameters.
Unfortunatelly, the cone didn't appeared where it was suppossed to.

I clean up the code and I copy here a snipset of the code I used and a
screenshot.

This code adds a Cone and a Box.
Both objects with the same origin. The box is only for reference (it
represents the XY plane at z=0).

As you can see in the attached screenshot, the cone is displaced 25% below
the XY plane (100 units). Its size is 400.

I was expected to that the bottom of the cone at z=0. Or, as in other API's,
the center of the cone at z=0.

Any ideas? is it a bug?

Thanks


=== CODE ===

   ViewerQT* viewerWindow = new ViewerQT;

//create a group and add the loaded model => terrain
osg::ref_ptr groupRoot = new osg::Group;

//Add the Cone
osg::Geode* geo = new osg::Geode();
geo->addDrawable(new osg::ShapeDrawable(new
osg::Cone(osg::Vec3(0,0,0), 50, 400)));
geo->addDrawable(new osg::ShapeDrawable(new osg::Box(
osg::Vec3(0,0,0) , 100, 100, 0.05f )));
groupRoot->addChild ( geo);

//set camera and set the root node.
viewerWindow->setCameraManipulator(new osgGA::TrackballManipulator);

osg::ref_ptr updateText = new osgText::Text;
// add the HUD subgraph.
groupRoot->addChild(*createHUD*(updateText.get()));
viewerWindow->addEventHandler(new *PickHandler*(updateText.get()));

viewerWindow->setSceneData(groupRoot.get());

=== CODE ===

-- 
Aitor Moreno
aitormoreno [EMAIL PROTECTED] gmail.com <[EMAIL PROTECTED]>
<>___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] how to read GeoTIFF files using osgdem?

[ümit uzun]

ÜMİT UZUN


> Date: Wed, 13 Feb 2008 18:40:37 -0800
> From: [EMAIL PROTECTED]
> To: osg-users@lists.openscenegraph.org
> Subject: Re: [osg-users] how to read GeoTIFF files using osgdem?
> 
> Hi Umit,
> 
> Do you know if osgdem actually look at any of the .prj, .aux, .rrd at all or 
> is it only looking
> at the .tif file?
> 
> Also, do you know if we have two GeoTIFFs of one big patch (but low 
> resolution) and one smaller patch
> (but high res) of the same area, we can use osgdem to generate an osga DEM 
> file with high res for the area
> where we have high res and low res for area we have low res, eg using:
> 
> osgdem -l 8 -d DEM_1m_landArea100x100m.tif -d DEM_10m_landArea4000x4000m.tif 
> -o test.ive -a test.osga
> 
> 
> 
> 
> Yes I understand you. You should look at LOD (Level of Detail) method. 
> osgviewer supporting this feature automatically. and you can't use different 
> resolution elevation images in same terrain. You should use same range of 
> resolution both of elevation and texture images. If you want to LOD 
> processing by this way you don't need two different images. Choose high 
> resolution and small patches and use them in osgdem -d 1.tif -d 2.tif . . . . 
> .
> 
> 
> 
> I didn't mean that the 2 patches are of the same area.  The 
> DEM_10m_landArea4000x4000m.tif would cover a bigger area 4 km by 4 km at 10 
> meter resolution, and the DEM_1m_landArea100x100m.tif would cover a smaller 
> area of the DEM_10m_landArea4000x4000m.tif but at a higher resolution.  The 
> reason for 2 tif files at different resolution is that we don't want the osga 
> DEM to have high resolution for areas we are not interested in when we are 
> higher up; osgviewer does this automatically but we don't want to have a 
> large osga DEM file.

Ok your high resolution image is small and you want to generate a scene like a 
google earth. When you get closer the target high resoluted patches within the 
lower resolution large image, you would to see more detailed part instead of 
lower resolution images at intersected areas on scene!
 -d parameteres could be one more time in osgdem command like a -t. I haven't 
try your thinking action yet. But I will try and if I success I will return you.

> 
> 
> Where did you get the images(DEM_1m_landArea100x100m.tif) Ling ?
> 
> 
> I don't have it yet.  USGS will generate them for us but I haven't figure out 
> if osgdem can handle them.  Actually, we were thinking of asking for 
> DEM_1m_landArea4000x4000m.tif and DEM_10m_landArea4x4m.tif instead of 
> what I said above, so you see that's alot of data processing.
> 
> Thanks Umit,
> 
> Linh
> 
> 
> 
> ÜMİT UZUN
> 
> 
> 
> 
> Date: Tue, 12 Feb 2008 18:42:38 -0800
> From: [EMAIL PROTECTED]
> To: osg-users@lists.openscenegraph.org
> Subject: [osg-users] how to read GeoTIFF files using osgdem?
> 
> Hi,
> 
> this is my first time trying to use osgdem on a GeoTIFF file and I
> wasn't successful in viewing the
> generated osga file. The data (from
> http://webgis.wr.usgs.gov/ftphirise/index.jsp) look like this:
> 
> % ls DEM_1m_VictoriaCrater*
> DEM_1m_VictoriaCrater.asc.gz DEM_1m_VictoriaCrater.rrd
> DEM_1m_VictoriaCrater.aux DEM_1m_VictoriaCrater.tif
> DEM_1m_VictoriaCrater.prj
> 
> % cat DEM_1m_VictoriaCrater.prj
> 
> PROJCS["Plate_Carree",GEOGCS["EQUIRECTANGULAR_CYLINDRICAL_MARS",DATUM["D_MARS",SPHEROID["MARS",3396190,0]],PRIMEM["Reference_Meridian",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Plate_Carree"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",180],PARAMETER["false_easting",0],PARAMETER["false_northing",0],UNIT["Meter",1]]
> 
> I then use osgdem command:
> 
> % osgdem -l 2 -d DEM_1m_VictoriaCrater.tif -o test.ive -a test.osga
> 
> % osgviewer test.osga
> 
> But I didn't see anything when osgviewer first came up, but I know
> something is there because when
> I spin it, I see something spin by really fast. My question are:
> 
> 1. Is the "-d DEM_1m_VictoriaCrater.tif" argument to osgdem all I need
> for a GeoTIFF file?
> 
> 2. Is there a way for osgviewer to put the object in the center so I can
> see it or do
> I have to ask the USGS to generate the GeoTIFF DEM that has the DEM
> in the center so I can see?
> 
> Thank you very much,
> 
> Linh
> 
> 
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> 
> 
> 
> _
> Yeni nesil Windows Live Servisleri’ne şimdi ulaşın!
> http://get.live.com
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> 
> 
> 
> _
> Yeni nesil Windows Live Servisleri’ne şimdi ulaşın!
> http://get.

Re: [osg-users] another one - osg and C#

[Serge Lages]

Hi Sherman,

I've done some C++/C# wrapping some time ago. Here are my advices :

- If you just need to call from your C# UI some predefined functions from
you C++ code, it's easy. You just need to create a Wrapping DLL which makes
the link with your C++ calls. Your C# code will just need to call these
functions (with invoke methods).

- If you need to make calls from you C++ part to your C# part, it's much
more complicated ! You need to use managed C++ and it's a real pain...

- If you need to call any OSG method from your C# code, take a look at the
OSG .net project.

Hope this helps !

On Thu, Feb 14, 2008 at 5:32 AM, sherman wilcox <[EMAIL PROTECTED]>
wrote:

> I've read a few posts and I'm a bit fuzzy on the subject. I have an
> OSG app wrapped up in a C++ library. Now I need a UI. I can attach
> this and drive this libarary from a console app, MFC GUI, or even the
> standard Windows API, etc. - All in C++. However, I'm considering
> using C#. I've heard lots of good things about C# from a UI
> development perspective. From an OSG/C# point of view - there seems to
> be lots of pain.
>
> I'm not a C# developer - it's all Greek to me - so what I'm imagining
> may not be practical in reality hence this post. Is it possible to
> link in my OSG app wrapped up in a C++ blanket and use my own API from
> with a C# GUI? Is it painful? What would I lose by going this route?
> Is possible that at some point I won't be able to take advantage of
> some latest OSG feature due to some unforeseen incapability? My
> current UIs (I'm thinking of one MFC UI in particular) don't really
> interact with the OSG - that's all handled by my own C++ API. I'm just
> not sure how well all this would glue together using C#.
>
> Can some of the veterans comment?
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



-- 
Serge Lages
http://www.tharsis-software.com
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgShadow one shot shadow map

[Wojciech Lewandowski]

Hi J-S,

> Thank you Wojtek, I'll check that out! I'm really very grateful to you 
> for contributing this. I've been banging my head on this and we're still 
> on OSG 2.2 here so I didn't think of going to see in the new additions 
> if there was something that would help me out.

You're welcome. I am glad I could help. 

Wojtek  


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Extra workload during first render of a model

[Emilio Lozano]

Hi Paul,

Thanks for your response.

I am using OpenSceneGraph through Delta3D.1.5 (it uses OSG.1.2), therefore
using osgProducer instead of osgViewer. Maybe I can force the running of
GLObjectsVisitor. I will read osgViewer's code and try to do it by myself.

I don't think that this could be a RAM problem becasue the workaround I'm
currently using to avoid these workload problem is the following: when I
launch my application, the first thing I do is to turn the camera's heading
from 0º to 360º. When the camera points for the first time to one of these
objects, the application freezes as said, but after the complete turn is
done (that is, I have rendered all the objects) I can look at anywhere
without experimenting anymore freezes. I guess that a RAM problem would
produce more swappings along the execution, but the freeze is only
experimented the first time the object is visited.

Regards,
Emilio Lozano.

2008/2/13, Paul Martz <[EMAIL PROTECTED]>:
>
>  If you are using osgViewer, it should run the GLObjectsVisitor for you,
> which should create all the OpenGL objects your entire scene graph requires.
> You can set a breakpoint in the GLObjectsVisitor to ensure this is
> happening.
>
> If the GLObjectsVisitor is being run and appears to be doing its job, then
> you still might experience the issue you describe if you have simply
> exhausted physical RAM on the graphics card and need to swap OpenGL objects
> in and out as needed.
>
> Paul Martz
> *Skew Matrix Software LLC*
> http://www.skew-matrix.com
> 303 859 9466
>
>
>
>
>  --
> *From:* [EMAIL PROTECTED] [mailto:
> [EMAIL PROTECTED] *On Behalf Of *Emilio Lozano
> *Sent:* Wednesday, February 13, 2008 11:06 AM
> *To:* osg-users@lists.openscenegraph.org
> *Subject:* [osg-users] Extra workload during first render of a model
>
> Hi all,
>
> In my application I load all the models I need before start to render the
> scene. These models are loaded from flt files (heavy models with a lot of
> data). These objects are spread along the scene, I mean, not all of them are
> watched at the same time. When I move the camera around,  the problem arises
> when it's the time to render one of the models for the first time, the
> application gets frozen for a couple of seconds. I guess that although the
> model is yet loaded, when it is the first render of the model there are some
> work that is done inside OSG (for example, I read in OpenSceneGraph Quick
> Start Guide that during the first render pass, OSG creates an OpenGL texture
> object to store the image data contained in osg::Texture2D).
>
> I wonder if it's a way to do all the job needed before the first render of
> the object, to achieve a continuous execution of my application.
>
> Thanks in advance.
>
> Emilio Lozano.
>
>
> ___
> 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