never heard of it.
google sez: mpr.dll is a module containing functions used to handle
communication between the Windows operating system and the installed
network providers.
-- mew
On Thu, Apr 17, 2008 at 8:03 PM, [EMAIL PROTECTED] wrote:
Hello,
I develop a osg application,it runs
Hi Art,
A long way back, 7 years ago, perhaps more, when I wrote
NodeVisitor I did consider adding detecting of cycles but considered
the code too costly to apply on every traverse or accept invocation.
Cyclic scene graphs are very much a special case that very few users
will ever use so
Hi Erland,
You could use osgViewer::GraphicsWindowEmbedded to replace SceneView,
see the osgviewerGLUT and osgviewerSDL examples.
Robert.
On Thu, Apr 17, 2008 at 10:13 PM, [EMAIL PROTECTED] wrote:
Hei Robert.
I would like to do that, but im working in a company and right now im trying
to
Hi Paul,
The osgdepthpartion example would be best rewritten as a Viewer with
slave Cameras, rather than a CompositeViewer with multiple Views.
The reason for this is that depth partition cameras are conceptually
work on the same view, and are locked in sync with the view and
projection matrix
Looking at that example I see that swapbuffers has to be called manually
in this case, but I fail to find the place in the source where Viewer
checks if it is running embedded and therefore doesn't have to call
swapbuffers itself. Can you give a hint where this is?
Paul
Robert Osfield wrote:
Hi,
with the latest SVN and osgprerender --image, I'm getting a lot of:
Warning: detected OpenGL error 'invalid enumerant' after RenderBin::draw(,)
lines written to the screen.
Does anyone else see this? Without --image there are no errors.
On another machine I have rev 8084 and have
Hi Donlin,
A good way to debug file search paths is to enable verbose debug messages via:
set OSG_NOTIFY_LEVEL=DEBUG
And then look for the output where it searches for the Font. It could
be that the search paths on each machine is different, or that each
machine doesn't have the same set of
Hi Paul,
On Fri, Apr 18, 2008 at 10:18 AM, Paul Melis [EMAIL PROTECTED] wrote:
Looking at that example I see that swapbuffers has to be called manually
in this case, but I fail to find the place in the source where Viewer
checks if it is running embedded and therefore doesn't have to call
Hi J.P,
On Fri, Apr 18, 2008 at 10:53 AM, J.P. Delport [EMAIL PROTECTED] wrote:
version 8084 (that works) already has MRT included, that's why I had it
on another machine.
It seems like it was the moving of the MRT to FBO that might be the problem.
Thanks for the clarification, gives us a
Hi J.P,
Thanks for the heads up, I just tried it on my machine (Kubuntu 7.10,
7800GT) and get the same error.
My guess is that the changes to support Multiple Render Targets has
broken something in RenderStage w.r.t reading imagery. Arrrgghghg
two steps forward, one step back
Robert.
Hi Robert,
Robert Osfield wrote:
Hi J.P,
On Fri, Apr 18, 2008 at 10:53 AM, J.P. Delport [EMAIL PROTECTED] wrote:
version 8084 (that works) already has MRT included, that's why I had it
on another machine.
It seems like it was the moving of the MRT to FBO that might be the problem.
Hi J.P,
On Fri, Apr 18, 2008 at 11:20 AM, J.P. Delport [EMAIL PROTECTED] wrote:
Yes, I think I know what is wrong.
Remember how you modified the enum Camera::BufferComponent so that
COLOR_BUFFER and COLOR_BUFFER0 were not the same? When glDrawBuffers was
in RenderStage, it knew to only
Hi,
how can I set the height in DriveManipulator ?
When I use setHeight, it has no effect, specially when I remove the
intersectTraversal.
When I look in the source code, I can't find how the height effects the
calculation.
Or do I miss something ?
Thanks
Dieter
Unclassified Mail
Hi
i´m compiling against windows with visual studio 2005 sp1
i´ve downloaded the osg windows dependencies from the svn and i´m also using
the gdal from the FWTools210 package. Do all the cmake stuff and the i build
the solution
62 projects of the solution compile succesfully vs 6 failed
Hi J.P et. al,
On Fri, Apr 18, 2008 at 12:22 PM, Robert Osfield
[EMAIL PROTECTED] wrote:
Change FBO so that it used osg::Camear::BufferComponent rather than
GLenum would be one way, as this would allow use to differentiate
properly. Changing setAttatchment(GLenum,..) to
Hi David,
This problem was fixed right after the 2.3.8 dev release, other
Windows users have since been compiling fine so I'd recommend you do
another svn update, and that doesn't work investigate why your local
svn checkout hasn't been updating the
include/osgViewer/api/Win32/GraphicsWindowWin32
i´m doing the checkout from this url
http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.3.8
tell me if that is correct, and if it is not, i´ll investigate on my own why it
is not working
thanks
Date: Fri, 18 Apr 2008 13:35:34 +0100
From: [EMAIL PROTECTED]
To:
Hi David,
i´m doing the checkout from this url
http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.3.8
That refers to the tag directly, so it's identical to the 2.3.8 tarball
you had. You won't get any subsequent updates.
Check out from
thanks, it´s working now
Date: Fri, 18 Apr 2008 08:54:09 -0400
From: [EMAIL PROTECTED]
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] error compiling last svn OSG
Hi David,
i´m doing the checkout from this url
Hi All,
With these changes the MRT and the non MRT FBO examples work for me.
Could users do an svn update and these out the new codes?
I have just done more testing, and found that while the follow works:
osgprerender cow.osg --image --fbo
Without the --image it fails - I just get a back
Hi All,
Many thanks for the the testing and feedback. Alas I'm afraid I'll
now further testing as this morning I've checked in a couple of bug
fixes that will need build and runtime testing.
I also forgot to mention, the SVN version of the OSG is now under
feature freeze, so only bug and build
The SVN gives this error:
[ 1%] Building CXX object src/osg/CMakeFiles/osg.dir/FrameBufferObject.o
/home/alberto/OSGSVN2/trunk/src/osg/FrameBufferObject.cpp: In member
function ‘void osg::FrameBufferObject::updateDrawBuffers()’:
/home/alberto/OSGSVN2/trunk/src/osg/FrameBufferObject.cpp:619:
Hi Alberto,
Sorry, missed this check in (I was managing multiple patches at once.)
The include/osg/Camera updates are now checked in.
Robert.
On Fri, Apr 18, 2008 at 2:44 PM, Alberto Luaces [EMAIL PROTECTED] wrote:
The SVN gives this error:
[ 1%] Building CXX object
Hi All,
I've tracked down the below problem and checked in a bug fix for it.
So please svn udpate and test.
Robert.
On Fri, Apr 18, 2008 at 2:16 PM, Robert Osfield
[EMAIL PROTECTED] wrote:
I have just done more testing, and found that while the follow works:
osgprerender cow.osg --image
Hi All,
I've a new problem, which is about Geometries.
this is simple : I've a node, already with a texture, and I want to put a
second texture on it. BUT, the second texture have to be well positioned on
the node, without depending on the Geometry's texture coordinates...
I've tried
Vincent,
I'm not sure what you're trying to do. The second texture will only look
right on the geometry if you define the texture coordinates to make it
right.
Each texture has it's own texture coordinates:
osg::Geometry::setTexCoordArray(texture unit, texture coordinate array)
The first
Brian,
ok so if I understand well, i can set a second array of coordinate of
texture. but for that I need the geometry... and i only can get the drawable
from a geode... so how can I get the geometry ?
thanks for help.
Vincent.
2008/4/18, Brian R Hill [EMAIL PROTECTED]:
Vincent,
I'm not
Bonjour Vincent,
this is simple : I've a node, already with a texture, and I want to put
a second texture on it. BUT, the second texture have to be well
positioned on the node, without depending on the Geometry's texture
coordinates...
Geometry can (and should) have texture coordinates
Bonjour Vincent,
ok so if I understand well, i can set a second array of coordinate of
texture. but for that I need the geometry... and i only can get the
drawable from a geode... so how can I get the geometry ?
Use a NodeVisitor to get to the geode you want (only you can know which
one
Hi Jean-Sébastien,
This is a very clear and complete explanation.
I'll will try all these to get the best in my case.
thanks a lot for these quick answers !!
Regards,
Vincent.
2008/4/18, Jean-Sébastien Guay [EMAIL PROTECTED]:
Bonjour Vincent,
ok so if I understand well, i can set a
Vincent,
The geode can have any number of drawables associated with it. You need to
know which one you are interested in.
for (unsigned int ii=0; iigeode-getNumDrawables(); ++ii)
{
osg::Geometry * geom = dynamic_castosg::Geometry
*(geode-getDrawable(ii));
if (geom)
{
// do your
On all three platforms on which I compiled, I got an error:
FrameBufferObject:619: error: 'COLOR_BUFFER15' is not a member of
'osg::Camera'.
I just did svn update in my root directory before compiling. Should
I have done something else?
andy
-Original Message-
From: [EMAIL PROTECTED]
Ok, it builds now, osgprerender --image works if what is intended is to
invert the colours of a rectangle inside of the cow texture. I really never
tried that example with the --image switch, but I think it's doing its work
nicely.
El Viernes 18 Abril 2008ES 15:55:54 Robert Osfield escribió:
Hi Andy,
This error was a missing check-in that has now been checked in. An
svn update will fix this.
Robert.
On Fri, Apr 18, 2008 at 4:07 PM, Andy Skinner
[EMAIL PROTECTED] wrote:
On all three platforms on which I compiled, I got an error:
FrameBufferObject:619: error: 'COLOR_BUFFER15' is
You can control this with an environment variable. The following is from the
OSG Reference Manual v2.2:
3.2.16 OSG_DRIVE_MANIPULATOR_HEIGHT
Specifies the view offset from ground level that the DriveManipulator uses.
The value is in world coordinate units.
Valid values: Any floating-point
OcclusionQueryNode works by performing occlusion tests against the contents
of the depth buffer. If your ceiling is being face culled and therefore not
writing into the depth buffer, then it shouldn't occlude the furniture, and
OcclusionQueryNode should render them. If this isn't happening,
Hi J-S -- Perhaps I was being too precise. The question in the subject line
is: When must you use SingleThreaded threading model? And the correct
answer to that question is any time you must use code that isn't thread
safe. :-)
Instead, if the question were worded as: How can I avoid having to
OK, latest SVN compiled on those same platforms.
It is a good bit more work to try it out with our code, and I may wait
until 2.3.9 for that. I don't expect a problem once it compiles, but
I'll check it before 2.4.
andy
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL
Hi All,
Many thanks for the build testing and assistance on getting bugs
characterised and fixed. Virtue of these fixes
we have stepped closer to OpenSceneGraph-2.4 stable release, and
today's 2.3.9 developer release is release
candidate for the final 2.4 stable release.
Details on
Hi Daniel,
I have made no changes to StateSet, not for a long time, last changes
were in a submission back in December.
I can only guess that you have mixed OpenGL versions such that the OSX
OpenGL headers are setting GLenum to one thing, then another header
such as from GLX is setting it to
Hi Robert,
Thanks to your answer. You describe the right problem.
If i set the following parameter in the xcode project, the application
was build successfully.
Base SDK Path:
$(DEVELOPER_SDK_DIR)/MacOSX10.4u.sdk
Thanks,
Daniel Moos
Am 18.04.2008 um 21:26 schrieb Robert Osfield:
Hi
Hi, Mike,
Mike Greene wrote:
While this did stop the messages from coming to the screen about the
texture being resized, it did NOT seem to speed things up. I have two
sets of texture sequences - one that is 800 x 600 and one that is 1024
x 512. The latter probably runs 10 times faster,
Hi Robert,
there is currently some unoptimized code in the osg.
If one do specify for example 10 texture attributes
for a stateset like this:
stateset-setTextureAttribute(i, new
osg::Texture2D());
and after some time you remove this attributes, there
is still an unneccessary call to
43 matches
Mail list logo
