date:20090511

On Mon, May 11, 2009 at 9:22 PM, Paul Martz  wrote:
> This is interesting if, for no other reason, the fact that the work is
> taking place just a few kilometers away from where I live and work. This is
> the SketchUp office in Boulder, Colorado, if I understand correctly.

Ooo that's where I might of ended up working then ;-)

A few years back I had a peculiar invite from google's HR for me to
apply for a job, but without any actual job description never
followed it up, too happy living somewhere as beautiful as the
Trossachs, but hey Boulder ain't too far from the mountains so perhaps
it wouldn't been too much of hardship :-)

> Given the long history of failed 3D web standards, I don't envy anyone
> working on this project. Nothing worse than working on something that has a
> proven track record of non-acceptance in the developer community. I hope
> they can overcome the shadow of the past. Looks like interesting stuff so
> far.

3D web has always been hyped as the next best thing...  never to take off.

It's interesting that they have gone for a lower level API centric
approach rather than a something based on a database format.  But if
it's so low level then why not just role your own plugin...

If one did expose something as powerful as the OSG with JavaScript it
would be an interesting comparison.  Both API centric, but one with
lots of art part support, threading, lots of high level effects etc,
but relatively big and complex with it and the other well... none of
those things.

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

Re: [osg-users] how to get a city's image data?

2009-05-11 Thread Ümit Uzun

Hi Forest;

You can download elevation Dem files and textures from
http://seamless.usgs.gov/index.php easily.
Or
http://geoengine.nga.mil/geospatial/SW_TOOLS/NIMAMUSE/webinter/rast_roam.html

Regards.

2009/5/12 forest 

> hi all
>   I want to use vpb to build a terrain and I have got the digital
> elevation data from
>
> ftp://ftp.glcf.umiacs.umd.edu/glcf/SRTM/Degree_Tiles/
>
> Now I want to find some corresponding texture image data for free, where
> can I get them?
>
>  Thanks in advance.
>
>
>
> best regards
>
> forest
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>


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

Re: [osg-users] txp database issue

HI Steve,

I'm afraid I can't give you an answers, I don't have your txp database
to test against, and I haven't ever seen this problem first hand.
Perhaps others in the community will have seen something similar and
may be able to help.

What I can say is that it'd be very useful for others if you provide
more information about your OSG version/OS/Graphics Card/Compiler
version/Compile build type.

Robert.


On Mon, May 11, 2009 at 9:54 PM, Stephan Posch  wrote:
> Hey everyone,
>
> I've been running into an issue with txp databases.  The problem is that 
> after running for a while the LODs start switching in and out rapidly like 
> the pager can't choose which ones to use.  Even when staying still in the 
> scene the LODs continue to switch.  It drops framerate down to around 6.0 Hz 
> and the statistics show somewhere between 100-150 ms times for GPU operations 
> (update/draw/cull all look normal).
>
> I can't really say what exactly triggers it because the timing of it seems to 
> be somewhat random.  Though it does seem to occur when externally referenced 
> models in the DB have been paged out/in multiple times.  In addition, the 
> highest LOD textures eventually lose all data and go all white.
>
> Any insight would be helpful and much appreciated!
>
> Thanks,
>
> Steve P.
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=11853#11853
>
>
>
>
>
> ___
> 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] VirtualProgram - making programmable pipeline lessfixed

Hi Wojtek,

On Mon, May 11, 2009 at 10:06 PM, Wojciech Lewandowski
 wrote:
> Thanks for Warm welcome. If nothing interrupts me I will try tomorrow to add
> changes that Robert made and maybe will create more advanced example.

I've made more changes this morning :-)

First up I've moved the State::getAttributeVec() into the public
section along with the associated typedefs.  This is now checked into
svn/trunk.  Just in case you want to compile against other versions of
OSG, the version numbers are also updated in svn/trunk so now read
2.9.5 in prep for the next dev release.

Changed file is attached.

Once you are happy with this example how do you feel about it being
included as an OSG example?  It could then live on as a test bed for
this type of functionality in prep for introducing something similar
for doing shader composite into the core OSG later down the line.

Robert.

#include
#include
#include
#include
#include

#include

using namespace osg;

#define MERGE_SHADERS 0

namespace osgExt {


osg::Shader * VirtualProgram::getShader
( const std::string & shaderSemantic, osg::Shader::Type type )
{
ShaderMap::key_type key( shaderSemantic, type );

return _shaderMap[ key ].get();
}

osg::Shader * VirtualProgram::setShader
( const std::string & shaderSemantic, osg::Shader * shader )
{
if( shader->getType() == osg::Shader::UNDEFINED ) 
return NULL;

ShaderMap::key_type key( shaderSemantic, shader->getType() );

ref_ptr< osg::Shader >   shaderNew = shader;
ref_ptr< osg::Shader > & shaderCurrent = _shaderMap[ key ];

//shaderNew->setName( shaderSemantic );

if( shaderCurrent != shaderNew ) {
#if 0
   if( shaderCurrent.valid() )
   Program::removeShader( shaderCurrent.get() );

   if( shaderNew.valid() )
   Program::addShader( shaderNew.get() );
#endif
   shaderCurrent = shaderNew;
}

return shaderCurrent;
}

void VirtualProgram::apply( osg::State & state ) const
{
State::AttributeVec *av = &state.getAttributeVec(this);

std::ostream &os  = osg::notify( osg::INFO );

os << "VirtualProgram cumulate Begin" << std::endl;

ShaderMap shaderMap;
for( State::AttributeVec::iterator i = av->begin(); i != av->end(); ++i )
{
const osg::StateAttribute * sa = i->first;
const VirtualProgram * effect = dynamic_cast< const VirtualProgram *>( sa );
if( effect && ( effect->_mask & _mask ) ) {

os << "VirtualProgram cumulate ["<< effect->getName() << "] apply" << std::endl;

   for( ShaderMap::const_iterator i = effect->_shaderMap.begin();
   i != effect->_shaderMap.end(); ++i )
shaderMap[ i->first ] = i->second;

} else {
os << "VirtualProgram cumulate ( effect from other space or not an effect ) ignore" << std::endl;

continue; // ignore osg::Programs
}
}

for( ShaderMap::const_iterator i = this->_shaderMap.begin();
   i != this->_shaderMap.end(); ++i )
shaderMap[ i->first ] = i->second;

os << "VirtualProgram cumulate End" << std::endl;

if( shaderMap.size() ) {

ShaderList sl;
for( ShaderMap::iterator i = shaderMap.begin(); i != shaderMap.end(); ++i )
sl.push_back( i->second );

osg::ref_ptr< osg::Program > & program = _programMap[ sl ];

if( !program.valid() ) {
program = new osg::Program;
#if !MERGE_SHADERS
for( ShaderList::iterator i = sl.begin(); i != sl.end(); ++i )
program->addShader( i->get() );
#else
std::string strFragment;
std::string strVertex;

for( ShaderList::iterator i = sl.begin(); i != sl.end(); ++i )
{
if( i->get()->getType() == osg::Shader::FRAGMENT )
strFragment += i->get()->getShaderSource();
else
strVertex += i->get()->getShaderSource();
}

if( strFragment.length() > 0 ) {
program->addShader( new osg::Shader( osg::Shader::FRAGMENT, strFragment ) );
}

if( strVertex.length() > 0  ) {
program->addShader( new osg::Shader( osg::Shader::VERTEX, strVertex ) );
}
#endif
}

#if !MERGE_SHADERS
assert( program->getNumShaders() == sl.size() );
#endif
program->apply( state );
} else {
Program::apply( state );
}

[osg-users] how to get a city's image data?

2009-05-11 Thread forest

hi all
   I want to use vpb to build a terrain and I have got the digital 
elevation data from  
ftp://ftp.glcf.umiacs.umd.edu/glcf/SRTM/Degree_Tiles/
 
Now I want to find some corresponding texture image data for free, where can I 
get them?
 
 Thanks in advance.
 
 
 
best regards
 
forest___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] bugfix osgDB cross-DLL allocation problem

2009-05-11 Thread Hartmut Seichter


Dear all,

for the sake of completeness some more of my findings (wrapped in a 
lengthy rant about Windows development) here.


- the osgDB::fopen is only the tip of the iceberg

- the whole thing is futile if you need to rely on prebuild 3rdparty 
binaries as chances are high the patch version of VS 2008 and its 
runtime does not match with what the 3rdparty binaries were build with 
(try to have a look at the WinSxS and count the variants of VS90_*)


- if you are build your own 3rdparty binaries you need to match exactly 
the same binding settings otherwise VisualStudio 2008 will actually do 
mixed bindings - thus the one for the actual binary plus the one from 
the dependencies. You can nicely look at this behaviour using the 
3rdparty package kindly provided on the OSG website plus using the _BIND 
- build the jpeg plugin and look at the osgdb_jpg.intermediate.manifest 
created in the binary tree - it will have bindings to two different C 
runtimes. Intermediate manifests are forcibly linked into your binaries.


- Microsoft actually also introduced bind redirection with manifests but 
for all of our sanity this would go to far to explain here now and after 
all its sounds also more like a workaround.


- In relation to the COLLADA 2.2 or 2.2.1 discussion - after being 
sensitised on that matter with the other problems I had - I can only say 
the COLLADA 2.2.1 trunk (and the 2.2 package) is the most eclectic mix 
of binaries and should not be used with VS 2008. There are VS8, VS9 and 
VS2003SP1 libraries all nicely bundles together. Zlib being linked 
against the latter 7.1 compiler thus interfering with the dependecy of 
the libpng provided in the 3rdparty binary. Crossing fingers to run an 
executable with this is probably not enough.


So I resorted finally to the solution Christian was suggesting earlier - 
shipping the VisualStudio 2008 SP1 redistributable (adding ~4MByte to an 
normally 5MByte installer) with my application. Its the only way to get 
all redirected manifests to point to the one and true VC runtime. Oh, 
and if you do so don't put the redist manifests and DLLs in the binary 
directory as they will break everything again. So finally Microsoft 
managed to let us C++ developer feel like C# or Java developers - don't 
forget that runtime of yours.



Cheers,
Hartmut







Jean-Sébastien Guay wrote:

Hi Robert, Hartmut,

The changes seem sound, I'd like to see if there are any side effects 
though, so I'll test the changes in a fresh build linked to a small 
application tomorrow. I'll let you know what I find out.


Change #1 (refer to the original e-mail from Hartmut) is ok, it's a 
small function that will now be inlined instead of in the DLL, 
preventing the fopen call being made in a different DLL context than the 
fclose call. The penalty for such a small function is small, so I don't 
see a problem. Perhaps a comment could be added explaining why this 
function is inline while all others are extern...


Change #2 is interesting. Trying to be diligent (since /a priori/ I 
didn't know anything about these settings), I looked up the defines 
Hartmut added, and found this:


http://blogs.msdn.com/vcblog/archive/2008/05/15/vc-runtime-binding.aspx

It seems that the behavior for resolving the C++ runtime version 
dependencies changed between VC2005 and VC2008. The defines Hartmut 
added just bring VC2008's settings back to VC2005 defaults. So in 
theory, it should have no effect for VC2005 either since the default was 
already set that way.


I wonder what the implication on user applications will be, considering 
the information on that page. But I guess if the developer ships the VC 
runtime DLLs (that he compiled the app with) with his application, or 
the user has that version or newer of the VC runtime installed, it 
should be ok. That's what happens for VC2005 after all.


It's true that perhaps those defines should be optional (I would make 
them default to on, as it will probably not change anything for most 
users but those who will have the same problems as Hartmut had will want 
to turn it on - people who want to turn it on will be few and will know 
the reasons why). Perhaps that should be added to the patch before final 
submission.


I've compiled OSG and an application I was working on with these 
changes, and didn't get any adverse change in behavior. Of course, I'm 
still using VC2005. Perhaps we could wait for someone else using VC2008 
to test as well, but as I said, I think the changes are OK even in that 
context.


Hope this helps,

J-S


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

Re: [osg-users] Web 3D opensource solution by Google ?

2009-05-11 Thread Chris 'Xenon' Hanson

Paul Martz wrote:
> This is interesting if, for no other reason, the fact that the work is
> taking place just a few kilometers away from where I live and work. This
> is the SketchUp office in Boulder, Colorado, if I understand correctly.

  I know a few of those guys over there. if there was any benefit to 
interaction with
them, I could probably put a few people in touch.

> Given the long history of failed 3D web standards, I don't envy anyone
> working on this project. Nothing worse than working on something that
> has a proven track record of non-acceptance in the developer community.
> I hope they can overcome the shadow of the past. Looks like interesting
> stuff so far.

  Yeah. It's like 1999 all over again!

  BTW, I'm interested in the OSG browser integration too, for some back-burner 
projects of
mine. Weren't there some smart Italians that had solved this already?

> Paul Martz
> *Skew Matrix Software LLC*
> http://www.skew-matrix.com 
> +1 303 859 9466

-- 
Chris 'Xenon' Hanson, omo sanza lettere  Xenon AlphaPixel.com
PixelSense Landsat processing now available! http://www.alphapixel.com/demos/
"There is no Truth. There is only Perception. To Perceive is to Exist." - Xen
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] VirtualProgram - making programmable pipeline less fixed

2009-05-11 Thread Chris 'Xenon' Hanson

Wojciech Lewandowski wrote:
> I would like to share some code I wrote one year ago, which my company
> have been succesfully using since then. Its not exactly something as big
> as tasks mentioned above, but I believe it makes a step forward to
> making osg::Programs and osg::Shaders more flexible and extensible. 

  This  is exactly something I've been concerned about recently myself. I'm 
very excited
by this development.

-- 
Chris 'Xenon' Hanson, omo sanza lettere  Xenon AlphaPixel.com
PixelSense Landsat processing now available! http://www.alphapixel.com/demos/
"There is no Truth. There is only Perception. To Perceive is to Exist." - Xen
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Question about asPositionAttitudeTransform()

2009-05-11 Thread Cyril Brulebois

Hi all,

I've moved some code of mine from PAT objects to MatrixTransform ones,
which suit my needs better. I'm still having a problem getting the
coordinates back. After a quick look, I figured I might be able to
transform an MT into a Transform, and then back into a PAT using the
following:
|   MatrixTransform *mt = new MatrixTransform();
|   {
| Matrix t = Matrix::translate(5, 0, 0);
| Matrix r = Matrix::rotate(45, 0, 0, 1);
| mt->setMatrix(t*r);
|   }
| 
|   Transform *t = mt->asTransform();
|   assert(t!=0);
| 
|   Transform *pat = t->asPositionAttitudeTransform();
|   assert(pat!=0);

(For reference, whole source code attached.)

I'm getting that:
| a.out: asPAT.cpp:27: int main(): Assertion `pat!=0' failed.

Should I understand that those functions, mimicking dynamic_cast calls,
would only work when a PAT object gets casted into a Transform one and
then back to a PAT object?

If so, I guess I'd have to extract the translation from the matrix I'd
have with mt->getMatrix()?

Thanks for your time.

Cheers,
-- 
Cyril Brulebois
#include 
#include 
#include 
#include 

#include 

using namespace osg;

int main(void) {
  MatrixTransform *mt = new MatrixTransform();
  {
Matrix t = Matrix::translate(5, 0, 0);
Matrix r = Matrix::rotate(45, 0, 0, 1);
mt->setMatrix(t*r);
  }

  Transform *t = mt->asTransform();
  assert(t!=0);

  Transform *re_mt = t->asMatrixTransform();
  assert(re_mt!=0);

  Transform *pat = t->asPositionAttitudeTransform();
  assert(pat!=0);

  return 0;
}


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

Re: [osg-users] constructing geometry using position, normal and uv coord arrays

Hi,

update: i'm now using another concept. (i think thats the one you recommended 
at the beginning of the thread)

instead of my original indexlist: 0, 1, 4, 2, 5, 3, 4, 0 which prevents me from 
assigning more than one normal per vertex, i'm using index swaps to "(re)visit" 
a vertex more than one time. this allows me to assign more than one normal per 
vertex without violating the triangle_strip rules.

new indexlist: 0, 1, 4, 1, 4, 2, 5, 2, 5, 3, 5, 3, 4, 0
normalslist: W, W, W, S, S, S, S, E, E, E, N, N, N, N

normals[]: {North, East, South, West}


Thank you!

Cheers,
Christian

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=11856#11856





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

Re: [osg-users] Rendering a series of nodes in precise order...

2009-05-11 Thread Frederic Bouvier

Hi,

- "Nathan Monteleone" a écrit :
> Mathias Fröhlich wrote:
> > Well, as far as I understand, and as far as I have my own applications for
> > such kind of scenes. You will need an own render bin number for each object
> > if every object just depends on the previous object to be rendered before.
> > Else the StateSet sorting might reorder the drawables - true?
> >
> > Anyway, Robert, I believe it would help to have a 'SceneGraphOrderSorted'
> > renderbin where the sorting order of the of the child nodes is just taken.
> > Can we have such a beast?
> >
> 
> 
> Yeah this is exactly my situation.  I could use the
> SceneGraphOrderSorted renderbin too - thanks for the suggestion, and
> to Robert for taking it.

I was thinking how I could implement a CSG algorithm ( like the one implemented 
here : 
http://www.opencsg.org/ ) using OSG. It seems a class like that could help a 
lot.

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

Re: [osg-users] VirtualProgram - making programmable pipeline lessfixed

2009-05-11 Thread Wojciech Lewandowski


J-S, Robert, Maciej, Roland et al,

Thanks for Warm welcome. If nothing interrupts me I will try tomorrow to add 
changes that Robert made and maybe will create more advanced example.


Roland, you are right this was a rather simple example of VirtualProgram. In 
practice we employ it in bit more complex scenarios.  Since I wrote this 
code some time ago,  I forgot one of original motives.  This idea was to 
allow some programability in model statesets while retaining freedom to 
create advanced(or simple) lighting of the whole scene. With osg::Program 
all shaders had to be stored in the model and as such it would not be 
possible to have the same model displayed with different lighting/shading 
algorithm. With VirtualProgram parts of program lighting could be 
virtualized and replaced by different lighting shaders. Thats why I though 
about creating the example that would show the cows on two views displaying 
them simultaneously  with vertex / pixel lighting.


Cheers,
Wojtek

--
From: "Roland Smeenk" 
Sent: Monday, May 11, 2009 10:18 PM
To: 
Subject: Re: [osg-users] VirtualProgram - making programmable pipeline 
lessfixed



Hi Wojtek,

Thanks for sharing your code. This will be very helpfull.
It would be nice if we could somehow combine this with the existing fixed 
function ShaderGen utility.


Thoughts about the demo:
The coloring of the children with only a different version of the 
ColorFilter would typically be implemented with a uniform that is 
overidden by the children. The children depend on a parent virtualprogram 
that actually calls the ColorFilter method. If this is not the case the 
Program used by the children will fail (which is logical, because they are 
incomplete)


I guess in practice you are using a virtualprogram with a lot of semantic 
blocks at the root of the tree so children have the opportunity to 
override multiple pieces of the shader similar to overriding 
stateattributes in a stateset.


warmest regards,

Roland

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=11851#11851





___
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] txp database issue

2009-05-11 Thread Stephan Posch

Hey everyone,

I've been running into an issue with txp databases.  The problem is that after 
running for a while the LODs start switching in and out rapidly like the pager 
can't choose which ones to use.  Even when staying still in the scene the LODs 
continue to switch.  It drops framerate down to around 6.0 Hz and the 
statistics show somewhere between 100-150 ms times for GPU operations 
(update/draw/cull all look normal).  

I can't really say what exactly triggers it because the timing of it seems to 
be somewhat random.  Though it does seem to occur when externally referenced 
models in the DB have been paged out/in multiple times.  In addition, the 
highest LOD textures eventually lose all data and go all white.

Any insight would be helpful and much appreciated!

Thanks,

Steve P.

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=11853#11853





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

Re: [osg-users] Web 3D opensource solution by Google ?

This is interesting if, for no other reason, the fact that the work is
taking place just a few kilometers away from where I live and work. This is
the SketchUp office in Boulder, Colorado, if I understand correctly.
 
Given the long history of failed 3D web standards, I don't envy anyone
working on this project. Nothing worse than working on something that has a
proven track record of non-acceptance in the developer community. I hope
they can overcome the shadow of the past. Looks like interesting stuff so
far.
 
Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com  
+1 303 859 9466
 

  _  

From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Pierre
Bourdin (gmail)
Sent: Monday, May 11, 2009 8:01 AM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] Web 3D opensource solution by Google ?


Hi all,

have you seen this project ?
http://code.google.com/intl/fr/apis/o3d/

http://code.google.com/intl/fr/apis/o3d/docs/techoverview.html

Here's an interview about it...
http://www.3d-test.com/interviews/google_O3D_1.htm

What's your opinion about this project ?
Pierre.


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] VirtualProgram - making programmable pipeline less fixed

2009-05-11 Thread Roland Smeenk

Hi Wojtek,

Thanks for sharing your code. This will be very helpfull.
It would be nice if we could somehow combine this with the existing fixed 
function ShaderGen utility.

Thoughts about the demo:
The coloring of the children with only a different version of the ColorFilter 
would typically be implemented with a uniform that is overidden by the 
children. The children depend on a parent virtualprogram that actually calls 
the ColorFilter method. If this is not the case the Program used by the 
children will fail (which is logical, because they are incomplete)

I guess in practice you are using a virtualprogram with a lot of semantic 
blocks at the root of the tree so children have the opportunity to override 
multiple pieces of the shader similar to overriding stateattributes in a 
stateset.

warmest regards,

Roland

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=11851#11851





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

Re: [osg-users] dynamic clipping node

You need to set the clip plant mode on or off using the StateSet associated
with your geometry, not the StateSet from the ClipNode or ClipPlane. This
should be clear from the osg clip example.

Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com
+1 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] dynamic clipping node

In addition to Robert's comments, I'll add the following:

If you intend to turn the clip plane on and off, make sure to set your
StateSet data variance to DYNAMIC.

Also, I recently wrote code to dynamically update a ClipPlane based on the
view vector to create a cross section that always shows the back half.
Again, set the DataVariance on the ClipPlane to DYNAMIC for this type of
algorithm. (This is part of a larger app that I intend to demo at the OSG
BOF at SIGGRAPH this year.)

Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com
+1 303 859 9466

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert
Osfield
Sent: Monday, May 11, 2009 1:18 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] dynamic clipping node

Hi Lee,

Clip planes are position state, so have to be positioned in space by the
osg::ClipNode, but the actually enabling of clip planes is decoupled from
this and control through osg::StateSet::setMode(GL_CLIP_PLANE0+i,
osg::StateAttribute::ON).
You typically wouldn't decorate your scene with the ClipNode, rather you
would usually place the ClipNode in your scene and positioned appropriately,
then enable the individual clip planes for the subgraphs you want them to be
on by just setting the modes (as above) via a StateSet that is attached to
root of subgraph that you want to enable it for.

Robert.

On Mon, May 11, 2009 at 8:02 PM, Butler, Lee Mr CIV USA USAMC
 wrote:
> I want to turn a cutting plane on and off at various levels in the 
> graph and update it under user control.  The osgclip example was 
> enough to show me how to add the clipping plane.  Getting it turned on 
> and off is something that somehow eludes me.  I'm having trouble 
> understanding the "OSG way" of doing this.
>
> Code looks like this:
>
>   // load geometry, etc ...
>   // add clip node
>   decorate_with_clip_node(scene);
>
>   // set attributes on stateset ...
>
>   MyVisitor myVisitor(stateset);
>
>   while (!viewer.done()) {
>         viewer.advance();
>         viewer.eventTraversal();
>         viewer.updateTraversal();
>         viewer.renderingTraversals();
>   }
>
> When the user presses a key to toggle the clipping plane I do:
>
>   clipped_subgraph->accept(myVisitor);
>
> which in turn does:
>
>     if (node.getStateSet()) {
>         node.setStateSet(NULL);
>     } else {
>         node.setStateSet( _stateset );
>     }
>
>
> The first time the NodeVisitor runs it claims to turn off the StateSet 
> on the graphNode.  Yet the clipping still occurs.  On the second pass 
> through, the stateset pointer is no longer valid, as if it had been 
> freed.  I've checked the reference count on the stateset after the 
> call to node.setStateSet(NULL) and the it is still 2, so I wouldn't have
anticipated it getting destroyed.
>
> Clearly I'm lost in newbie-land.  I've tried searching the archives, 
> but I haven't found the right posting and the website doesn't seem to 
> be very stable this month.
>
> Help?
>
> Lee
> ___
> 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] dynamic clipping node

2009-05-11 Thread Butler, Lee Mr CIV USA USAMC

OK, from your explanation I attempted a simple "flip the cut plane on and off" 
example.  The graph looks roughly like:

rootnode -+- TransformNode -+- ClipNode
+- GroupNode -+- Geode1
+- Geode2
and I get:

ClipNode {
  name "Clip Node"
  nodeMask 0x
  cullingActive FALSE
  StateSet {
UniqueID StateSet_0
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
GL_CLIP_PLANE0 ON
  }
  referenceFrame RELATIVE
  ClipPlane {
clipPlaneNum 0
plane -1 0 0 0.5
  }
}

Now the simulation loop code looks like:

unsigned frame = 0;

#define LIM 1
while (!viewer.done()) {
viewer.advance();
viewer.eventTraversal();
viewer.updateTraversal();

if (frame == 0) {
fprintf(stderr, "frame %u\n", frame);
stateset->setMode(GL_CLIP_PLANE0,osg::StateAttribute::OFF);
} else if (frame == (LIM/2)) {
fprintf(stderr, "frame %u\n", frame);
stateset->setMode(GL_CLIP_PLANE0+0,osg::StateAttribute::ON);
}

viewer.renderingTraversals();
frame = (frame+1) % LIM;
}

This I hoped would "flip" the cutting plane on and off, but the cutting plane 
was always on, despite the logging reporting that setMode was being called.

Lee

- Original Message -
From: Robert Osfield 
Date: Monday, May 11, 2009 15:18
Subject: Re: [osg-users] dynamic clipping node
To: OpenSceneGraph Users 


> Hi Lee,
> 
> Clip planes are position state, so have to be positioned in space by
> the osg::ClipNode, but the actually enabling of clip planes is
> decoupled from this and control through
> osg::StateSet::setMode(GL_CLIP_PLANE0+i, osg::StateAttribute::ON).
> You typically wouldn't decorate your scene with the ClipNode, rather
> you would usually place the ClipNode in your scene and positioned
> appropriately, then enable the individual clip planes for the
> subgraphs you want them to be on by just setting the modes (as above)
> via a StateSet that is attached to root of subgraph that you want to
> enable it for.
> 
> Robert.
> 
> On Mon, May 11, 2009 at 8:02 PM, Butler, Lee Mr CIV USA USAMC
> < wrote:
> > I want to turn a cutting plane on and off at various levels in the graph and
> > update it under user control.  The osgclip example was enough to show me how
> > to add the clipping plane.  Getting it turned on and off is something that
> > somehow eludes me.  I'm having trouble understanding the "OSG way" of doing
> > this.
> >
> > Code looks like this:
> >
> >   // load geometry, etc ...
> >   // add clip node
> >   decorate_with_clip_node(scene);
> >
> >   // set attributes on stateset ...
> >
> >   MyVisitor myVisitor(stateset);
> >
> >   while (!viewer.done()) {
> >         viewer.advance();
> >         viewer.eventTraversal();
> >         viewer.updateTraversal();
> >         viewer.renderingTraversals();
> >   }
> >
> > When the user presses a key to toggle the clipping plane I do:
> >
> >   clipped_subgraph->accept(myVisitor);
> >
> > which in turn does:
> >
> >     if (node.getStateSet()) {
> >         node.setStateSet(NULL);
> >     } else {
> >         node.setStateSet( _stateset );
> >     }
> >
> >
> > The first time the NodeVisitor runs it claims to turn off the StateSet on 
> > the
> > graphNode.  Yet the clipping still occurs.  On the second pass through, the
> > stateset pointer is no longer valid, as if it had been freed.  I've checked
> > the reference count on the stateset after the call to node.setStateSet(NULL)
> > and the it is still 2, so I wouldn't have anticipated it getting destroyed.
> >
> > Clearly I'm lost in newbie-land.  I've tried searching the archives, but I
> > haven't found the right posting and the website doesn't seem to be very 
> > stable
> > this month.
> >
> > Help?
> >
> > Lee
> > ___
> > 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] VirtualProgram - making programmable pipeline less fixed

Hi Wojtek,

Thought I'd squeeze in a few more minutes work before I head offline.
I couldn't get you little project to compile due to not having the
debug libs built on my machine, so I had to tweak the Cmake file to
not link against the debug if no debug libs were found.  There might
be a more efficient way of doing it, but I though't I'd throw this
little revision out there just in case others need it.

if (${OPENTHREADS_LIBRARY_DEBUG})
target_link_libraries( osgVirtualProgramTest optimized
${OPENTHREADS_LIBRARY} debug ${OPENTHREADS_LIBRARY_DEBUG} )
target_link_libraries( osgVirtualProgramTest optimized
${OSG_LIBRARY} debug ${OSG_LIBRARY_DEBUG} )
target_link_libraries( osgVirtualProgramTest optimized
${OSGDB_LIBRARY} debug ${OSGDB_LIBRARY_DEBUG} )
target_link_libraries( osgVirtualProgramTest optimized
${OSGVIEWER_LIBRARY} debug ${OSGVIEWER_LIBRARY_DEBUG} )
else()
target_link_libraries( osgVirtualProgramTest optimized
${OPENTHREADS_LIBRARY})
target_link_libraries( osgVirtualProgramTest optimized ${OSG_LIBRARY})
target_link_libraries( osgVirtualProgramTest optimized ${OSGDB_LIBRARY})
target_link_libraries( osgVirtualProgramTest optimized ${OSGVIEWER_LIBRARY})
endif()

With this little change I get the four multi-coloured cows :-)

Robert.
cmake_minimum_required (VERSION 2.6)

project (osgVirtualProgram)

set( CMAKE_DEBUG_POSTFIX  "d" )

find_package (OpenThreads REQUIRED)
find_package (osg REQUIRED)
find_package (osgDB REQUIRED)
find_package (osgViewer REQUIRED)

include_directories (${OSG_INCLUDE_DIR})
include_directories (${osgVirtualProgram_SOURCE_DIR})

add_library( osgVirtualProgram STATIC VirtualProgram.cpp VirtualProgram.h )

add_executable ( osgVirtualProgramTest VirtualProgramTest.cpp )

target_link_libraries( osgVirtualProgramTest osgVirtualProgram )

if (${OPENTHREADS_LIBRARY_DEBUG})
target_link_libraries( osgVirtualProgramTest optimized 
${OPENTHREADS_LIBRARY} debug ${OPENTHREADS_LIBRARY_DEBUG} )
target_link_libraries( osgVirtualProgramTest optimized ${OSG_LIBRARY} debug 
${OSG_LIBRARY_DEBUG} )
target_link_libraries( osgVirtualProgramTest optimized ${OSGDB_LIBRARY} 
debug ${OSGDB_LIBRARY_DEBUG} )
target_link_libraries( osgVirtualProgramTest optimized ${OSGVIEWER_LIBRARY} 
debug ${OSGVIEWER_LIBRARY_DEBUG} )
else()
target_link_libraries( osgVirtualProgramTest optimized 
${OPENTHREADS_LIBRARY})
target_link_libraries( osgVirtualProgramTest optimized ${OSG_LIBRARY})
target_link_libraries( osgVirtualProgramTest optimized ${OSGDB_LIBRARY})
target_link_libraries( osgVirtualProgramTest optimized ${OSGVIEWER_LIBRARY})
endif()

___
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-11 Thread David Spilling

Kim,

For very large
> expanses of ocean the problem I forsee is the time it takes to update the
> vertices and primitive sets.
> However, since the FFT technique is tileable it would be possible to only
> update 1 tile and then translate
> them into position using a shader. This would rule out any surface
> interactions


"Surface interactions" in terms of locally modifying the vertex heights?
Tileable FFT doesn't definately rule it out : you can use the following
approach:

1) render a FFT derived heightfield into a texture
2) RTT local heightfields (wakes and so on) attached to some object , as if
you were the camera.
3) Use a vertex shader operating on a screen-aligned grid (i.e. projective
grid approach) and some vertex texture operations to sample the FFT
heightfield for the correct world position, and also to sample the RTT
texture of "local" vertex heights.

Unfortunately, the possibility of this type of technique makes providing
some sort of overall osgOcean architecture that can act as a framework for
all techniques very tricky, IMHO. (you get entangled in too many overall
scenegraph issues)

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

Re: [osg-users] osgOcean release

Hi Kim,

On Mon, May 11, 2009 at 7:50 PM, Kim C Bale  wrote:
>>Is there any chance that we'd be able to get osgOcean working on
> geocentric databases?  It'd be very cool to be able zoom down from
> space to the sea.
>
> As I don't know a lot about geocentric databases it would be hard for me to 
> say. But the potential
> for animated oceans on very large terrain datasets would be very exciting. 
> For very large
> expanses of ocean the problem I forsee is the time it takes to update the 
> vertices and primitive sets.

LOD'ing, tiling and local coordinate systems are the tools of the
whole earth database trade.  In the context of osgOcean I would expect
to have several different techniques - one for near water effects like
you have which his surface displacement and shaders, then for lower
levels of detail techniques that just have static geometry meshes
and shaders/textures for the water rendering.

You'd also want to try an reuse tiles so that as you move out of range
of one set of tiles these then get reused for the new tiles that need
to be created.  It is sometimes possible to reuse a small set of
geometries and just use shaders to map the separate instances - this
is what I did for the rain and snow effects - it's an effectively
infinite effect, but implementation it's just a single block of
geometry that is animated and positioned by uniforms pass into shaders
to look like an infinite effect.  Perhaps something similar might be
possible.

The other challange would be the non uniform boundaries between water
and land.  Is there any support for this?

Another little point with geocentric databases is that each tile is
slightly curved, the lower the level of detail the large the area
covered and the more curvature it will have.  For precision one also
uses a local MatrixTransform above each tile to ensure that there is a
local origin in the center of the tile to maximum precision.

One also need to think about the how the tiles boundaries are managed,
with a dynamic effect like sea it'll be more difficult to hide than on
terrain where even crude skirts can be sufficient.  If the boundary is
far enough then the gap might be small enough not to matter.

> However, since the FFT technique is tileable it would be possible to only 
> update 1 tile and then translate
> them into position using a shader. This would rule out any surface 
> interactions, but for this type
> of application they probably wouldn't be necessary. I'll add it to the list 
> of things to look at.
>
>>Is there are plans for following water like in rivers?
>
> For the moment rivers are out of the scope of the project as I think this 
> would require a totally differant
> approach. The problem is that I'm torn between what I'd like to do and what 
> I'm bound by
> contract to open source. So for the moment I'm concentrating on getting the 
> code out to keep
> the reviewers happy, then once I'm done with that I'll do some research into 
> the many suggestions that
> have been posted here.

Understood.  Is it possible to do lakes and non flowing rivers though

>>Sorry for the all the awkward questions, this stuff is just too pretty
> not to want to put it everywhere :-)
>
> Not at all. I'm extremely happy that it has been so well recieved.

Ahh we're all just suckers for a nice bit of eye candy ;-)

Robert.
___
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-11 Thread Kim C Bale

Hi Robert,

>Is there any chance that we'd be able to get osgOcean working on
geocentric databases?  It'd be very cool to be able zoom down from
space to the sea.

As I don't know a lot about geocentric databases it would be hard for me to 
say. But the potential
for animated oceans on very large terrain datasets would be very exciting. For 
very large 
expanses of ocean the problem I forsee is the time it takes to update the 
vertices and primitive sets. 
However, since the FFT technique is tileable it would be possible to only 
update 1 tile and then translate
them into position using a shader. This would rule out any surface 
interactions, but for this type
of application they probably wouldn't be necessary. I'll add it to the list of 
things to look at.

>Is there are plans for following water like in rivers?

For the moment rivers are out of the scope of the project as I think this would 
require a totally differant
approach. The problem is that I'm torn between what I'd like to do and what I'm 
bound by 
contract to open source. So for the moment I'm concentrating on getting the 
code out to keep
the reviewers happy, then once I'm done with that I'll do some research into 
the many suggestions that 
have been posted here.

>Sorry for the all the awkward questions, this stuff is just too pretty
not to want to put it everywhere :-)

Not at all. I'm extremely happy that it has been so well recieved. 

Regards,

Kim.

From: osg-users-boun...@lists.openscenegraph.org on behalf of Robert Osfield
Sent: Fri 08/05/2009 19:56
To: OpenSceneGraph Users
Subject: Re: [osg-users] osgOcean release

Hi Kim,

On Fri, May 8, 2009 at 5:58 PM, Kim C Bale  wrote:
> Hi Robert,
>
> You need to download the resource pack from the downloads sections and drop 
> the textures into the resource directory before you hit install. I seperated 
> them as I didn't want them to get versioned. But everyone seems to be 
> tripping up on that one so perhaps I should include them by default.

Ack... case of me not doing any background reading... Sorry about that.

> I get the same 'invalid operation' error on an nVidia, I just haven't located 
> the source yet :) still working on it.

If you up the OpenGL error checking in osg::State to per
StateAttribute you might get a more precise location of the error.
After realize you could just do the following on all the viewers
graphics windows:

graphicswindow->getState()->setCheckForGLErrors(osg::State::ONCE_PER_ATTRIBUTE);

> It's possible the choppy frame rate is caused by the update callback when it 
> updates the primitives and vertices on a resolution change. If you turn on 
> stats you can see the update callback pinging up when theres a change. I 
> hadn't thought about this actually, on my machine it's barely noticeable. I 
> think i may need to thread the update to prevent the frame being delayed.

I had the KDE desktop compositor enabled during my earlier tests.  I
tested just now with the desktop compositor off and got a solid 75Hz
so it does look like it's the ATI driver/KWin compositor not working
smoothly.  So it does look this is a non issue.

Is there any chance that we'd be able to get osgOcean working on
geocentric databases?  It'd be very cool to be able zoom down from
space to the sea.

Is there are plans for following water like in rivers?

Sorry for the all the awkward questions, this stuff is just too pretty
not to want to put it everywhere :-)
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

<>*
To view the terms under which this email is distributed, please go to 
http://www.hull.ac.uk/legal/email_disclaimer.html
*___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OGR plugin : Build failed, under VS 2005

Hi Adrian,

I haven't head of build errors with the ogr plugin before.  Could you
be specific about which version of the OSG and OGR you are using and
the error you see.

Perhaps other Windows users who've built the OGR can suggest what
might be wrong.

Robert.

On Mon, May 11, 2009 at 8:14 PM, Adrian Egli OpenSceneGraph (3D)
<3dh...@gmail.com> wrote:
> Hi Robert,
>
> There are some build bugs under VS 2005, OGR plugin. How can i fix it, or
> what should i install to build correctly?
>
> missing CPL_STDCALL
>
> #ifndef CPL_STDCALL
> #if defined(_MSC_VER) && !defined(CPL_DISABLE_STDCALL)
> #  define CPL_STDCALL __stdcall
> #else
> #  define CPL_STDCALL
> #endif
> #endif
>
>
> MISSING CPL ...
>
> class ReaderWriterOGR : public osgDB::ReaderWriter
> {
>
> public:
>     ReaderWriterOGR()
>     {
>     supportsExtension("ogr","OGR file reader");
>     supportsOption("useRandomColorByFeature", "Assign a random color to
> each feature.");
>     supportsOption("addGroupPerFeature", "Places each feature in a
> seperate group.");
> -->   oldHandler = CPLSetErrorHandler(CPLOSGErrorHandler);
>     }
>
>     virtual ~ReaderWriterOGR()
>     {
> -->    CPLSetErrorHandler(oldHandler);
>     }
>
>
> /regards
> Adrian
>
> --
> 
> Adrian Egli
>
> ___
> 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] dynamic clipping node

Hi Lee,

Clip planes are position state, so have to be positioned in space by
the osg::ClipNode, but the actually enabling of clip planes is
decoupled from this and control through
osg::StateSet::setMode(GL_CLIP_PLANE0+i, osg::StateAttribute::ON).
You typically wouldn't decorate your scene with the ClipNode, rather
you would usually place the ClipNode in your scene and positioned
appropriately, then enable the individual clip planes for the
subgraphs you want them to be on by just setting the modes (as above)
via a StateSet that is attached to root of subgraph that you want to
enable it for.

Robert.

On Mon, May 11, 2009 at 8:02 PM, Butler, Lee Mr CIV USA USAMC
 wrote:
> I want to turn a cutting plane on and off at various levels in the graph and
> update it under user control.  The osgclip example was enough to show me how
> to add the clipping plane.  Getting it turned on and off is something that
> somehow eludes me.  I'm having trouble understanding the "OSG way" of doing
> this.
>
> Code looks like this:
>
>   // load geometry, etc ...
>   // add clip node
>   decorate_with_clip_node(scene);
>
>   // set attributes on stateset ...
>
>   MyVisitor myVisitor(stateset);
>
>   while (!viewer.done()) {
>         viewer.advance();
>         viewer.eventTraversal();
>         viewer.updateTraversal();
>         viewer.renderingTraversals();
>   }
>
> When the user presses a key to toggle the clipping plane I do:
>
>   clipped_subgraph->accept(myVisitor);
>
> which in turn does:
>
>     if (node.getStateSet()) {
>         node.setStateSet(NULL);
>     } else {
>         node.setStateSet( _stateset );
>     }
>
>
> The first time the NodeVisitor runs it claims to turn off the StateSet on the
> graphNode.  Yet the clipping still occurs.  On the second pass through, the
> stateset pointer is no longer valid, as if it had been freed.  I've checked
> the reference count on the stateset after the call to node.setStateSet(NULL)
> and the it is still 2, so I wouldn't have anticipated it getting destroyed.
>
> Clearly I'm lost in newbie-land.  I've tried searching the archives, but I
> haven't found the right posting and the website doesn't seem to be very stable
> this month.
>
> Help?
>
> Lee
> ___
> 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] OGR plugin : Build failed, under VS 2005

2009-05-11 Thread Adrian Egli OpenSceneGraph (3D)

Hi Robert,

There are some build bugs under VS 2005, OGR plugin. How can i fix it, or
what should i install to build correctly?

missing CPL_STDCALL

#ifndef CPL_STDCALL
#if defined(_MSC_VER) && !defined(CPL_DISABLE_STDCALL)
#  define CPL_STDCALL __stdcall
#else
#  define CPL_STDCALL
#endif
#endif


MISSING CPL ...

class ReaderWriterOGR : public osgDB::ReaderWriter
{

public:
ReaderWriterOGR()
{
supportsExtension("ogr","OGR file reader");
supportsOption("useRandomColorByFeature", "Assign a random color to
each feature.");
supportsOption("addGroupPerFeature", "Places each feature in a
seperate group.");
-->   oldHandler = CPLSetErrorHandler(CPLOSGErrorHandler);
}

virtual ~ReaderWriterOGR()
{
-->CPLSetErrorHandler(oldHandler);
}


/regards
Adrian

-- 

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

[osg-users] dynamic clipping node

2009-05-11 Thread Butler, Lee Mr CIV USA USAMC

I want to turn a cutting plane on and off at various levels in the graph and
update it under user control.  The osgclip example was enough to show me how
to add the clipping plane.  Getting it turned on and off is something that
somehow eludes me.  I'm having trouble understanding the "OSG way" of doing
this.

Code looks like this:

   // load geometry, etc ...
   // add clip node
   decorate_with_clip_node(scene);

   // set attributes on stateset ...

   MyVisitor myVisitor(stateset);

   while (!viewer.done()) {
 viewer.advance();
 viewer.eventTraversal();
 viewer.updateTraversal();
 viewer.renderingTraversals();
   }

When the user presses a key to toggle the clipping plane I do:

   clipped_subgraph->accept(myVisitor);

which in turn does:

 if (node.getStateSet()) {
 node.setStateSet(NULL);
 } else {
 node.setStateSet( _stateset );
 }


The first time the NodeVisitor runs it claims to turn off the StateSet on the
graphNode.  Yet the clipping still occurs.  On the second pass through, the
stateset pointer is no longer valid, as if it had been freed.  I've checked
the reference count on the stateset after the call to node.setStateSet(NULL)
and the it is still 2, so I wouldn't have anticipated it getting destroyed.

Clearly I'm lost in newbie-land.  I've tried searching the archives, but I
haven't found the right posting and the website doesn't seem to be very stable
this month.

Help?

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

Re: [osg-users] OSG and QT example

2009-05-11 Thread David Guthrie

Hi,

Yes, it does fix the keyboard issues, at least most of them, and I have done 
some minor testing with the threading and it seems to work.

... 

Thank you!

Cheers,
David

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=11839#11839





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

Re: [osg-users] Web 3D opensource solution by Google ?

Hi Maciej,

On Mon, May 11, 2009 at 6:01 PM, Maciej Krol  wrote:
> Google is promising great performance from V8 JavaScript engine
> http://code.google.com/p/v8. It was created with embedding in mind. It would
> be great to write node update callbacks in JavaScript or Lua.

I have briefly looked at V8 but then found out that its only 32bit so
far.  I only have one 32bit machine now, and that's a 5 year old
laptop so it sucks that google aren't a little more on the ball.

For Present3D my plan is to have a couple of high level scene object
classes with well defined interface to make it easier to expose the
features in scripting language.  These classes will become part of an
osgPresentation library that will be the take over the bulk of
Present3D functionality.  This is something I'm be tackling in next
couple of months.

The browser integration is another part of the jigsaw we need to
complete on the OSG side.  We had lots of noise on this a few months
back, but not much recently...  Any more news on this front anyone?

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

Re: [osg-users] Mixing event callbacks and camera manipulators

Hi Paul,

On Mon, May 11, 2009 at 5:49 PM, Paul Martz  wrote:
> Thanks, Serge. Odd, I thought that the default behavior was that handled
> events did _not_ filter on to subordinate handlers. I must've been mistaken.

In OSG-1.x events were not passed on if handled.

In OSG-2.x events are passed on to all manipulators/event handlers and
it's the event handlers responsibility to decide whether they want to
ignore handled events or not.  This approach is more flexible and
robust once you now about if (handled) trick.

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

Re: [osg-users] VirtualProgram - making programmable pipeline less fixed

Hi Wojtek,

Great to see more activity on the shader front.  I've only read your
description so far, but it does sound something that's heading in the
same direction as to my thoughts on state/shader interface for
OSG-3.0.  Given you've got something working without too many changes
to the core OSG it could well serve as an interim step.

I'm busy on other tasks right now so can't dive into review some new
techniques like this.  I hopefully will get a breather soon and will
be able to dive in.  On the modification to osg::State, in principle I
don't have objections to these.

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

Re: [osg-users] Web 3D opensource solution by Google ?

2009-05-11 Thread Maciej Krol

Hi Robert,

Google is promising great performance from V8 JavaScript engine
http://code.google.com/p/v8. It was created with embedding in mind. It would
be great to write node update callbacks in JavaScript or Lua.

Regards,
Maciej

2009/5/11 Robert Osfield 

> Hi Pierre,
>
> Thanks for the links.  Just had a quick browse, it's amusing to find
> some OpenSceneGraph terminology turn up in their technology
> overview... StateSet, RenderGraph anyone, coincidence or inspiration
> :-)
>
> Lightweight javascript scene graph will have some value for browsers.
> It's unlikely to scale well to complex graphics apps and data sizes.
> When Google announced this effort it did make think about whether a
> JavaScript wrapper for the OSG might just be an decent alternate
> solution for those who need real power and scalability.
>
> Another thought I've had is for the future of Present3D to migrate to
> be script driven, with the scripting sitting upon a high level
> abstraction of the various assets you have in the scene.  One could
> possible select JavaScript ontop of this high level abstraction,
> although personally I'm inclined towards Lua for it's ease of
> integration.  In the context of browsers JavaScript is king though...
>
> Robert.
>
>
> On Mon, May 11, 2009 at 3:01 PM, Pierre Bourdin (gmail)
>  wrote:
> > Hi all,
> >
> > have you seen this project ?
> > http://code.google.com/intl/fr/apis/o3d/
> >
> > http://code.google.com/intl/fr/apis/o3d/docs/techoverview.html
> >
> > Here's an interview about it...
> > http://www.3d-test.com/interviews/google_O3D_1.htm
> >
> > What's your opinion about this project ?
> > Pierre.
> > 
> > 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
> >
> >
> ___
> 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] Mixing event callbacks and camera manipulators

Thanks, Serge. Odd, I thought that the default behavior was that handled
events did _not_ filter on to subordinate handlers. I must've been mistaken.
 
For the archives, I found that I can also add the following to my custom
MatrixManipulator:
setIgnoreHandledEventsMask(
osgGA::GUIEventAdapter::DRAG
);
This causes the events passed in (it's a bitmask) to be ignored and not
passed to the handle() method.

Either solution (yours or mine) works, but I think I'll go with yours.
Thanks again for the fast response.
 
Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com  
+1 303 859 9466
 



From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Serge Lages
Sent: Monday, May 11, 2009 10:40 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Mixing event callbacks and camera manipulators


Hi Paul,

Have you checked the following in your custom manipulator :

if (ea.getHandled()) return false;

Each event handler needs to check itself (or not) this variable to know if
it needs to handle the event.

Hope this helps.
Cheers,


On Mon, May 11, 2009 at 6:32 PM, Paul Martz  wrote:


Hi Robert and others -- I'm pretty good with OpenGL and 3D stuff,
but when it comes to GUI interactions I'm a little week. I'm hoping someone
can give me some pointers on what I might be doing wrong here.
 
I've got an event callback attached to some node in my scene graph
that looks for DRAG events. It returns true when it handles one so that the
camera manipulator doesn't also attempt to handle the DRAG.
 
This works great when I have a TrackballManipulator set as the
Viewer's CameraManipulator. However, if I switch over to a custom
MatrixManipulator that I've created, the event appears to get passed to my
custom manipulator and it. too, processes the DRAG event -- even though my
event callback is returning true.
 
Like I said, the TrackballManipulator properly ignores the DRAG, so
the problem must be in my custom matrix manipulator (and not in my event
callback).
 
Any idea what I might be doing wrong?
 
Sorry this is so open-ended. I'm hoping someone else has encountered
something similar and can reply from experience.
 
Thanks,
 
Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com  
+1 303 859 9466
 

___
osg-users mailing list
osg-users@lists.openscenegraph.org

http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org






-- 
Serge Lages
http://www.tharsis-software.com


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

Re: [osg-users] Rendering a series of nodes in precise order...

2009-05-11 Thread Nathan Monteleone


Mathias Fröhlich wrote:
> Well, as far as I understand, and as far as I have my own applications for 
> such kind of scenes. You will need an own render bin number for each object 
> if every object just depends on the previous object to be rendered before. 
> Else the StateSet sorting might reorder the drawables - true?
> 
> Anyway, Robert, I believe it would help to have a 'SceneGraphOrderSorted' 
> renderbin where the sorting order of the of the child nodes is just taken.
> Can we have such a beast?
> 


Yeah this is exactly my situation.  I could use the SceneGraphOrderSorted 
renderbin too - thanks for the suggestion, and to Robert for taking it.

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=11831#11831





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

Re: [osg-users] VirtualProgram - making programmable pipeline less fixed

2009-05-11 Thread Maciej Krol

Hi Wojtek, J-S et al,

Thanks for sharing the code Wojtek. It is always nice to see production code
that does the job. What a coincidence, right now I am experimenting with
embedding custom modes (including Your osgShadow) and shader composition
directly in a cull traversal. Definitely I will take a look at Your code.
IMO the ubershader is not the way to go, OSG should focus on more
distributed approaches like the one You presented.

I wrote StateEx in ShaderGen to get access to protected members of
osg::State. In the past osg::State was not used outside of cull/render
stages. Since shaders came into play it is more often abused :).

Regards,
Maciej

2009/5/11 Jean-Sébastien Guay 

> Hi Wojtek,
>
>  I am glad I have Your support. Honestly, I was counting on You ;-) I am
>> not that fluent in English as I would like to be. Writing such posts usually
>> take me much longer than in may native polish, I often realize that some
>> ideas got lost in the midle of batlle with proper word/expression selection,
>> so its always good to have some support from native speakers ;-).
>>
>
> Actually my native language is French, but I learned English at a very
> young age so I'm pretty fluent. Thanks for the compliment, I'm glad to help
> and when the functionality is something I've wanted for a while I'm even
> more glad! :-)
>
>  Look at StateHack class and reinterpret_cast expression in
>> VirtualProgram apply.
>>
>
> Wow, how did I miss that? :-)
>
>  StateHack overrides osg::State class to make getAttribureVec method
>> accessible to Virtual program. This method is protected or private to
>> osg::State.
>> Obiously this could be solved by mamking VirtualProgram a friend of
>> osg::State but that would require changes to core OSG.
>>
>
> I've actually seen such a class a few times in the past few months (one in
> the osgUtil::ShaderGen class (cpp file, class called StateEx). That, to me,
> means that perhaps the osg::State API isn't as flexible as it could be (or
> perhaps it was ok in the past but now it needs to be evolved in new
> directions). Robert, any comments on this?
>
> Obviously exposing osg::State's internals wholesale would make it easy for
> users to muck things up, but two cases of overriding it to provide access to
> some of its private/protected methods/data tells me that it might be nice to
> think about a cleaner way to provide this access? In both cases, the methods
> are just getters so perhaps they could be safely added to the API (or in a
> slightly modified mode)?
>
> Hoping to see this move forward,
>
>
> J-S
> --
> __
> Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
>   http://www.cm-labs.com/
>http://whitestar02.webhop.org/
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Mixing event callbacks and camera manipulators

2009-05-11 Thread Serge Lages

Hi Paul,

Have you checked the following in your custom manipulator :

if (ea.getHandled()) return false;

Each event handler needs to check itself (or not) this variable to know if
it needs to handle the event.

Hope this helps.
Cheers,

On Mon, May 11, 2009 at 6:32 PM, Paul Martz  wrote:

>  Hi Robert and others -- I'm pretty good with OpenGL and 3D stuff, but
> when it comes to GUI interactions I'm a little week. I'm hoping someone can
> give me some pointers on what I might be doing wrong here.
>
> I've got an event callback attached to some node in my scene graph that
> looks for DRAG events. It returns true when it handles one so that the
> camera manipulator doesn't also attempt to handle the DRAG.
>
> This works great when I have a TrackballManipulator set as the Viewer's
> CameraManipulator. However, if I switch over to a custom MatrixManipulator
> that I've created, the event appears to get passed to my custom manipulator
> and it. too, processes the DRAG event -- even though my event callback is
> returning true.
>
> Like I said, the TrackballManipulator properly ignores the DRAG, so the
> problem must be in my custom matrix manipulator (and not in my event
> callback).
>
> Any idea what I might be doing wrong?
>
> Sorry this is so open-ended. I'm hoping someone else has encountered
> something similar and can reply from experience.
>
> Thanks,
>
> Paul Martz
> *Skew Matrix Software LLC*
> http://www.skew-matrix.com
> +1 303 859 9466
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>


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

[osg-users] Mixing event callbacks and camera manipulators

Hi Robert and others -- I'm pretty good with OpenGL and 3D stuff, but when
it comes to GUI interactions I'm a little week. I'm hoping someone can give
me some pointers on what I might be doing wrong here.
 
I've got an event callback attached to some node in my scene graph that
looks for DRAG events. It returns true when it handles one so that the
camera manipulator doesn't also attempt to handle the DRAG.
 
This works great when I have a TrackballManipulator set as the Viewer's
CameraManipulator. However, if I switch over to a custom MatrixManipulator
that I've created, the event appears to get passed to my custom manipulator
and it. too, processes the DRAG event -- even though my event callback is
returning true.
 
Like I said, the TrackballManipulator properly ignores the DRAG, so the
problem must be in my custom matrix manipulator (and not in my event
callback).
 
Any idea what I might be doing wrong?
 
Sorry this is so open-ended. I'm hoping someone else has encountered
something similar and can reply from experience.
 
Thanks,
 
Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com  
+1 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] VirtualProgram - making programmable pipeline less fixed


Hi Wojtek,

I am glad I have Your support. Honestly, I was counting on You ;-) I am 
not that fluent in English as I would like to be. Writing such posts 
usually take me much longer than in may native polish, I often realize 
that some ideas got lost in the midle of batlle with proper 
word/expression selection, so its always good to have some support from 
native speakers ;-).


Actually my native language is French, but I learned English at a very 
young age so I'm pretty fluent. Thanks for the compliment, I'm glad to 
help and when the functionality is something I've wanted for a while I'm 
even more glad! :-)


Look at StateHack class and reinterpret_cast expression in 
VirtualProgram apply. 


Wow, how did I miss that? :-)

StateHack overrides osg::State class to make 
getAttribureVec method accessible to Virtual program. This method is 
protected or private to osg::State.
Obiously this could be solved by mamking VirtualProgram a friend of 
osg::State but that would require changes to core OSG.


I've actually seen such a class a few times in the past few months (one 
in the osgUtil::ShaderGen class (cpp file, class called StateEx). That, 
to me, means that perhaps the osg::State API isn't as flexible as it 
could be (or perhaps it was ok in the past but now it needs to be 
evolved in new directions). Robert, any comments on this?


Obviously exposing osg::State's internals wholesale would make it easy 
for users to muck things up, but two cases of overriding it to provide 
access to some of its private/protected methods/data tells me that it 
might be nice to think about a cleaner way to provide this access? In 
both cases, the methods are just getters so perhaps they could be safely 
added to the API (or in a slightly modified mode)?


Hoping to see this move forward,

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] constructing geometry using position, normal and uv coord arrays

Hi,

okay, now i think i understand you. first step: construct the roof in 
conjunction with a normalarray that defines normals for as much as complete 
faces as possible. for the remaining ones, construct further primitives, which 
overlap the faces where the right normals weren't defined till yet.

[Image: http://www.spatiality.at/osg/roof2.jpg ]

was this the way you meant?

Cheers,
Christian

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=11828#11828





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

[osg-users] autotransform and fit

2009-05-11 Thread Gianluca Natale

Hi All,
I have a scene graph with an autotransform in it (I want the size

of an arrow be preserved from any change that might happen on window size).

So, to fit my model in that window, I would need to get the whole bounding
sphere.

Is there a visitor that does what I need, without redrawing the model (I saw
that the
cull visitor does it, but I don't want to repaint anything)?
Or do I have to write it on my own?

 

Thanks,

Gianluca

 

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

Re: [osg-users] Development of Qt support as part of osgViewer

2009-05-11 Thread Martin Beckett

Probably not the right thread - but I get continual recursive repaint with  
QOSGWidget on Qt4.5 when built with the default raster backend.

This is on Windows XP on both a Nvidia GeForce5200 (laptop) and GeForce8500 
(desktop) it runs perfectly on linux (ubuntu 8.10 and 9.04) on both.

With Qt4.4 it gave a warning about recursive repaint but worked.
With Qt4.5 and the OpenGL backend it works but all the Qt gui elements (outside 
the OSGwidget) are also redrawn at 60fps making the app slow.

I have an ATI board on order to test that and I should be able to test Win7 
this week.

Cheers,
Martin

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=11824#11824





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

Re: [osg-users] VirtualProgram - making programmable pipeline less fixed

2009-05-11 Thread Wojciech Lewandowski


Thanks J-S,

I am glad I have Your support. Honestly, I was counting on You ;-) I am not 
that fluent in English as I would like to be. Writing such posts usually 
take me much longer than in may native polish, I often realize that some 
ideas got lost in the midle of batlle with proper word/expression selection, 
so its always good to have some support from native speakers ;-).


Look at StateHack class and reinterpret_cast expression in 
VirtualProgram apply. StateHack overrides osg::State class to make 
getAttribureVec method accessible to Virtual program. This method is 
protected or private to osg::State.
Obiously this could be solved by mamking VirtualProgram a friend of 
osg::State but that would require changes to core OSG.


Cheers,
Wojtek Lewandowski



- Original Message - 
From: "Jean-Sébastien Guay" 

To: "OpenSceneGraph Users" 
Sent: Monday, May 11, 2009 5:19 PM
Subject: Re: [osg-users] VirtualProgram - making programmable pipeline less 
fixed




Hello Wojtek,

The code is simple and its basically one class named VirtualProgram. Its 
derived from osg::Program. It does what its name implies - virtualizes 
program and shaders in osg::Program similarly to C++ method overloading.


Wow, very nice! This indeed fills in one rather large gap that exists in 
shader usage in OSG, which is to make using and managing shader fragments 
easier in order to reduce the number of necessary permutations of shaders 
we need to use to support many hardware and effect combinations. And it's 
done in an elegant way. Good work!


I am not sending this as submission but more as some material for 
discussion. I would love to have similar functionality in OSG but I am 
aware that this approach slightly changes filosophy of OSG state 
attribute handling. Obviously I don't have ideal understanding of OSG 
intrinsics and I might not carefully realized all implications of this 
code imlementation. I suspect that proper implementing such feature may 
require some redesign of OSG. But I hope that this code may be used as 
foundation for such development.


I'll let Robert and others discuss the low-level implications, but to me 
this looks like a great step in the right direction.


To implement VirtualProgram I had to do small hack to make state 
attribute stack available to VirtualProgram.


I'm not sure I spotted any such hack in the code you sent, what is it?

Thanks a lot and again, good work!

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org 


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

Re: [osg-users] Rendering a series of nodes in precise order...

2009-05-11 Thread Mathias Fröhlich


Hi Robert,

On Monday 11 May 2009, Robert Osfield wrote:
> Wow I haven't ever thought of SceneGraphOrderRenderBin before.  I have
> just done a quick review of RenderBin and CullVisitor and while it
> won't be trivial to implement (it requires mods to
> CullVsitor/StateGraph/RenderBin and StateSet) it should be too
> difficult to implement, and it would certainly make certain types of
> techniques far simpler to create and fast at runtime too.
:)

> Leave this with me, once I completed some other work I'll have a look
> at the implementation.
Would be great to have!

Greetings

Mathias

-- 
Dr. Mathias Fröhlich, science + computing ag, Software Solutions
Hagellocher Weg 71-75, D-72070 Tuebingen, Germany
Phone: +49 7071 9457-268, Fax: +49 7071 9457-511
-- 
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Dr. Roland Niemeier, 
Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Michel Lepert
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196 


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

Re: [osg-users] Geodes VS Shaders

2009-05-11 Thread Maxime BOUCHER


robertosfield wrote:
> HI Maxime,
> 
> The best way to implement projective texture in the OSG is to use a
> TexGenNode that positions the texture coordinate generation in space.
> The osgspotlight example shows this in action.  There isn't any need
> to have lots of separate TexGen objects in your scene, a single one
> attached to a single TexGenNode is all that you require, so it really
> isn't an issue of Geodes vs Shaders, projective texturing in the OSG
> is completely orthogonal, you can use it with or without shaders.
> 
> Robert.
> 
> On Mon, May 11, 2009 at 3:27 PM, Maxime BOUCHER <> wrote:
> _
> osg-users mailing list
> 
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> 
>  --
> Post generated by Mail2Forum

Thanks,

 I totally agree when there's only one projector.

But, if I have, let's say, P projectors and I want to apply textures as a blend 
from a max of N projectors while moving in the scene.
Then, imagine we have M visible primitives from all cameras.
The number of possible TexGenNodes will be superior to (please excuse me if 
it's confuse, I don't really know how to say it in proper english):

binomial coefficient (P,N) * M

Do you agree?

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=11823#11823





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

Re: [osg-users] VirtualProgram - making programmable pipeline less fixed


Hello Wojtek,

The code is simple and its basically one class named VirtualProgram. Its 
derived from osg::Program. It does what its name implies - virtualizes 
program and shaders in osg::Program similarly to C++ method overloading.


Wow, very nice! This indeed fills in one rather large gap that exists in 
shader usage in OSG, which is to make using and managing shader 
fragments easier in order to reduce the number of necessary permutations 
of shaders we need to use to support many hardware and effect 
combinations. And it's done in an elegant way. Good work!


I am not sending this as submission but more as some material for 
discussion. I would love to have similar functionality in OSG but I am 
aware that this approach slightly changes filosophy of OSG state 
attribute handling. Obviously I don't have ideal understanding of OSG 
intrinsics and I might not carefully realized all implications of this 
code imlementation. I suspect that proper implementing such feature 
may require some redesign of OSG. But I hope that this code may be used 
as foundation for such development.


I'll let Robert and others discuss the low-level implications, but to me 
this looks like a great step in the right direction.


To implement VirtualProgram I had to do small hack to make state 
attribute stack available to VirtualProgram. 


I'm not sure I spotted any such hack in the code you sent, what is it?

Thanks a lot and again, good work!

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Web 3D opensource solution by Google ?

Hi Robert,

Le lundi 11 mai 2009 à 15:41 +0100, Robert Osfield a écrit :
> Hi Pierre,
> 
> Thanks for the links.  Just had a quick browse, it's amusing to find
> some OpenSceneGraph terminology turn up in their technology
> overview... StateSet, RenderGraph anyone, coincidence or inspiration
> :-)

OSG is now a world wide reference ;-)

> 
> Lightweight javascript scene graph will have some value for browsers.
> It's unlikely to scale well to complex graphics apps and data sizes.
> When Google announced this effort it did make think about whether a
> JavaScript wrapper for the OSG might just be an decent alternate
> solution for those who need real power and scalability.
> 
What I've seen, with OSG & Firefox is really promising...

> Another thought I've had is for the future of Present3D to migrate to
> be script driven, with the scripting sitting upon a high level
> abstraction of the various assets you have in the scene.  One could
> possible select JavaScript ontop of this high level abstraction,
> although personally I'm inclined towards Lua for it's ease of
> integration.  In the context of browsers JavaScript is king though...
> 
> Robert.

Look promising too...

Pierre.

> 
> 
> On Mon, May 11, 2009 at 3:01 PM, Pierre Bourdin (gmail)
>  wrote:
> > Hi all,
> >
> > have you seen this project ?
> > http://code.google.com/intl/fr/apis/o3d/
> >
> > http://code.google.com/intl/fr/apis/o3d/docs/techoverview.html
> >
> > Here's an interview about it...
> > http://www.3d-test.com/interviews/google_O3D_1.htm
> >
> > What's your opinion about this project ?
> > Pierre.
> > 
> > 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
> >
> >

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] Rendering a series of nodes in precise order...

HI Mathias,

Wow I haven't ever thought of SceneGraphOrderRenderBin before.  I have
just done a quick review of RenderBin and CullVisitor and while it
won't be trivial to implement (it requires mods to
CullVsitor/StateGraph/RenderBin and StateSet) it should be too
difficult to implement, and it would certainly make certain types of
techniques far simpler to create and fast at runtime too.

Leave this with me, once I completed some other work I'll have a look
at the implementation.

Robert.

2009/5/11 Mathias Fröhlich :
>
> Hi,
>
> On Monday 11 May 2009, Robert Osfield wrote:
>> > However, using setRenderBinDetails seems problematic in my admittedly
>> > quirky case, because I'm going to need two new render bins for each
>> > object I render with this technique.  I need to make sure the two steps
>> > happen one after the other without anything else being drawn in between.
>> >
>> > The more I talk about it the more it sounds like I just need to write a
>> > custom drawable...  Any thoughts on that approach?
>>
>> The OSG will just create a single rendering bin for each bin number
>> you use, RenderBinDetails just selects between them so there should be
>> no need for every object you render having it's own bin.
> Well, as far as I understand, and as far as I have my own applications for
> such kind of scenes. You will need an own render bin number for each object
> if every object just depends on the previous object to be rendered before.
> Else the StateSet sorting might reorder the drawables - true?
>
> Anyway, Robert, I believe it would help to have a 'SceneGraphOrderSorted'
> renderbin where the sorting order of the of the child nodes is just taken.
> Can we have such a beast?
>
>> Using a custom drawable would very rarely be required for this type of
>> work.
> Well, this might be an option in this case also.
> I have such a problem too. I have a huge amount of small objects that require
> to be drawn in a particular order. Putting them into an own renderbin
> introduces a noticable runtime overhead compared to the defaullt renderbin
> execution time.
> So if there is no way for such a scenegraph ordered renderbin, a custom
> drawable might be something to at least think about.
>
> Any chance for such a RenderBin where the scenegraph order is preserved?
>
> Greetings
>
> Mathias
>
> --
> Dr. Mathias Fröhlich, science + computing ag, Software Solutions
> Hagellocher Weg 71-75, D-72070 Tuebingen, Germany
> Phone: +49 7071 9457-268, Fax: +49 7071 9457-511
> --
> Vorstand/Board of Management:
> Dr. Bernd Finkbeiner, Dr. Roland Niemeier,
> Dr. Arno Steitz, Dr. Ingrid Zech
> Vorsitzender des Aufsichtsrats/
> Chairman of the Supervisory Board:
> Michel Lepert
> Sitz/Registered Office: Tuebingen
> Registergericht/Registration Court: Stuttgart
> Registernummer/Commercial Register No.: HRB 382196
>
>
> ___
> 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] [3rdparty] looking at osgOcean; some provocative ideas.

2009-05-11 Thread Judd Tracy

Here is an interesting site on grass and tree rendering. Thought some of you
might find it interesting.
http://www.kevinboulanger.net/index.html

On Mon, May 11, 2009 at 9:26 AM, Jean-Sébastien Guay <
jean-sebastien.g...@cm-labs.com> wrote:

> Hi Art,
>
> Very nice! The presentation is great too, have you ever been part of the
> demoscene before? Those demos are in similar style...
> http://en.wikipedia.org/wiki/Demoscene
>
>  1. http://www.tevs.eu/project_siggraph07b.html
>> Demo was created with osg 1.2 (very first release of osgPPU)
>>
>> sorry, instead of the first one, you take a look better here:
>> http://www.tevs.eu/project_r4o.html
>>
>> Is just a little bit different version with more nice renderings ;)
>>
>
> I read your paper when it came out and saw screenshots, but seeing the
> thing in action is even better.
>
> (minor nitpicking) that second video's aspect ratio is wrong... The balls
> are squished (longer vertically than horizontally).
>
>  2. http://www.tevs.eu/project_i3d08.html
>> OSG 2.2 (osgPPU v0.2)
>>
>> 3. http://www.tevs.eu/project_sigasia08.html (starts around 03:15)
>> OSG 2.4 (osgPPU v0.3)
>>
>
> Also impressive!
>
> I agree that we should make a page on the wiki for "eye candy" demos, and
> advanced rendering techniques / technology demos. These should be
> publicized, and the links to them should be prominent on the OSG main page.
> Additionally, is there any chance you could release these demos in
> executable form, or even source code? IMHO, a video is nice, but running it
> on my own machine and studying the code is so much better.
>
> Good work, let's hope we can make other good demos like those!
>
> J-S
> --
> __
> Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
>   http://www.cm-labs.com/
>http://whitestar02.webhop.org/
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Geodes VS Shaders

HI Maxime,

The best way to implement projective texture in the OSG is to use a
TexGenNode that positions the texture coordinate generation in space.
The osgspotlight example shows this in action.  There isn't any need
to have lots of separate TexGen objects in your scene, a single one
attached to a single TexGenNode is all that you require, so it really
isn't an issue of Geodes vs Shaders, projective texturing in the OSG
is completely orthogonal, you can use it with or without shaders.

Robert.

On Mon, May 11, 2009 at 3:27 PM, Maxime BOUCHER  wrote:
> Hi,
>
>  It's me again.
> In order to implement a nice Projective Texture Mapping, I want to project on 
> all visible primitives, and only it.
>  Maybe I'm wrong, and if I am, please tell me, but I projective-texture-map 
> using osg::TexGen that I only can apply on Groups or Geodes (well, anything 
> StateSet-able) so not on primitives.
>  Thus I think of extracting each visible primitive and putting it in a new 
> Geode in order to only texture them.
>  Moreover, I'd like to have several projectors, then having all visible 
> primitives extracted will make the managing of multi-texturing much more 
> easier.
>  This way, I may add a significant number of Geodes to my scene, this may be 
> costful to render.
>
>  The other way is to define shaders for these visible primitives.
>
>  In your opinion, which of these two ways is the more efficient?
>
> Thank you!
>
> Cheers,
> Maxime
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=11809#11809
>
>
>
>
>
> ___
> 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] Development of Qt support as part of osgViewer

Hi Martin,

On Mon, May 11, 2009 at 3:27 PM, Martin Beckett  wrote:
> I'm still relying on adapterwidget because QOSGWidget doesn't work on Windows 
> unless you build Qt with OpenGL rendering (which is very slow).

This sounds a bit odd.  QOSGWidget use GraphicsWindow inheritance in
which osgViewer provides the actual OpenGL implementation, so Qt
shouldn't need to nothing at all about OpenGL.  So it doesn't sound
like a configuration issue somewhere along the line.

> One feature that would be nice is support for Qt widgets being drawn within 
> OSG 
> (http://labs.trolltech.com/blogs/2008/06/27/accelerate-your-widgets-with-opengl/)

This is something for further down the line, but would likely be a
good step towards embedding a WebKit browser into the OSG.

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

Re: [osg-users] osgWidget's Window's _index problem

2009-05-11 Thread Fajran Iman Rusadi

On Mon, May 11, 2009 at 13:12, Fajran Iman Rusadi  wrote:
>
> After I investigated further, seems WindowManager tries to assign an
> _index to Window. This index should corresponds with the index in the
> Group's _children. The problem arises when I delete any Window but the
> last one, because the Window's _index is disrupted since I found no
> _index rearrangement (cmiiw).
>

I made a small patch for this problem. Hopefully it addresses the
problem correctly. At least in my case, the problem is gone.


-- 
Iang-
http://fajran.web.id y!m: fajran
diff --git a/src/osgWidget/WindowManager.cpp b/src/osgWidget/WindowManager.cpp
index 2fb9f4d..11df694 100644
--- a/src/osgWidget/WindowManager.cpp
+++ b/src/osgWidget/WindowManager.cpp
@@ -232,6 +232,11 @@ void WindowManager::childInserted(unsigned int i) {
 
 if(!window) return;
 
+// Update Window's index
+for(Iterator w = begin(); w != end(); w++) {
+if(w->get()->_index >= i) w->get()->_index++;
+}
+
 _objects.push_back(window);
 
 window->_index = i;
@@ -261,6 +266,12 @@ void WindowManager::childRemoved(unsigned int start, unsigned int numChildren) {
 window->unmanaged(this);
 }
 }
+
+// Update Window's index
+for(Iterator w = begin(); w != end(); w++) {
+if(w->get()->_index >= start) w->get()->_index -= numChildren;
+}
+
 }
 
 // This method performs intersection testing at the given XY coords, and returns true if
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] bugfix osgDB cross-DLL allocation problem

Hi JS,

Thanks for the testing.

The fact that Change #1 does change a function to become a inline
implementation does change the ABI, not a problem from 2.9.x but does
rule out being part of OSG-2.8.1 as so far there has been not ABI
breaks despite all the bug fixes.

Feedback from others please :-)

Robert.

On Mon, May 11, 2009 at 3:19 PM, Jean-Sébastien Guay
 wrote:
> Hi Robert, Hartmut,
>
>> The changes seem sound, I'd like to see if there are any side effects
>> though, so I'll test the changes in a fresh build linked to a small
>> application tomorrow. I'll let you know what I find out.
>
> Change #1 (refer to the original e-mail from Hartmut) is ok, it's a small
> function that will now be inlined instead of in the DLL, preventing the
> fopen call being made in a different DLL context than the fclose call. The
> penalty for such a small function is small, so I don't see a problem.
> Perhaps a comment could be added explaining why this function is inline
> while all others are extern...
>
> Change #2 is interesting. Trying to be diligent (since /a priori/ I didn't
> know anything about these settings), I looked up the defines Hartmut added,
> and found this:
>
> http://blogs.msdn.com/vcblog/archive/2008/05/15/vc-runtime-binding.aspx
>
> It seems that the behavior for resolving the C++ runtime version
> dependencies changed between VC2005 and VC2008. The defines Hartmut added
> just bring VC2008's settings back to VC2005 defaults. So in theory, it
> should have no effect for VC2005 either since the default was already set
> that way.
>
> I wonder what the implication on user applications will be, considering the
> information on that page. But I guess if the developer ships the VC runtime
> DLLs (that he compiled the app with) with his application, or the user has
> that version or newer of the VC runtime installed, it should be ok. That's
> what happens for VC2005 after all.
>
> It's true that perhaps those defines should be optional (I would make them
> default to on, as it will probably not change anything for most users but
> those who will have the same problems as Hartmut had will want to turn it on
> - people who want to turn it on will be few and will know the reasons why).
> Perhaps that should be added to the patch before final submission.
>
> I've compiled OSG and an application I was working on with these changes,
> and didn't get any adverse change in behavior. Of course, I'm still using
> VC2005. Perhaps we could wait for someone else using VC2008 to test as well,
> but as I said, I think the changes are OK even in that context.
>
> Hope this helps,
>
> J-S
> --
> __
> Jean-Sebastien Guay    jean-sebastien.g...@cm-labs.com
>                               http://www.cm-labs.com/
>                        http://whitestar02.webhop.org/
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] constructing geometry using position, normal and uv coord arrays

Hi J.P.

Thank you for taking the time in helping me. i have two questions regarding 
your recommendations.


> I think most people would nowadays advise to just
> specify normals per vertex and not try to use normals per face (slow
> path).


- does this mean: if a normals-indexarray hasn't the same amount of entries 
like the vertex-indexarray (like in the case i'm planning to do) the rendering 
will be done with glBegin/glEnd calls instead of the faster alternatives 
(displaylists, indexed arrays, etc.)

- i have never heard the phrase "slow path", but this does not sounds good ;-) 
does this mean the consequences mentioned above?


> 
> E.g.
> primitive 1 = vertex_array_shared + normal_array1 + drawelements
> primitive 2 = vertex_array_shared + normal_array2 + drawelements
> 


i' m a opengl/osg beginner, so i hope i got you right
- you mean that instead of defining one primitive (triangle_strip, 
drawElements) that defines a roof-geometry, i define several primitives 
(triangle_strip, drawElements) with same vertices and indices, but different 
assigned normalarrays) for the same roof-geometry. (there would still be a need 
of normals array 3, for the normals of vertex 4 and 5, pointing north)
this will result in two exact overlying, seperate triangle_strips so no 
difference will be noticed, 
[Image: http://www.spatiality.at/osg/roof.jpg ] 

but wouldn't their faces z-fighting?

Best regards,
christian sam

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=11814#11814





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

Re: [osg-users] Web 3D opensource solution by Google ?

Hi Pierre,

Thanks for the links.  Just had a quick browse, it's amusing to find
some OpenSceneGraph terminology turn up in their technology
overview... StateSet, RenderGraph anyone, coincidence or inspiration
:-)

Lightweight javascript scene graph will have some value for browsers.
It's unlikely to scale well to complex graphics apps and data sizes.
When Google announced this effort it did make think about whether a
JavaScript wrapper for the OSG might just be an decent alternate
solution for those who need real power and scalability.

Another thought I've had is for the future of Present3D to migrate to
be script driven, with the scripting sitting upon a high level
abstraction of the various assets you have in the scene.  One could
possible select JavaScript ontop of this high level abstraction,
although personally I'm inclined towards Lua for it's ease of
integration.  In the context of browsers JavaScript is king though...

Robert.

On Mon, May 11, 2009 at 3:01 PM, Pierre Bourdin (gmail)
 wrote:
> Hi all,
>
> have you seen this project ?
> http://code.google.com/intl/fr/apis/o3d/
>
> http://code.google.com/intl/fr/apis/o3d/docs/techoverview.html
>
> Here's an interview about it...
> http://www.3d-test.com/interviews/google_O3D_1.htm
>
> What's your opinion about this project ?
> Pierre.
> 
> 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
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Rendering a series of nodes in precise order...

2009-05-11 Thread Mathias Fröhlich


Hi,

On Monday 11 May 2009, Robert Osfield wrote:
> > However, using setRenderBinDetails seems problematic in my admittedly
> > quirky case, because I'm going to need two new render bins for each
> > object I render with this technique.  I need to make sure the two steps
> > happen one after the other without anything else being drawn in between.
> >
> > The more I talk about it the more it sounds like I just need to write a
> > custom drawable...  Any thoughts on that approach?
>
> The OSG will just create a single rendering bin for each bin number
> you use, RenderBinDetails just selects between them so there should be
> no need for every object you render having it's own bin.
Well, as far as I understand, and as far as I have my own applications for 
such kind of scenes. You will need an own render bin number for each object 
if every object just depends on the previous object to be rendered before. 
Else the StateSet sorting might reorder the drawables - true?

Anyway, Robert, I believe it would help to have a 'SceneGraphOrderSorted' 
renderbin where the sorting order of the of the child nodes is just taken.
Can we have such a beast?

> Using a custom drawable would very rarely be required for this type of
> work.
Well, this might be an option in this case also.
I have such a problem too. I have a huge amount of small objects that require 
to be drawn in a particular order. Putting them into an own renderbin 
introduces a noticable runtime overhead compared to the defaullt renderbin 
execution time.
So if there is no way for such a scenegraph ordered renderbin, a custom 
drawable might be something to at least think about.

Any chance for such a RenderBin where the scenegraph order is preserved?

Greetings

Mathias

-- 
Dr. Mathias Fröhlich, science + computing ag, Software Solutions
Hagellocher Weg 71-75, D-72070 Tuebingen, Germany
Phone: +49 7071 9457-268, Fax: +49 7071 9457-511
-- 
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Dr. Roland Niemeier, 
Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Michel Lepert
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196 


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

[osg-users] Geodes VS Shaders

2009-05-11 Thread Maxime BOUCHER

Hi,

  It's me again.
In order to implement a nice Projective Texture Mapping, I want to project on 
all visible primitives, and only it.
 Maybe I'm wrong, and if I am, please tell me, but I projective-texture-map 
using osg::TexGen that I only can apply on Groups or Geodes (well, anything 
StateSet-able) so not on primitives.
 Thus I think of extracting each visible primitive and putting it in a new 
Geode in order to only texture them.
 Moreover, I'd like to have several projectors, then having all visible 
primitives extracted will make the managing of multi-texturing much more easier.
 This way, I may add a significant number of Geodes to my scene, this may be 
costful to render.

 The other way is to define shaders for these visible primitives.

 In your opinion, which of these two ways is the more efficient?

Thank you!

Cheers,
Maxime

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=11809#11809





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

Re: [osg-users] Development of Qt support as part of osgViewer

2009-05-11 Thread Martin Beckett

I'm still relying on adapterwidget because QOSGWidget doesn't work on Windows 
unless you build Qt with OpenGL rendering (which is very slow).

One feature that would be nice is support for Qt widgets being drawn within OSG 
(http://labs.trolltech.com/blogs/2008/06/27/accelerate-your-widgets-with-opengl/)
 

I would be happy to help if I can, I'm not a great OSG expert (yet)
Martin

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=11808#11808





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

Re: [osg-users] Rendering a series of nodes in precise order...

On Mon, May 11, 2009 at 3:03 PM, Nathan Monteleone
 wrote:
>
> robertosfield wrote:
>>
>> ---snip---
>>
>> In your case it's like StateSet::setRenderBinDetails(..) is all that
>> you'll need.  See the osgreflect example.
>>
>> Robert.
>
>
> Thanks for the overview of Camera/RenderBin/RenderStage. I've always had a 
> hard time getting a solid picture of those in my head.
>
> However, using setRenderBinDetails seems problematic in my admittedly quirky 
> case, because I'm going to need two new render bins for each object I render 
> with this technique.  I need to make sure the two steps happen one after the 
> other without anything else being drawn in between.
>
> The more I talk about it the more it sounds like I just need to write a 
> custom drawable...  Any thoughts on that approach?

The OSG will just create a single rendering bin for each bin number
you use, RenderBinDetails just selects between them so there should be
no need for every object you render having it's own bin.

Using a custom drawable would very rarely be required for this type of work.

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

Re: [osg-users] bugfix osgDB cross-DLL allocation problem


Hi Robert, Hartmut,

The changes seem sound, I'd like to see if there 
are any side effects though, so I'll test the changes in a fresh build 
linked to a small application tomorrow. I'll let you know what I find out.


Change #1 (refer to the original e-mail from Hartmut) is ok, it's a 
small function that will now be inlined instead of in the DLL, 
preventing the fopen call being made in a different DLL context than the 
fclose call. The penalty for such a small function is small, so I don't 
see a problem. Perhaps a comment could be added explaining why this 
function is inline while all others are extern...


Change #2 is interesting. Trying to be diligent (since /a priori/ I 
didn't know anything about these settings), I looked up the defines 
Hartmut added, and found this:


http://blogs.msdn.com/vcblog/archive/2008/05/15/vc-runtime-binding.aspx

It seems that the behavior for resolving the C++ runtime version 
dependencies changed between VC2005 and VC2008. The defines Hartmut 
added just bring VC2008's settings back to VC2005 defaults. So in 
theory, it should have no effect for VC2005 either since the default was 
already set that way.


I wonder what the implication on user applications will be, considering 
the information on that page. But I guess if the developer ships the VC 
runtime DLLs (that he compiled the app with) with his application, or 
the user has that version or newer of the VC runtime installed, it 
should be ok. That's what happens for VC2005 after all.


It's true that perhaps those defines should be optional (I would make 
them default to on, as it will probably not change anything for most 
users but those who will have the same problems as Hartmut had will want 
to turn it on - people who want to turn it on will be few and will know 
the reasons why). Perhaps that should be added to the patch before final 
submission.


I've compiled OSG and an application I was working on with these 
changes, and didn't get any adverse change in behavior. Of course, I'm 
still using VC2005. Perhaps we could wait for someone else using VC2008 
to test as well, but as I said, I think the changes are OK even in that 
context.


Hope this helps,

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Rendering a series of nodes in precise order...

2009-05-11 Thread Nathan Monteleone

robertosfield wrote:
> 
> ---snip---
> 
> In your case it's like StateSet::setRenderBinDetails(..) is all that
> you'll need.  See the osgreflect example.
> 
> Robert.

Thanks for the overview of Camera/RenderBin/RenderStage. I've always had a hard 
time getting a solid picture of those in my head.

However, using setRenderBinDetails seems problematic in my admittedly quirky 
case, because I'm going to need two new render bins for each object I render 
with this technique.  I need to make sure the two steps happen one after the 
other without anything else being drawn in between.

The more I talk about it the more it sounds like I just need to write a custom 
drawable...  Any thoughts on that approach?

Thanks.

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=11806#11806

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

[osg-users] Web 3D opensource solution by Google ?

Hi all,

have you seen this project ?
http://code.google.com/intl/fr/apis/o3d/

http://code.google.com/intl/fr/apis/o3d/docs/techoverview.html

Here's an interview about it...
http://www.3d-test.com/interviews/google_O3D_1.htm

What's your opinion about this project ?
Pierre.

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

[osg-users] Development of Qt support as part of osgViewer

Hi All,

There has been lots of support questions relating to Qt integration
with the OSG over the past year, and especially in the last few
months.  This a good in terms of see a cross platform GUI toolkit
becoming more widely spread, bad in terms of the difficulties that
users still have.  Part of the difficulties is down to Qt being a
little bit awkward to integrate with making it not entirely straight
forward, and while we have an example, it's just a guide so lots of
users are having to go re-invent the wheel each time.  So it'd be good
to try and address this issue by providing a better Qt/OSG widget for
users to adopt directly.

One of the design facets of osgViewer library is that it's designed to
work with multiple windowing toolkits, with four models of integration
possible:

1) GraphicsWindowEmbedded - provides very basic single threaded,
single context window integration suitable for use with simple apps
that use SDL/GLUT.

 2) GraphicsWindow core osgViewer implementations (i.e.
GraphisWindowWin32/X11/Carbon/Cocoa) - full OpenGL + multi-context,
threadeding and pbuffer capabilities exposed.  You'll find these
implementation interfaces in include/osgViewer/api/Win32, X11, Carbon
and Cocoa.

 3) GraphicsWindow subclass (i.e GraphicsWindowWx) - 3rd party
implementation of a GraphicsWindow, potential for full capabilities if
all parts of GraphicsWindow are correctly implemented.  For pbuffer
support one will have to add PixelBuffer implementation as well.

4)  GraphicsWindow window inheritance - windowing toolkit provides the
window, while GraphicsWindowWin32/X11/Carbon/Cocoa provide the actual
OpenGL context implementation.


Now Item 1) is really just for very simple apps, and is often adopted
by end users because it's really easy to use, but almost always starts
limiting you as your project goes on.  I wouldn't recommend 1 for
anything by GLUT/SDL style apps.

Items 2 is great for sim and games that don't need any GUI.  You can
get the full capabilities of the OSG with very little effort on your
part.   If you want a traditional 2D GUI though then it won't help
you.

Item 3 is possible, but rarely do 3rd party window toolkits do OpenGL
really well, often they won't expose the full capabilities of OpenGL
or support pbuffers.  It also often requires the most work in
implementation.

Item 4 is possible, but a little bit awkward, but potentially can give
users the best of both worlds - full OpenGL/OSG capabilities and the
2D GUI.

--

So where does that leave the Qt side?  We'll my preference would be to
work together to get a GraphicsWindowQt and/or a window inheritance
implemented in a full and flexible way that users could just reuse the
implementation provided in a new include/osgViewer/api/Qt collection
of headers.  I would suggest the implementation should be done
entirely in the headers to avoid the need for linking the osgViewer
library itself to Qt.

Now I've tinkered with Qt, but I'm not Qt expert, to get a really good
implementation we'll need members of the community to pitch in with
helping refine the implementation.  Anybody feel that they could help
spearhead this development?

The first step might simple be to clean up the current Qt example, or
start a new example where the new classes could be refined and when
ready moved into their own directory in include/osgViewer/api/Qt.

Thoughts?  Volunteers?

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

Re: [osg-users] [3rdparty] looking at osgOcean; some provocative ideas.


Hi Art,

Very nice! The presentation is great too, have you ever been part of the 
demoscene before? Those demos are in similar style...

http://en.wikipedia.org/wiki/Demoscene


1. http://www.tevs.eu/project_siggraph07b.html
Demo was created with osg 1.2 (very first release of osgPPU)

sorry, instead of the first one, you take a look better here:
http://www.tevs.eu/project_r4o.html

Is just a little bit different version with more nice renderings ;)


I read your paper when it came out and saw screenshots, but seeing the 
thing in action is even better.


(minor nitpicking) that second video's aspect ratio is wrong... The 
balls are squished (longer vertically than horizontally).



2. http://www.tevs.eu/project_i3d08.html
OSG 2.2 (osgPPU v0.2)

3. http://www.tevs.eu/project_sigasia08.html (starts around 03:15)
OSG 2.4 (osgPPU v0.3)


Also impressive!

I agree that we should make a page on the wiki for "eye candy" demos, 
and advanced rendering techniques / technology demos. These should be 
publicized, and the links to them should be prominent on the OSG main 
page. Additionally, is there any chance you could release these demos in 
executable form, or even source code? IMHO, a video is nice, but running 
it on my own machine and studying the code is so much better.


Good work, let's hope we can make other good demos like those!

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OSG and QT example

2009-05-11 Thread Simon Loic

Hi David,

Just to answer your point, I would be personally interested in such an
integration.
So far I'm using the AdapterWidget of the ViewerQt example but I'm not fully
satisfied. Indeed it suffers a couple of problems as :
- the lack of multiple thread support
- a bad translation between QT keyboard events and OSG one.

I had a quick look to the code you pointed and both seems to be handled in
it (tell me if I'm wrong).

As for the QOSGWidget, I tried to embed it in a QtDesigner based GUI and I
must confess I couldn't make it. May be I dind't try hard enough. Yet if
someone could provide such an example (ie without the trick to avoid the moc
steps and so on), that would be hell of a tip.

Thanks



On Thu, May 7, 2009 at 8:43 PM, David Guthrie wrote:

> Hi,
>
> We wrote a QT/OSG integration that implements the windowing system
> interface for qt.
>
> It's in the delta3d dtQt library.  It seems like the sort of thing that
> should be part of OSG, we just haven't submitted it.  If there is interest,
> we can look at what the code should look like and where it should go...
>
> Look at
>
> https://delta3d.svn.sourceforge.net/svnroot/delta3d/trunk/delta3d/inc/dtQt
> https://delta3d.svn.sourceforge.net/svnroot/delta3d/trunk/delta3d/src/dtQt
>
> at the files
>
> osgadapterwidget.h
> osggraphicswindowqt.h
> qtguiwindowsystemwrapper.h
>
> osgadapterwidget.cpp
> osggraphicswindowqt.cpp
> qtguiwindowsystemwrapper.cpp
>
> Thank you!
> David Guthrie
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=11639#11639
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



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

Re: [osg-users] constructing geometry using position, normal and uv coord arrays

2009-05-11 Thread J.P. Delport

Hi Chiristian,

Christian Sam wrote:

Hi,

thank you for the reply. to give you some more information of my
situation: i want to visualize certain roof types. i generate the
geometry information (vertices, tex-coords, normals) programmatically
in my application. i'm using triangle_strips with drawElements
indices to construct my roof types - one reason for this is, i have
to insert some "index-swaps" to get certain roofforms done with only
one triangle_strip primitive per roof.

the next step would be to calculate the normal vectors. my first (and
most confortable) idea was to use the osg::smoothingVisitor. the
problem arrived with that was, i was getting averaged normals, which
didn't represent roofs very well.

so i was looking for another way where i could use for every planar
face of my triangle_strip its own normals to get facetted looking
roofs and posted here in this thread the question how to do this.

now, after some further research, i'm currently thinking, due the
circumstance of shared vertices in a triangle_strip, it is impossible
to assign multiple normals to one vertex. i' ve read of a
"workaround" where to use one normal for every triangle_strip's
planar face in addition and using FLATSHADING. i know this is not the
same like the above mentioned in SMOOTHSHADING, but i think it would
certainly better than the average normals.

so what do you think of that approach, or maybe you might have some
other ideas?

Sounds like you need fine grained control over the normals anyway, so it
would be best if you just calculate them programmatically together with
the other data. I think most people would nowadays advise to just
specify normals per vertex and not try to use normals per face (slow
path). As for multiple normals per vertex, you would have to create
multiple normal arrays, but you can reuse the same vertex array.

E.g.

primitive 1 = vertex_array_shared + normal_array1 + drawelements
primitive 2 = vertex_array_shared + normal_array2 + drawelements

rgds
jp

Best Regards, Christian Sam

-- Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=11799#11799

___ 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] looking at osgOcean; some provocative ideas.

2009-05-11 Thread Sergey Kurdakov

Hi All,

if to speak of procedural trees ( mentioned in the thread ) then there
is a nice free software

http://dryad.stanford.edu/

they even claim it will soon be open source and it can be used to accompany osg.

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

Re: [osg-users] constructing geometry using position, normal and uv coord arrays

Hi,

thank you for the reply. to give you some more information of my situation: i 
want to visualize certain roof types. i generate the geometry information 
(vertices, tex-coords, normals) programmatically in my application. i'm using 
triangle_strips with drawElements indices to construct my roof types - one 
reason for this is, i have to insert some "index-swaps" to get certain 
roofforms done with only one triangle_strip primitive per roof. 

the next step would be to calculate the normal vectors. my first (and most 
confortable) idea was to use the osg::smoothingVisitor. the problem arrived 
with that was, i was getting averaged normals, which didn't represent roofs 
very well.

so i was looking for another way where i could use for every planar face of my 
triangle_strip its own normals to get facetted looking roofs and posted here in 
this thread the question how to do this.

now, after some further research, i'm currently thinking, due the circumstance 
of shared vertices in a triangle_strip, it is impossible to assign multiple 
normals to one vertex. 
i' ve read of a "workaround" where to use one normal for every triangle_strip's 
planar face in addition and using FLATSHADING. i know this is not the same like 
the above mentioned in SMOOTHSHADING, but i think it would certainly better 
than the average normals.

so what do you think of that approach, or maybe you might have some other ideas?


Best Regards,
Christian Sam

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=11799#11799





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

[osg-users] osgWidget's Window's _index problem

2009-05-11 Thread Fajran Iman Rusadi

Dear all,

I've been dealing with a problem (probably due to a bug) with
osgWidget. If I tried to remove Window(s) from WindowManager not in
the reverse order as I insert them, I'll get a segmentation fault. My
debugger says the problem is in file WindowManager.cpp line 431.

for(Iterator w = begin(); w != end(); w++) {
Window* win = w->get();

win->_zRange = zRange;

win->update();
}

The value of win is NULL there. So the next _zRange assignment will
cause an error.

After I investigated further, seems WindowManager tries to assign an
_index to Window. This index should corresponds with the index in the
Group's _children. The problem arises when I delete any Window but the
last one, because the Window's _index is disrupted since I found no
_index rearrangement (cmiiw).

I found at least two functions in WindowManager that use this _index:
childRemoved() and resizeAllWindows(). The first one gets an index
(that should be the index in Group's _children) but uses it for
comparison with the incorrect Window's _index. The second function
uses the Window's _index to call Switch's getValue() which then use it
to get a value from its _values. There are also some other functions
in Window class that use this _index value.

FYI, I'm using OpenSceneGraph 2.8.0. I've checked the latest code in
the svn repo, but no changes there since 2.8.0.

any comments?


regards,

-- 
Iang-
http://fajran.web.id y!m: fajran
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgInEurope - osg meeting/conference in Paris

2009-05-11 Thread Mathias Fröhlich


Hi,

On Monday 11 May 2009, Art Tevs wrote:
> @Mathias:
> Hmm, some time ago there was a poll about where we would like to have such
> an event. The majority of the users voted for Paris, so I do not think,
> that we would like to change to Berlin now.
Not a problem, just dumped some ideas ...

Greetings

Mathias

-- 
Dr. Mathias Fröhlich, science + computing ag, Software Solutions
Hagellocher Weg 71-75, D-72070 Tuebingen, Germany
Phone: +49 7071 9457-268, Fax: +49 7071 9457-511
-- 
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Dr. Roland Niemeier, 
Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Michel Lepert
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196 


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

Re: [osg-users] how to set osg::notify to a file

2009-05-11 Thread Simon Hammett

This works for me:

#include 
#include 

static std::ofstreamg_log("c:\\Message.log");

extern "C" int WINAPI _tWinMain(HINSTANCE /*hInstance*/, HINSTANCE
/*hPrevInstance*/, LPTSTR /*lpCmdLine*/, int nShowCmd)
{
   std::cout.rdbuf(g_log.rdbuf());
   std::cerr.rdbuf(g_log.rdbuf());
   ...
   ...
}

There's a version that outputs to the debug window in visual studio on
the osg website and in the mail achieves if that's your preference.

2009/5/11 Vincent Bourdier :
> Hi,
>
> Using the std stream, you can redirect the out stream into a file stream.
> I don't know if osg implements a thing about that, i think it don't...
>
> Regards,
>    Vincent
>
> 2009/5/11 forest 
>>
>> hi all
>>    osg::notify put notifies on the console defaultly.Can I put these
>> notifies to a file?
>>    thanks in advance.
>>    best regardes
>> forest
>> ___
>> 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

Re: [osg-users] looking at osgOcean; some provocative ideas.

Can you tell me more about that ?

Le lundi 11 mai 2009 à 09:29 +0100, Robert Osfield a écrit :

> SpeedTree integration with the OSG
> that are available commercially so one could do the forest rendering
> if you are prepared to dip into your pocket.

I'm interested in rendering vegetation...

Pierre.

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] osgInEurope - osg meeting/conference in Paris

2009-05-11 Thread Cedric Pinson

I cheked if there is an event in paris, but i did not find an event at
this period.
Serges can you confirm the date of the meeting ? i guess it will not be
the entire week ? :)

Cheers,
Cedric

On Wed, 2009-05-06 at 17:00 +0200, Mathias Fröhlich wrote:
> Hi,
> 
> On Wednesday 06 May 2009, Cedric Pinson wrote:
> > I will not be able to make a talk the first week of september, it's the
> > only week i am not in Paris, murphy's law i guess ;)
> > Another idea about this meeting could be to synchronize it with free
> > software event, then we could use the structure and organisation for an
> > osg meeting.
> 
> Is there such an event in Paris?
> If not, may be the LinuxTag in Berlin at the end of june is something to 
> consider!?
> Or little later, Fosdem at Bruxeles at the beginning of each year?
> 
> Greetings
> 
> Mathias
> 
> -- 
> Dr. Mathias Fröhlich, science + computing ag, Software Solutions
> Hagellocher Weg 71-75, D-72070 Tuebingen, Germany
> Phone: +49 7071 9457-268, Fax: +49 7071 9457-511
-- 
+33 (0) 6 63 20 03 56  Cedric Pinson mailto:morni...@plopbyte.net
http://www.plopbyte.net



signature.asc
Description: This is a digitally signed message part
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [3rdparty] looking at osgOcean; some provocative ideas.

Hi Sergey,

Sergey Kurdakov wrote:
> 
> But overall idea was to impress others ( esp newbees on a large scale
> )...
> 

But isn't that a main aim of all the demos ;) 
The demos showed actually new techniques of rendering. To understand exactly 
what the new thing of them was, one has to take a look into according papers.

> 
> it it possible to organize youtube gallery of demos on forum ?
> 

Shouldn't be a big problem. However, maybe a wiki would be a better place for 
that. Forum could then just mirror the wiki pages to show the gallery.
I take a look what nice opportunities there exists for the forum, where people 
could put in their screenshots or videos. I think on similar thing like on the 
OGRE-Webpage.

Regards
Artem ;)

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=11792#11792

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

Re: [osg-users] [3rdparty] looking at osgOcean; some provocative ideas.

2009-05-11 Thread Sergey Kurdakov

Hi Art,

thanks, I really enjoyed.

But overall idea was to impress others ( esp newbees on a large scale
) (reading for about  5 years a list I seen quite a bit ).

it it possible to organize youtube gallery of demos on forum ?

Regards
Sergey

On Mon, May 11, 2009 at 1:31 PM, Art Tevs  wrote:
> Hi Sergey,
>
> sorry, instead of the first one, you take a look better here:
> http://www.tevs.eu/project_r4o.html
>
> Is just a little bit different version with more nice renderings ;)
>
> Cheers,
> Art
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [3rdparty] looking at osgOcean; some provocative ideas.

Hi Sergey,

sorry, instead of the first one, you take a look better here:
http://www.tevs.eu/project_r4o.html

Is just a little bit different version with more nice renderings ;)

Cheers,
Art

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=11789#11789





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

Re: [osg-users] osgInEurope - osg meeting/conference in Paris

2009-05-11 Thread Serge Lages

Hi all,

Currently we are available all september, so don't hesitate to try to find
the better date for everybody.

Cheers,

On Mon, May 11, 2009 at 11:23 AM, Art Tevs  wrote:

> Hi folks,
>
> @Cedric, Serge:
>
> Cedric Pinson wrote:
> > Hi,
> > I will not be able to make a talk the first week of september, it's the
> > only week i am not in Paris, murphy's law i guess ;)
> > Another idea about this meeting could be to synchronize it with free
> > software event, then we could use the structure and organisation for an
> > osg meeting.
> >
>
>
> I think going into the second week of september wouldn't be a big problem.
> Serge what do you think?
>
> @Mathias:
> Hmm, some time ago there was a poll about where we would like to have such
> an event. The majority of the users voted for Paris, so I do not think, that
> we would like to change to Berlin now.
>
> Cheers,
> art
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=11787#11787
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



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

Re: [osg-users] [3rdparty] looking at osgOcean; some provocative ideas.

Hi Sergey,

if you like to see some nice demos created with OpenSceneGraph, then take a 
look here:

1. http://www.tevs.eu/project_siggraph07b.html
Demo was created with osg 1.2 (very first release of osgPPU)

2. http://www.tevs.eu/project_i3d08.html
OSG 2.2 (osgPPU v0.2)

3. http://www.tevs.eu/project_sigasia08.html (starts around 03:15)
OSG 2.4 (osgPPU v0.3)


regards,
Art

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=11788#11788





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

Re: [osg-users] osgInEurope - osg meeting/conference in Paris

Hi folks,

@Cedric, Serge:

Cedric Pinson wrote:
> Hi,
> I will not be able to make a talk the first week of september, it's the
> only week i am not in Paris, murphy's law i guess ;)
> Another idea about this meeting could be to synchronize it with free
> software event, then we could use the structure and organisation for an
> osg meeting.
> 

I think going into the second week of september wouldn't be a big problem. 
Serge what do you think?

@Mathias:
Hmm, some time ago there was a poll about where we would like to have such an 
event. The majority of the users voted for Paris, so I do not think, that we 
would like to change to Berlin now. 

Cheers,
art

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=11787#11787

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

Re: [osg-users] About QT example!

2009-05-11 Thread Simon Loic

Hi YangXiao,
I've seen in some previous thread that if you want to make multiple
threading schema work, you have to use the QOSGWidget instead of the
AdapterWidget. Don't ask me why as I don't know anything about it.
Hope I could help.



On Mon, May 11, 2009 at 4:05 AM, YangXiao  wrote:

> Hi everyone
>  In QTOSG example,When i modify the thread model to
> osgViewer::Viewer::DrawThreadPerContext); I get a runtime error!
>
> class ViewerQT : public osgViewer::Viewer, public AdapterWidget
> {
> public:
>  ViewerQT(QWidget * parent = 0, const char * name = 0, const QGLWidget *
> shareWidget = 0, WindowFlags f = 0):
>AdapterWidget( parent, name, shareWidget, f )
>{
> getCamera()->setViewport(new osg::Viewport(0,0,width(),height()));
> getCamera()->setProjectionMatrixAsPerspective(30.0f,
> static_cast(width())/static_cast(height()), 1.0f, 1.0f);
> getCamera()->setGraphicsContext(getGraphicsWindow());
> setThreadingModel(osgViewer::Viewer::SingleThreaded);
> //setThreadingModel(osgViewer::Viewer::DrawThreadPerContext);  //here i
> modify
>   addEventHandler(new osgGA::StateSetManipulator );
> connect(&_timer, SIGNAL(timeout()), this, SLOT(updateGL()));
> _timer.start(10);
>}
>virtual void paintGL()
>{
> frame();
>}
> protected:
>  QTimer _timer;
> };
>
> Thanks YangXiao.
>
> --
> 好玩贺卡等你发，邮箱贺卡全新上线！
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>


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

[osg-users] looking at osgOcean; some provocative ideas.

2009-05-11 Thread Sergey Kurdakov

Hi Robert

> I just read the paper.  It's a interesting and should be flexible
> approach to generating smooth roads by using coarse geometry and pixel
> shaders to compute the tex coords to give a final smooth look.  I
> wouldn't have though it'd take too much work to implement either.

in case anyone is interested there is one more paper.

http://www.j3l7h.de/talks/2005-02-01_Paving_Procedual_Roads_with_Pixel_Shaders.pdf

> The OSG has very capable multi-threaded paging which is more general
> purpose than this approach.  What is missing is would the procedural
> instancing and reuse of geometry for the trees/grasses.  If you
> implemented the later then you could use the standard PagedLOD for
> handling all the multi-threaded paging to get the scalability.

I'm long reader of osg list but my tasks are mostly in ai, physics,
planning small team work. I read it to keep my understanding of
graphics up to date .

and now I'm temporarily even in video processing industry, so when I
return to graphics world I think will do something like that


>  Intel's
> job is selling CPU's not teaching one the best way to implement
> something given the complete range of hardware available...

yes still they implemented quite intresting way to separate and sync
threads - which could be used to scale future demos based on osg ( not
just OpenScenegraph will be split between  threads, but physics, AI
logic, etc - it is important in a light that there are seems a
roadblock for Mghz for processors for a while and not only Intel will
follow a road of many processors and cores.


> With the integration of Present3D into OpenSceneGraph body it's my
> plan to start putting presentations together that show off a few more
> of the capabilities of the OSG in a more accessible way.

this is a great news.

Hope really there will be exciting demos in a near future.

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

Re: [osg-users] missing includes

2009-05-11 Thread Simon Loic

Hi,
Sorry I was not here this week-end. I indeed tried to compile osgearth
again, and apparently there is no problem. Maybe there wasn't at all as I'm
messing up between all the osg applications I built. Actually, I just built
VTP (the svn trunk version) and I can confirm this kind of problem with gcc
4.3.3.  In fact, the #include  is right in the concerned file
(TerrainSDK/vtdata/FilePath.cpp), but enclosed in a #ifdef VTUNIX directive
which seems not managed by the CMakeLists (or maybe I'm not using cmake in
the right way). I had to add the following line in the master CMakeLists.txt
to overcome this problem :
 add_definitions(-DVTUNIX)

Don't know if it's a good way though. Anyway, it is so difficult to make VTP
compile on my machine that I think I will just give up.


Thanks again for your help.

On Fri, May 8, 2009 at 4:36 PM, Jason Beverage wrote:

> Thanks Robert, that's good to hear!
>
> Jason
>
>
> On Fri, May 8, 2009 at 9:33 AM, Robert Osfield 
> wrote:
>
>> Hi Jason and Colin,
>>
>> I've just checked out the latest osgEarth and it compiles fine for my
>> under Kubuntu 9.04 (Jaunty) with g++ 4.3.3.
>>
>> Robert.
>>
>> On Fri, May 8, 2009 at 2:21 PM, Jason Beverage 
>> wrote:
>> > Hi Colin,
>> >
>> > Thanks for pointing that out, it looks like Jaunty does indeed default
>> to
>> > 4.3.  I'll play around with it this weekend and see if I can get
>> osgEarth
>> > compiling with 4.3.
>> >
>> > Thanks!
>> >
>> > Jason
>> >
>> > On Fri, May 8, 2009 at 4:19 AM, Colin Steinberg
>> >  wrote:
>> >>
>> >> Hi all,
>> >>
>> >> The gcc-team weeded out some includes in their headers for the 4.3
>> >> release.
>> >> If a program uses a cstdlib function, but does not include the header
>> file
>> >> because it was already pulled in by another c++ header, it will break
>> now.
>> >> I don't know which gcc version Jaunty defaults to, but if it is a 4.3
>> >> release, this would be the problem.
>> >>
>> >> Cheers,
>> >> Colin
>> >>
>> >> On Thu, May 7, 2009 at 10:40 PM, Jason Beverage <
>> jasonbever...@gmail.com>
>> >> wrote:
>> >> > Hi Simon,
>> >> >
>> >> > I try to build osgEarth pretty regularly on Ubuntu 8.10 and haven't
>> seen
>> >> > this error before.  Perhaps its something to do with Jaunty, I've not
>> >> > tried
>> >> > it yet.
>> >> >
>> >> > I'll try to give it a go when I get a chance, I've been wanting to
>> >> > update
>> >> > anyway:)
>> >> >
>> >> > Jason
>> >> >
>> >> > On Thu, May 7, 2009 at 4:23 AM, Simon Loic 
>> wrote:
>> >> >>
>> >> >> Hi Jason,
>> >> >> thanks for helping
>> >> >> I'm on a linux : kubuntu Jaunty.
>> >> >> To be totally honest in the first place I really doubted that the
>> code
>> >> >> I'm
>> >> >> talking about could compile on another linux. However, as this  code
>> >> >> (eg
>> >> >> VTP) must have been extensively tested I turned out to think that I
>> was
>> >> >> missing something.
>> >> >>
>> >> >> Thanks again.
>> >> >>
>> >> >> On Wed, May 6, 2009 at 11:24 PM, Jason Beverage
>> >> >> 
>> >> >> wrote:
>> >> >>>
>> >> >>> Hi Simon,
>> >> >>>
>> >> >>> What platform are you compiling on where you are seeing these
>> issues?
>> >> >>>
>> >> >>> Jason
>> >> >>>
>> >> >>> On Wed, May 6, 2009 at 3:47 PM, Simon Loic 
>> >> >>> wrote:
>> >> 
>> >>  Hello everyone,
>> >>  It may certainly be a stupid question and not the right place to
>> ask.
>> >>  Still I've been compiling a couple of osg based application : VTP,
>> >>  osgEphemeris, osgearth. The fact is that for most of them I had to
>> >>  add a
>> >>  couple of #include directive to make them compile. It's always
>> some
>> >>  c++
>> >>  wrapping of c headers like  or .
>> >>  I don't understand if it is possible that those application
>> compile
>> >>  without problem on some computer. Which would mean that I have to
>> >>  tune some
>> >>  environment variables or whatever.
>> >>  Is this the case or should I report those missing directive to the
>> >>  concerned developper?
>> >> 
>> >>  Thanks for any answer on this.
>> >> 
>> >> 
>> >>  --
>> >>  Loïc Simon
>> >> 
>> >>  ___
>> >>  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
>> >> >>>
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Loïc Simon
>> >> >>
>> >> >> ___
>> >> >> osg-users mailing list
>> >> >> osg-users@lists.openscenegraph.org
>> >> >>
>> >> >>
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>> >> >>
>> >> >
>> >> >
>> >> > ___

Re: [osg-users] how to set osg::notify to a file

2009-05-11 Thread Vincent Bourdier

Hi,

Using the std stream, you can redirect the out stream into a file stream.
I don't know if osg implements a thing about that, i think it don't...

Regards,
   Vincent

2009/5/11 forest 

> hi all
>osg::notify put notifies on the console defaultly.Can I put these
> notifies to a file?
>thanks in advance.
>best regardes
> forest
>
> ___
> 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] how to set osg::notify to a file

2009-05-11 Thread forest

hi all
osg::notify put notifies on the console defaultly.Can I put these 
notifies to a file? 
thanks in advance.
best regardes
 forest___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] looking at osgOcean; some provocative ideas.

HI Sergey,

On Sat, May 9, 2009 at 12:55 PM, Sergey Kurdakov  wrote:
> to have osgRoad by this paper
> http://wscg.zcu.cz/wscg2005/Papers_2005/Full/C61-full.pdf

I just read the paper.  It's a interesting and should be flexible
approach to generating smooth roads by using coarse geometry and pixel
shaders to compute the tex coords to give a final smooth look.  I
wouldn't have though it'd take too much work to implement either.

> and osgForest - something like
> http://www.ogre3d.org/wiki/index.php/PagedGeometry_Engine

The OSG has very capable multi-threaded paging which is more general
purpose than this approach.  What is missing is would the procedural
instancing and reuse of geometry for the trees/grasses.  If you
implemented the later then you could use the standard PagedLOD for
handling all the multi-threaded paging to get the scalability.

Right now there is blueberry and SpeedTree integration with the OSG
that are available commercially so one could do the forest rendering
if you are prepared to dip into your pocket.

Personally I'd like to see a procedural geometry generation and reuse
support available as part of the core OSG, it would be great for
forests and potentially other items like fences, roads, houses etc.

> with that features others could also create sophisticated demos . For
> example make
> osg demo like Smoke Demo by intel
> http://software.intel.com/en-us/articles/smoke-game-technology-demo/.

Umm this is just a demo of how to pull different bits of
middleware to create a demo, it isn't really about techniques for
rendering smoke.  Personally I would rather move complex smoke
simulation off onto the GPU than do it on the CPU as you have two
orders of magnitude more cores available to do the compute...  Intel's
job is selling CPU's not teaching one the best way to implement
something given the complete range of hardware available...

So I'd recommend looking at osgCompute for this type of work ;-)

> Robert mentioned once that we need demos.
>
> I believe we are near  a breakthrough to the days when fantastically
> beatiful demos are done in matters of weeks.

Do you mean osgviewer cow.osg isn't impressive enough :-)

Really compelling demos are certainly missing.  All our examples just
demonstrate just one particular feature at a time, and their main
purpose is teaching + testing, not selling the capabilities of the
OSG.  Given we have high quality volume rendering, terrain rendering,
paging, particle effects, character animation and plenty of advanced
3rd party libs like osgEarth, osgPPU, ossimPlanet, osgOcean,  there
are huge capabilities that aren't put together to show off the full
capabilities.

With the integration of Present3D into OpenSceneGraph body it's my
plan to start putting presentations together that show off a few more
of the capabilities of the OSG in a more accessible way.

I would love to see other technology demonstrators pop up as well :-)

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

Re: [osg-users] osgOcean release