Hello community,
I compiled osg for GL3, and created a glContextVersion( "3.3" ) GL
context. In my simple test application Camera Manipulation and
MatrixTransforms are working as usual without me writing any
transformation shader. Is this possible ?
As I have doubts about this I guess that I
Hi -- A simple search of the source code shows that glContextVersion is parsed
in only one place: GraphicsContextWin32.cpp, line 1678. Set a breakpoint there
in the debugger and step through the following lines of code to ensure you're
getting the right context.
-Paul
On 10/11/2011 1:32 AM
Hi folks,
additional observation:
In case, where for each frame in the update-callback the color-buffer
attachment is bound to new Image instance, and all outcoming pictures are all
gray, except the first one -- I now store the reference to the initial
color-buffer bound image, and write it's
Hi, Alexej
Try this callback as cull callback on your camera, call reset() after you
change attachments
class CameraResetCallback: public osg::NodeCallback
{
public:
CameraResetCallback():m_resetFlag(true){}
void operator() (osg::Node* node, osg::NodeVisitor* nv)
{
Hi hybr,
yes, it works now!
I was already on finding out, how can I change
RenderStage::_cameraRequiresSetUp per frame. You've shorten this a lot!
Many thanks for your help!!!
Cheers,
Alexej
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=43316
Hi Paul,
Thanks for the replies.
I wasn't using Materials initially, but I tried adding them to see if they
would make a difference. The two geometries are still showing up as the same
color, but it didn't seem to be because of the Materials being the same.
Here's another .osg file with
I was seeing a similar (perhaps the same) problem a while back. I was
also trying to build a database without imagery (just DTED only). I got
sidetracked with other tasks so I wasn't able to chase down the problem.
I was running an older version of OSG (2.9.8 I believe) and VPB on a
Fedora core 13
Hi,
I've implemented picking in my application using
"pView->computeIntersection(...)" which use a LineSegmentIntersector
In my scene, I have some custom geometry and one of these custom geometry is
made of lines, like this :
Code:
p_geode = new osg::Geode()
p_geometry = new osg::Geometry();
Hi Paul,
thanks, but unfortunately this does not help as the method
GraphicsWindowWin32::createContextImplementation() does not get called
at all, and the glContextVersion does not get parsed ( at my site ).
This brings me back to my doubts and original question, probably I use
the wrong way
Hi,
I'm experimenting with replacing an existing widget set with versions based on
osg::Widget. I hope to create most items by composition, eg a scrollbar as two
end buttons, plus a 'track' and 'thumb', each an osgWidget::Frame or similar,
arranged in a layout. I was wondering if anyone had any
Hi Aurelien,
You can't computationally intersect infinitely thin lines with with
infinitely thin line segments so what you are asking specifically
isn't possible.
What you are probably after is intersecting a scene with a cone or
cylinder rather a line segment. Is is that you are implementing
sc
Your Materials have color mode set to DIFFUSE. In OpenGL parlance, this enables
GL_COLOR_MATERIAL and causes the diffuse lighting component to come from the
primary color instead of the material diffuse color.
Remove the color mode setting (or leave it set to default OFF) and you will see
the
You are on Windows, right? And I assume you built OSG for GL3 (changed all the
CMake setting from their default GL2 values)?
-Paul
On 10/11/2011 10:25 AM, PP CG wrote:
Hi Paul,
thanks, but unfortunately this does not help as the method
GraphicsWindowWin32::createContextImplementation() do
On Tue, 2011-10-11 at 17:32 +0100, James Turner wrote:
> Hi,
>
> I'm experimenting with replacing an existing widget set with versions based
> on osg::Widget. I hope to create most items by composition, eg a scrollbar as
> two end buttons, plus a 'track' and 'thumb', each an osgWidget::Frame or
Yes I am on Windows, sorry for not mentioning. And yes I turned off all
GL features but GL3 in the cmake built, as explained in other posts.
Cheers, PP
You are on Windows, right? And I assume you built OSG for GL3 (changed
all the CMake setting from their default GL2 values)?
-Paul
On 10
OK, I was misunderstanding how the setColorMode method worked. I changed that
to setColorMode( osg::Material::OFF ), but the first geometry is still using
the color from the color array (green), and the second geometry is using that
same color.
Here's my updated scenegraph in case it helps:
Co
On 10/11/2011 11:20 AM, Dan West wrote:
OK, I was misunderstanding how the setColorMode method worked. I changed that
to setColorMode( osg::Material::OFF ), but the first geometry is still using
the color from the color array (green), and the second geometry is using that
same color.
I copie
Hi,
> You can't computationally intersect infinitely thin lines with with
> infinitely thin line segments so what you are asking specifically
> isn't possible.
We use an algorithm with a "intersection distance" parameter : if minimum
distance between the two lines (or segment, or line/segment)
Hi Paul,
I changed my camera to a group, but I'm still seeing both geometries as
green. Here's my modified .osg file (i had to remove some of the texture
binding and projection stuff for it to behave like a normal group).
Code:
Group {
UniqueID Camera_0
nodeMask 0x
cullingActiv
HI Aurelien,
On Tue, Oct 11, 2011 at 7:08 PM, Aurelien Albert
wrote:
>
> We use an algorithm with a "intersection distance" parameter : if minimum
> distance between the two lines (or segment, or line/segment) is below this
> minimum, we consider that the lines intersect.
>
> It acts like inter
I'm still seeing the Material colors being used. I can only imaging that you
*don't* get the Material colors because you have somehow turned off lighting. To
make sure lighting is enabled, on your top-level group (or camera), do this:
getOrCreateStateSet()->setMode( GL_LIGHTING,
osg::StateAttr
Hi Shayne,
thanks for your feedback!
In my case it's also definitly no my machine. Currently it builds a database
with a bluemarbleNG texture as workaround and that build is scheduled for
another two days. Then I can go on chasing the bug with roberts/your? help.
I also added a single output li
Ok, so I have the unenviable task of rewriting software from the mid 1980's for
our virtual reality/cave environment and while I'm rewriting all of this
software I must make sure that it works with the older software so that
operations can continue as before; yes, welcome to my world.
The syste
Greetings Paul!
Yea, I came to the same conclusion also! That is why I went to the second
choice.
Oh! I goofed when I gave you that last corrected code segment. It should be:"
Code:
colors->push_back(osg::Vec4(_PrimaryColor.r(), _PrimaryColor.g(),
_PrimaryColor.b(), 1.0 - getTransparency())
Sweet, I got it working.
For some reason our scene must be doing something weird with the lighting. Both
stateSet()->setMode( GL_LIGHTING,
osg::StateAttribute::ON|osg::StateAttribute::PROTECTED ); and
stateSet()->setMode( GL_LIGHTING,
osg::StateAttribute::OFF|osg::StateAttribute::PROTECTED); did
Torben,
When I get around to it, I will try to debug things on my end. I've been
swamped with other priorities.
I just wanted to inform you that I've seen the same problem when trying
to build a database with DTED only (no imagery). If I add the imagery,
things work fine as you have said...
Rega
Hi ?,
How frequent of an occurrence is the need to add/remove portions of the scene
graph? And what kind of performance are you looking for as it happens? If it
is infrequent, could you simply stop threading on the viewer, modify your scene
graph structure however you need to, and start threa
On 10/11/2011 2:00 PM, Joshua Cook wrote:
> Since the root node of the scene may constantly change I was just thinking of
> making its variance DYNAMIC. Of course that has been touted as very
> inefficient and I agree with that. I had looked at inheriting from
> osg::Drawable::UpdateCallback b
On 10/11/2011 2:00 PM, Joshua Cook wrote:
the wrong computer, fails to send the packet, or UDP just fails to make that
left turn at Albuquerque
Ooo! A Bugs Bunny reference. :-)
Since the root node of the scene may constantly change I was just thinking of
making its variance DYNAMIC. Of cou
Hi Joshua,
I'm wondering, have you tried just adding / removing nodes in your graph
before calling frame() on your viewer?
The Draw traversal, which may still be running when the previous frame()
returns, should theoretically not care about changes in the graph.
That's because the cull trave
Hi Alexej & Sergey,
also note that if you only want to change a texture attachment and the
formats and sizes stay the same, you can in the cull callback change it.
Like so:
void KeepHistoryPass::CameraCullCallback::operator()(osg::Node* node,
osg::NodeVisitor* nv)
{
osg::Camera* fboCam
31 matches
Mail list logo
