date:20090515

Re: [osg-users] light, normals

2009-05-15 Thread J.P. Delport

Hi,

Jean-Sébastien Guay wrote:

Hi Christian,

my geometry has 9 vertices - i thought if i use a drawElement index
with index swaps to revist a vertex, this would give me the
opportunity to use more than one normal per vertex (there are reasons
why i need this ;-). i now think the truth is, only real vertices in
the vertexlist let me allow to do this.

Yes, if you need hard edges, then you need different normals for the
same vertex when it's part of a different face. But the way to express
that with vertex arrays is to duplicate the vertex in the array and use
a different normal.

Your analysis seems correct. From what you say above, what you actually
did was have a larger number of normals than vertices, thinking that
then the extra normals would be used when the same vertex was used in a
different primitive set. That doesn't work. When normals are used in
BIND_PER_VERTEX mode, it's assumed that you have the same number of
vertices as normals, and so the result was just that the extra normals
were never used. (same with colors in the color array BTW)

So to recap, if normals are used in BIND_PER_VERTEX mode, then vertex i
is used with normal i. But vertex i and vertex j can be equal, with a
different normal j. And then vertex i and vertex j can be part of
different triangles (well, should, otherwise you have a degenerate
triangle).

At first this seems like a waste of memory, but the hardware is really
optimized to work this way.

Hope this helps,

J-S

What J-S says is right and would work fine if you want a single
primitive. You can however avoid duplicating vertices if you are willing
to make more primitives.

Simple contrived example: say you want to draw a triangle and specify
normals for both sides manually. (GL_TRIANGLES)

Now you can make a single vertex array, normal array and drawelements

va = [v1, v2, v3, v3, v2, v1]
na = [n1, n1, n1, n2, n2, n2]
de = [0, 1, 2, 3, 4, 5]

and make a primitive out of this.

Or, you can make a single vertex array, 2 normal arrays and 2 drawelements

va = [v1, v2, v3]
na1 = [n1, n1, n1]
na2 = [n2, n2, n2]
de1 = [0, 1, 2]
de2 = [2, 1, 0]

and make two primitives.

In this way you can sometimes save some memory by having less vertices
loaded up.

--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.

This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean. MailScanner thanks Transtec Computers for their support.

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

Re: [osg-users] Remote execution and OSG

2009-05-15 Thread Pierre Bourdin (gmail)

Hi all,

maybe the first thing to do is test with some easy application, like
xclock or something else to be sure your X forwarding is working...

I've just tested yesterday, with "ssh -X" and it was working for me...
But it's extremely low...

Pierre.


Le jeudi 14 mai 2009 à 21:45 +0100, Simon Hammett a écrit :
> No idea, sry.
> It's getting on for 15 years since I did any xlib programming.
> 
> You could have a poke around in:
> 
> src\osgViewer\GraphicsWindowX11.cpp
> 
> and work backwards from there.
> 
> 2009/5/14  :
> >
> > Already tried "xhost +".. No help..
> >
> > What is so special about "osgkeyboardmouse, osgcompositeviewer, 
> > osgsidebyside, osgtexture3D, osgslice,  and osgwindows" that would cause 
> > them not to work but other do?  "osgviewer --window" seems to work fine..  
> > Does this have something to do with the GraphicsContext?
> >
> > Paul P.
> >
> >
> > - Original Message 
> > From: Simon Hammett 
> > To: OpenSceneGraph Users 
> > Sent: Thursday, May 14, 2009 2:58:09 PM
> > Subject: Re: [osg-users] Remote execution and OSG
> >
> > Don't you have to grant access on your machine to remote connections?
> > IIRC, try 'xhost +' on your machine before starting the program on the
> > remote machine.
> >
> > 2009/5/14  :
> >>
> >> Yes, I am using Redhat Linux with OSG 2.9.3.
> >>
> >> Using "ssh -Y" didn't help...
> >>
> >> Also, as I pointed out in my last e-mail, I get this X11 connection 
> >> refused, however, the application still runs but FULL SCREEN instead of in 
> >> a window...
> >>
> >> Paul P.
> >>
> >>
> >> - Original Message 
> >> From: "Thrall, Bryan" 
> >> To: OpenSceneGraph Users 
> >> Sent: Thursday, May 14, 2009 1:35:45 PM
> >> Subject: Re: [osg-users] Remote execution and OSG
> >>
> >> paul1...@yahoo.com wrote on Thursday, May 14, 2009 12:28 PM:
> >>
> >>> I need to be able to run my OSG program remotely (from a different machine
> >>> that where the display location). I'm using "ssh" to login to the remote
> >>> location and have my "setenv DISPLAY" set back to my original computer 
> >>> (I've
> >>> set xhost + on the server machine).
> >>>
> >>> When I do this, on SOME OSG examples, I'm getting:
> >>> Xlib: connection to ":0.0" refused by server
> >>> Xlib: No protocol specified
> >>>
> >>> Error: Unable to open display ":0.0".
> >>> Error: unable to create graphics window
> >>>
> >>> I haven't narrowed down when I get this but it seems that I get it only 
> >>> when
> >>> I run applications that create their own windows. I do not see this when
> >>> running osgviewer in full screen mode nor with many of the other OSG
> >>> examples. However, I do see this problem with osgkeyboardmouse,
> >>> osgcompositeviewer, osgsidebyside, osgtexture3D, osgslice,  and 
> >>> osgwindows.
> >>> In these cases, instead of opening up a window as I think these are 
> >>> supposed
> >>> to do, it runs full screen.
> >>>
> >>> Any idea what is going on here?
> >>
> >> Not sure what's wrong with your DISPLAY, but 'ssh -Y' will tunnel the X 
> >> connection through ssh and set up the DISPLAY correctly (usually to 
> >> something like 'localhost:10.0') without you having to mess with it.
> >>
> >> You don't say, but I'm assuming you're running Linux or something like 
> >> that; OSG compiled for Windows doesn't do X forwarding :)
> >>
> >> --
> >> Bryan Thrall
> >> FlightSafety International
> >> bryan.thr...@flightsafety.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
> >>
> >
> >
> >
> > --
> > http://www.ssTk.co.uk
> > ___
> > 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
> >
> 
> 
> 

Pierre BOURDIN
I.M.E.R.I.R.
Av. Pascot BP 90443
66004 PERPIGNAN
tél: 04 68 56 84 95
fax: 04 68 55 03 86
email: bour...@imerir.com


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

Re: [osg-users] VPB stuff

2009-05-15 Thread J.P. Delport

Hi,

Mao wrote:
Hi! Recently, our project is planning to migrate from mini to VPB.
However, we encounter with several questions.

1. In the example of osgDEM, I infer that osgDEM processes tiff
format only. But tiff uses 32-bit offset which limits its size to 4G
bytes. Most of our data are ERDAS img file or rrd file, which are huge
in size. Yesterday, we processed an img file of size 20G bytes, and
gdal_translate it to a 21G bytes tiff. That confused me. How can VPB
handle extra bytes?

osgdem/virtualplanetbuilder can read all files that gdal can read, so
have a look here:

http://www.gdal.org/formats_list.html

You can use the gdal tools to split your large data into multiple
smaller geotiffs <2GB if you want.

It is better in pieces :) Smaller files, easier to handle. VPB can
handle multiple texture files, you can even pass a directory name and it
would use all the files in the directory.

See here too:
http://www.openscenegraph.org/projects/VirtualPlanetBuilder/wiki/ExampleClusterJPD

3. The last question is when applied with “--Terrain” or
“—HEIGHT_FIELD” options, there is no texture at all. Can we encapsulate
both texture and DEM data into one output file? And it seems that
osg::HeightField does not provide height = getHieghtAt(terrain.x,
terrain.y) method.

Hi, --terrain works for me. You can have DEM layer + multiple texture
layers. I can't answer about height_field.

Thank you very much for listening!

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

This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean. MailScanner thanks Transtec Computers for their support.

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

Re: [osg-users] [build] iv file not being read

2009-05-15 Thread Mattias Helsing

Hello Abhinav,

There is nothing for anyone to go on to even try to help you. The code
snippet is not even osg code so no chance for us to know anything
about what it does.

* use a debugger to see what "readAll" returns and why
* crank up OSG_NOTIFY_LEVEL
* see Paul Martz top 10 debugging tips at
http://www.skew-matrix.com/bb/viewtopic.php?f=6&t=5

cheers
Mattias


On 5/15/09, Abhinav Dubey  wrote:
> Hi,
> i am trying to read an iv file but its not being read. the code i am using
> is :
> ***
>  SoInput sceneInput;
>   if ( !sceneInput.openFile( "plugins\\graphs\\myInventor.iv" ) ) {
> QMessageBox::information(mInventorGrid[3], "Error", "Cannot open
> file requested iv file");
> return;
> }
>
> SoSeparator *sc_root = SoDB::readAll( &sceneInput );
>sc_root->ref();
>
>  Use one of the convenient SoQt viewer classes.
> mViewer = new SoQtExaminerViewer(iv_widget);
> mViewer->setSceneGraph(sc_root);
> mViewer->setDecoration(false);
> mViewer->show();
> ***
> and the iv file named myInventor.iv has the following:
> #Inventor V2.1 ascii
>
> Separator {
> SoXipExaminer {
>   modeNONE
>   viewBoundingBox 230 0 0 0
>   0 227.785 0 0
>   0 0 42.1032 0
>   -112.59 -117.21 50.3972 1
>   complexity  Complexity {
>   value   0.5
>   textureQuality  0.5
>   }
>
>   orthoCamera DEF +0 OrthographicCamera {
>   }
>
>   perspectiveCamera   DEF +1 PerspectiveCamera {
>   position0.181952 88.5125 454.632
>   orientation -0.494995 0.0901597 0.864206  0.470889
>   nearDistance230.823
>   farDistance 557.256
>   focalDistance   394.04
>   heightAngle 0.785398
>   }
>
>   borderNode  SoXipViewportBorder {
>   fields [ SFColor activeColor, SFColor inactiveColor,  ]
>   activeColor 0.7 0.7 0.7
>   inactiveColor   0.7 0.7 0.7
>   }
>
>   cameraSwitchSwitch {
>   whichChild  1
>   USE +0
>   USE +1
>   }
>
> }
> SoXipLut {
>   fields [ SFEnum inputMode, SFEnum outputMode, SFShort bitsUsed, SFFloat
> rampWidth,
>   SFFloat rampCenter, MFColor arrayColor, MFFloat arrayAlpha ]
>   inputMode   TRAPEZOID
>   outputMode  COLOR
>   bitsUsed12
>   rampWidth   0.05
>   rampCenter  0.009
>   arrayColor  [  ]
>   arrayAlpha  [  ]
> }
> SoXipImage {
>   fields [ SoXipSFDataImage image ]
>   image   "DATA" =
>   SoXipLoadDicom {
>   inputs [ MFString name ]
>   name"C:\Xip\examples\data\24884367.dcm"
>   outputs [ SoXipMFDataDicom dicom ]
>   }
>   . dicom
>
> }
> }
> ***
> when i run the code it crashes at sc_Root.ref();
> plz help me out
> ...
>
>
> Thank you!
>
> Cheers,
> Abhinav
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=12174#12174
>
>
>
>
>
> ___
> 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 stuff

2009-05-15 Thread Pierre Bourdin (gmail)

Hi,
I can confirm it works well with many textures...

Here's screenshot of some terrain build with 2 textures:
http://perso.imerir.com/bourdin/wiki/doku.php/en/projet/massane


The only problem I have is with Shapefile, but I'm using osggis for
that... If you know how to use them with osgdem ? I'm interested...

For the --terrain option, it works also very well, but I have to disable
GL_ARB extension with my ATI otherwise it crashes. 

Pierre

Le vendredi 15 mai 2009 à 09:08 +0200, J.P. Delport a écrit :
> Hi,
> 
> Mao wrote:
> > Hi! Recently, our project is planning to migrate from mini to VPB. 
> > However, we encounter with several questions.
> > 
> >  
> > 
> > 1.   In the example of osgDEM, I infer that osgDEM processes tiff 
> > format only. But tiff uses 32-bit offset which limits its size to 4G 
> > bytes. Most of our data are ERDAS img file or rrd file, which are huge 
> > in size. Yesterday, we processed an img file of size 20G bytes, and 
> > gdal_translate it to a 21G bytes tiff. That confused me. How can VPB 
> > handle extra bytes?
> 
> osgdem/virtualplanetbuilder can read all files that gdal can read, so 
> have a look here:
> http://www.gdal.org/formats_list.html
> 
> You can use the gdal tools to split your large data into multiple 
> smaller geotiffs <2GB if you want.
> 
> > 
> > 2.   Another thing is that, texture files we got sometimes are in 
> > pieces, and we should use gdal_merge.py to merge them into one big tiff. 
> > According to the source code, VPB can handle only one texture file. Can 
> > we use multiple texture files?
> 
> It is better in pieces :) Smaller files, easier to handle. VPB can 
> handle multiple texture files, you can even pass a directory name and it 
> would use all the files in the directory.
> 
> See here too:
> http://www.openscenegraph.org/projects/VirtualPlanetBuilder/wiki/ExampleClusterJPD
> 
> > 
> > 3.   The last question is when applied with “--Terrain” or 
> > “—HEIGHT_FIELD” options, there is no texture at all. Can we encapsulate 
> > both texture and DEM data into one output file? And it seems that 
> > osg::HeightField does not provide height = getHieghtAt(terrain.x, 
> > terrain.y) method.
> 
> Hi, --terrain works for me. You can have DEM layer + multiple texture 
> layers. I can't answer about height_field.
> 
> jp
> 
> > 
> >  
> > 
> > Thank you very much for listening!
> > 
> > 
> > 
> > 
> > ___
> > osg-users mailing list
> > osg-users@lists.openscenegraph.org
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> 

Pierre BOURDIN
I.M.E.R.I.R.
Av. Pascot BP 90443
66004 PERPIGNAN
tél: 04 68 56 84 95
fax: 04 68 55 03 86
email: bour...@imerir.com


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

Re: [osg-users] Remote execution and OSG

2009-05-15 Thread J.P. Delport


Hi,

paul1...@yahoo.com wrote:

Already tried "xhost +".. No help..

What is so special about "osgkeyboardmouse, osgcompositeviewer, osgsidebyside, osgtexture3D, 
osgslice,  and osgwindows" that would cause them not to work but other do?  "osgviewer 
--window" seems to work fine..  Does this have something to do with the GraphicsContext?


Not sure, but it looks like some code ignores the $DISPLAY setting and 
just tries to open :0.0.


I can confirm that I get the same behaviour between two Debian machines:
osgviewer cow.osg runs at a staggering 2fps

osgkeyboardmouse fails with:
No protocol specified
Error: Unable to open display ":0.0".
Error: unable to create graphics window.

jp



Paul P.


- Original Message 
From: Simon Hammett 
To: OpenSceneGraph Users 
Sent: Thursday, May 14, 2009 2:58:09 PM
Subject: Re: [osg-users] Remote execution and OSG

Don't you have to grant access on your machine to remote connections?
IIRC, try 'xhost +' on your machine before starting the program on the
remote machine.

2009/5/14  :

Yes, I am using Redhat Linux with OSG 2.9.3.

Using "ssh -Y" didn't help...

Also, as I pointed out in my last e-mail, I get this X11 connection refused, 
however, the application still runs but FULL SCREEN instead of in a window...

Paul P.


- Original Message 
From: "Thrall, Bryan" 
To: OpenSceneGraph Users 
Sent: Thursday, May 14, 2009 1:35:45 PM
Subject: Re: [osg-users] Remote execution and OSG

paul1...@yahoo.com wrote on Thursday, May 14, 2009 12:28 PM:


I need to be able to run my OSG program remotely (from a different machine
that where the display location). I'm using "ssh" to login to the remote
location and have my "setenv DISPLAY" set back to my original computer (I've
set xhost + on the server machine).

When I do this, on SOME OSG examples, I'm getting:
Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified

Error: Unable to open display ":0.0".
Error: unable to create graphics window

I haven't narrowed down when I get this but it seems that I get it only when
I run applications that create their own windows. I do not see this when
running osgviewer in full screen mode nor with many of the other OSG
examples. However, I do see this problem with osgkeyboardmouse,
osgcompositeviewer, osgsidebyside, osgtexture3D, osgslice,  and osgwindows.
In these cases, instead of opening up a window as I think these are supposed
to do, it runs full screen.

Any idea what is going on here?

Not sure what's wrong with your DISPLAY, but 'ssh -Y' will tunnel the X 
connection through ssh and set up the DISPLAY correctly (usually to something 
like 'localhost:10.0') without you having to mess with it.

You don't say, but I'm assuming you're running Linux or something like that; 
OSG compiled for Windows doesn't do X forwarding :)

--
Bryan Thrall
FlightSafety International
bryan.thr...@flightsafety.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







--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. 
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.


This message has been scanned for viruses and dangerous content by MailScanner, 
and is believed to be clean.  MailScanner thanks Transtec Computers for their support.


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

Re: [osg-users] osgOcean release

2009-05-15 Thread yann le paih

An other Interesting paper

http://www.informatik.uni-rostock.de/~hc009/publications.html



On Thu, May 14, 2009 at 11:53 AM, David Spilling
wrote:

> Kim,
>
>
> it does sound difficult to implement as a general case.
>
>
> Actually, I think that the only way to meet all current techniques with as
> common a scenegraph structure as possible is to render the heightfield to
> texture (generated somehow, e.g. FFT on CPU, sum of sines, FFT on GPU), then
> use vertex texture fetch to draw the vertices (e.g. projective, tiled,
> etc.).
>
> The main drawback (IMHO) is current performance : vertex texture fetch is
> slow on many cards; even fewer seem to support GL_LINEAR in hardware (which
> you need). Undoubtedly this will get better, but when I looked at this a
> little while ago, it was sluggish in comparison to techniques not involving
> VTF.
>
> To be honest I've don't think I've seen a real time
>> ocean simulation with geometric wake formations, they usually just use
>> texture overlays.
>
>
> I  agree; vertex deformation by wakes is... uncommon (we've done it in the
> past, but for very very application specific reasons that probably wouldn't
> be appropriate). However applying a deformation to your _normal_ field works
> easily, and works especially well at high altitudes in calm seas when you
> can't / shouldn't be able to see the vertices anyway. It's equivalent in
> construction to the way the surface wake foam textures work.
>
> One other point : for semi-infinite tiling oceans, have a look at the new
> instancing stuff that I recently saw contributed into OSG. I haven't played
> with yet it myself, but just repeating the base (high res) tile as an
> instance is probably higher performance than having to bother with LOD,
> skirts, and all the rest.
>
> Best regards,
>
> David
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>


-- 
Yann Le Paih
Keraudrono
56150 BAUD
Portable: +33(0)610524356
lepaih.y...@gmail.com
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] VPB stuff

2009-05-15 Thread J.P. Delport

Hi,

Pierre Bourdin (gmail) wrote:

Hi,
I can confirm it works well with many textures...

Here's screenshot of some terrain build with 2 textures:
http://perso.imerir.com/bourdin/wiki/doku.php/en/projet/massane

The only problem I have is with Shapefile, but I'm using osggis for
that... If you know how to use them with osgdem ? I'm interested...

sorry, I should have made it more clear that I meant gdal raster
formats. I don't know of better way than osggis to include vector data.

For the --terrain option, it works also very well, but I have to disable
GL_ARB extension with my ATI otherwise it crashes.

Pierre

Le vendredi 15 mai 2009 à 09:08 +0200, J.P. Delport a écrit :

Hi,

Mao wrote:
Hi! Recently, our project is planning to migrate from mini to VPB.
However, we encounter with several questions.

http://www.gdal.org/formats_list.html

You can use the gdal tools to split your large data into multiple
smaller geotiffs <2GB if you want.

2. Another thing is that, texture files we got sometimes are in
pieces, and we should use gdal_merge.py to merge them into one big tiff.
According to the source code, VPB can handle only one texture file. Can
we use multiple texture files?
It is better in pieces :) Smaller files, easier to handle. VPB can
handle multiple texture files, you can even pass a directory name and it
would use all the files in the directory.

See here too:
http://www.openscenegraph.org/projects/VirtualPlanetBuilder/wiki/ExampleClusterJPD

Thank you very much for listening!

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

Pierre BOURDIN
I.M.E.R.I.R.
Av. Pascot BP 90443
66004 PERPIGNAN
tél: 04 68 56 84 95
fax: 04 68 55 03 86
email: bour...@imerir.com

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

This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean. MailScanner thanks Transtec Computers for their support.

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

1 2 >

1 - 100 of 126 matches

Mail list logo