Re: [osg-users] Depth Buffer max and min values?
Look at the osgShadow::ShadowMaps class ;) zarrandreas wrote: Oh cool. Is there a good example for rendering depth buffer to a texture with osg::CameraNode? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marcus Fritzen Sent: Thursday, September 13, 2007 5:42 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Depth Buffer max and min values? Hi, as far as I know these values are real depth values and not in range [0,1]. --marcus zarrandreas wrote: Hi, If I use osg::CameraNode to render DepthBuffer, what kind of values is then in Depth Buffer? Is that float values between [0, 1.0] or real depth values? ___ 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG 2.1.10 crash in osgText / osgdb_freetyped
Hi Gert,
(ever been Dutch? ;-))
The top of the stack trace you attached looks an awful lot like the one
I get in the osgdepthpeeling example (both point to
osgText::Text::computePositions() as the point where things go hayward):
(gdb) bt
#0 0x0032c4e2 in std::vectorosg::Vec3f, std::allocatorosg::Vec3f
::_M_fill_insert (this=0xb673ace0, __position=
{_M_current = 0xb672bbb0}, __n=396, [EMAIL PROTECTED])
at
/usr/lib/gcc/i386-redhat-linux/4.0.2/../../../../include/c++/4.0.2/bits/stl_construct.h:81
#1 0x0071d81e in osgText::Text::computePositions (this=0xb6705bf0,
contextID=0)
at
/usr/lib/gcc/i386-redhat-linux/4.0.2/../../../../include/c++/4.0.2/bits/stl_vector.h:658
#2 0x00722515 in osgText::Text::drawImplementation (this=0xb6705bf0,
[EMAIL PROTECTED], [EMAIL PROTECTED])
at /home/paul/c/osg-svn/src/osgText/Text.cpp:1545
#3 0x00722f29 in osgText::Text::drawImplementation (this=0xb6705bf0,
[EMAIL PROTECTED])
at /home/paul/c/osg-svn/src/osgText/Text.cpp:1470
#4 0x0057a4a7 in osgUtil::RenderLeaf::render (this=0xb6727e88,
[EMAIL PROTECTED], previous=0x0)
at /home/paul/c/osg-svn/include/osg/Drawable:868
#5 0x00571157 in osgUtil::RenderBin::drawImplementation
(this=0xb6761760, [EMAIL PROTECTED], [EMAIL PROTECTED])
at /home/paul/c/osg-svn/src/osgUtil/RenderBin.cpp:408
#6 0x00570d95 in osgUtil::RenderBin::draw (this=0xb6761760,
[EMAIL PROTECTED], [EMAIL PROTECTED])
at /home/paul/c/osg-svn/src/osgUtil/RenderBin.cpp:373
#7 0x005711e7 in osgUtil::RenderBin::drawImplementation
(this=0xb6761520, [EMAIL PROTECTED], [EMAIL PROTECTED])
at /home/paul/c/osg-svn/src/osgUtil/RenderBin.cpp:458
#8 0x00583bdd in osgUtil::RenderStage::drawImplementation
(this=0xb6761520, [EMAIL PROTECTED], [EMAIL PROTECTED])
at /home/paul/c/osg-svn/src/osgUtil/RenderStage.cpp:1051
#9 0x00570d95 in osgUtil::RenderBin::draw (this=0xb6761520,
[EMAIL PROTECTED], [EMAIL PROTECTED])
at /home/paul/c/osg-svn/src/osgUtil/RenderBin.cpp:373
#10 0x005841c1 in osgUtil::RenderStage::drawInner (this=0xb6761520,
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED])
at /home/paul/c/osg-svn/src/osgUtil/RenderStage.cpp:719
#11 0x005835c4 in osgUtil::RenderStage::draw (this=0xb6761520,
[EMAIL PROTECTED], [EMAIL PROTECTED])
at /home/paul/c/osg-svn/src/osgUtil/RenderStage.cpp:913
#12 0x0057b57e in osgUtil::RenderStage::drawPostRenderStages
(this=0x87e2a08, [EMAIL PROTECTED], [EMAIL PROTECTED])
at /home/paul/c/osg-svn/src/osgUtil/RenderStage.cpp:1069
#13 0x0058343d in osgUtil::RenderStage::draw (this=0x87e2a08,
[EMAIL PROTECTED], [EMAIL PROTECTED])
at /home/paul/c/osg-svn/src/osgUtil/RenderStage.cpp:979
#14 0x00597db3 in osgUtil::SceneView::draw (this=0x87e1c78) at
/home/paul/c/osg-svn/src/osgUtil/SceneView.cpp:1456
#15 0x00c28551 in osgViewer::Renderer::draw (this=0x87e1ab8) at
/home/paul/c/osg-svn/src/osgViewer/Renderer.cpp:382
#16 0x00c299e9 in osgViewer::Renderer::operator() (this=0x87e1ab8,
context=0x8800da8)
at /home/paul/c/osg-svn/src/osgViewer/Renderer.cpp:571
#17 0x0035035f in osg::GraphicsContext::runOperations (this=0x8800da8)
at /home/paul/c/osg-svn/src/osg/GraphicsContext.cpp:670
#18 0x0035356b in osg::RunOperations::operator() (this=0x88a6140,
context=0x8800da8) at /home/paul/c/osg-svn/src/osg/GraphicsThread.cpp:133
#19 0x0035340a in osg::GraphicsOperation::operator() (this=0x88a6140,
object=0x8800da8)
at /home/paul/c/osg-svn/src/osg/GraphicsThread.cpp:50
#20 0x00379a82 in osg::OperationThread::run (this=0x88a5ec8) at
/home/paul/c/osg-svn/src/osg/OperationThread.cpp:413
#21 0x0035363a in osg::GraphicsThread::run (this=0x88a5ec8) at
/home/paul/c/osg-svn/src/osg/GraphicsThread.cpp:38
#22 0x00dbf846 in OpenThreads::ThreadPrivateActions::StartThread
(data=0x88a5ed8)
at /home/paul/c/osg-svn/src/OpenThreads/pthreads/PThread.c++:160
#23 0x009b3bd4 in start_thread () from /lib/libpthread.so.0
#24 0x00b134fe in clone () from /lib/libc.so.6
Paul
Gert van Maren wrote:
Hi guys,
Still getting crashes on dual core machines in osg21-osgTextd.dll /
osg21-osgd.dll (with 2.1.10 (also 2.1.9)). It seems to do with the
osgdb_freetyped.dll because when we disable all osgText in our app -
the osgdb_freetyped.dll does not get loaded hence no crashes. If I
disable dual core in the bios, I can have text - no crashes.
So when running dual core - still osgText crashes.
below: the 'windows' output for 2 crashes and I have attached a call
stack as well.
'v3_viewerd.exe': Loaded
'D:\OpenSceneGraph-2.1.10\OpenSceneGraph\bin\osgplugins-2.1.10\osgdb_freetyped.dll',
Symbols loaded.
First-chance exception at 0x00cd1161 (osg21-osgTextd.dll) in
v3_viewerd.exe: 0xC005: Access violation reading location 0x.
First-chance exception at 0x7c812a5b in v3_viewerd.exe: Microsoft C++
exception: [rethrow] @ 0x.
'v3_viewerd.exe': Loaded
'D:\OpenSceneGraph-2.1.10\OpenSceneGraph\bin\osgplugins-2.1.10\osgdb_freetyped.dll',
Re: [osg-users] osgShadow::ShadowMap adding some polish
Hi Mihai,
I'm currently very busy, so only skimming osg-users, and as a
consequence finding it difficult to dive into complex topics.
General comments:
osgShadow is still in its infancy so comments/suggestions for improvements
are very welcome.
Support for perspective shadow maps is really needed, and the
osgSim::OverlayNode provides some of the required code and a proof of
concept on the OSG side. Perspective shadow maps might diminish the need
to manually specifying the center of shadow.
W.r.t tracking of lights, it was my intention that the lights in the
subgraph would
be tracked by allowing the cull traversal to go collect them, then as a post
process in the ShadowTechnique use these settings. This keeps things loose
coupled and means that you don't need to add any extra mechanism to do
this tracking.
When posting files, making sure they aren't inlined, such as by
zipping them or
adjusting your mail tool as its not practical to review inline source files.
Robert.
On 9/13/07, Mihai Radu [EMAIL PROTECTED] wrote:
Hi Robert,
I'm working now on integrating the new osgViewer and osg 2.x into the
simulator of our company, and as a result I am moving to using
osgShadow::ShadowMap in place of the old code that I refactored to use
with osg 1.2, before the first iterations of the NodeKit.
I will extend the osg class to integrate with the company's physics and
viewer, and I am trying to keep to a minimum the overlap between the osg
code and the derived class.
Therefore there are a couple of things that seem simpler to change or
add-in to osgShadow::ShadowMap, and this way the class gets some
additions, if they are warranted.
As an example I added functions to get/set a Vec2 for the x/y size of
the depth texture used. (I attached the changed files)
There are three other points that I will need to work with:
1. updating the camera TexGen during cull()
One part here is to change the way the light is selected, one option
is to keep a reference to the intended osg::Light, the current code will
use the last light in the list of the RenderStage.
Another is to set a different ways to update, the current way is to
use the bounding box of the entire scene. Another style that I found
useful is to use a given reference point and radius, for example so that
the shadows can follow a vehicle without losing resolution as it moves
about a terrain, or use the parameters of a given SpotLight.
I see that ShadowTechnique defines ShadowTechnique::CameraCullCallback,
but I did not see if it is ever used, is it intended for this kind of
usage ? Then what would be the best way of using it ?
2. custom GLSL shaders
Need to be able to set / get custom programs for rendering the
scene. I can see this done by either passing an std::string for
vertex/fragment shaders, or by passing osg::Shader/Program.
3. Uniform variables for controlling rendering
I suggest to have a set of standard uniforms ( a standard name like
for the other ones used by osg ) to help with implementation of custom
shaders. The values that are immediately needed are baseTexture,
shadowTexture, ambientBias, and the texture unit used for shadowing
coordinates, to access the appropriate gl_TexCoord[].
When using the nodekit on complex scenes with multiple lights, that
can be enabled/disabled at run-time, I found that I needed to also use a
uniform to disable shadow application when the shadow casting light is
turned off, this can also be used on a per-object basis to turn off
application of shadows on some parts of the scene. The GL number of the
shadow-casting light is another important value when a different light
is used to cast shadows.
I'm eager to get your opinion on this.
Cheers
Mihai Radu
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield
*
* This library is open source and may be redistributed and/or modified under
* the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or
* (at your option) any later version. The full license is in LICENSE file
* included with this distribution, and on the openscenegraph.org website.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* OpenSceneGraph Public License for more details.
*/
#include osgShadow/ShadowMap
#include osgShadow/ShadowedScene
#include osg/Notify
#include osg/ComputeBoundsVisitor
#include osg/PolygonOffset
#include osg/CullFace
#include osg/io_utils
using namespace osgShadow;
//
// fragment shader
//
static const char fragmentShaderSource_noBaseTexture[] =
uniform sampler2DShadow shadowTexture; \n
uniform vec2 ambientBias; \n
\n
void main(void) \n
{ \n
gl_FragColor = gl_Color *
Re: [osg-users] getProjectionRectangle
Hi CG, The core OSG uses osg::Viewport rather than ProjectionRectangle, Viewport is a direct mapping to OpenGL's glViewport. You can get the Viewport from the Camera i.e. viewer.getCamera()-getViewport(); The ProjectionRectangle is really just a viewport, but Don decided he didn't like the use of the word viewport for glViewport and that ProjectionRectangle was somehow more intuitive. The core OSG by contrast follows OpenGL naming. Robert. On 9/14/07, #POH CHENG GUAN# [EMAIL PROTECTED] wrote: Hi, In version 1.2, I used the Producer's function: getProjectionRectangle to get my projected x, y, width and height for picking purpose. In version 2, how do I get the projected x, y, width and height? Regards, CG ___ 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] OSG 2.1.10 crash in osgText / osgdb_freetyped
Hi Gert, Is this in your own application or one of the OSG examples? Are you creating text and then updating per frame? Are you running osgViewer multi-threaded? If so which threading model? One possibility is that the new DrawThreadPerContext threaded model is overlapping the drawing of the text with any updating of the text. The way to prevent problems like this is to explictly set the data variance on the text to DYNAMIC so that the draw traversal knows to hold back the next frame till all the dynamic objects have been dispatched. You can ensure this via: myText-setDataVariance(osg::Object::DYNAMIC); Robert. On 9/14/07, Gert van Maren [EMAIL PROTECTED] wrote: Hi guys, Still getting crashes on dual core machines in osg21-osgTextd.dll / osg21-osgd.dll (with 2.1.10 (also 2.1.9)). It seems to do with the osgdb_freetyped.dll because when we disable all osgText in our app - the osgdb_freetyped.dll does not get loaded hence no crashes. If I disable dual core in the bios, I can have text - no crashes. So when running dual core - still osgText crashes. below: the 'windows' output for 2 crashes and I have attached a call stack as well. 'v3_viewerd.exe': Loaded 'D:\OpenSceneGraph-2.1.10\OpenSceneGraph\bin\osgplugins-2.1.10\osgdb_freetyped.dll', Symbols loaded. First-chance exception at 0x00cd1161 (osg21-osgTextd.dll) in v3_viewerd.exe: 0xC005: Access violation reading location 0x. First-chance exception at 0x7c812a5b in v3_viewerd.exe: Microsoft C++ exception: [rethrow] @ 0x. 'v3_viewerd.exe': Loaded 'D:\OpenSceneGraph-2.1.10\OpenSceneGraph\bin\osgplugins-2.1.10\osgdb_freetyped.dll', Symbols loaded. First-chance exception at 0x008b4232 (osg21-osgd.dll) in v3_viewerd.exe: 0xC005: Access violation reading location 0x0006. Hopefully this points to the bug. Gert -- Gert van Maren Head of Research Development K2Vi Virtual Reality Software Data Interface Technologies Ltd Phone: +64 21 2855581 Email: [EMAIL PROTECTED] Web: http://www.k2vi.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] OSG 2.1.10 crash in osgText / osgdb_freetyped
Hi Paul,
This might well be the same issue. I have added the line
_hudText-setDataVariance(osg::Object::DYNAMIC);
In the contruction of the text in the osgdepthpeeling example and
checked this in. Could you do a svn update and let me know if it
fixes it.
Robert.
On 9/14/07, Paul Melis [EMAIL PROTECTED] wrote:
Hi Gert,
(ever been Dutch? ;-))
The top of the stack trace you attached looks an awful lot like the one
I get in the osgdepthpeeling example (both point to
osgText::Text::computePositions() as the point where things go hayward):
(gdb) bt
#0 0x0032c4e2 in std::vectorosg::Vec3f, std::allocatorosg::Vec3f
::_M_fill_insert (this=0xb673ace0, __position=
{_M_current = 0xb672bbb0}, __n=396, [EMAIL PROTECTED])
at
/usr/lib/gcc/i386-redhat-linux/4.0.2/../../../../include/c++/4.0.2/bits/stl_construct.h:81
#1 0x0071d81e in osgText::Text::computePositions (this=0xb6705bf0,
contextID=0)
at
/usr/lib/gcc/i386-redhat-linux/4.0.2/../../../../include/c++/4.0.2/bits/stl_vector.h:658
#2 0x00722515 in osgText::Text::drawImplementation (this=0xb6705bf0,
[EMAIL PROTECTED], [EMAIL PROTECTED])
at /home/paul/c/osg-svn/src/osgText/Text.cpp:1545
#3 0x00722f29 in osgText::Text::drawImplementation (this=0xb6705bf0,
[EMAIL PROTECTED])
at /home/paul/c/osg-svn/src/osgText/Text.cpp:1470
#4 0x0057a4a7 in osgUtil::RenderLeaf::render (this=0xb6727e88,
[EMAIL PROTECTED], previous=0x0)
at /home/paul/c/osg-svn/include/osg/Drawable:868
#5 0x00571157 in osgUtil::RenderBin::drawImplementation
(this=0xb6761760, [EMAIL PROTECTED], [EMAIL PROTECTED])
at /home/paul/c/osg-svn/src/osgUtil/RenderBin.cpp:408
#6 0x00570d95 in osgUtil::RenderBin::draw (this=0xb6761760,
[EMAIL PROTECTED], [EMAIL PROTECTED])
at /home/paul/c/osg-svn/src/osgUtil/RenderBin.cpp:373
#7 0x005711e7 in osgUtil::RenderBin::drawImplementation
(this=0xb6761520, [EMAIL PROTECTED], [EMAIL PROTECTED])
at /home/paul/c/osg-svn/src/osgUtil/RenderBin.cpp:458
#8 0x00583bdd in osgUtil::RenderStage::drawImplementation
(this=0xb6761520, [EMAIL PROTECTED], [EMAIL PROTECTED])
at /home/paul/c/osg-svn/src/osgUtil/RenderStage.cpp:1051
#9 0x00570d95 in osgUtil::RenderBin::draw (this=0xb6761520,
[EMAIL PROTECTED], [EMAIL PROTECTED])
at /home/paul/c/osg-svn/src/osgUtil/RenderBin.cpp:373
#10 0x005841c1 in osgUtil::RenderStage::drawInner (this=0xb6761520,
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED])
at /home/paul/c/osg-svn/src/osgUtil/RenderStage.cpp:719
#11 0x005835c4 in osgUtil::RenderStage::draw (this=0xb6761520,
[EMAIL PROTECTED], [EMAIL PROTECTED])
at /home/paul/c/osg-svn/src/osgUtil/RenderStage.cpp:913
#12 0x0057b57e in osgUtil::RenderStage::drawPostRenderStages
(this=0x87e2a08, [EMAIL PROTECTED], [EMAIL PROTECTED])
at /home/paul/c/osg-svn/src/osgUtil/RenderStage.cpp:1069
#13 0x0058343d in osgUtil::RenderStage::draw (this=0x87e2a08,
[EMAIL PROTECTED], [EMAIL PROTECTED])
at /home/paul/c/osg-svn/src/osgUtil/RenderStage.cpp:979
#14 0x00597db3 in osgUtil::SceneView::draw (this=0x87e1c78) at
/home/paul/c/osg-svn/src/osgUtil/SceneView.cpp:1456
#15 0x00c28551 in osgViewer::Renderer::draw (this=0x87e1ab8) at
/home/paul/c/osg-svn/src/osgViewer/Renderer.cpp:382
#16 0x00c299e9 in osgViewer::Renderer::operator() (this=0x87e1ab8,
context=0x8800da8)
at /home/paul/c/osg-svn/src/osgViewer/Renderer.cpp:571
#17 0x0035035f in osg::GraphicsContext::runOperations (this=0x8800da8)
at /home/paul/c/osg-svn/src/osg/GraphicsContext.cpp:670
#18 0x0035356b in osg::RunOperations::operator() (this=0x88a6140,
context=0x8800da8) at /home/paul/c/osg-svn/src/osg/GraphicsThread.cpp:133
#19 0x0035340a in osg::GraphicsOperation::operator() (this=0x88a6140,
object=0x8800da8)
at /home/paul/c/osg-svn/src/osg/GraphicsThread.cpp:50
#20 0x00379a82 in osg::OperationThread::run (this=0x88a5ec8) at
/home/paul/c/osg-svn/src/osg/OperationThread.cpp:413
#21 0x0035363a in osg::GraphicsThread::run (this=0x88a5ec8) at
/home/paul/c/osg-svn/src/osg/GraphicsThread.cpp:38
#22 0x00dbf846 in OpenThreads::ThreadPrivateActions::StartThread
(data=0x88a5ed8)
at /home/paul/c/osg-svn/src/OpenThreads/pthreads/PThread.c++:160
#23 0x009b3bd4 in start_thread () from /lib/libpthread.so.0
#24 0x00b134fe in clone () from /lib/libc.so.6
Paul
Gert van Maren wrote:
Hi guys,
Still getting crashes on dual core machines in osg21-osgTextd.dll /
osg21-osgd.dll (with 2.1.10 (also 2.1.9)). It seems to do with the
osgdb_freetyped.dll because when we disable all osgText in our app -
the osgdb_freetyped.dll does not get loaded hence no crashes. If I
disable dual core in the bios, I can have text - no crashes.
So when running dual core - still osgText crashes.
below: the 'windows' output for 2 crashes and I have attached a call
stack as well.
'v3_viewerd.exe': Loaded
'D:\OpenSceneGraph-2.1.10\OpenSceneGraph\bin\osgplugins-2.1.10\osgdb_freetyped.dll',
Symbols
Re: [osg-users] OSG 2.1.10 windows refresh / performance
On 9/14/07, Robert Osfield [EMAIL PROTECTED] wrote: Hi Gert, On 9/14/07, Gert van Maren [EMAIL PROTECTED] wrote: With 2.1.10 (and 2.1.9/8 as well) my windows taskbar does not refresh after I go from fullscreen osgviewer to windowed. I need to kill osgviewer to get a refresh. Anybody else have these issues? We have it on ATI as well as Nvidia cards. I haven't heard of this problem before. Do others see it as well? Actually I have this problem for a long time now (It started when I migrated from osg 1.2 to osg 2.0). But the majority of my apps work windowed, that's why I see it only when I use osgviewer. -- Serge Lages http://www.magrathea-engine.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG 2.1.10 crash in osgText / osgdb_freetyped
Robert Osfield wrote:
This might well be the same issue. I have added the line
_hudText-setDataVariance(osg::Object::DYNAMIC);
In the contruction of the text in the osgdepthpeeling example and
checked this in. Could you do a svn update and let me know if it
fixes it.
Yup, that seems to do the trick, no segfaults anymore. The example seems
to use one or more OpenGL extensions that I don't have, but that's
another story...
Paul
Robert.
On 9/14/07, Paul Melis [EMAIL PROTECTED] wrote:
Hi Gert,
(ever been Dutch? ;-))
The top of the stack trace you attached looks an awful lot like the one
I get in the osgdepthpeeling example (both point to
osgText::Text::computePositions() as the point where things go hayward):
(gdb) bt
#0 0x0032c4e2 in std::vectorosg::Vec3f, std::allocatorosg::Vec3f
::_M_fill_insert (this=0xb673ace0, __position=
{_M_current = 0xb672bbb0}, __n=396, [EMAIL PROTECTED])
at
/usr/lib/gcc/i386-redhat-linux/4.0.2/../../../../include/c++/4.0.2/bits/stl_construct.h:81
#1 0x0071d81e in osgText::Text::computePositions (this=0xb6705bf0,
contextID=0)
at
/usr/lib/gcc/i386-redhat-linux/4.0.2/../../../../include/c++/4.0.2/bits/stl_vector.h:658
#2 0x00722515 in osgText::Text::drawImplementation (this=0xb6705bf0,
[EMAIL PROTECTED], [EMAIL PROTECTED])
at /home/paul/c/osg-svn/src/osgText/Text.cpp:1545
#3 0x00722f29 in osgText::Text::drawImplementation (this=0xb6705bf0,
[EMAIL PROTECTED])
at /home/paul/c/osg-svn/src/osgText/Text.cpp:1470
#4 0x0057a4a7 in osgUtil::RenderLeaf::render (this=0xb6727e88,
[EMAIL PROTECTED], previous=0x0)
at /home/paul/c/osg-svn/include/osg/Drawable:868
#5 0x00571157 in osgUtil::RenderBin::drawImplementation
(this=0xb6761760, [EMAIL PROTECTED], [EMAIL PROTECTED])
at /home/paul/c/osg-svn/src/osgUtil/RenderBin.cpp:408
#6 0x00570d95 in osgUtil::RenderBin::draw (this=0xb6761760,
[EMAIL PROTECTED], [EMAIL PROTECTED])
at /home/paul/c/osg-svn/src/osgUtil/RenderBin.cpp:373
#7 0x005711e7 in osgUtil::RenderBin::drawImplementation
(this=0xb6761520, [EMAIL PROTECTED], [EMAIL PROTECTED])
at /home/paul/c/osg-svn/src/osgUtil/RenderBin.cpp:458
#8 0x00583bdd in osgUtil::RenderStage::drawImplementation
(this=0xb6761520, [EMAIL PROTECTED], [EMAIL PROTECTED])
at /home/paul/c/osg-svn/src/osgUtil/RenderStage.cpp:1051
#9 0x00570d95 in osgUtil::RenderBin::draw (this=0xb6761520,
[EMAIL PROTECTED], [EMAIL PROTECTED])
at /home/paul/c/osg-svn/src/osgUtil/RenderBin.cpp:373
#10 0x005841c1 in osgUtil::RenderStage::drawInner (this=0xb6761520,
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED])
at /home/paul/c/osg-svn/src/osgUtil/RenderStage.cpp:719
#11 0x005835c4 in osgUtil::RenderStage::draw (this=0xb6761520,
[EMAIL PROTECTED], [EMAIL PROTECTED])
at /home/paul/c/osg-svn/src/osgUtil/RenderStage.cpp:913
#12 0x0057b57e in osgUtil::RenderStage::drawPostRenderStages
(this=0x87e2a08, [EMAIL PROTECTED], [EMAIL PROTECTED])
at /home/paul/c/osg-svn/src/osgUtil/RenderStage.cpp:1069
#13 0x0058343d in osgUtil::RenderStage::draw (this=0x87e2a08,
[EMAIL PROTECTED], [EMAIL PROTECTED])
at /home/paul/c/osg-svn/src/osgUtil/RenderStage.cpp:979
#14 0x00597db3 in osgUtil::SceneView::draw (this=0x87e1c78) at
/home/paul/c/osg-svn/src/osgUtil/SceneView.cpp:1456
#15 0x00c28551 in osgViewer::Renderer::draw (this=0x87e1ab8) at
/home/paul/c/osg-svn/src/osgViewer/Renderer.cpp:382
#16 0x00c299e9 in osgViewer::Renderer::operator() (this=0x87e1ab8,
context=0x8800da8)
at /home/paul/c/osg-svn/src/osgViewer/Renderer.cpp:571
#17 0x0035035f in osg::GraphicsContext::runOperations (this=0x8800da8)
at /home/paul/c/osg-svn/src/osg/GraphicsContext.cpp:670
#18 0x0035356b in osg::RunOperations::operator() (this=0x88a6140,
context=0x8800da8) at /home/paul/c/osg-svn/src/osg/GraphicsThread.cpp:133
#19 0x0035340a in osg::GraphicsOperation::operator() (this=0x88a6140,
object=0x8800da8)
at /home/paul/c/osg-svn/src/osg/GraphicsThread.cpp:50
#20 0x00379a82 in osg::OperationThread::run (this=0x88a5ec8) at
/home/paul/c/osg-svn/src/osg/OperationThread.cpp:413
#21 0x0035363a in osg::GraphicsThread::run (this=0x88a5ec8) at
/home/paul/c/osg-svn/src/osg/GraphicsThread.cpp:38
#22 0x00dbf846 in OpenThreads::ThreadPrivateActions::StartThread
(data=0x88a5ed8)
at /home/paul/c/osg-svn/src/OpenThreads/pthreads/PThread.c++:160
#23 0x009b3bd4 in start_thread () from /lib/libpthread.so.0
#24 0x00b134fe in clone () from /lib/libc.so.6
Paul
Gert van Maren wrote:
Hi guys,
Still getting crashes on dual core machines in osg21-osgTextd.dll /
osg21-osgd.dll (with 2.1.10 (also 2.1.9)). It seems to do with the
osgdb_freetyped.dll because when we disable all osgText in our app -
the osgdb_freetyped.dll does not get loaded hence no crashes. If I
disable dual core in the bios, I can have text - no crashes.
So when running dual core - still osgText crashes.
below: the 'windows' output for 2 crashes and I have attached a call
stack as well.
'v3_viewerd.exe': Loaded
[osg-users] Multiple render targets
Hi,
is there anything else I need to do to render to two textures with the same
fragment shader? I have the following code:
cam-setRenderTargetImplementation(Camera::FRAME_BUFFER_OBJECT);
cam-attach(Camera::COLOR_BUFFER0, _texture.get());
cam-attach(Camera::COLOR_BUFFER1, _texture2.get());
And the following fragment shader:
void main(void)
{
gl_FragData[0] = vec4(1.0, 0.0, 0.0, 1.0);
gl_FragData[1] = vec4(0.4, 0.4, 0.0, 1.0);
}
The first texture comes out red as expected, but the second one (which is
identical in size and format as the first) comes out black.
-J
__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple render targets
Hi,
as far as I know its not supported in current version of OSG, there is
no call to glDrawBuffers (as opposed to glDrawBuffer) which is needed
for MRT.
I have a version of RenderStage.cpp that I modified to allow MRT for one
of our projects, but its a hack and I still need to properly organise it
before I can submit a patch.
I can post it with instructions if you want it?
regards
jp
John Donovan wrote:
Hi,
is there anything else I need to do to render to two textures with the same
fragment shader? I have the following code:
cam-setRenderTargetImplementation(Camera::FRAME_BUFFER_OBJECT);
cam-attach(Camera::COLOR_BUFFER0, _texture.get());
cam-attach(Camera::COLOR_BUFFER1, _texture2.get());
And the following fragment shader:
void main(void)
{
gl_FragData[0] = vec4(1.0, 0.0, 0.0, 1.0);
gl_FragData[1] = vec4(0.4, 0.4, 0.0, 1.0);
}
The first texture comes out red as expected, but the second one (which is
identical in size and format as the first) comes out black.
-J
__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__
___
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] Multiple render targets
Ah! That'd explain it :) Thanks JP.
It would be handy to have a look at what you've done; perhaps we can both faff
about with it to make it submittable.
-J
J.P. Delport wrote:
Hi,
as far as I know its not supported in current version of OSG, there is
no call to glDrawBuffers (as opposed to glDrawBuffer) which is needed
for MRT.
I have a version of RenderStage.cpp that I modified to allow MRT for one
of our projects, but its a hack and I still need to properly organise it
before I can submit a patch.
I can post it with instructions if you want it?
regards
jp
John Donovan wrote:
Hi,
is there anything else I need to do to render to two textures with the same
fragment shader? I have the following code:
cam-setRenderTargetImplementation(Camera::FRAME_BUFFER_OBJECT);
cam-attach(Camera::COLOR_BUFFER0, _texture.get());
cam-attach(Camera::COLOR_BUFFER1, _texture2.get());
And the following fragment shader:
void main(void)
{
gl_FragData[0] = vec4(1.0, 0.0, 0.0, 1.0);
gl_FragData[1] = vec4(0.4, 0.4, 0.0, 1.0);
}
The first texture comes out red as expected, but the second one (which is
identical in size and format as the first) comes out black.
-J
__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
__
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Depth Buffer max and min values?
Thanks! the example was very helpful. Now I render depth buffer to the osg::Image, but there are not real depth values in the depth buffer image, Depth values are projected between [0.0, 1.0]. I projected the values of the texture, between max and min values of pixels in the whole texture, and got nice gray picture of depth buffer. How can I get real depth values? Is there any factors, which camera use to compute depth buffer? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marcus Fritzen Sent: Friday, September 14, 2007 8:52 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Depth Buffer max and min values? Look at the osgShadow::ShadowMaps class ;) zarrandreas wrote: Oh cool. Is there a good example for rendering depth buffer to a texture with osg::CameraNode? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marcus Fritzen Sent: Thursday, September 13, 2007 5:42 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Depth Buffer max and min values? Hi, as far as I know these values are real depth values and not in range [0,1]. --marcus zarrandreas wrote: Hi, If I use osg::CameraNode to render DepthBuffer, what kind of values is then in Depth Buffer? Is that float values between [0, 1.0] or real depth values? ___ 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 ___ 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] Multiple render targets
J.P. Delport wrote: Hi, OK, here goes. Thanks JP, that worked a treat! We need some mechanism to store/assign more than one drawbuffer inside camera and possibly a flag to indicate we want MRT. RenderStage can then inherit/query these values to properly call glDrawBuffer(s). Yeah, I can see it's a bit hacky, but not as bad as I was expecting! Robert, do you have any plans for doing MRT stuff, or are you happy with JP and me to come up with something workable and submit it? The changes JP has made are fairly trivial, so it wouldn't take much to make it more robust. If you have time, give it a bash. I won't have time to look any deeper until next week, but it does at least work :) -JD __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple render targets
On 9/14/07, John Donovan [EMAIL PROTECTED] wrote: Robert, do you have any plans for doing MRT stuff, or are you happy with JP and me to come up with something workable and submit it? The changes JP has made are fairly trivial, so it wouldn't take much to make it more robust. Send me a patch and I'll review it. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG 2.1.10 windows refresh / performance
Hello Robert, Gert, With 2.1.10 (and 2.1.9/8 as well) my windows taskbar does not refresh after I go from fullscreen osgviewer to windowed. I need to kill osgviewer to get a refresh. Anybody else have these issues? We have it on ATI as well as Nvidia cards. I haven't heard of this problem before. Do others see it as well? I'm on Windows XP as well, and hadn't seen it before, but now I've just tried it and it does indeed happen. It's very weird, I don't recall any other graphics apps ever having this behavior. I would have no idea where to look to fix it though, perhaps someone well-versed in Win32 programming would have an idea? I haven't yet worked out how to make CMake by itself default to selecting Release build. Under unices you can use the configure script which simple does: cmake . -DCMAKE_BUILD_TYPE=Release On Windows, when building in MSVC, just selecting Release at the top and then building will build the release version. That's one difference between Linux and Windows, no need to re-run CMake to select release or debug, as both are included in the generated project files and you can just switch in Visual Studio. Its absolutely essential to make a release build before doing any benchmarking as it makes a massive difference to performance. Absolutely. J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Instrument Panel rendering - interest? ideas?
Greetings, Over the last couple years we've worked on a few OSG/Delta3D projects that have included a rendered instrument panel. We have a pretty decent solution that currently hangs out as a Delta3D utility (dtUtil). Since it's mostly OSG code we're wondering if it wouldn't make more sense to make this an osg thing. So the questions are: Would this sort of application be useful for others? Is there enough interest and ability to support as part of OSG? What would be the right way to go - build as a plugin? Thanks! Joe S. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Instrument Panel rendering - interest? ideas?
Hi Joe, There are certainly a number of projects which would benefit from NodeKit that provides an rendered instrument panel. I'm not sure if its generally useful enough to make it into the core OSG, but it could certainly become part of the family and perhaps hosted on the osgforge alongside VirtualPlanetBuilder, osgLua etc. Robert. On 9/14/07, Sullivan, Joseph (CDR) [EMAIL PROTECTED] wrote: Greetings, Over the last couple years we've worked on a few OSG/Delta3D projects that have included a rendered instrument panel. We have a pretty decent solution that currently hangs out as a Delta3D utility (dtUtil). Since it's mostly OSG code we're wondering if it wouldn't make more sense to make this an osg thing. So the questions are: Would this sort of application be useful for others? Is there enough interest and ability to support as part of OSG? What would be the right way to go - build as a plugin? Thanks! Joe S. ___ 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] osgPlugins directory name
Small point here, but I'm hoping to make sure it is settled. I do the build, but not install, steps on multiple platforms. For the windows build, the plugins are in a directory named osgplugins-2.1.10. For linux, they're in osgPlugins-2.1.10. This may not matter on Windows, but it seems they should be the same. Right? andy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] probs running OSG on non-dev system?
Pardon the sparse details, had a problem in wee hours this morn... Built a 2.1.10-ish OSG on one system w/ winxppro/vs8, tried to run the resulting osgviewer on a different system w/ winxphome but no VS8 installed. I got entirely unhelpful errormsgs/dialogs along the lines of that application cant be run or trying reinstalling the app. The VS8 runtime libs were present on the non-VS8 system Does this ring any bells? Could the VS8 or Cmake ocnfigs be triggering some OS or binary dependency? Thanks -- mew Mike Weiblen -- Zebra Imaging -- Austin Texas USA -- http://www.zebraimaging.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Instrument Panel rendering - interest? ideas?
Our group would GREATLY appreciate access to something like this in osg. We have tried many different approaches to a gauge/panel solution but have not found anything effective, especially in a vr environment (cave,powerwall). An osg nodekit to handle gauges/panels directly sounds like a good idea to me. Just my 2 cents! biv On 9/14/07, Robert Osfield [EMAIL PROTECTED] wrote: Hi Joe, There are certainly a number of projects which would benefit from NodeKit that provides an rendered instrument panel. I'm not sure if its generally useful enough to make it into the core OSG, but it could certainly become part of the family and perhaps hosted on the osgforge alongside VirtualPlanetBuilder, osgLua etc. Robert. On 9/14/07, Sullivan, Joseph (CDR) [EMAIL PROTECTED] wrote: Greetings, Over the last couple years we've worked on a few OSG/Delta3D projects that have included a rendered instrument panel. We have a pretty decent solution that currently hangs out as a Delta3D utility (dtUtil). Since it's mostly OSG code we're wondering if it wouldn't make more sense to make this an osg thing. So the questions are: Would this sort of application be useful for others? Is there enough interest and ability to support as part of OSG? What would be the right way to go - build as a plugin? Thanks! Joe S. ___ 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] probs running OSG on non-dev system?
On 9/14/07, Mike Weiblen [EMAIL PROTECTED] wrote: Pardon the sparse details, had a problem in wee hours this morn... Built a 2.1.10-ish OSG on one system w/ winxppro/vs8, tried to run the resulting osgviewer on a different system w/ winxphome but no VS8 installed. I got entirely unhelpful errormsgs/dialogs along the lines of that application cant be run or trying reinstalling the app. The VS8 runtime libs were present on the non-VS8 system Does this ring any bells? Could the VS8 or Cmake ocnfigs be triggering some OS or binary dependency? Hi, Are you sure that the redistributable package you have installed in the non-VS8 system correspond to the VS you use to build the application ? If you use VS8 SP1 make sure you use the updated run time libs for it. -- Serge Lages http://www.magrathea-engine.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] PSSM: Latest Version : Please Test and Debug
hi, i will post the first version of the PSSM for a sun as directional lights. Please help in test, debug, and optimisation, than we can integrate it into OSG core, i would like doing this as soon as possible. call in a console... PSSM --help example PSSM.exe dumptruck.osg --noUpdate --mapcount 3 PSSM.exe dumptruck.osg --noUpdate --mapcount 3 --NO-DEBUG * we need a better GLSL shader ! My version isn't yet good enough (and robust) * i guess there is still a little bug, the near-far clipping plane for the each camera (shadow) * ... others thanks for help / adrian -- Adrian Egli PSSM.rar Description: application/rar ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Instrument Panel rendering - interest? ideas?
Something that would fill the needs of aircraft/vehicle controls display, but also be flexible enough for general information display, would be quite useful. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] I still have 2 build issues (unices)
In my now broken mac build: [ 21%] Building CXX object src/osgUtil/CMakeFiles/osgUtil.dir/ Tessellator.o /usr/bin/c++ -DosgUtil_EXPORTS -arch ppc -arch i386 -isysroot / Developer/SDKs/MacOSX10.4u.sdk -mmacosx-version-min=10.4 -ftree- vectorize -fvisibility-inlines-hidden -O3 -DNDEBUG -fPIC -I/Volumes/ viz/OpenSceneGraph/include -F/System/Library/Frameworks - DOSGUTIL_LIBRARY -o src/osgUtil/CMakeFiles/osgUtil.dir/Tessellator.o - c /Volumes/viz/OpenSceneGraph/src/osgUtil/Tessellator.cpp /Volumes/viz/OpenSceneGraph/src/osgUtil/Tessellator.cpp: In member function 'void osgUtil::Tessellator::beginTessellation()': /Volumes/viz/OpenSceneGraph/src/osgUtil/Tessellator.cpp:44: error: invalid conversion from 'GLvoid (*)(...)' to 'GLvoid (*)()' from CMakeCache.txt: //Include for OpenGL on OSX OPENGL_INCLUDE_DIR:PATH=/System/Library/Frameworks/OpenGL.framework //OpenGL lib for OSX OPENGL_gl_LIBRARY:FILEPATH=/System/Library/Frameworks/OpenGL.framework //AGL lib for OSX OPENGL_glu_LIBRARY:FILEPATH=/System/Library/Frameworks/AGL.framework very confusing why sometimes it builds, other times not... environment vars messed up? OSG_DIR=/Volumes/viz//OpenSceneGraph/osg-darwinIntel GDAL_DIR=/Volumes/viz//gdal-1.4.2/RELEASES/darwinIntel ml On Sep 14, 2007, at 2:14 AM, Robert Osfield wrote: On 9/14/07, Mike Logan [EMAIL PROTECTED] wrote: Ok, so its seems to be just macs then. Linux dependencies seem fine. Maybe my problem is related to the previous thread on Tessellator and Mac builds.. CMake must be picking up on the OpenGL framework rather the GLX version of gl.h, or perhaps its the other way around, its assume the OpenGL framework version bit getting the GLX gl.h version. /Volumes/viz/OpenSceneGraph/src/osgUtil/Tessellator.cpp: In member function 'void osgUtil::Tessellator::beginTessellation()': /Volumes/viz/OpenSceneGraph/src/osgUtil/Tessellator.cpp:44: error: invalid conversion from 'GLvoid (*)(...)' to 'GLvoid (*)()' From this I can't work out which way around it it your case. In ccmake .. could you have a look at which verision of OpenGL it's using? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users- openscenegraph.org Michael Logan Perot Systems Govt. Services / NASA Ames Res. Ctr. Task Lead / Visual Cueing Simulation Visualization Engineer / Adaptive Control Technologies MS 269-1, Moffett Field, CA, 94035 (650)-604-4494 If you want to start a revolution, don't pick up a gun. Do it with science and technology. - Stanford R. Ovshinsky ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Instrument Panel rendering - interest? ideas?
Hello Joseph, I have been putting off doing this myself. I need speedometer, RPM, and compass gauges to display onscreen. My plan was to make them just another 3D model that sit in their own HUD. How does the Delta3D one work? I know it would be difficult to encapsulate this sort of thing because each instrument panel has different properties. So how do you define the interface to the instrument panel node? Thanks. _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sullivan, Joseph (CDR) Sent: Friday, September 14, 2007 10:42 AM To: osg-users@lists.openscenegraph.org Subject: [osg-users] Instrument Panel rendering - interest? ideas? Greetings, Over the last couple years we've worked on a few OSG/Delta3D projects that have included a rendered instrument panel. We have a pretty decent solution that currently hangs out as a Delta3D utility (dtUtil). Since it's mostly OSG code we're wondering if it wouldn't make more sense to make this an osg thing. So the questions are: Would this sort of application be useful for others? Is there enough interest and ability to support as part of OSG? What would be the right way to go - build as a plugin? Thanks! Joe S. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgPlugins directory name
Hi Andy, Yes they should be the same, I've just done a serach for osgplugins in the OSG and can't find any - its all osgPlugins, this makes me wonder where the difference is coming from perhaps VS itself it doing it... Robert. On 9/14/07, Andy Skinner [EMAIL PROTECTED] wrote: Small point here, but I'm hoping to make sure it is settled. I do the build, but not install, steps on multiple platforms. For the windows build, the plugins are in a directory named osgplugins-2.1.10. For linux, they're in osgPlugins-2.1.10. This may not matter on Windows, but it seems they should be the same. Right? andy ___ 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] probs running OSG on non-dev system?
Hi Mike, My bells rang: Include a manifest. For DLL's: mt -manifest test.dll.manifest -outputresource:test.dll;2 For EXE's: mt -manifest test.exe.manifest -outputresource:test.exe;1 Hope this helps, Paul Mike Weiblen wrote: Pardon the sparse details, had a problem in wee hours this morn... Built a 2.1.10-ish OSG on one system w/ winxppro/vs8, tried to run the resulting osgviewer on a different system w/ winxphome but no VS8 installed. I got entirely unhelpful errormsgs/dialogs along the lines of that application cant be run or trying reinstalling the app. The VS8 runtime libs were present on the non-VS8 system Does this ring any bells? Could the VS8 or Cmake ocnfigs be triggering some OS or binary dependency? Thanks -- mew Mike Weiblen -- Zebra Imaging -- Austin Texas USA -- http://www.zebraimaging.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] I still have 2 build issues (unices)
Hi Mike, Very curious... you comment about it working sometimes and not others suggest that either the compiler is playing tricks or the include path is changing between different builds. This observation reminds me when I had Martin Lavery working here alongside me - in the CMake build on his Mac he'd see the problem problem, we never get to the bottom of it. It always built fine under Xcode build. It didn't used to have problems under the old GNUmakfile system either, which suggest to me a problem somewhere on the CMake side. Perhaps the CMake community might have something to suggest. Robert. On 9/14/07, Mike Logan [EMAIL PROTECTED] wrote: In my now broken mac build: [ 21%] Building CXX object src/osgUtil/CMakeFiles/osgUtil.dir/Tessellator.o /usr/bin/c++ -DosgUtil_EXPORTS -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -mmacosx-version-min=10.4 -ftree-vectorize -fvisibility-inlines-hidden -O3 -DNDEBUG -fPIC -I/Volumes/viz/OpenSceneGraph/include -F/System/Library/Frameworks -DOSGUTIL_LIBRARY -o src/osgUtil/CMakeFiles/osgUtil.dir/Tessellator.o -c /Volumes/viz/OpenSceneGraph/src/osgUtil/Tessellator.cpp /Volumes/viz/OpenSceneGraph/src/osgUtil/Tessellator.cpp: In member function 'void osgUtil::Tessellator::beginTessellation()': /Volumes/viz/OpenSceneGraph/src/osgUtil/Tessellator.cpp:44: error: invalid conversion from 'GLvoid (*)(...)' to 'GLvoid (*)()' from CMakeCache.txt: //Include for OpenGL on OSX OPENGL_INCLUDE_DIR:PATH=/System/Library/Frameworks/OpenGL.framework //OpenGL lib for OSX OPENGL_gl_LIBRARY:FILEPATH=/System/Library/Frameworks/OpenGL.framework //AGL lib for OSX OPENGL_glu_LIBRARY:FILEPATH=/System/Library/Frameworks/AGL.framework very confusing why sometimes it builds, other times not... environment vars messed up? OSG_DIR=/Volumes/viz//OpenSceneGraph/osg-darwinIntel GDAL_DIR=/Volumes/viz//gdal-1.4.2/RELEASES/darwinIntel ml On Sep 14, 2007, at 2:14 AM, Robert Osfield wrote: On 9/14/07, Mike Logan [EMAIL PROTECTED] wrote: Ok, so its seems to be just macs then. Linux dependencies seem fine. Maybe my problem is related to the previous thread on Tessellator and Mac builds.. CMake must be picking up on the OpenGL framework rather the GLX version of gl.h, or perhaps its the other way around, its assume the OpenGL framework version bit getting the GLX gl.h version. /Volumes/viz/OpenSceneGraph/src/osgUtil/Tessellator.cpp: In member function 'void osgUtil::Tessellator::beginTessellation()': /Volumes/viz/OpenSceneGraph/src/osgUtil/Tessellator.cpp:44: error: invalid conversion from 'GLvoid (*)(...)' to 'GLvoid (*)()' From this I can't work out which way around it it your case. In ccmake .. could you have a look at which verision of OpenGL it's using? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Michael Logan Perot Systems Govt. Services / NASA Ames Res. Ctr. Task Lead / Visual Cueing Simulation Visualization Engineer / Adaptive Control Technologies MS 269-1, Moffett Field, CA, 94035 (650)-604-4494 If you want to start a revolution, don't pick up a gun. Do it with science and technology. - Stanford R. Ovshinsky ___ 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] OSG 2.1.10 crash in osgText / osgdb_freetyped
Hi Robert, Is this in your own application or one of the OSG examples? It is our own app. Are you creating text and then updating per frame? We're creating text and using UpdateCallback to add. Are you running osgViewer multi-threaded? If so which threading model? Well when I run dual core the OSG automatically picks the DrawThreadPerContext model - crash. If I turn dual core off - SingleThread no crash. One possibility is that the new DrawThreadPerContext threaded model is overlapping the drawing of the text with any updating of the text. The way to prevent problems like this is to explictly set the data variance on the text to DYNAMIC so that the draw traversal knows to hold back the next frame till all the dynamic objects have been dispatched. You can ensure this via: myText-setDataVariance(osg::Object::DYNAMIC); Great, that did the trick Thanks Robert. -- Gert van Maren Head of Research Development K2Vi Virtual Reality Software Data Interface Technologies Ltd Phone: +64 21 2855581 Email: [EMAIL PROTECTED] Web: http://www.k2vi.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Dos, Don'ts and DOH's of Drawables with threading?
I'm not sure why you have a thread hung in drawImplementation() after Viewer's destructor has been called. But I can explain some of the other stuff you have questions on, and hopefully that'll help. My question is, how do you guys normally deal with data (scene graph, geometry, text, whatever) being modified on the main thread while Viewer is apparently busy rendering the same data? Mark the Node or Drawable as DYNAMIC DataVariance, and only modify it during the update traversal (or outside the rendering traversals). Having looked at a lot of the other drawables included in OSG, I don't see how the double buffering scheme works -- how is that any of the scene graph or other geometry data get updated without creating a race condition like this? OSG operates on a gentleman's agreement under which you can do whatever you want to DYNAMIC nodes during the update traversal, and OSG's possibly multiple threads can perform read-only operations during the cull/draw traversals. With osgViewer-based apps, marking nodes that you intend to modify as DYNAMIC is critical, otherwise OSG might let the update traversal start (or return from frame()) before it has finished processing the node that you're going to modify. What's the trick here? What can/can't one do from with the drawImplementation() method in order to remain thread safe? drawImplementation() should be const, so as long as you don't modify it or anything else in the scene graph, you should be OK. Hope that helps. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
