[osg-users] StateSetManipulator doesn't work

[Su Gang]

Hi,

I have a strange problem. Runing the following code will cause 
StateSetManipulator doesn't work. That is I can't enble/ disable texture by 
clicking key "T" (And the Lighting, CyclePolygonMode). 
I've tried. If keep only one geom->addPrimitiveSet of the first two POLYGONs, 
remove the Tessellator part and other PrimitiveSets, the StateSetManipulator 
would work.
I was using OSG 2.9.15. It occurs on windows 32-bit and linux 64-bit release.
On windows 32-bit debug and 64-bit release it works fine.
I saw StateSetManipulator::handle() run. 
The problem is so strange to me. Do you have the answer to this? 

Thank you!

Cheers,
Su


[code]
osg::ref_ptr new3DPolygonVertexArray = new osg::Vec3Array;
...  get new3DPolygonVertexArray ...
osg::Geode *new3dGeode = create3dShapeFrom2dPolygon(new3DPolygonVertexArray, 
m_ZThreshold3d, m_baseShapeColor, m_shapeFileDepthTest);

// destSwitch->addChild(new3dGeode); // 即使不 addChild， StateSetManipulator 也不起作用


osg::Geode *create3dShapeFrom2dPolygon (osg::Vec3Array 
*new3DPolygonVertexArray, float zThreshold3d, osg::Vec4 colour, bool depthTest)
{
osg::Geode* boxGeode = new osg::Geode();

osg::ref_ptr geom = new osg::Geometry();
geom->setUseVertexBufferObjects( true );

float min = 0.0;
float max = 0.0;

// Some times begin = end.
if (*(new3DPolygonVertexArray->begin()) != 
*(new3DPolygonVertexArray->end() -1))
{

new3DPolygonVertexArray->push_back(*(new3DPolygonVertexArray->begin()));
}


osg::ref_ptr tmpArray = new osg::Vec3Array;
geom->setVertexArray(tmpArray.get());

//  Ignore the last point.
for (osg::Vec3Array::iterator iter = new3DPolygonVertexArray->begin(); 
iter < new3DPolygonVertexArray->end() -1; iter++)
{
tmpArray->push_back(osg::Vec3(iter->x(), iter->y(), min));  
// Top
}
for (osg::Vec3Array::iterator iter = new3DPolygonVertexArray->begin(); 
iter < new3DPolygonVertexArray->end() -1; iter++)
{
tmpArray->push_back(osg::Vec3(iter->x(), iter->y(), max));  
// Bottom
}


unsigned int numTopPoints = (tmpArray->size())/2;
geom->addPrimitiveSet(new osg::DrawArrays(osg::PrimitiveSet::POLYGON, 
0, numTopPoints));// Top
//geom->addPrimitiveSet(new osg::DrawArrays(osg::PrimitiveSet::POLYGON, 
numTopPoints, numTopPoints));   // Bottom

{
osg::ref_ptr tscx=new 
osgUtil::Tessellator;

tscx->setTessellationType(osgUtil::Tessellator::TESS_TYPE_POLYGONS);
tscx->setBoundaryOnly(false);
tscx->setWindingType( osgUtil::Tessellator::TESS_WINDING_ODD);
tscx->retessellatePolygons(*(geom.get()));
}

numTopPoints = (tmpArray->size())/2;
unsigned int numQUAD_STRIP = new3DPolygonVertexArray->size() 
-1;//(numPointsAfterTessellate - numPoints*2)/2;
for (osg::Vec3Array::iterator iter = new3DPolygonVertexArray->begin(); 
iter < new3DPolygonVertexArray->end(); iter++)
{
tmpArray->push_back(osg::Vec3(iter->x(), iter->y(), min));  
// Sides
tmpArray->push_back(osg::Vec3(iter->x(), iter->y(), max));
}

for (unsigned int i = 0; i< numQUAD_STRIP; i++)
{
geom->addPrimitiveSet(new 
osg::DrawArrays(osg::PrimitiveSet::QUAD_STRIP, numTopPoints *2 + 2*i, 4));// 
Sides
}

geom->addPrimitiveSet(new osg::DrawArrays(osg::PrimitiveSet::LINE_LOOP, 
0, numTopPoints));
geom->addPrimitiveSet(new osg::DrawArrays(osg::PrimitiveSet::LINE_LOOP, 
numTopPoints, numTopPoints));
geom->addPrimitiveSet(new osg::DrawArrays(osg::PrimitiveSet::LINES, 
numTopPoints*2, numQUAD_STRIP*2));

boxGeode->addDrawable(geom.get());
return boxGeode;
}[/code]

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





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

Re: [osg-users] Any libraries of public domain shapes for Open Scene Graph?

[Robert Osfield]

Hi Barry,

On 18 March 2012 22:01, Barry  wrote:
> I would like to know if there are libraries of public domain shapes for Open 
> Scene Graph, other than the basic ones provided?

I'm rather perplexed by what your actually mean, I'm sure others will
be similarly confused by what exactly you are asking.  Could you
please explain what you are specifically looking for.  Also I'd like
to note that the OpenSceneGraph (OSG) is not public domain, it's open
source, and 3rd party open source tooklits associated with the OSG
will also not be public domain.

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

Re: [osg-users] Any libraries of public domain shapes for Open Scene Graph?

[Christian Buchner]

I am not the original poster, but I'd love to see a library of
implicitly (mathematically) defined shapes that use GLSL
raytracing/raymarching for rendering. So you can get perfect spheres
without any geometry load.

Spheres, Cones, etc... that kind of stuff that is hard to tacke with meshes.

If the GLSL allowed for flexibly defined material properties, this
would be even nicer.

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

Re: [osg-users] Any libraries of public domain shapes for Open Scene Graph?

[Andrew Lowe]

Quoting Robert Osfield :


Hi Barry,

On 18 March 2012 22:01, Barry  wrote:
I would like to know if there are libraries of public domain shapes  
for Open Scene Graph, other than the basic ones provided?


I'm rather perplexed by what your actually mean, I'm sure others will
be similarly confused by what exactly you are asking.  Could you
please explain what you are specifically looking for.  Also I'd like
to note that the OpenSceneGraph (OSG) is not public domain, it's open
source, and 3rd party open source tooklits associated with the OSG
will also not be public domain.

Robert.


I'm reading this to be models of things such as the Utah Teapot, cars,  
planes, animals, etc etc etc that is stuff in a format suitable for  
easy reading into OSG apps, such as the reflective cow. Just out of  
interest, does the cow have a name - Beryl? Daisy? Bert??


Prepared to be proven wrong,
  Andrew

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

Re: [osg-users] Camera attached to object

[Sergey Bocharov]

zonk wrote:
> Hi Sergey,
> 
> why don't you use OSGs standard nodetrackermanipulator?
> You can track a node and configure which DOF are controllable via the 
> manipulator.
> 
> 
> Cheers,
> Torben


Hi Torben nodetrackermanipulator allow to sen node as point of view and camera 
flying around this node. I need the same thing but camera must be at the node 
and point of view flying around camera. Is in possible with 
nodetrackermanipulator?

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





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

[osg-users] Site where I can get free bumpmaps and free textures?

[Zachary Hilbun]

Hi,

What are some sites where I can get free bumpmaps and free textures?

Thank you!

Cheers,
Zachary

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





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

[osg-users] osgShadow and multitexturing

[Daniel Schmid]

Hi y'all

I'm trying to implement shadow in my scene. My scene makes use of up to 4 
texture levels in its models. I read in some comments that the lipsm and other 
shader based shadow techniques are not really made for multi texturing. Ist 
here anybody out there that made a custom shader that implements multitexturing 
and aswell fog functionality?

Regards
Daniel

***
Daniel Schmid
Swiss SIMTEC AG
Frutigenstrasse 4
CH-3600 Thun

Tel:+41 33 533 02 10
Fax:   +41 33 533 02 01

Mail:  daniel.sch...@swiss-simtec.ch
URL:  http://www.swiss-simtec.ch
***

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

Re: [osg-users] Incorrect volume image

[Clement.Chu]

Hi Robert,

I appreciated your details explanation.  My program was using coin3D for 
volume rendering previously and it was working fine on Intel graphics machine, 
so I expected osg can work the same.   I absolutely agree with your point of 
view.  I have set the minimum requirement for using osg.  It is worth to 
replace coin3D with OSG for the future use.  Thanks again for your help and 
suggestion.


Regards,
Clement



From: osg-users-boun...@lists.openscenegraph.org 
[osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield 
[robert.osfi...@gmail.com]
Sent: Monday, 19 March 2012 7:54 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Incorrect volume image

Hi Clement,

On 18 March 2012 09:46,   wrote:
>   Many thanks for your suggestion.  osg is working perfectly on my dell e6410 
> laptop, but others people can't run osg properly on their machines which are 
> standard dell desktop machine with Intel graphics hardware.  I want to 
> overcome this problem on standard dell desktop machines.  Last time you 
> mentioned how to use texture2D, but it seems quite complicated and not using 
> standard osgVolume api.  I would like to know the minimum system requirement 
> for osg especially running osgVolume.  Thanks.

I can specify a minimum requirement for the OSG as it's the minimum
requirements will depend upon each applications needs, so it's really
up to the application developer what limits they choose.  In the case
of osgVolume it requires a least 3D texture support, and preferably
GLSL shader support to go along with it.  Practically this means
OpenGL 2.0 with proper hardware and driver support for 3D textures.
The only hardware and drivers that reliably provide this functionality
are ATI and NVidia GPU and associated drivers.

Intel hardware and drivers so far have shown them selves to be
inappropriate for supporting osgVolume, and I very much doubt this
will change in the mid term.  Perhaps one day Intel will buy out
NVidia and final gets some decent graphics know how, but for now I
think it's a pretty safe bet to assume that all Intel graphics will
not be suitable and would probably be best to be detected at run-time
and an appropriate report provided to your end users.

The 2D texturing fallback you could implement, but it will never be
able to provide the same quality of results and the performance will
be so poor compared to a full osgVolume implementation rendered on
decent hardware I really don't think it would be worth the effort.  As
a point of reference 3 1/2 years ago when I first start work on
osgVolume I looked at the various routes we could take with the
implementation and it was pretty clear that it didn't make much sense
to try and implement a rendering fallback using 2D texturing as the
cost of implementing and maintaining it would be highly
disproportionate to the actual capability achieved.  3 1/2 years it we
already had low cost, low end graphics card capable of doing 3D
textures, it was only the Intel embedded graphics that wouldn't be
able to handle, but they don't have the performance to do it anyway so
it's rather pointless.  Back then anyone who really wants to do volume
rendering would be using a mid to high range card, one wouldn't
convenience of doing high end graphics like volume rendering on
anything less.

Fast forward to today and still doesn't make any sense to adept to
support hardware that doesn't have the feature set or performance to
do volume, and it's so cheap to purchase hardware that can handle it
it really is far far cheaper just to buy someone a new card.  As for
laptops that are stuck with Intel graphics, well sorry, they have
crappy graphics, one shouldn't ever purchase low end graphics for high
end graphics tasks.   Volume rendering *is* high end graphics, it's
one of the few tasks that can push modern graphics cards.

I must admit, I'm kinda surprised that I should have to telling you
this.  You are the first engineer I've come across that has ever
expected volume rendering to work properly on Intel graphics.

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

[osg-users] Rubber band selection for pixel masking

[Marco Fiocco]

Hi all,
I'm trying to implement a rubber band selection tool (and also a polygonal
selection tool), and I'm wondering which is best approach since there are a
number of options in OSG and it's a bit confusing...
Note that I don't really need the PolytopeIntersector, because I need to
create a bit mask for the pixels inside the polygon.
For the drawing of the rectangle (or polygon) I was thinking to do it in
screen coordinates, using a HUD camera, but then I need to handle the mouse
events and the state machine for the various mouse presses... where should
be best handled this?
Should I use a node callback, and event handler or create my custom node
and handle the events in the traverse()?
Thanks in advance
Marco
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Segmentation fault in osgDB::readNodeFile()

[Mark Green]

Hi,

So the porting shouldn't be that ard, that is good to hear.
Unfortunately, the problem still exists after trying to change the makefile in 
many ways.

A possibly important bit of information I forgot to mention was that while the 
compiling did not produce any errors, it did produce the following warning: 
"warning: libstdc++.so.5, needed by /usr/local/lib/libosg.so, may conflict with 
libstdc++.so.6"

Is there any reason why this particular warning could be thrown and could the 
cause of it lead to the problem I'm experiencing? I wouldn't expect version 
differences of the std library to exist within one version of OSG itself and I 
also wouldn't be able to imagine how a different version used within a part of 
the program that is never even executed or referenced could cause an error 
within internal OSG code. But it's still interesting to see this warning 
appear, maybe it might be of help.

Upon removal of ibosg.so from the loaded librarys, the warning just changes to 
warn about the other osg libs used (osgDB osgGA osgUtil osgViewer)

Thank you!

Cheers,
Mark

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





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

Re: [osg-users] [vpb] Multiple terrain layers and relative altitude heightmap

[Eric Zaremba]

Ok, thank you, I will take a look at all of that.

Eric

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





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

Re: [osg-users] Segmentation fault in osgDB::readNodeFile()

[Robert Osfield]

HI Mark,

On 19 March 2012 15:08, Mark Green  wrote:
> A possibly important bit of information I forgot to mention was that while 
> the compiling did not produce any errors, it did produce the following 
> warning:
> "warning: libstdc++.so.5, needed by /usr/local/lib/libosg.so, may conflict 
> with libstdc++.so.6"
> Is there any reason why this particular warning could be thrown and could the 
> cause of it lead to the problem I'm experiencing?

I have seen this warning reported to before.  I kinda sounds like the
version of libosg.so was built against a different version of libstdc
that your application or is still available.  Such warning is a good
red flag and may well be why you have seen the crash.

I don't know the history of how the OSG has been built and installed
for you system.


> I wouldn't expect version differences of the std library to exist within one 
> version of OSG itself and I also wouldn't be able to imagine how a different 
> version used within a part of the program that is never even executed or 
> referenced could cause an error within internal OSG code. But it's still 
> interesting to see this warning appear, maybe it might be of help.

The OSG will build against on version of all the external libraries,
what you is seeing is abnormal.  The only possibility I can see that
one could see mixed 3rd party libs would be if different external
dependencies of the OSG linked against different versions of libs i..e
libtiff linking against one version, and the rest of the OSG compiling
against another.  This is a hypothetical suggestion, it's not
something ever come across personally or seen others come across.
What you seeing is very odd.


> Upon removal of ibosg.so from the loaded librarys, the warning just changes 
> to warn about the other osg libs used (osgDB osgGA osgUtil osgViewer)

I would recommend removing all the old OSG libs and plugins that were
previously on your system, then build the OSG locally on your machine
and install it, then recompile your application from scratch.

If you using a OSG build from a distribution repository I would expect
things to be consistent as well, but perhaps the packager made a
mistake.

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

Re: [osg-users] Incorrect volume image

[Robert Osfield]

Hi Clement,

On 19 March 2012 14:41,   wrote:
>    I appreciated your details explanation.  My program was using coin3D for 
> volume rendering previously and it was working fine on Intel graphics 
> machine, so I expected osg can work the same.   I absolutely agree with your 
> point of view.  I have set the minimum requirement for using osg.  It is 
> worth to replace coin3D with OSG for the future use.  Thanks again for your 
> help and suggestion.

Coin3D will have been using the crude 2D Texture axis aligned quad
approach that I suggested as an option previously.  However, this
approach while it might produce a result, it won't perform well or
have what I would call an acceptable level of visual quality.  The old
2D texture approach is really something that dates back over a decade
to when 3D textures didn't exist on common hardware, and is rather a
relic on old era of graphics.

As a fallback perhaps you could just render an opaque cube and pick
out the sides of the cube from the image.

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

Re: [osg-users] osgShadow and multitexturing

[Robert Osfield]

Hi Daniel,

All the osgShadow techniques can work with multi-texturing and it's
certainly how I'd expect most users to use it.  However, the built in
shaders they provide can't handle all the types of effects you might
want to use so you'll need to replace these with your own custom
shaders.

Robert.

On 19 March 2012 14:40, Daniel Schmid  wrote:
> Hi y’all
>
>
>
> I’m trying to implement shadow in my scene. My scene makes use of up to 4
> texture levels in its models. I read in some comments that the lipsm and
> other shader based shadow techniques are not really made for multi
> texturing. Ist here anybody out there that made a custom shader that
> implements multitexturing and aswell fog functionality?
>
>
>
> Regards
>
> Daniel
>
>
>
> ***
>
> Daniel Schmid
>
> Swiss SIMTEC AG
>
> Frutigenstrasse 4
>
> CH-3600 Thun
>
>
>
> Tel:    +41 33 533 02 10
>
> Fax:   +41 33 533 02 01
>
>
>
> Mail:  daniel.sch...@swiss-simtec.ch
>
> URL:  http://www.swiss-simtec.ch
>
> ***
>
>
>
>
> ___
> 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] Can't resize framebuffer texture attachments

[Sean O'Connell]

I'm trying to resize the textures attached to my framebuffer during run-time, 
however the viewport size that the scene is rendered into stays the same.  If 
the framebuffer starts off at 64x64 pixels and I then resize to 512x512, the 
output only contains rendered pixels in the lower left 64x64 region and the 
rest of the image is black.  I've found other forum posts similar to this issue 
but their solutions did not work.  Here's the code I'm using to resize.

colorbuffer->setTextureSize(width, height);
colorbuffer->dirtyTextureObject();

depthbuffer->setTextureSize(width, height);
depthbuffer->dirtyTextureObject();

osg::Camera::setViewport(0, 0, width, height);
osgViewer::Renderer* renderer = (osgViewer::Renderer* 
)osg::Camera::getRenderer();
renderer->getSceneView(0)->getRenderStage()>setFrameBufferObject(NULL);
renderer->getSceneView(0)->getRenderStage()>setCameraRequiresSetUp(true);

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





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

[osg-users] Texture render ratio?

[Paul Griffiths]

Hi,

Lets say I have a texture 800 * 480.
I have a quad which is 10 * 10.

If I render the texture to the quad, the texture will be squashed on the x axis.

How do I compensate for this, correct the aspect ratio?

... 

Thank you!

Cheers,
Paul

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





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

Re: [osg-users] Texture render ratio?

[Jan Ciger]

On Mon, Mar 19, 2012 at 6:32 PM, Paul Griffiths  wrote:

> Hi,
>
> Lets say I have a texture 800 * 480.
> I have a quad which is 10 * 10.
>
> If I render the texture to the quad, the texture will be squashed on the x
> axis.
>

> How do I compensate for this, correct the aspect ratio?
>

By using proper texture coordinates on the quad.

Regards,

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

Re: [osg-users] osgShadow and multitexture

[Daniel Schmid]

Hi Robert

Thanks for your answer. I was hoping all osgShadow techniques support 
multi-texturing... but in my application, i tried every single one, and I only 
have strange effects. What happens basically is the following: I can manage to 
have a shadow with standardshadowmap, and all the view based techniques, by 
selecting the base texture unit as 0 and the shadow texture unit between 1 and 
4. What happens then is that the according texture level of my model is 
replaced with my shadow texture and the texture coordinates of this level get 
mixed up, like i have other textures moving when rotating my viewport. So I 
thought, probably these levels are already occupied by my scene model, so I 
have to use a value above 4, but then I have no more shadow displayed at all.

I'm sure I'm missing somehow an important point about the way base texture and 
shadow texture units must have been supposed to use. But after some days of try 
and error, I cannot figure how I can have osg create a shadow without removing 
my textures or messing with a textures layer coordinate...

I'm really stuck... help appreciated. There are not really any tutorials out 
there explaining the use of osgShadow...

Regards
Daniel

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

[osg-users] PixelBuffer Cocoa - Meaning of output message?

[Hartwig Wiesmann]

Hi,

in osgView::PixelBufferCocoa::realizeImplementation there is a line


Code:

std::cout << "PixelBufferCocoa :: realizeImplementation not implemented yet " 
<< std::endl;



Isn't this message obsolete? At least it seems to me that the method is 
implemented.

Thank you!

Cheers,
Hartwig

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





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