[osg-users] OSG Training

[Paul Martz]

Hi all -- Just another reminder about the upcoming OSG Training courses in
Washington DC, Jan 22-24. You can register online here:
http://www.skew-matrix.com/training.asp

If your company would like to pay using a PO, we can accommodate that.
Please contact me directly.

Thanks,

Paul Martz
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] StateSet bin mode

[Paul Martz]

Thanks, Tim -- Now that I've had a closer look, let me regurgitate what you
said. Tell me if it seems I'm missing something.

CullVisitor encounters a Node, and it's StateSet bin mode is:

- INHERIT: The CullVisitor does not change the current RenderBin, and
continues traversal.

- Not INHERIT (and no parent Node's StateSet had bin mode set to OVERRIDE):
In this case, the CullVisitor creates (or reuses, if already created) a new
RenderBin using the StateSet's bin number and name, then continues
traversal.

- OVERRIDE: The CullVisitor increments a counter to indicate that a parent
Node's StateSet had bin mode OVERRIDE, then it continues traversal.

Users should use INHERIT to have Drawables stored in the current RenderBin.
Users should use USE or OVERRIDE to create a new RenderBin or change to a
RenderBin previously created. The reason you'd want to use OVERRIDE is to
suppress creation or switching to different RenderBins in the subgraph.

Hm. Interesting. Let me sleep on this now and grow a few neural connections.

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] About virtualplanetbuilder (Robert Osfield)

[GuiYe]

 
 
 
 
   Hello,Rebert! 
 
   Thanking for your answering! When can I use the virtualplanetbuilder 0.93 in 
windows? I hope that you can give us a detailed document about how to use the 
virtualplanetbuilder 0.93 when the virtualplanetbuilder 0,93 is release.Waiting 
for your good news!
 
   Thanks!___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] SKYBOX ?

[Jean-Sébastien Guay]

Hello ümit,

I want to skybox for surround my terrain! How can I do ? Which way   
is the easiest? And is there any example?


I don't believe there is any example of this in OSG right now. This  
has come up a few times recently on the list. Here is some code I  
developed to create a skybox out of a vertical cross cubemap, like the  
ones you can find on http://www.debevec.org/Probes/ . I hope it is  
useful.


To use it:

  osg::Node* skybox = createSkyBoxCubeMap(filename);

Then put the returned node under your scene root. Optionally, you can  
pass a stateset as second argument, which will be used on the cubemap,  
and then you can change the cubemap image at run time. This was used  
in my Masters project. But the default second argument of zero will  
just create a stateset.


The filename must be a vertical cross cubemap. It can be in HDR format  
or any other format that OSG supports. HDR images will be clamped (no  
tone mapping is done).


One note: I have found that using the cubemaps on debevec.org, I had  
to resize them down by 1 pixel (they are 1024x1365, resize it to  
1023x1364) so that the dimensions are divisible by the number of  
images in each direction (3 horizontally, 4 vertically). You can use  
HDRShop (available at http://projects.ict.usc.edu/graphics/HDRShop/)  
to resize HDR images. YMMV.


This could be modified to use 6 images, and would actually be much  
simpler, as most of the code relates to extracting the 6 faces from  
the vertical cross, and then rotating/mirroring them correctly so they  
appear on the skybox in the correct orientation.


Hope this helps,

J-S
--
__
Jean-Sebastien Guay [EMAIL PROTECTED]
http://whitestar02.webhop.org/


This message was sent using IMP, the Internet Messaging Program.

//---
// (c) 2006-2008   Jean-S�bastien Guay
// 
// This code will create a skybox in OpenSceneGraph. The core of it comes
// from Farshid Lashkari  - see 
// http://openscenegraph.org/archiver/osg-users/2005-June/0581.html
//
// I added the functionality to be able to extract the six cube face 
// textures from a vertical cross texture such as the ones on
// http://www.debevec.org/Probes/.
//
// This code is distributed in the hope it will be useful, but without 
// any warranty whatsoever. You may use it in any project, as well as modify
// it without restriction, as long as this notice is retained in the 
// relevant files.
//---

#ifndef __SKYBOX_H__
#define __SKYBOX_H__ 1

#include 
#include 

osg::Node* createSkyBoxCubeMap(const std::string& cubemap, osg::StateSet* 
stateset = 0);

#endif
//---
// (c) 2006-2008   Jean-S�bastien Guay
// This code is distributed in the hope it will be useful, but without 
// any warranty whatsoever. You may use it in any project, as well as modify
// it without restriction, as long as this notice is retained in the 
// relevant files.
//---

#include "Skybox.h"

#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 

#include "osgUtil.h"

class SkyboxTransform : public osg::Transform
{
public:
// Get the transformation matrix which moves from local coords to world 
coords.
virtual bool computeLocalToWorldMatrix(osg::Matrix& matrix,
osg::NodeVisitor* nv) const
{
osgUtil::CullVisitor* cv = dynamic_cast(nv);
if (cv)
{
osg::Vec3 eyePointLocal = cv->getEyeLocal();
matrix.preMult(osg::Matrix::translate(eyePointLocal));
}

return true;
}

// Get the transformation matrix which moves from world coords to local 
coords.
virtual bool computeWorldToLocalMatrix(osg::Matrix& matrix,
osg::NodeVisitor* nv) const
{
osgUtil::CullVisitor* cv = dynamic_cast(nv);
if (cv)
{
osg::Vec3 eyePointLocal = cv->getEyeLocal();
matrix.postMult(osg::Matrix::translate(-eyePointLocal));
}

return true;
}
};

osg::Node* createSkyBoxCubeMap(const std::string& cubemap, osg::StateSet* 
stateset)
{
float radius = 100.0f;

if (!stateset)
stateset = new osg::StateSet;

// Set texture mode to REPLACE
osg::TexEnv* te = new osg::TexEnv;
te->setMode(osg::TexEnv::REPLACE);
stateset->setTextureAttributeAndModes(0, te, osg::StateAttribute::ON);

// Turn off lighting and cull face
stateset->setMode(GL_LIGHTING,  osg::StateAttribute::OFF);
stateset->setMode(GL_CULL_FACE, osg::StateAttribute::OFF);

// Basic princip

[osg-users] SKYBOX ?

[ümit uzun]

Hi All;

I want to skybox for surround my terrain! How can I do ? Which way is the 
easiest? And is there any example? 

I have try to make a skybox looked at the osgtexture2D.cpp . Is it good way to 
do or not?
_
Windows Live Messenger'ın için Ücretsiz 30 İfadeyi yükle
http://get.live.com
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] New osgPPU NodeKit (RTT, multipass postprocessing), take a look!

[Art Tevs]

Hi Markus,


> my Hardware at home is not the best  for testing
> this (AGP8x, 7600GS) , 
> but soon I will try get a new system with 2x 8800GT
> and a mainboard with 
> 750i SLI Chipset. Today I can only render 512x512,
> else the framerate  
> is going down under 10 Hz. It should run much faster
> on a new system.
I do not know exactly why, but actually the framerate
shouldn't be so slow. In my current project
implementation (Mipmaps for Heightfield Intersection
which is also on the homepage under I3D08) I have used
the full set of PPUs again (Depth Of Field + HDR +
extra Set to compute the Mipmap for the algorithm + to
compute the normal map for the heightmap on the fly)
and the performance never falls under 100Hz (when only
simple things are visible) 

Unfortunately the osgPPU example does run only with
50Hz and has only a small subset of PPUs on the same
machine. I think there is something wrong with vsync
or other settings, because actually it should be much,
much, much faster. In all the other projects I have
used GLFW to open the window, maybe this has some
advantages, I do not know. (changing the vsync
settings in the driver doesn't help)

 
> When using the osgPPU lib for applications, it seems
> for me that a 
> little bit training is required to get predictable
> and good results when 
> combining and reusing lots of units. I tried to
> change/animate some 
> parameter/uniforms to find out how it works.
> Changing some of the 
> PP-Unit's index was a funny experiment.

Yeah, I understand that fact. It is not really clear
in the beginning how to use them. But after you get
familar with it, it is much much easier (whener there
are no bugs in the ppu implementation) to create nice
effects. Even more I have used them also for GPGPU,
like I mentioned before to precompute the dataset for
the algorithm and to compute normal map from the
heightfield data. 


> Hmm, it was not difficult to get your lib built and
> running, but I'm 
> affraid that I have to study about "Light Physics"
> first, before I can 
> contribute to implement such Effects like "Eikonal
> Rendering".  At the 
> moment , unfortunately there is not enough time for
> starting advanced 
> stuff  because of job and family. I just try to
> follow the current 
> osg-development.
I see. No problem. Eikonal Rendering has not to be
implemented, I just want to include some more specific
stuff for which ppus are ideal. For example Deferred
Lighting is that what the ppus are really good for.


> For making users more familiar with osgPPU, maybe
> there is  a need for a 
> GUI application - like a "osgPPU Browser" with
> embedded osg-viewer. I 
> can try starting such Project after work for learnig
> more about uses of 
> osgPPU. Personally, I think that interactive control
> and animation of 
> shader parameters, unit index etc. could be helpful
> for osgPPU users 
> under application development.
I have one guy here at the institute, who has created
such a gui while ago. He has created this for his own
purpose, but as I saw that, I thought directly: "Wow,
how that guy knows that this is really what I have
looked for ;-)" I'll ask him, if it is possible to
reuse his software.

But you are right, at least a browser of ppus is
needed to just be able to have an overview over the
ppu pipeline which is currently used. Take a look into
PostProcess.cpp and change #define DEBUG_PPU to 1 and
you can get output how the pipeline is looks like
while rendering. It is not the best, but good to
debug.



Best,
Art



   __  Ihre erste Baustelle? Wissenswertes 
für Bastler und Hobby Handwerker. www.yahoo.de/clever
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Blue Marble example

[Michael W. Hall]

I am looking at the Blue Marble example that come with the source.  I
have a question about the createWorld function.  The first line of the
function they are getting a readerwriter.  They make a call to
getReaderWriterForExtension("gdal").  What is this extension and how do
you know what extensions to pass in?  Is there a list of them somewhere?



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

Re: [osg-users] StateSet bin mode

[Paul Martz]

> Stare hard at CullVisitor::pushStateSet :)

Been there. :-) But with the info you've provided, perhaps a second stare is
in order. Thanks.
   -Paul

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

[osg-users] Intersection using C#

[Ke Li]

Hi all,
 
I'm using C# to implement picking in OSG for my project.
 
I created a OsgUtil.PolytopeIntersector object (picker) in my pick method and 
registered it to a OsgUtil.IntersectionVisitor. The picker seems to work when I 
called OsgUtil.PolytopeIntersector.Intersection intersection = 
picker.getFirstIntersection(). But I'm stuck here, because I couldn't see any 
methods that obtain the picked nodes from the intersection object.
 
In C++, it is simple to do so:
osgUtil::LineSegmentIntersector::Intersection intersection = 
picker->getFirstIntersection();
osg::NodePath& nodePath = intersection.nodePath;
osg::Node* node = (nodePath.size()>=1)?nodePath[nodePath.size()-1]:0;
osg::Group* parent = 
(nodePath.size()>=2)?dynamic_cast(nodePath[nodePath.size()-2]):0;
 
 
If anyone knows how to obtain picked nodes using C#, please give me some 
advice. Your help is highly appreciated!
 
 
Regards,
 
 
Ke Li
_
Make distant family not so distant with Windows Vista® + Windows Live™.
http://www.microsoft.com/windows/digitallife/keepintouch.mspx?ocid=TXT_TAGLM_CPC_VideoChat_distantfamily_012008___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] StateSet bin mode

[Tim Moore]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Paul Martz wrote:
| Hi Robert -- The bin mode parameter of setRenderBinDetails doesn't appear to
| be clearly documented. Looking into it, it's somewhat confusing. I'm hoping
| you can tell me what affect one should expect when setting one of
| INHERIT_RENDERBIN_DETAILS (default), USE_RENDERBIN_DETAILS, or
| OVERRIDE_RENDERBIN_DETAILS.
|
| As near as I can tell, these only have an effect on the state graph
| constructed by the CullVisitor. Perhaps it'd be useful if you could
| elaborate on the state graph and how these values control it?
|
| In my own tinkering, I've found that INHERIT_RENDERBIN_DETAILS produces a
| nested processing order, as we've discussed previously on this list. Three
| nodes with bin numbers 1, 2, and 3, with the Node using bin 2 having two
| children, and the two children use bin number 0 and 5 (or, graphically:)
|   Root (bin details unspecified) Group with 3 children
| NodeA (bin# 1)
| NodeB (bin# 2) Group with 2 children
|   NodeBsub0 (bin# 0)
|   NodeBsub1 (bin# 4)
| NodeC (bin# 3)
|
| With INHERIT, I get the following render order: NodeA, NodeBsub0, NodeBsub1,
| NodeC. NodeBsub0 and NodeBsub1 inherit their parent's bin number for
| processing relative to the parent's siblings. This makes sense, and I can
| document it.
If all these nodes' state sets use INHERIT, then the bin numbers have no effect 
on the
the rendering order, as I understand it. The order you are seeing looks like 
what
you'd get with an in-order traversal of the tree.
|
| If I set all nodes to USE, the render order is the same as INHERIT.

In this case, sure: the bins for NodeA, NodeB and NodeC's state sets are 
arranged in
that order in the root render bin, with NodeBsub0 and NodeBsub1 in order in 
NodeB's bin.

| However, I do get interesting results if I set all nodes to USE _except_ for
| NodeB, which I leave as INHERIT. In this scenario, render bin numbers appear
| to specify absolutely rendering order: NodeBsub0, NodeA, NodeC, NodeBsub1.
That's because the bins established by the state sets with USE are all 
arranged, in
numeric order, in the root's render bin.
|
| I've yet to find a use for OVERRIDE.
|
| Any light you can shed would be appreciated. The code is not clear.
USE establishes a current render bin and gives it an order relative to other 
render bins
and drawables in the parent render bin. The parent render bin is the previous 
current
render bin.

INHERIT doesn't change anything and has no effect on the draw order.

OVERRIDE is like USE, except it disables the creation of new render bins in the 
nodes
under state set's node.

Stare hard at CullVisitor::pushStateSet :)

Tim
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHhpiSeDhWHdXrDRURAo+CAKCZJffXK/PuTwD5L3CA3k673RvNiQCgp0YT
JJym39EMPfVK5/sbM0u34UM=
=Yshf
-END PGP SIGNATURE-
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] VPB in SVN

[Jean-Sébastien Guay]

Hello Robert,

> Any chance you could make available the data and osgdem commndline   
> you've used?

I've put the data at

   http://whitestar02.webhop.org/files/OSG/NED_59396523.zip

It's about 24MB. I'll remove it once you've gotten it... It comes from  
http://seamless.usgs.gov/, as instructed by the short tutorial at

   http://www.palomino3d.com/pal/openscenegraph/#GIS

(I selected a part of the western US seaboard, I think around Seattle,  
Washington)

The command lines I used were taken from that as well:

   mkdir test
   cd test
   /osgdem -d ../NED_59396523.tif -t ../NED_59396523.tif -o  
terrain.ive -a terrain.osga -l 8 -v 0.08

and

   mkdir test
   cd test
   /osgdem -d ../NED_59396523.tif -t ../NED_59396523.tif  
--terrain -o terrain.ive -a terrain.osga -l 8 -v 0.08

Let me know if that helps, or if you need something else.

J-S
-- 
__
Jean-Sebastien Guay [EMAIL PROTECTED]
 http://whitestar02.webhop.org/


This message was sent using IMP, the Internet Messaging Program.


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

Re: [osg-users] polytopeIntersector

[Robert Osfield]

HI Gianluca,

In the 2.3.x dev release and SVN of the OSG there are improvements to
the PolytopeIntersector that might help you so it'd be worth trying
out over using 2.2

Robert.

On Jan 10, 2008 5:46 PM, Gianluca Natale <[EMAIL PROTECTED]> wrote:
>
>
>
>
> Hi all!
>
>
>
> I'm trying to use a osgUtil::PolytopeIntersector
>
> to find the closest object in my 3D scene graph (with OSG ver.2.2).
>
> I read on the OSG QSG that it should return the closest object
>
> as the first in the list of intersections.
>
> But it is not like that!
>
> I mean that the array of intersections correctly contains all of
>
> the objects hit by the intersection volume,
>
> but the first of those is not necessary the closest.
>
> BTW, it seems to be the object with the shortest node path. Might it be?
>
>
>
> Any idea of my mistake?
>
>
>
> Thank you in advance.
>
>
>
> Gianluca
>
>
>
> P.S.=attached is the source file (look into the class PickHandler,
>
> in the method pick; first I tried getting directly the first
> intersection in
>
> the list, picker->getFirstIntersection(); then I tried to sort
>
> the intersection on my own. But I pick always the background
> rectangle!)
>
>
> ___
> 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] VPB in SVN

[Robert Osfield]

On Jan 10, 2008 5:27 PM, Jean-Sébastien Guay
<[EMAIL PROTECTED]> wrote:
> Sorry for the little info, don't really know what to give. The osgdem
> without --terrain just finished, it worked and looks great. Running
> with --terrain ran a lot faster, but I can't see anything in osgviewer
> with the resulting file. The file is over twice the size (~500k versus
> ~202k without --terrain). It doesn't really matter either way - I was
> just trying it out.

Something is amiss, --terrain normally results in smaller files.  I
haven't seen any problem with rendering of them either.

Any chance you could make available the data and osgdem commndline you've used?

> Thanks, I'll look those up. Geotiffs are the most common/useful, is
> that correct? (just assuming from what I've read in the past on this
> list)

Any data with geospatial coords system assigned to them will work
pretty well, GeoTiff is the most common one for imagery.

Image and DEM's without geospatial coord system are a pain as you have
to manually specify things.

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

Re: [osg-users] New osgPPU NodeKit (RTT, multipass postprocessing), take a look!

[Markus Hein]

Hi Art,

> Cool, I am glad to hear that the library also runs on
> another machines.
my Hardware at home is not the best  for testing this (AGP8x, 7600GS) , 
but soon I will try get a new system with 2x 8800GT and a mainboard with 
750i SLI Chipset. Today I can only render 512x512, else the framerate  
is going down under 10 Hz. It should run much faster on a new system.

> As I have mentioned on the osgPPU Homepage I am
> planning to release Depth of Field example
> application. In my application I had already that
> effect running. Hence there is only a proper example
> application needed to setup it.
When using the osgPPU lib for applications, it seems for me that a 
little bit training is required to get predictable and good results when 
combining and reusing lots of units. I tried to change/animate some 
parameter/uniforms to find out how it works. Changing some of the 
PP-Unit's index was a funny experiment.

> Because you like
> to implement another testing application you can try
> to implement the depth of field effect. I can upload
> all the shaders and a xml description of the ppu setup
> to run depth of field as in Eikonal Rendering (demo
> video on my homepage). What do you think?
Hmm, it was not difficult to get your lib built and running, but I'm 
affraid that I have to study about "Light Physics" first, before I can 
contribute to implement such Effects like "Eikonal Rendering".  At the 
moment , unfortunately there is not enough time for starting advanced 
stuff  because of job and family. I just try to follow the current 
osg-development.

For making users more familiar with osgPPU, maybe there is  a need for a 
GUI application - like a "osgPPU Browser" with embedded osg-viewer. I 
can try starting such Project after work for learnig more about uses of 
osgPPU. Personally, I think that interactive control and animation of 
shader parameters, unit index etc. could be helpful for osgPPU users 
under application development.


> Currently I have to prepare some video sequences for
> the upcoming Siggraph deadline, therefor I do not have
> a lot of free time to improve osgPPU.
I don't want to stop you :-)  Interestings papers and videos on the 
"Eikonal Rendering" project-page


Regards, Markus




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

[osg-users] StateSet bin mode

[Paul Martz]

Hi Robert -- The bin mode parameter of setRenderBinDetails doesn't appear to
be clearly documented. Looking into it, it's somewhat confusing. I'm hoping
you can tell me what affect one should expect when setting one of
INHERIT_RENDERBIN_DETAILS (default), USE_RENDERBIN_DETAILS, or
OVERRIDE_RENDERBIN_DETAILS.

As near as I can tell, these only have an effect on the state graph
constructed by the CullVisitor. Perhaps it'd be useful if you could
elaborate on the state graph and how these values control it?

In my own tinkering, I've found that INHERIT_RENDERBIN_DETAILS produces a
nested processing order, as we've discussed previously on this list. Three
nodes with bin numbers 1, 2, and 3, with the Node using bin 2 having two
children, and the two children use bin number 0 and 5 (or, graphically:)
  Root (bin details unspecified) Group with 3 children
NodeA (bin# 1)
NodeB (bin# 2) Group with 2 children
  NodeBsub0 (bin# 0)
  NodeBsub1 (bin# 4)
NodeC (bin# 3)

With INHERIT, I get the following render order: NodeA, NodeBsub0, NodeBsub1,
NodeC. NodeBsub0 and NodeBsub1 inherit their parent's bin number for
processing relative to the parent's siblings. This makes sense, and I can
document it.

If I set all nodes to USE, the render order is the same as INHERIT.

However, I do get interesting results if I set all nodes to USE _except_ for
NodeB, which I leave as INHERIT. In this scenario, render bin numbers appear
to specify absolutely rendering order: NodeBsub0, NodeA, NodeC, NodeBsub1.

I've yet to find a use for OVERRIDE.

Any light you can shed would be appreciated. The code is not clear.

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] polytopeIntersector

[Daniel Moos]

Hi Gianluca

You say you wish to get the nearest intersection with the PolytopeIntersector...

I think the mistake is here:
osg::NodePath& nodePath = 
/*picker->getFirstIntersection()*/closestIntersection.nodePath;

If you want to have the nearest intersection, you must get the first 
intersection from the picker...
osg::NodePath& nodePath = picker->getFirstIntersection();

We also use the Polytope Intersector in our Project. And it works great!
Daniel


Am Donnerstag, 10. Januar 2008 18.46:18 schrieb Gianluca Natale:
> Hi all!
>
>
>
> I'm trying to use a osgUtil::PolytopeIntersector
>
> to find the closest object in my 3D scene graph (with OSG ver.2.2).
>
> I read on the OSG QSG that it should return the closest object
>
> as the first in the list of intersections.
>
> But it is not like that!
>
> I mean that the array of intersections correctly contains all of
>
> the objects hit by the intersection volume,
>
> but the first of those is not necessary the closest.
>
> BTW, it seems to be the object with the shortest node path. Might it be?
>
>
>
> Any idea of my mistake?
>
>
>
> Thank you in advance.
>
>
>
> Gianluca
>
>
>
> P.S.=attached is the source file (look into the class PickHandler,
>
> in the method pick; first I tried getting directly the first
> intersection in
>
> the list, picker->getFirstIntersection(); then I tried to sort
>
> the intersection on my own. But I pick always the background
> rectangle!)


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

[osg-users] polytopeIntersector

[Gianluca Natale]

Hi all!

 

I'm trying to use a osgUtil::PolytopeIntersector

to find the closest object in my 3D scene graph (with OSG ver.2.2).

I read on the OSG QSG that it should return the closest object

as the first in the list of intersections.

But it is not like that!

I mean that the array of intersections correctly contains all of

the objects hit by the intersection volume,

but the first of those is not necessary the closest.

BTW, it seems to be the object with the shortest node path. Might it be?

 

Any idea of my mistake?

 

Thank you in advance.

 

Gianluca

 

P.S.=attached is the source file (look into the class PickHandler,

in the method pick; first I tried getting directly the first
intersection in

the list, picker->getFirstIntersection(); then I tried to sort

the intersection on my own. But I pick always the background
rectangle!)

 

// Test 11: OSG 3D application with node callback to dynamically modify the 
graph,
//  changing the color of an object when it is picked by the user (and 
restoring
//  it to the original color once no object is selected any more).
//  It creates a scene graph, and shows it in a window created by the 
osgViewer::Viewer.
//  The camera is kept rotating around the scene to let it be seen from 
many different
//  points of view (that is accomplished by directly modifying the 
modelview matrix
//  of the camera in the main loop).
//  When the user picks a point onto the screen (picking is checked by 
deriving a class
//  from an osgGA::GUIEventHandler), a Polytope intersector is created 
and
//  passed to an IntersectionVisitor. So, at the end it 
will return the list of selected
//  objects, sorted from the nearest to the viewer up to the farthest.
//  Then the picker will attach a ChangeColor callback to 
the nearest selected node, in
//  order to change its current color to the 'selection' color in the 
next update traversal.
//  Note that the color is changed by changing the material properties 
of the object,
//  so changing the corresponding rendering state in the 
parent matrix transform of the node.

// The scene graph shown in the window is made by these nodes:
//
//MRT MRT = main root node
// |  TMn = tranformation 
matrix n
//+---++--+++ GPn = group n
//   TM1 GP1 TM6  TM7  TM8GEn = geode n
//|   ++--+--++   ||| LSn = light source n
//|  TM2  TM3   TM4  TM5  |||
//|   ++--+--++   |||
//   GE1 GE2 LS1  LS2  GE3
//
// Specifically, in this graph we have:
// GE1 = a rectangle
// GE2 = a sphere
// GE3 = a cube to show the position of the spot light source (LS2)
// LS1 = a directional light (fixed in the scene)
// LS2 = a localized spot light (moving with the scene)
/

#include// include the class osg::ref_ptr, to manage the smart 
osg ref_ptr
 // (a smart pointer to Referenced objects in OSG)
#include   // include the class osg::Geometry to manage the 
geometry of a drawable
 // (vertices, colors, normals)
#include  // include the class osg::geode (geode stands for 
GEOmetry noDE),
 // that is to say the node which stores the geometry 
of an object
#include   // for material properties, when an object is lit by a 
light source
#include  // for the generic shape drawable used to 
implement spheres, cylinders, etc...
#include  // to store a source of light in the scene graph, in 
order to lit the scene
#include  // to deal with transformation matrices
#include  // to store a group node, that is to say a node that can 
have child nodes
#include  // to store the shade model of an object (FLAT or 
SMOOTH)

#include  // to include the viewer, which creates a window 
and a rendering
// context, to make it current for OpenGL drawing 
commands

#include   // for node callback, that allows a 
dynamic modification of the graph
#include  // (during the update traversal)

#include  // the base class to handle events from the 
user
#include  
#include 

#include  // to check intersection against a 
polytope and objects
#include  // in the scene

#include 
#include 
using std::endl;

///
// A class derived from NodeCallback to allow dynamic modification of a 
transformation
// matrix (that is to say, the material properties associated with that matrix)
class ChangeColorCB : public osg::NodeCallback
{
public:
ChangeColorCB(osg::

Re: [osg-users] INT32 redeifinition with Win32 and VS8binary package

[Mike Weiblen]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:osg-users-
> [EMAIL PROTECTED] On Behalf Of Jean-Sébastien Guay
> Sent: Wednesday, January 09, 2008 6:19 PM
> To: osg-users@lists.openscenegraph.org
> Subject: Re: [osg-users] INT32 redeifinition with Win32 and VS8binary
> package
...
> 
> To reply to Philip Taylor about the 64-bit issues, this is a 3rd party
> header, so OSG has little control over it. On the other hand, it comes
> from libjpeg, which is very popular and is used on almost all linux
> distros (most of which are  built both 32 and 64 bit these days), so I
> imagine if there were any 64-bit-cleanliness issues, they would have
> heard about them by now. That is not to discount your point, which
> could very well be correct, but it's "out of OSG's hands" anyways.

FWIW, when I generate my 3rdParty libs, I develop a patchset against the 
upstream source; that's how I document and encapsulate the mods necessary to 
build the libs in an OSG-friendly manner.  In fact, that patchset, to me, is 
the main value of my 3rdParty SVN; the actual binaries are just mechanical 
products derived from the patchset information. (tho having those mechanical 
products is obviously of value in themselves)

So if something in the 3rdParty libs needs tweaking for OSG, I'm willing to 
accept submissions.

Similarly, if anyone wants to contribute build-clues for other 3rdParty libs 
(eg lib in the VS7.1 set not yet ported to VS8), I'd welcome.  To reiterate, I 
don't want prebuilt binaries, I want the source/buildsystem mods to generate 
the binaries.  (For folks familiar with linux distros, an analogy is to be more 
Gentoo-like rather than RedHat-like.)

Cheers
-- mew



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

Re: [osg-users] VPB in SVN

[Jean-Christophe Lombardo]

Jean-Sébastien Guay wrote:
> Is there any reference to the various formats that osgdem can use? I  
> could wait until Paul and Bob's course, but I'm curious :-)
>   
As far as I understand, osgdem relies on gdal to read dem & texture 
files. So osgdem supported formats are gdal ones and GEOTiff is part of 
them.
I am using the FWTools (http://fwtools.maptools.org/) precompiled gdal 
package instead of the one provided by osg 3rd party binaries to gain an 
access to more format and to the corresponding gdal tools (gdalinfo, 
gdalwarp an so on).

jcl




 
 

This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer 
viruses.




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

Re: [osg-users] VPB in SVN

[Jean-Sébastien Guay]

Hello Robert,

> --terrain should work fine with imagery only databases, not seeing
> something suggests problems somewhere, but where? How knows with so
> little info to go on.  Does the generated database run without if you
> don't use the --terrain option?

Sorry for the little info, don't really know what to give. The osgdem  
without --terrain just finished, it worked and looks great. Running  
with --terrain ran a lot faster, but I can't see anything in osgviewer  
with the resulting file. The file is over twice the size (~500k versus  
~202k without --terrain). It doesn't really matter either way - I was  
just trying it out.

> gdal is used for loaded all imagery and dem's so simpy run
>
>gdalinfo --formats

Thanks, I'll look those up. Geotiffs are the most common/useful, is  
that correct? (just assuming from what I've read in the past on this  
list)

J-S
-- 
__
Jean-Sebastien Guay [EMAIL PROTECTED]
 http://whitestar02.webhop.org/


This message was sent using IMP, the Internet Messaging Program.


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

Re: [osg-users] osgVolume example bug?

[Gerrick Bivins]

Hi,If you are referring to the "slices" that you see, this is a typical
artifact in volume rendering applications due
to under-sampling (low number of polygon slices).  A simple solution
(not efficient though) is to increase the number of slices
until the artifact goes away (usually 2*max_texture_dimension).There are
other solutions (more efficient)out there
as well...(The Real-Time volume
Graphicsbook is a great
reference).If you are not talking about the
slicing, it's not very clear what you mean by "And notice the head,it's a
little strange"
biv
On Jan 10, 2008 10:59 AM, hesicong2006 <[EMAIL PROTECTED]> wrote:

> Thanks Robert and could you try my volume data? (Sorry its too big for
> email, but you can download from http://www.hesicong.net/volumedata.rar)
> You can see the animated failure.
> I recaptured the image, P1.jpg and P2.jpg use the default setting you
> provided. In P3, I decreased the sampleDensity, but it still have the
> problem.
> At last my computer is:
> CPU: Intel Core 2 Duo Q6600
> RAM: 3G
> GPU: Geforce 8800GTS 320M with 169.09 driver under XP. I think it will
> not be hardware failure or driver failure. Is that caused by projection
> view? I tried to modify it to ortho view, but I even can't see the
> volume cube~~~
>
> At last the command I use is here, thanks again for your help.
> osgvolumed --shader --replace-alpha-with-luminance --images 000.TIF
> 001.TIF 002.TIF 003.TIF 004.TIF 005.TIF 006.TIF 007.TIF 008.TIF 009.TIF
> 010.TIF 011.TIF 012.TIF 013.TIF 014.TIF 015.TIF 016.TIF 017.TIF 018.TIF
> 019.TIF 020.TIF 021.TIF 022.TIF 023.TIF 024.TIF 025.TIF 026.TIF 027.TIF
> 028.TIF 029.TIF 030.TIF 031.TIF 032.TIF 033.TIF 034.TIF 035.TIF 036.TIF
> 037.TIF 038.TIF 039.TIF 040.TIF 041.TIF 042.TIF 043.TIF 044.TIF 045.TIF
> 046.TIF 047.TIF 048.TIF 049.TIF 050.TIF 051.TIF 052.TIF 053.TIF 054.TIF
> 055.TIF 056.TIF 057.TIF 058.TIF 059.TIF 060.TIF 061.TIF 062.TIF 063.TIF
> 064.TIF 065.TIF 066.TIF 067.TIF 068.TIF 069.TIF 070.TIF 071.TIF 072.TIF
> 073.TIF 074.TIF 075.TIF 076.TIF 077.TIF 078.TIF 079.TIF 080.TIF 081.TIF
> 082.TIF 083.TIF 084.TIF 085.TIF 086.TIF 087.TIF 088.TIF 089.TIF 090.TIF
> 091.TIF 092.TIF 093.TIF 094.TIF 095.TIF 096.TIF 097.TIF 098.TIF 099.TIF
> 100.TIF 101.TIF 102.TIF 103.TIF 104.TIF 105.TIF 106.TIF 107.TIF 108.TIF
> 109.TIF 110.TIF 111.TIF 112.TIF 113.TIF 114.TIF 115.TIF 116.TIF 117.TIF
> 118.TIF 119.TIF 120.TIF 121.TIF 122.TIF 123.TIF 124.TIF 125.TIF 126.TIF
> 127.TIF 128.TIF 129.TIF 130.TIF 131.TIF 132.TIF 133.TIF 134.TIF 135.TIF
> 136.TIF 137.TIF 138.TIF 139.TIF 140.TIF 141.TIF 142.TIF 143.TIF 144.TIF
> 145.TIF 146.TIF 147.TIF 148.TIF 149.TIF 150.TIF 151.TIF 152.TIF 153.TIF
> 154.TIF 155.TIF 156.TIF 157.TIF 158.TIF 159.TIF 160.TIF 161.TIF 162.TIF
> 163.TIF 164.TIF 165.TIF 166.TIF 167.TIF 168.TIF 169.TIF 170.TIF 171.TIF
> 172.TIF 173.TIF 174.TIF 175.TIF 176.TIF 177.TIF 178.TIF 179.TIF 180.TIF
> 181.TIF 182.TIF 183.TIF 184.TIF 185.TIF 186.TIF 187.TIF 188.TIF 189.TIF
> 190.TIF 191.TIF 192.TIF 193.TIF 194.TIF 195.TIF 196.TIF 197.TIF 198.TIF
> 199.TIF 200.TIF 201.TIF 202.TIF 203.TIF 204.TIF 205.TIF 206.TIF 207.TIF
> 208.TIF 209.TIF 210.TIF 211.TIF 212.TIF 213.TIF 214.TIF 215.TIF 216.TIF
> 217.TIF 218.TIF 219.TIF 220.TIF 221.TIF 222.TIF 223.TIF 224.TIF 225.TIF
> 226.TIF 227.TIF 228.TIF 229.TIF 230.TIF 231.TIF 232.TIF 233.TIF 234.TIF
> 235.TIF 236.TIF 237.TIF 238.TIF 239.TIF 240.TIF 241.TIF 242.TIF 243.TIF
> 244.TIF 245.TIF 246.TIF 247.TIF 248.TIF 249.TIF 250.TIF 251.TIF 252.TIF
> 253.TIF 254.TIF 255.TIF
>
> Robert Osfield wrote:
> > Hi,
> >
> > I'm the author of the osgvolume example.  Its just a quick
> > prototype/proof of concept, and one I haven't touched in the last year
> > or two so its a bit cold.   The visual errors on the frame region
> > you've observed aren't ones I've seen before, but then I've never
> > played with a volume dataset that has a frame in it.  I'm afraid I
> > can't think of any obvious failure modes that would introduce these
> > artefacts.  Try different hardware/OpenGL drivers/OS to see if the
> > artefacts changes.  As for the head region, I can't spot any problem.
> >
> > Robert.
> >
> > On Jan 10, 2008 6:40 AM, hesicong2006 <[EMAIL PROTECTED]> wrote:
> >
> >> Hi everyone:
> >> I'm now doing a medical application using volume rendering technology.
> >> osgVolume example gives me a very good start, thanks to people who
> >> contributes to this example. But I found some image errors (see
> >> attachments) , In p1.jpg, see the red circle, the outboder line bends.
> >> In p2.jpg, the line bends more than that in p1.jpg. And notice the
> head,
> >> it's a little strange. I tried to fix this problem, but I still can't
> >> figure out why it happens to be like this.Does someone can help me or
> >> point out why it appears like this?
> >> Thanks very much!
> >>
> >> ___
> >> osg-users mailing list
> >> osg-users@lists.openscenegraph.org
> >>
> http://lists.openscenegrap

Re: [osg-users] VPB in SVN

[Robert Osfield]

On Jan 10, 2008 4:47 PM, Jean-Sébastien Guay
<[EMAIL PROTECTED]> wrote:
> Hello Robert,
>
> > If its a dataset with DEM's try adding --terrain to the command line
>
> If that gives me a file which doesn't display anything (when given to
> osgviewer) does that mean that --terrain didn't work, or does it mean
> that the dataset didn't have DEMs? I *think* I'm using geotiffs (still
> very new to this!).

--terrain should work fine with imagery only databases, not seeing
something suggests problems somewhere, but where? How knows with so
little info to go on.  Does the generated database run without if you
don't use the --terrain option?

> Is there any reference to the various formats that osgdem can use? I
> could wait until Paul and Bob's course, but I'm curious :-)

gdal is used for loaded all imagery and dem's so simpy run

   gdalinfo --formats

When I do this on my machine I get:

Supported Formats:
  VRT (rw+): Virtual Raster
  GTiff (rw+): GeoTIFF
  NITF (rw+): National Imagery Transmission Format
  HFA (rw+): Erdas Imagine Images (.img)
  SAR_CEOS (ro): CEOS SAR Image
  CEOS (ro): CEOS Image
  ELAS (rw+): ELAS
  AIG (ro): Arc/Info Binary Grid
  AAIGrid (rw): Arc/Info ASCII Grid
  SDTS (ro): SDTS Raster
  OGDI (ro): OGDI Bridge
  DTED (rw): DTED Elevation Raster
  PNG (rw): Portable Network Graphics
  JPEG (rw): JPEG JFIF
  MEM (rw+): In Memory Raster
  JDEM (ro): Japanese DEM (.mem)
  GIF (rw): Graphics Interchange Format (.gif)
  ESAT (ro): Envisat Image Format
  BSB (ro): Maptech BSB Nautical Charts
  XPM (rw): X11 PixMap Format
  BMP (rw+): MS Windows Device Independent Bitmap
  AirSAR (ro): AirSAR Polarimetric Image
  RS2 (ro): RadarSat 2 XML Product
  PCIDSK (rw+): PCIDSK Database File
  PCRaster (rw): PCRaster Raster File
  ILWIS (rw+): ILWIS Raster Map
  SGI (ro): SGI Image File Format 1.0
  Leveller (ro): Leveller heightfield
  GMT (rw): GMT NetCDF Grid Format
  netCDF (rw): Network Common Data Format
  HDF4 (ro): Hierarchical Data Format Release 4
  HDF4Image (rw+): HDF4 Dataset
  PNM (rw+): Portable Pixmap Format (netpbm)
  DOQ1 (ro): USGS DOQ (Old Style)
  DOQ2 (ro): USGS DOQ (New Style)
  ENVI (rw+): ENVI .hdr Labelled
  EHdr (rw+): ESRI .hdr Labelled
  PAux (rw+): PCI .aux Labelled
  MFF (rw+): Vexcel MFF Raster
  MFF2 (rw+): Vexcel MFF2 (HKV) Raster
  FujiBAS (ro): Fuji BAS Scanner Image
  GSC (ro): GSC Geogrid
  FAST (ro): EOSAT FAST Format
  BT (rw+): VTP .bt (Binary Terrain) 1.3 Format
  LAN (ro): Erdas .LAN/.GIS
  CPG (ro): Convair PolGASP
  IDA (rw+): Image Data and Analysis
  NDF (ro): NLAPS Data Format
  DIPEx (ro): DIPEx
  ISIS2 (ro): USGS Astrogeology ISIS cube (Version 2)
  PDS (ro): NASA Planetary Data System
  JPEG2000 (rw): JPEG-2000 part 1 (ISO/IEC 15444-1)
  L1B (ro): NOAA Polar Orbiter Level 1b Data Set
  FIT (rw): FIT Image
  RMF (rw+): Raster Matrix Format
  WCS (ro): OGC Web Coverage Service
  RST (rw+): Idrisi Raster A.1
  RIK (ro): Swedish Grid RIK (.rik)
  USGSDEM (rw): USGS Optional ASCII DEM (and CDED)
  GXF (ro): GeoSoft Grid Exchange Format
  HDF5 (ro): Hierarchical Data Format Release 5
  HDF5Image (ro): HDF5 Dataset
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] VPB in SVN

[Jean-Sébastien Guay]

Hello Robert,

> If its a dataset with DEM's try adding --terrain to the command line

If that gives me a file which doesn't display anything (when given to  
osgviewer) does that mean that --terrain didn't work, or does it mean  
that the dataset didn't have DEMs? I *think* I'm using geotiffs (still  
very new to this!).

Is there any reference to the various formats that osgdem can use? I  
could wait until Paul and Bob's course, but I'm curious :-)

J-S
-- 
__
Jean-Sebastien Guay [EMAIL PROTECTED]
 http://whitestar02.webhop.org/


This message was sent using IMP, the Internet Messaging Program.


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

Re: [osg-users] About virtualplanetbuilder

[Jean-Sébastien Guay]

Hello GuiYe

> At the same time , I want to  know the last version of  
> virtualplanetbuilder is 0.93?

The last known-working version is 0.9.1, and the current SVN is 0.9.3  
(which was updated to compile on Windows yesterday and today, but is  
not really tested).

If you want to help testing, grab the SVN. If you just want it to  
work, grab 0.9.1.

>2. Where I can get the information about how to use the   
> virtualplanetbuilder? And I don't know that the meaning of much   
> parameters in virtualplanetbuilder.Who can tell me in detail?

I'm new to this too. I found this:

   http://www.palomino3d.com/pal/openscenegraph/#GIS

but it's a bit succinct. This has a bit more:

   http://www.openscenegraph.org/projects/osg/wiki/Support/UserGuides/osgdem

but it's a bit old so might be outdated. It also doesn't include all  
the new things in VPB SVN (see  
http://www.openscenegraph.org/projects/VirtualPlanetBuilder/wiki/DevelopmentPlans).

Good luck,

J-S
-- 
__
Jean-Sebastien Guay [EMAIL PROTECTED]
 http://whitestar02.webhop.org/


This message was sent using IMP, the Internet Messaging Program.


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

Re: [osg-users] About virtualplanetbuilder

[Robert Osfield]

On Jan 10, 2008 4:15 PM, GuiYe <[EMAIL PROTECTED]> wrote:
>   Hello,I want to ask two questions:
>
>1. Where I can get the last version of virtualplanetbuilder? I found that
> the URL:
> svn checkout
> http://www.openscenegraph.org/svn/VirtualPlanetBuilder/tags/VirtualPlanetBuilder-0.9.1
> VirtualPlanetBuilder

0.9.1 is the last stable version.

> svn checkout http://www.openscenegraph.org/svn/VirtualPlanetBuilder/trunk
> VirtualPlanetBuilder can't be useful.At the same time , I want to know the
> last version of virtualplanetbuilder is 0.93?

0.9.3 is a dev version, it only compiles under Unices.

You'll need SVN to get a version compiling under Windows.

>2. Where I can get the information about how to use the
> virtualplanetbuilder? And I don't know that the meaning of much parameters
> in virtualplanetbuilder.Who can tell me in detail?

There are basic docs on osgdem on the OSG wiki which are a bit out of
date, but still useful:

   http://www.openscenegraph.org/projects/osg/wiki/Support/UserGuides/osgdem

VPB is still under going heavy development, once this is further on
I'll be put more docs online about all the new functionality.  Up till
then please be patient.

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

Re: [osg-users] INT32 redefinition with Win32 and VS8binary package

[Jean-Sébastien Guay]

Hello Andrew,

> I'm guessing the problem might only show up in certain situations.   
> It is possible that the jmorecfg.h and the basetsd.h file are only   
> included together in certain development situations (and perhaps   
> not, for example, when compiling OSG itself)

That's probably the case, because I've done lots of OSG development  
and never seen it. It would be nice to find out why you are...

What do others think? The fix seems harmless, and I'm always a fan of  
less warnings, so we could just apply it and be done with it. I'm just  
puzzled as to why this is the first we've heard of this...

J-S
-- 
__
Jean-Sebastien Guay [EMAIL PROTECTED]
 http://whitestar02.webhop.org/


This message was sent using IMP, the Internet Messaging Program.


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

[osg-users] About virtualplanetbuilder

[GuiYe]

 
 
 
  Hello,I want to ask two questions:
  
   1. Where I can get the last version of virtualplanetbuilder? I found that 
the URL:
svn checkout 
http://www.openscenegraph.org/svn/VirtualPlanetBuilder/tags/VirtualPlanetBuilder-0.9.1
 VirtualPlanetBuilder

svn checkout http://www.openscenegraph.org/svn/VirtualPlanetBuilder/trunk 
VirtualPlanetBuilder can't be useful.At the same time , I want to know the last 
version of virtualplanetbuilder is 0.93?
 
   2. Where I can get the information about how to use the 
virtualplanetbuilder? And I don't know that the meaning of much parameters in 
virtualplanetbuilder.Who can tell me in detail?
 
Thank you !___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] INT32 redefinition with Win32 and VS8binary package

[Somerville, Andrew]

Hi J-S,

I'm running VS8/2005 on XP. The warning shows the conflict with the VS8 sdk 
file:
   microsoft visual studio 8\vc\platformsdk\include\basetsd.h

I'm guessing the problem might only show up in certain situations. It is 
possible that the jmorecfg.h and the basetsd.h file are only included together 
in certain development situations (and perhaps not, for example, when compiling 
OSG itself)

you can see more reports of same/similar issue here:
   http://www.cygwin.com/ml/cygwin/2004-07/msg01051.html

Also it seems that GNUWIN32 distributes Win32 specific versions of many GNU 
related libs. In GNUWIN32's version of jmorecfg.h the ifdef protection is there:
   http://gnuwin32.sourceforge.net/packages/jpeg.htm

That being said, instead of patching the jmorecfg.h we could use the one 
included in the GNUWIN32 package instead.


  Andy



-Original Message-
From: [EMAIL PROTECTED] on behalf of Jean-Sébastien Guay
Sent: Wed 1/9/2008 7:19 PM
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] INT32 redeifinition with Win32 and VS8binary   package
 
Hello Andrew,

> It appears that the VS8 binary package for osg2.2.0 has a problem in
> one of the 3rd party header files included. (jmorecfg.h)
> Compiling against it causes an error regarding redefinition of INT32.

[...]

> in jmorecfg.h:
>
> #ifndef XMD_H
> typedef long INT32;
> #endif
>
> is changed to:
>
> #if !defined( XMD_H ) && !defined( WIN32 )
> typedef long INT32;
> #endif

I just checked, and on my systems, the first block of code is in  
jmorecfg.h (*no* include guard for WIN32), yet I never got the  
redefinition warning. I'm using both Windows XP and Vista, with both  
VC++ 2005 and 2008. Are you sure this isn't caused by some other  
headers you're including in your app? That is to say, one definition  
is in jmorecfg.h, where is the other one?

If you can post the entire warning (with file names and line numbers)  
it would be easier to see what's going on. Just to check that this  
isn't a red herring.


To reply to Philip Taylor about the 64-bit issues, this is a 3rd party  
header, so OSG has little control over it. On the other hand, it comes  
from libjpeg, which is very popular and is used on almost all linux  
distros (most of which are  built both 32 and 64 bit these days), so I  
imagine if there were any 64-bit-cleanliness issues, they would have  
heard about them by now. That is not to discount your point, which  
could very well be correct, but it's "out of OSG's hands" anyways.


J-S
-- 
__
Jean-Sebastien Guay [EMAIL PROTECTED]
 http://whitestar02.webhop.org/


This message was sent using IMP, the Internet Messaging Program.


___
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] VPB in SVN

[Jean-Sébastien Guay]

Hi Paul,

> Bob and I wanted to use SVN head of VPB for the upcoming terrain training
> January 24, but aborted that idea and went back to 0.9.1 when we encountered
> the Windows issues. I was reluctant to bite off porting it with so much to
> do between now and the course.

That was actually my motivation too. :-) When I saw that you were  
recommending downloading 0.9.1, I got the SVN, tried it, and saw it  
didn't compile...

Looking forward to the course.

J-S
-- 
__
Jean-Sebastien Guay [EMAIL PROTECTED]
 http://whitestar02.webhop.org/


This message was sent using IMP, the Internet Messaging Program.


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

Re: [osg-users] VPB in SVN

[Jean-Sébastien Guay]

Hi Robert,

> The --terrain functionality is very early days though (checked in
> yesterday) so there are still a few loose ends, but its certainly
> enough to have a first pass look.

Cool, I'll try that out.

> Yep, you can use multiple cores, and multiple machines, or multiple
> cores on one machine, all managed via the new vpbmaster app.  osgdem
> itself has some preliminary multi-threaded support to, but not yet to
> the level afforded by running multiple osgdem's in parallel.

Excellent!

Thanks,

J-S
-- 
__
Jean-Sebastien Guay [EMAIL PROTECTED]
 http://whitestar02.webhop.org/


This message was sent using IMP, the Internet Messaging Program.


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

Re: [osg-users] VPB in SVN

[Paul Martz]

I just wanted to thank all involved for the work on this.

Bob and I wanted to use SVN head of VPB for the upcoming terrain training
January 24, but aborted that idea and went back to 0.9.1 when we encountered
the Windows issues. I was reluctant to bite off porting it with so much to
do between now and the course.

With this work in place, Bob and I will once again consider using SVN head
for the course.

(Shameless plug: register for the course here:
http://www.skew-matrix.com/training.asp.)

Thanks again,

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] osgShadow::ShadowMap not reacting to changes

[Jean-Sébastien Guay]

Hello Andreas,

> have you run the project with OSG_NOTIFY_LEVEL=debug?
> There you can see, if your shader-program is faulty.

Thanks for the tip, we're making progress here. When running my  
program with OSG_NOTIFY_LEVEL=DEBUG, I can see that the shader is  
never even compiled! If I do the same with the osgshadow example, I see:

   Compiling FRAGMENT source:
   

which never appears for my program.

What causes this? Is there some setting that tells osgShadow to use  
the fixed pipeline instead of the shader? Or is there some criterion  
that OSG uses to decide to not use the shader?

Thanks,

J-S
-- 
__
Jean-Sebastien Guay [EMAIL PROTECTED]
 http://whitestar02.webhop.org/


This message was sent using IMP, the Internet Messaging Program.


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

Re: [osg-users] boost serialization

[Robert Osfield]

Hi Manu,

In recent VPB work I have actually experimented with this approach,
its not full blown like in boost codes, but it's a step along the way,
and certainly much cleaner than the existing .osg and .ive codes.

BTW, have you considered automatically generating the .cpp file using
osgIntrospection?

W.r.t boost I'm not keen to introduce this as a dependency into the
core OSG, but I'm certainly not shy of learning a few tips and tricks
from it so am very interested to see how you get on.

Robert.

On Jan 10, 2008 3:27 PM, Emmanuel Roche <[EMAIL PROTECTED]> wrote:
> Hi every one,
>
> I'm just wondering if any one as never think about using Boost serialization
> framework to write/read OSG files ?
>
> I'm working on this question, and until now I'm rather amazed:
>
>  - Sure, on one side you need to have a Boost dependency somewhere,
> - And I haven't done any performance test yet but I'm pretty sure the io
> operations will be slower than forIVE files.
>
> But if read/write speed is not that critical to you this kind of framework
> has very interesting feature:
>
> 1) You can use a single function to handle read and write process per class
> 2) This single function is used to write Text, Binary or even XML files (so
> no duplication of code like for .osg vs .ive)
> 3) The code to do this become so simple it's almost frightening (cf example)
> (in fact it hides all the reading/writing details...)
> 4) You can extend OSG with your own classes even more easily.
>
> If someone already worked on this subject, did you end up with an unsolvable
> problem ?
>
>
> Here is an example of the code I use to serialize osg::Geometry:
>
> #include 
>
> #define TARGET osg::Geometry
>
> BOOST_CLASS_EXPORT(TARGET)
>
>  namespace boost {
> namespace serialization {
>
>  OSG_REF_TEMPLATE(TARGET);
>
> template <>
>  void access::destroy(const TARGET* t)
> {
> // Do nothing: protected destructor;
> }
>
> template
> void serialize(Archive & ar, TARGET::ArrayData& obj, const unsigned int
> version)
>  {
> NVP("Array",obj.array);
> NVP("Indices", obj.indices);
> NVP("Binding",obj.binding);
> NVP("Normalize", obj.normalize);
> };
>
> template
> void serialize(Archive & ar, TARGET& obj, const unsigned int version)
>  {
> SERIALIZE_BASE(osg::Drawable);
>
>  NVP("PrimitiveSetList",obj.getPrimitiveSetList());
> NVP("VertexData",obj.getVertexData());
>  NVP("NormalData",obj.getNormalData());
> NVP("ColorData",obj.getColorData());
> NVP("SecondaryColorData",obj.getSecondaryColorData());
> NVP("FogCoordData", obj.getFogCoordData());
> NVP("TexCoordArrayList",obj.getTexCoordArrayList());
>  NVP("VertexAttribArrayList",obj.getVertexAttribArrayList());
>
> SERIALIZE_MEMBER(bool,FastPathHint);
> }
>
> } // namespace serialization
> } // namespace boost
>
> #undef TARGET
>
> With the following macros:
>
> #define OSG_REF_TEMPLATE(name) template \
>  void serialize(Archive & ar, osg::ref_ptr& ref, const unsigned int
> version) \
> { \
> name* obj = ref.get(); \
> ar & obj; \
>  ref = obj; \
> }
>
>  #define SERIALIZE_MEMBER(type,name){ \
> type member = obj.get ## name(); \
>  ar & boost::serialization::make_nvp( # name, member); \
> if(Archive::is_loading()) \
>  obj.set ## name(member); \
> }
>
>  #define NVP(t,o) ar & boost::serialization::make_nvp(t,o)
>
> #define SERIALIZE_BASE(name) ar & boost::serialization::base_object<
> name >(obj)
>
>
> ... Compare this with the content of Geometry.cpp in the osg or ive plugin
> and you will probably be surprised... : the Boost serialization framework
> handle automatically STL containers, derived classes, pointer references
> etc...
>
> Any way, I keep working on this project until I have a full
> "ReaderWriter"... I'll tell you later if it's a so interesting feature or
> not :-).
>
> Manu.
>
>
> ___
> 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] VPB in SVN

[Robert Osfield]

On Jan 10, 2008 3:16 PM, Jean-Sébastien Guay
<[EMAIL PROTECTED]> wrote:
> Yep, seems so. osgdem still running... I probably should have chosen a
> smaller dataset as a first test. :-)

If its a dataset with DEM's try adding --terrain to the command line,
it builds much, much faster using osgTerrain::Terrain to store the
GeightFields rather than creating osg::Geometry meshes from the DEM's
and then simplifying these (its the simplification which is slow).
The --terrain functionality is very early days though (checked in
yesterday) so there are still a few loose ends, but its certainly
enough to have a first pass look.

> > Once I've completed some more work on
> > VPB I'll do a write up on all the new functionality and then strike up
> > a discussion on osg-users about how to tackle distributed builds under
> > Windows/mixed networks, I'll need suggestions from the community on
> > this part though, the best I can do is say how things work under unix
> > and trust in windows experts for a similar solution under Windows.
>
> Looking forward to it. I imagine if distributed builds work, it should
> be possible to use multiprocessor/multicore machines in the same way,
> by just specifying the same machine multiple times? Right now osgdem
> is taking only 25% of my spiffy quad-core CPU! :-(

Yep, you can use multiple cores, and multiple machines, or multiple
cores on one machine, all managed via the new vpbmaster app.  osgdem
itself has some preliminary multi-threaded support to, but not yet to
the level afforded by running multiple osgdem's in parallel.

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

Re: [osg-users] VPB in SVN

[Robert Osfield]

On Jan 10, 2008 3:15 PM, Jean-Christophe Lombardo
<[EMAIL PROTECTED]> wrote:
> I still have 2 slight modifications to suggest on windows side:
>  * in vpb/FileUtils I had to add a #include   to define the
> O_RDWR flag with no leading _

Already checked in.

>  * in vpb/FileUtils.cpp I think that vpb::sync() could be defined as
> void vpb::sync() { (void) _flushall(); }

Thanks, I've added this and checked it in.

> Jean-Sébastien, I'm sorry for the 12 hours lag, but 12 hours ago, I was
> sleeping :) as it was night on my side of the pond...

OSG/VPB development never sleeps :-)

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

[osg-users] boost serialization

[Emmanuel Roche]

Hi every one,

I'm just wondering if any one as never think about using Boost serialization
framework to write/read OSG files ?

I'm working on this question, and until now I'm rather amazed:

- Sure, on one side you need to have a Boost dependency somewhere,
- And I haven't done any performance test yet but I'm pretty sure the io
operations will be slower than forIVE files.

But if read/write speed is not that critical to you this kind of framework
has very interesting feature:

1) You can use a single function to handle read and write process per class
2) This single function is used to write Text, Binary or even XML files (so
no duplication of code like for .osg vs .ive)
3) The code to do this become so simple it's almost frightening (cf example)
(in fact it hides all the reading/writing details...)
4) You can extend OSG with your own classes even more easily.

If someone already worked on this subject, did you end up with an unsolvable
problem ?


Here is an example of the code I use to serialize osg::Geometry:

#include 

#define TARGET osg::Geometry

BOOST_CLASS_EXPORT(TARGET)

namespace boost {
namespace serialization {

OSG_REF_TEMPLATE(TARGET);

template <>
void access::destroy(const TARGET* t)
{
// Do nothing: protected destructor;
}

template
void serialize(Archive & ar, TARGET::ArrayData& obj, const unsigned int
version)
{
NVP("Array",obj.array);
NVP("Indices",obj.indices);
NVP("Binding",obj.binding);
NVP("Normalize",obj.normalize);
};

template
void serialize(Archive & ar, TARGET& obj, const unsigned int version)
{
SERIALIZE_BASE(osg::Drawable);

NVP("PrimitiveSetList",obj.getPrimitiveSetList());
NVP("VertexData",obj.getVertexData());
NVP("NormalData",obj.getNormalData());
NVP("ColorData",obj.getColorData());
NVP("SecondaryColorData",obj.getSecondaryColorData());
NVP("FogCoordData",obj.getFogCoordData());
NVP("TexCoordArrayList",obj.getTexCoordArrayList());
NVP("VertexAttribArrayList",obj.getVertexAttribArrayList());

SERIALIZE_MEMBER(bool,FastPathHint);
}

} // namespace serialization
} // namespace boost

#undef TARGET

With the following macros:

#define OSG_REF_TEMPLATE(name) template \
void serialize(Archive & ar, osg::ref_ptr& ref, const unsigned int
version) \
{ \
name* obj = ref.get(); \
ar & obj; \
ref = obj; \
}

#define SERIALIZE_MEMBER(type,name){ \
type member = obj.get ## name(); \
ar & boost::serialization::make_nvp( # name, member); \
if(Archive::is_loading()) \
obj.set ## name(member); \
}

#define NVP(t,o) ar & boost::serialization::make_nvp(t,o)

#define SERIALIZE_BASE(name) ar & boost::serialization::base_object<
name >(obj)


... Compare this with the content of Geometry.cpp in the osg or ive plugin
and you will probably be surprised... : the Boost serialization framework
handle automatically STL containers, derived classes, pointer references
etc...

Any way, I keep working on this project until I have a full
"ReaderWriter"... I'll tell you later if it's a so interesting feature or
not :-).

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

Re: [osg-users] VPB in SVN

[Jean-Sébastien Guay]

Hello jcl,

>  * in vpb/FileUtils I had to add a #include   to define the
> O_RDWR flag with no leading _

Already done in the second batch of modifications (it was already in  
the #else, so we just moved it out of the #ifdef).

>  * in vpb/FileUtils.cpp I think that vpb::sync() could be defined as
> void vpb::sync() { (void) _flushall(); }

Nice, I didn't know about that one. I did some research on an  
equivalent to sync() on Windows, and that one never came up... Could  
you add it please Robert?

> Jean-Sébastien, I'm sorry for the 12 hours lag, but 12 hours ago, I was
> sleeping :) as it was night on my side of the pond...

I know, I know :-) I was just joking. That's the interesting thing  
about contributing to this project, during the afternoon there is  
almost no traffic on the list, and then when I get back in the morning  
there's a slew of new posts - Robert being in Scotland and all... :-)

Thanks for testing.

J-S
-- 
__
Jean-Sebastien Guay [EMAIL PROTECTED]
 http://whitestar02.webhop.org/


This message was sent using IMP, the Internet Messaging Program.


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

Re: [osg-users] VPB in SVN

[Jean-Sébastien Guay]

Hello Robert,

> Fingers crossed this should now mean VPB is
> ported back to windows, at least for basic osgdem functionality.

Yep, seems so. osgdem still running... I probably should have chosen a  
smaller dataset as a first test. :-)

> Once I've completed some more work on
> VPB I'll do a write up on all the new functionality and then strike up
> a discussion on osg-users about how to tackle distributed builds under
> Windows/mixed networks, I'll need suggestions from the community on
> this part though, the best I can do is say how things work under unix
> and trust in windows experts for a similar solution under Windows.

Looking forward to it. I imagine if distributed builds work, it should  
be possible to use multiprocessor/multicore machines in the same way,  
by just specifying the same machine multiple times? Right now osgdem  
is taking only 25% of my spiffy quad-core CPU! :-(

J-S
-- 
__
Jean-Sebastien Guay [EMAIL PROTECTED]
 http://whitestar02.webhop.org/


This message was sent using IMP, the Internet Messaging Program.


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

Re: [osg-users] VPB in SVN

[Jean-Christophe Lombardo]

I still have 2 slight modifications to suggest on windows side:
 * in vpb/FileUtils I had to add a #include   to define the 
O_RDWR flag with no leading _
 * in vpb/FileUtils.cpp I think that vpb::sync() could be defined as 
void vpb::sync() { (void) _flushall(); }

Jean-Sébastien, I'm sorry for the 12 hours lag, but 12 hours ago, I was 
sleeping :) as it was night on my side of the pond...

jcl




 
 

This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer 
viruses.




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

[osg-users] bug in osgManipulator example

[Scene Maker]

There is a bug in the osgManipulator example file osgmanipulator.cpp.

On line 192 a local variable is created.
osgUtil::LineSegmentIntersector::Intersections intersections;

A member variable keeps a pointer to this variable
_pointer.addIntersection(hitr->nodePath, hitr->getLocalIntersectPoint());

When the local variable is destroyed MSVC throws an exception.

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

Re: [osg-users] VPB in SVN

[Robert Osfield]

On Jan 10, 2008 1:45 PM, Robert Osfield <[EMAIL PROTECTED]> wrote:
> The changes are now all checked in.  Could you do an svn update on OSG
> and VPB and let me know how you get on.

I've just received, merged and submitted to SVN further update from
J-S that tweak the changes I checked in earlier, so another svn update
is required for VPB.  Fingers crossed this should now mean VPB is
ported back to windows, at least for basic osgdem functionality.

While VPB should now compile under Windows the distributed builds are
likely to still be a problem as they rely upon network files systems
and remote application invocation using ssh are all used, both things
that are possible under Windows, but not quite as straight
forward/built in as in unix.  Once I've completed some more work on
VPB I'll do a write up on all the new functionality and then strike up
a discussion on osg-users about how to tackle distributed builds under
Windows/mixed networks, I'll need suggestions from the community on
this part though, the best I can do is say how things work under unix
and trust in windows experts for a similar solution under Windows.

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

Re: [osg-users] VPB in SVN

[Jean-Sébastien Guay]

Hi Robert,

> A number of items are outstanding, such as the Windows versions of
> posix functions.  JS has created a Utils file for these, I'm about to
> just start reviewing these.  I'll follow JS's lead in collecting all
> these functions into one place, but I'll probably not follow the
> naming convention he's adopted.   I will make further steps along
> getting route to getting things compiling under Windows.

Changing the naming convention is fine. I just picked one that seemed  
ok, in the hopes of avoiding peppering the whole code-base with #ifdef  
WIN32 #else #endif everywhere...

Thanks,

J-S
-- 
__
Jean-Sebastien Guay [EMAIL PROTECTED]
 http://whitestar02.webhop.org/


This message was sent using IMP, the Internet Messaging Program.


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

Re: [osg-users] VPB in SVN

[Jean-Sébastien Guay]

Bonjour Jean-Christophe,

> I don't know whether this can be useful or not, nor how I can
> contribute. Let me know.

Hehe, I would have liked to know this yesterday :-)

I sent to osg-submissions the changed files to make VPB from SVN  
compile cleanly on Windows yesterday. We'll see if they make it into  
SVN as-is or if more work is needed. And similarly to you, I have not  
yet tested the parts that use posix functions, just good old osgdem...

And you're right, most functions have straight equivalents (or just  
add an underscore to the name), but others were a bit more touchy. In  
any case, these things rarely work right after a straight port, as  
platform compatibility often amounts to more than just function names.

Hopefully it's a step in the right direction. Thanks for your offer,  
even if it was just about 12 hours late :-)

J-S
-- 
__
Jean-Sebastien Guay [EMAIL PROTECTED]
 http://whitestar02.webhop.org/


This message was sent using IMP, the Internet Messaging Program.


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

Re: [osg-users] VPB in SVN

[Robert Osfield]

On Jan 10, 2008 11:13 AM, Jean-Christophe Lombardo
<[EMAIL PROTECTED]> wrote:
> ok, fine for me.

The changes are now all checked in.  Could you do an svn update on OSG
and VPB and let me know how you get on.

Also could you review the src/vpb/FileUtils.cpp file to see if the
windows equivalents of posix methods match up to what you tried, if
you spot anything that could be improved upon just email the osg-users
list with the suggestions.

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

Re: [osg-users] VPB in SVN

[Jean-Christophe Lombardo]

ok, fine for me.

jcl



 
 

This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer 
viruses.




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

Re: [osg-users] VPB in SVN

[Robert Osfield]

Hi JCL,

I am just merging changes than JS submitted yesterday evening, I'm not
merging all the suggested changes, rather merging the uncontroversial
ones first, making other alternative ammendments for others.  These
changes are now checked in.

A number of items are outstanding, such as the Windows versions of
posix functions.  JS has created a Utils file for these, I'm about to
just start reviewing these.  I'll follow JS's lead in collecting all
these functions into one place, but I'll probably not follow the
naming convention he's adopted.   I will make further steps along
getting route to getting things compiling under Windows.

My suggestion for yourself is to wait for me to get the next set of
changes merged and submitted.  This probably won't get things working
out of the box under Windows quite yet, but should make it clearer
what bits to tweak and where to complete the job.  At this point it'd
be very useful if you could help test and fill out the blanks where
they are missing.

Robert.

On Jan 10, 2008 10:43 AM, Jean-Christophe Lombardo
<[EMAIL PROTECTED]> wrote:
> Hi
>
> I have a  msvc8 version of vpb 0.9.3.
> I found some straight forward equivalents for most of the posix
> functions, but I had to make rather rude stuff for others.
> I did not test this part (tasks and machines), but the project compiles
> and run fine on one single computer.
>
> I don't know whether this can be useful or not, nor how I can
> contribute. Let me know.
>
> jcl
>
> --
> Jean-Christophe Lombardo  - Salle Immersive "Le Corbusier"
> http://salle-immersive.cstb.fr
> EVE / Centre Scientifique et Technique du Batiment
> 290 route des Lucioles - BP 209 - 06904 Sophia Antipolis - France
>
>
>
>
>
>
> 
> This footnote confirms that this email message has been scanned by
> PineApp Mail-SeCure for the presence of malicious code, vandals & computer 
> viruses.
> 
>
>
>
>
> ___
> 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] VPB in SVN

[Jean-Christophe Lombardo]

Hi

I have a  msvc8 version of vpb 0.9.3.
I found some straight forward equivalents for most of the posix 
functions, but I had to make rather rude stuff for others.
I did not test this part (tasks and machines), but the project compiles 
and run fine on one single computer.

I don't know whether this can be useful or not, nor how I can 
contribute. Let me know.

jcl

-- 
Jean-Christophe Lombardo  - Salle Immersive "Le Corbusier"
http://salle-immersive.cstb.fr
EVE / Centre Scientifique et Technique du Batiment
290 route des Lucioles - BP 209 - 06904 Sophia Antipolis - France 




 
 

This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer 
viruses.




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

Re: [osg-users] Getting the current frame number of an animation

[Robert Osfield]

On Jan 10, 2008 10:23 AM, Bart Kevelham <[EMAIL PROTECTED]> wrote:
> Hi Robert,
>
> Wouldn't that just give me the number of displayed frames by the viewer? So
> something I could use for a framerate counter for example?

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

Re: [osg-users] INT32 redeifinition with Win32 and VS8 binarypackage

[Wojciech Lewandowski]

Hi, Philip,

FYI: All integral types in Win64 are the same size as they were in Win32. 
Only ptr types got "promoted" to 64 bit. See this article:
http://blogs.msdn.com/oldnewthing/archive/2005/01/31/363790.aspx

Cheers,
Wojtek Lewandowski


- Original Message - 
From: "Philip Taylor" <[EMAIL PROTECTED]>
To: "OpenSceneGraph Users" 
Sent: Wednesday, January 09, 2008 11:34 PM
Subject: Re: [osg-users] INT32 redeifinition with Win32 and VS8 
binarypackage


> Just an idle thought in passing 
>
> with the advent of 64 bit builds, it may not be such a good idea to mark a
> "long" as a 32 bit quantity since I believe the redmond 64 bit model 
> defines
> long as a 64 bit quantity where as an int is 32 bits. On 32 bit systems, 
> the
> two are the same size and can be freely interchanged. So apply the patch 
> but
> ensure the build is 32 bits only.
>
> Happy New Year
> PhilT
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of
> Somerville, Andrew
> Sent: 09 January 2008 21:43
> To: osg-users@lists.openscenegraph.org
> Subject: [osg-users] INT32 redeifinition with Win32 and VS8 binary
> package
>
>
>
> It appears that the VS8 binary package for osg2.2.0 has a problem in
> one of the 3rd party header files included. (jmorecfg.h)
>
> Compiling against it causes an error regarding redefinition of INT32.
>
> Im not sure if there are any repercussions, but there is a simple fix
> seen in an old patch on the secondlife wiki which protects the define
> with a check against WIN32
>
> https://wiki.secondlife.com/wiki/Patch_jpeglib
> in jmorecfg.h:
>
> #ifndef XMD_H
> typedef long INT32;
> #endif
>
> is changed to:
>
> #if !defined( XMD_H ) && !defined( WIN32 )
> typedef long INT32;
> #endif
>
>
> It also does an #undef on FAR just before it blanks it to remove a
> warning about redifinition.
>
> Im not sure how hard it would be to repackage the current 2.2 VS8
> binary package, but at least it can be fixed for for future Visual
> Studio packages.
>
>Regards,
>Andy
> ___
> 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] Getting the current frame number of an animation

[Bart Kevelham]

Hi Robert,

Wouldn't that just give me the number of displayed frames by the viewer? So
something I could use for a framerate counter for example?

Bart.

On 10/01/2008, Robert Osfield <[EMAIL PROTECTED]> wrote:
>
> Hi Bart,
>
> You can get the frame number form the osg::FrameStamp, you'll find
> this attached to the NodeVisitor that is traversing and calling the
> callbacks etc.  Or just get it from the viewer.
>
> Robert.
>
> On Jan 10, 2008 9:55 AM, Bart Kevelham <[EMAIL PROTECTED]> wrote:
> >
> > Hi all,
> >
> > I have created an animation at 25fps and I'm succesfully loading and
> playing
> > the animation inside openscenegraph in loop mode. (Set up everything
> > correctly with animation paths and the appropriate callbacks)
> > I want to add some functionality to my program that requires the frame
> > number of the current frame of the animation being played. (or the best
> > guess possible since it might be inbetween two control points) I have
> seen
> > getAnimationTime from AnimationPathCallback, but I can't seem to get the
> > correct final values out of it. Does anyone of you have any hints/tips
> or
> > perhaps even a solution to this problem? (using OSG 1.2 by the way)
> >
> > Thanks in advance.
> > With kind regards,
> >
> > Bart
> > ___
> > 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] Texture mipmapping parameters (Request)

[Robert Osfield]

Hi Art,

On Jan 10, 2008 9:16 AM, Art Tevs <[EMAIL PROTECTED]> wrote:
> Currently I am also overloaded. I was asked to help
> out with the upcoming Siggraph paper deadline to
> create an animation (of course with osg again ;-) )

I'd guess 90%+ of the community are overworked... just the life of a
software engineer.

> I thought also in that direction, either to implement
> this as additional feature in the Texture class or as
> some extra StateAttribute. StateAttribute would be
> also my choice. However currently I do not have a real
> idea of how to make sure that this StateAttribute
> TextureLOD
>  is executed exactly after the according texture unit
> was bound. But, I think, I can find it in TexEnv or
> TexEnvCombine classes.

Now of the Texture related state attributes have the texture unit
built into them, the binding of the texture is done entirely by
osg::State when it applies what is defined in the StateSet (ie. what
unit the attribute is attached too), this means the individual Texture
state attributes don't need to worry about setting the texture unit
themselves.

If the OpenGL state requires the texture object then you'll need to
add the extra options to Texture, but if they just invariant with the
texture object like tex env etc then you use a separate
StateAttribute.

> Since I am the one who only need that functionality, I
> will implement them bymyself, if you are agreed with
> that.

You probably aren't the only one to need it, just the first to ask.  I
actually kinda surprised its taken so long before someone has asked as
its been on my low priority todo list for well over five years!

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

Re: [osg-users] Getting the current frame number of an animation

[Robert Osfield]

Hi Bart,

You can get the frame number form the osg::FrameStamp, you'll find
this attached to the NodeVisitor that is traversing and calling the
callbacks etc.  Or just get it from the viewer.

Robert.

On Jan 10, 2008 9:55 AM, Bart Kevelham <[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
> I have created an animation at 25fps and I'm succesfully loading and playing
> the animation inside openscenegraph in loop mode. (Set up everything
> correctly with animation paths and the appropriate callbacks)
> I want to add some functionality to my program that requires the frame
> number of the current frame of the animation being played. (or the best
> guess possible since it might be inbetween two control points) I have seen
> getAnimationTime from AnimationPathCallback, but I can't seem to get the
> correct final values out of it. Does anyone of you have any hints/tips or
> perhaps even a solution to this problem? (using OSG 1.2 by the way)
>
> Thanks in advance.
> With kind regards,
>
> Bart
> ___
> 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] Getting the current frame number of an animation

[Bart Kevelham]

 Hi all,

I have created an animation at 25fps and I'm succesfully loading and
playing the animation inside openscenegraph in loop mode. (Set up everything
correctly with animation paths and the appropriate callbacks)
I want to add some functionality to my program that requires the frame
number of the current frame of the animation being played. (or the best
guess possible since it might be inbetween two control points) I have seen
getAnimationTime from AnimationPathCallback, but I can't seem to get the
correct final values out of it. Does anyone of you have any hints/tips or
perhaps even a solution to this problem? (using OSG 1.2 by the way)

Thanks in advance.
With kind regards,

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

Re: [osg-users] Texture mipmapping parameters (Request)

[Art Tevs]

Hi Robert.

Currently I am also overloaded. I was asked to help
out with the upcoming Siggraph paper deadline to
create an animation (of course with osg again ;-) ) 

I thought also in that direction, either to implement
this as additional feature in the Texture class or as
some extra StateAttribute. StateAttribute would be
also my choice. However currently I do not have a real
idea of how to make sure that this StateAttribute
TextureLOD 
 is executed exactly after the according texture unit
was bound. But, I think, I can find it in TexEnv or
TexEnvCombine classes.

Since I am the one who only need that functionality, I
will implement them bymyself, if you are agreed with
that.


Cheers,
Art

> Hi Art,
> 
> I have considered implemented Texture LOD controls
> in the OSG before,
> but haven't actually had a direct need for them, so
> following the
> extreme programming principle of only implemented
> what you need I have
> left this one till there was a concrete need...
> looks like the time
> has come :-)

> I don't have scope for running off and implemented
> new features of the
> OSG right now, so you'll need to wait till I have a
> lull in work, or
> get coding yourself.  The choice for implementation
> is to either place
> the additional controls into osg::Texture or to
> introduce a new
> TextureLOD state attribute that wraps up these
> controls.   The later
> is more flexible as you can then alter it
> independently from the
> texture.
> 
> Robert.
> 
> On Jan 9, 2008 9:33 PM, Art Tevs
> <[EMAIL PROTECTED]> wrote:
> > Hi, folks!
> >
> > I am wonder why the current implementation do not
> > provide any method to specify GL_TEXTURE_MIN_LOD,
> > GL_TEXTURE_MAX_LOD, GL_TEXTURE_BASE_LEVEL, and
> > GL_TEXTURE_MAX_LEVEL (it exists already since
> OpenGL
> > v1.2)
> >
> > I need to change the base and max level parameters
> of
> > a texture (maybe I do not really need this, but
> there
> > are some bugs which disapears when I use this
> texture
> > parameters).
> > Would it be a good idea if I provide a
> > patch which do implement this to the osg core?
> This
> > would probably introduce at least 4 more variables
> in
> > the osg::Texture class and couple of methods.
> > Are there some objections against this?
> >
> >
> > Best,
> > Art
> >
> >
> >
> >   Heute schon einen Blick in die Zukunft von
> E-Mails wagen? www.yahoo.de/mail
> > ___
> > 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
> 



  Jetzt Mails schnell in einem Vorschaufenster überfliegen. Dies und viel 
mehr bietet das neue Yahoo! Mail - www.yahoo.de/mail
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgVolume example bug?

[Robert Osfield]

Hi,

I'm the author of the osgvolume example.  Its just a quick
prototype/proof of concept, and one I haven't touched in the last year
or two so its a bit cold.   The visual errors on the frame region
you've observed aren't ones I've seen before, but then I've never
played with a volume dataset that has a frame in it.  I'm afraid I
can't think of any obvious failure modes that would introduce these
artefacts.  Try different hardware/OpenGL drivers/OS to see if the
artefacts changes.  As for the head region, I can't spot any problem.

Robert.

On Jan 10, 2008 6:40 AM, hesicong2006 <[EMAIL PROTECTED]> wrote:
> Hi everyone:
> I'm now doing a medical application using volume rendering technology.
> osgVolume example gives me a very good start, thanks to people who
> contributes to this example. But I found some image errors (see
> attachments) , In p1.jpg, see the red circle, the outboder line bends.
> In p2.jpg, the line bends more than that in p1.jpg. And notice the head,
> it's a little strange. I tried to fix this problem, but I still can't
> figure out why it happens to be like this.Does someone can help me or
> point out why it appears like this?
> Thanks very much!
>
> ___
> 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] Texture mipmapping parameters (Request)

[Robert Osfield]

Hi Art,

I have considered implemented Texture LOD controls in the OSG before,
but haven't actually had a direct need for them, so following the
extreme programming principle of only implemented what you need I have
left this one till there was a concrete need... looks like the time
has come :-)

I don't have scope for running off and implemented new features of the
OSG right now, so you'll need to wait till I have a lull in work, or
get coding yourself.  The choice for implementation is to either place
the additional controls into osg::Texture or to introduce a new
TextureLOD state attribute that wraps up these controls.   The later
is more flexible as you can then alter it independently from the
texture.

Robert.

On Jan 9, 2008 9:33 PM, Art Tevs <[EMAIL PROTECTED]> wrote:
> Hi, folks!
>
> I am wonder why the current implementation do not
> provide any method to specify GL_TEXTURE_MIN_LOD,
> GL_TEXTURE_MAX_LOD, GL_TEXTURE_BASE_LEVEL, and
> GL_TEXTURE_MAX_LEVEL (it exists already since OpenGL
> v1.2)
>
> I need to change the base and max level parameters of
> a texture (maybe I do not really need this, but there
> are some bugs which disapears when I use this texture
> parameters).
> Would it be a good idea if I provide a
> patch which do implement this to the osg core? This
> would probably introduce at least 4 more variables in
> the osg::Texture class and couple of methods.
> Are there some objections against this?
>
>
> Best,
> Art
>
>
>
>   Heute schon einen Blick in die Zukunft von E-Mails wagen? 
> www.yahoo.de/mail
> ___
> 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] Problem with .3ds files.

[Alberto Luaces]

El Thursday 10 January 2008 07:26:43 Omkaranathan escribió:
> Is there any tool available to transfer the per-vertex material colour
> to OpenGL colour(instead of default white) while converting to any of
> the OSG supported formats?
> Or is there any other way by which I can overcome this?

I don't know of any, but you can write a nodeVisitor that traverses every 
drawable, collects its diffuse colour from its osg::StateSet and applies that 
single colour ( setColorArray) to all its vertices.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org