HI Michael,
You'll kick yourself, parse the command line and you find no space
between las_shallow_topo_east.tif and --geocentric.
Robert.
On Sun, Feb 24, 2008 at 8:35 PM, Michael W. Hall [EMAIL PROTECTED] wrote:
I have the following files land_shallow_topo_east.tif and
loy_1987 wrote:
I am not familiar with this problem.I hope someone could give me a hint.
For Linux you might want to try Bugle
(http://www.opengl.org/sdk/tools/BuGLe/). I've succesfully used it to
capture OpenGL sessions to an .avi file.
It can also help debugging OpenGL programs in
Thanks a lot for your answer, now I understand a bit of what is going on...
I will write the example for better understanding of what I am trying to do
and look at the code you suggested.
I'll derive it from the code in osgwindows (setting one camera for each
window in an independent viewer) and
Hello,
I will make my own answer :
I used osg::Image to obtain the unsigned char* data array, and i use it to
melt the two pictures in one.
data[n] = osg::maximum(Edata[n], (unsigned char)Cdata[i]);
This is not a the solution of the problem, but it can solve it, when no
other solution
Hi Paul,
On Mon, Feb 25, 2008 at 1:32 AM, Paul Mlyniec [EMAIL PROTECTED] wrote:
We have been developing an application framework over OSG for several years
(previously over Performer). We've built several apps, including an
immersive CAD system and an immersive Command and Control system.
Hi, there has been a similar request some weeks ago ..
If you just want to capture the rendering result you can use an external
tool such as
fraps for win32. There was some tool for linux also but I cannot
recall ...
HTH
Sebastian
loy_1987 schrieb:
I am not familiar with this problem.I hope
HI Vincent,
Perhaps everybody else like me is a bit confused by what you are
actually after. The OSG supports multi-texturing, and shaders, the
plugins are all orthogonal to final readering - all in all is most
likely what you are trying to do is very straightforward. I can't
really glean
On Mon, Feb 25, 2008 at 8:49 AM, nicolas peña [EMAIL PROTECTED] wrote:
Just in case you are curious about my case of use, I will try to explain a
bit my intentions, if you consider that my
approximation is not right please correct me.
I am building a simulation framework aimed at multi-robot
Hi all
did someone still implemented this SSAO in OSG, any demo?
http://rgba.scenesp.org/iq/computer/articles/ssao/ssao.htm
--
Adrian Egli
___
osg-users mailing list
osg-users@lists.openscenegraph.org
Hi Robert.
Perhaps i'm not very clear in what i intend to do :
I want to create a sphere to simulate the earth. for texturing it, i use 2
textures : one of the sea and lands, one of the clouds. the second one can
be with opacity (to keep only clouds).
I would just put the 2 textures on the earth,
HI Vincent,
Have a look at the osgplanets example is has code paths that do
multi-texturing on spheres.
Robert.
On Mon, Feb 25, 2008 at 9:01 AM, Vincent Bourdier
[EMAIL PROTECTED] wrote:
Hi Robert.
Perhaps i'm not very clear in what i intend to do :
I want to create a sphere to simulate the
On Mon, Feb 25, 2008 at 9:22 AM, nicolas peña [EMAIL PROTECTED] wrote:
Yes, I think I'll be OK with that.
Sorry for my lack of knowledge but, can you tell me how can I
deactivate/activate
the cameras ?.
I don't find the proper method.
camera-setNodeMask(0x0);
Thanks, I think i have understood that TexEnvCombine is necessary. I'll try
this as soon as possible.
Thank you for your explanations.
2008/2/25, Robert Osfield [EMAIL PROTECTED]:
HI Vincent,
Have a look at the osgplanets example is has code paths that do
multi-texturing on spheres.
I'll work with this.
Thanks a lot.
Nicolas.
2008/2/25, Robert Osfield [EMAIL PROTECTED]:
On Mon, Feb 25, 2008 at 9:22 AM, nicolas peña [EMAIL PROTECTED]
wrote:
Yes, I think I'll be OK with that.
Sorry for my lack of knowledge but, can you tell me how can I
deactivate/activate
the
Thanks Stephane,
it's a pitty that this can't be done directly. Would this be of use for
anyone but me?
I could imagine to introduce some mechnism to set such defines per shader.
Might involve pre-parsing the shader-source ... mmh
I just asking myself if this would somehow break other things.
Hello,
I was wondering if the preprocessor language in GLSL is somehow useable
for osg.
Imagine I had a shader with
..
#ifdef SIMPLE
vec4 Color = vec4(1.0);
#else if NOT_SO_SIMPLE
vec4 Color = unimaginableComplicatedColorFunction(...)
#endif
Can I pass those defines to osg::Shader? I didn't
Hi,
No you can't do that directly.
But you could load your shader file into a string and add your
preprocessor definitions at the begining of it and then send it as
source to the osg::Shader constructor:
std::string source = loadShaderFile(filename);
source = #define SIMPLE \n + source;
Joachim E. Vollrath schrieb:
Hi Sebastian,
certainly would be a nice feature, although maybe shader synthetization
should perhaps be done in a library of its own..
I agree that high level modifications shouldn't be part of the
osg::Shader / Program.
But I consider the preprocessor macros
Hi Sebastian,
certainly would be a nice feature, although maybe shader synthetization
should perhaps be done in a library of its own...
What do the others think?
To this end, I have added an #include directive for my GLSL shaders
which was trivially implemented by hand at the application
Hi Brian,
I've looked at line line question, the addIntersection method that it
uses, and your email but still can't work out what you think is going
amiss - there is simply too little info to know what the problems is.
Could you please obtain and stack trace from the crash and report this
to
Hi,
I am using a standard graphics card for todays, and
rendering a 100 mb (s3tc textured) terrain database.
The cull traversal time increases too much when I add
animated models (osg model with update callback)
(each having 1400-1500 polygons) to the scene, so that
the frame rate drops too
Hi, I'm also developping a volume renderring for MRI, current at very
early stage. Some pictures and videos are posted at my blog, you can
see them at the following URL: (Sorry right now it is written in
Chinese, but you can see the video instead)
MRI 3D reconstruction, transform function
I have written a small set of user ortho 2d interface classes one of which
includes a slider bar control.
I detect the intersection with the slider's geometry to check the mouse has a
hold of it and then update it's position based on the coordinates I get from
the event handlers 'drag' event.
Hi Andreas,
may you would be able to implement an opensource nodekit for openscenegraph,
like osgShadow. This would be greate to get, implementing twice similar
things are not so funny. if you would be able to add Inigo algorithm this
would be really greate.
/adrian
2008/2/25, Andreas Lindmark
I have written a small set of user ortho 2d interface classes one of which
includes a slider bar control.
I detect the intersection with the slider's geometry to check the mouse has a
hold of it and then update it's position based on the coordinates I get from
the event handlers 'drag' event.
5ms for a 1500 polys is a lot,
are there a lot of different textures, colours, materials on the models ?,
large textures sizes ?
Are there degenerate polygons etc.
do you see the same hit is you run osgview with one of the problematic cases
?
Could you post an example of the model the
Hi Adrian,
I do not think that a nodekit just for this purpose is
usefull or needed.
This kind of screen space algorithms can be perfectly
described by the osgPPU. I really like this kind of
effects and it seems that it is very straight forward
to implement. I will try to create a .ppu file
Hi All,
In my OSG application, I want to find the normal vector corresponding to
each pixel position. It means that after rendering if an image pixel (i,j)
comes from an object plane P, I need to find the Normal vector to P. One of
the ways would be to use LineSegmentIntersector to find
Ah ok, bit of a follow up to that, the crash doesn't occur when updating the
position of the slider, but when it updates an osgText::Text object using
-setText(string);
It will do it a few times and seems to crash intermittently if I change it too
often.
Any thoughts?
Hi,
I did not want to say that OSG had any problem nor I
have the power to reimplement it :), sorry if my
sayings were misunderstood
I only wanted to ask for advice in solving my
performance problem due to my models' (an animated
person model in osg) complexity. Since this problem is
observed
HI Franz,
On Thu, Feb 7, 2008 at 5:18 PM, Melchior FRANZ [EMAIL PROTECTED] wrote:
* Melchior FRANZ -- Thursday 07 February 2008:
And it works here with my patch, while first tests have shown
that FocusOut, LeaveNotify, and KeymapNotify weren't triggered
at all (which is suspicious).
Hi Harash,
Render you scene to a depth texture and then compute the normals from
this in a second pass in the shader.
Robert.
On Mon, Feb 25, 2008 at 3:20 PM, Harash Sharma [EMAIL PROTECTED] wrote:
Hi All,
In my OSG application, I want to find the normal vector corresponding to
each
Hi Kim,
Try changing your viewer to run single threaded, or try setting the
DataVariance on the Text to DYNAMIC to tell the draw traversal that
its an dynamic objects and to hold back the next frame till this has
been rendered.
Robert.
On Mon, Feb 25, 2008 at 3:29 PM, Kim C Bale [EMAIL
I have also noticed problems with updating osgText::Text objects in the
wrong stage of traversal. I think this has something to do with
threading. Are you crashing in the osgText::Text::computePositions()?
I dealt with this issue about 3 months ago, and I was able to resolve it
by moving the
Thanks, that worked a treat!
Regards,
Kim.
From: [EMAIL PROTECTED] on behalf of Robert Osfield
Sent: Mon 25/02/2008 15:34
To: OpenSceneGraph Users
Subject: Re: [osg-users] Updating node position in event handler.
Hi Kim,
Try changing your viewer to run
* Robert Osfield -- Monday 25 February 2008:
Do you have a new set of changes pending? Are the ones from 21st Feb
the latest and definitive set to review?
BTW, for future submissions could you send whole files rather a diff,
as per the instructions on:
I sent the whole files to
Good morning all-
We are using the depth partition node approach and we are noticing issues where
our scaled objects are being clipped by what looks like the near and far
clipping planes. At times, we will only see the ‘’middle slice” of an object,
perhaps the middle slice is as wide as the
Hi justin,
Cheers for the heads up but changing the data variance seems to have solved it.
It's odd though because it was working fine as it was, but just recently
started crashing..
K.
From: [EMAIL PROTECTED] on behalf of Vican, Justin E.
Sent: Mon
OSG already culls the models based on heirarchical bounding volumes.
The complexity of the models is the most likely problem. You need to
understand the model structure and how it impacts performance. The applies
to every stage - update, cull, draw.
Try running without your terrain or skydome
Hi Robert,
Quick question about screen arrangement. As I understand it,
WindowingSystemInterface currently has no way of reporting the
arrangement of the screens (physically), so there is no real way to
support, for example, a single view spread over 4 screens arranged in a
2x2 square. Is
* Robert Osfield -- Monday 25 February 2008:
although caps lock is currently getting out of sync.
My keyboard doesn't have a caps lock key. But I'll plug another
in and check.
One other item that needs resolving is the warning:
Hi Franz,
On Mon, Feb 25, 2008 at 3:41 PM, Melchior FRANZ
[EMAIL PROTECTED] wrote:
BTW, for future submissions could you send whole files rather a diff,
as per the instructions on:
I sent the whole files to osg-submissions, as the instructions say.
This here was only for people to test
* Melchior FRANZ -- Friday 22 February 2008:
Here's a new version with the following changes made:
- be a bit more pedantic about modifier settings for
artificially pressed/released keys
- fix a compiler warning
- simplification minor improvements
attached:
On Mon, Feb 25, 2008 at 4:20 PM, Melchior FRANZ
[EMAIL PROTECTED] wrote:
* Melchior FRANZ -- Friday 22 February 2008:
Here's a new version with the following changes made:
- be a bit more pedantic about modifier settings for
artificially pressed/released keys
- fix a compiler
Hi,
I thought that geodes received primitive culling but I
could not find it to close it(now know that there is
no primitive culling, it is left to graphic card),
therefore solution seems to be flattening the model,
Thanks a heaps
--- Brian R Hill [EMAIL PROTECTED] wrote:
OSG already culls
* Robert Osfield -- Monday 25 February 2008:
/home/robert/OpenSceneGraph/src/osgViewer/GraphicsWindowX11.cpp:1310:
warning: converting to 'Time' from 'double'
Which relates to:
event.time = time;
This can simple be changed to
event.time = 0;
We only fill an XKeyboardEvent here
The transforms might slow down the CullVisitor.
Please post the model as a .osg file. Are you running the osgUtil::Optimizer
in your app on the loaded model?
Please take osgviewer timings again, but first disable the Optimizer with
OSG_OPTIMIZER=OFF. It would be interesting to see if this allows
Hi Justin,
I've written a lot about threading models over the past six months,
and the how DataVariance is used to avoid crash overlapping overlaps.
So it'd be worthing doing a search back through the archives.
I believe Paul might have mentioned it in the the Quick Start Guide.
Robert.
On
Hi J-S,
The defaults settings in osgViewer can't cope with novel display
arrangements, and this is well beyond the scope of
WindowSystemInterface as once you start going beyond nx1 displays
things can very rapidly get very complicated.
The right way to handle complex screen arrangements is to
Hi,
The cull and draw times you have are appalling slow. Its clear that
your model is really badly conditioned. The number of transforms and
geodes etc isn't that high, and shouldn't cause things to be that
slow.
Hows about some details of the OS, hardware you have. Also are you
compiling in
* Robert Osfield -- Monday 25 February 2008:
I was wondering about just setting time to 0, the X11 headers mention
that 0 represents the current time.
The XKeyEvent is only filled out for XLookupString, which in turn
only looks at the display, keycode and the modifier mask for
translating the
On Mon, Feb 25, 2008 at 4:19 PM, Melchior FRANZ
[EMAIL PROTECTED] wrote:
One other item that needs resolving is the warning:
/home/robert/OpenSceneGraph/src/osgViewer/GraphicsWindowX11.cpp:1310:
warning: converting to 'Time' from 'double'
Err ... I told you to take the files from
On Mon, Feb 25, 2008 at 4:27 PM, Melchior FRANZ
[EMAIL PROTECTED] wrote:
/home/robert/OpenSceneGraph/src/osgViewer/GraphicsWindowX11.cpp:1310:
warning: converting to 'Time' from 'double'
Which relates to:
event.time = time;
This can simple be changed to
event.time =
* Melchior FRANZ -- Monday 25 February 2008:
Err ... I told you to take the files from the followup message in
that thread, not the one from the first message.
Ah, sorry. You did that. :-/
I'll check the code again.
m.
___
osg-users mailing list
FYI
I googled it up quickly and did not find anything. I tried however to use
GL_RGB16F_ARB
instead of GL_RGB32F_ARB and it worked. I don't need the extra precision so
that solves
my problem...
-bill
-Original Message-
From: [EMAIL PROTECTED] on behalf of Robert Osfield
Sent: Sat
Hi Robert,
Thanks for the tip. I'll parse through the user group mail and see what
I can find out. For now, I seem to have solved my problem, but I
wouldn't doubt it if I just covered it up again. Would hate to
re-discover it right before a big release.
Thanks Again,
Justin
-Original
Hi Sherman,
Finally had a chance to look at your repro, and I agree it is an OSG
bug. It's a consequence of the unique handling of glProgram state
within OpenGL; I thought we'd fixed this before, but you seem to have
uncovered a different failure vector.
In the repro example you gave me, since
Hi Robert,
The defaults settings in osgViewer can't cope with novel display
arrangements, and this is well beyond the scope of
WindowSystemInterface as once you start going beyond nx1 displays
things can very rapidly get very complicated.
Nothing novel in this case, just trying to get
Hi,
I don't know of a way to pass #define values, other than composing a
shader of multiple strings:
(enableSimple ? #define SIMPLE\n : #undef SIMPLE\n),
#ifdef SIMPLE\n
vec4 Color = vec4(1.0);\n
#else if NOT_SO_SIMPLE\n
vec4 Color = unimaginableComplicatedColorFunction(...)\n
#endif\n
OpenGL
Hi Art,
Thanks for the idea. I do have a Geforce 8800, and the extensions are reported
as being supported.
I've attached a very simple program (shaders inlined in the code) which shows
my setup, if anyone
is interested. Thanks.
-Sean
Date: Mon, 25 Feb 2008 13:27:55 +0100
From: [EMAIL
Hi Sean,
as far as I see you have an error in your setup. This
line:
ref_ptrUniform texturesUniform = new
Uniform(Uniform::FLOAT,
textures, 1);
must be replaced with something like this:
ref_ptrUniform texturesUniform = new
Uniform(Uniform::SAMPLER_2D_ARRAY,
textures, 0);
Try this out.
Art,
Thanks a lot, I've made the change you suggested. Also, as it turns out, I had
a number of
other things preventing my sample program from working. I needed to add
textureArray-setFilter(osg::Texture2DArray::MIN_FILTER,
osg::Texture2DArray::NEAREST);
On Mon, Feb 25, 2008 at 6:06 PM, Jean-Sébastien Guay
[EMAIL PROTECTED] wrote:
The defaults settings in osgViewer can't cope with novel display
arrangements, and this is well beyond the scope of
WindowSystemInterface as once you start going beyond nx1 displays
things can very rapidly
Hi Robert,
Trust in configuration files, they are very powerful for this type of
stuff. For instance you can have it work on one screen of your four
using one file, then another configuration file can set up all four.
etc. etc.
Well we already have config files for the views (similar to
Thanks Mike - glad to hear the problem manifested for you as well. If
I can be of any additional assistance let me know.
On Mon, Feb 25, 2008 at 12:03 PM, Mike Weiblen
[EMAIL PROTECTED] wrote:
Hi Sherman,
Finally had a chance to look at your repro, and I agree it is an OSG
bug. It's a
Hi,
I am running the application on windows XP and my
graphic card is NVidia Geforce 6600.
I was compiling in debug mode, now I would change the
configuration to release mode.
Thanks in advance
--- Robert Osfield [EMAIL PROTECTED] wrote:
Hi,
The cull and draw times you have are
66 matches
Mail list logo
