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
If it walks like a duck and quacks like a duck it's a duck :-)
In my case, it walks like a dog but it quacks like a duck, so it's probably a
dock...
We compute line-geometry intersections, and the only special case is when
geometry is made of lines : in this situation, we have to consider
Thanks for pointing me to the example, Robert.
That helped. Obviously, I was too blind to see the part in the example.
Cheers,
Carsten
_
Carsten Scharfe
Software Developer
Experiment Software ESIM
dSPACE GmbH
Rathenaustraße 26
33102 Paderborn
Germany
Tel.: +49 5251
Hello together,
Thanks for the help! I will try the cheaper approach next.
But in general, the current behavior of ignoring the color_buffer binding looks
more like a bug to me. Cause having such essential changes on the camera
settings, I would expect the renderer to be aware of that!?
O.K. in any case, thank you for your time Paul.
@Community, I wonder if this behavior should be treated as bug and
should be reported. What else could be done to find the source of the
problem ?
Summary: My GL3 compiled osg version does not reach the code where a
forward compatible GL3
On 10/12/2011 09:55 AM, Wojciech Lewandowski wrote:
I have prepared a modified osgViewer source which can be used to
reproduce the bug (run it without args). See attached screenshots for
correct and incorrect output. I will be grateful for some feedback on
this issue...
Hi, Wojtek,
RHEL 6.1
Hey,
I appreciate the advice from everybody and have implemented a lot of it as it
will help me develope better code. However, my original problem does not stem
from thread safety but from the .IV plugin and COIN. We discoved this before I
left for the day and I believe this may be an issue
Hi Wojciech,
I get the bad result, running on NVidia Quadro NVS 140M, Driver version
186.94, Windows 7 Enterprise 32bit.
Hi Robert and Community,
I am seeing strange problem with VBOs in OSG on Windows and several
NVidia boards and several driver versions. Basically a set of
geometries with
Hi,
I want to mix some FBO pre-render cameras and osgCuda. Basically I need
to do the following in a single frame:
- do some FBO rendering
- some cuda ops
- again some FBO rendering
- some cuda ops
- again some FBO rendering
For each cuda ops part I have a Computation node. Ideally I'd like
Hi,
On 12/10/2011 15:55, Wojciech Lewandowski wrote:
Could you guys check if this problem also happens in other systems ?
I'm getting the good result.
Debian Sid 64-bit
Nvidia Quadro 2000M
Driver 280.13
jp
--
This message is subject to the CSIR's copyright terms and conditions, e-mail
On 10/12/2011 8:31 AM, Joshua Cook wrote:
To make a long story short COIN was failing in a bad way but the standard
notify message at the INFO level is:
DynamicLibrary::failed loading osgPlugins-3.0.0/osgdb_ivd.dll
Warning: Could not find plugin to read objects from file ../../some_file.iv.
I got everything working but have one more question:
If the units of the object I am attaching to my terrain are in meters, and the
original geotiffs that I started with before converting them using osgdem were
also in meters, is any further scaling of the attached object necessary? I am
The --geocentric flag in osgdem builds a round earth database in meters
with the coordinate system origin being the center of the earth. When
you place your models on the earth (position and orientation), you'll
need to keep this in mind. If your models are in meters you should be
good and no
On 10/12/2011 10:12 AM, Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC wrote:
The --geocentric flag in osgdem builds a round earth database in meters
with the coordinate system origin being the center of the earth. When
you place your models on the earth (position and orientation), you'll
need
On 12.10.2011 15:55, Wojciech Lewandowski wrote:
Could you guys check if this problem also happens in other systems ?
Hi Wojtek, bad result.
Win 7 x64, osg build for x86
NVIDIA GTX 295
driver 280.26
Cheers, PP
___
osg-users mailing list
S2LR wrote:
The --geocentric flag in osgdem builds a round earth database in meters
with the coordinate system origin being the center of the earth. When
you place your models on the earth (position and orientation), you'll
need to keep this in mind. If your models are in meters you should be
Hi,
reply to self...
On 12/10/2011 16:45, J.P. Delport wrote:
Hi,
I want to mix some FBO pre-render cameras and osgCuda. Basically I need
to do the following in a single frame:
- do some FBO rendering
- some cuda ops
- again some FBO rendering
- some cuda ops
- again some FBO rendering
For
Hi, Thank You Guys
Yeah, pattern starts to show. Its most probably something related to NVidia
OpenGL drivers on Windows. When I have sent the email I realized I may test the
code on Intel HD 3000 I have on a wife laptop. And I got “good” result there
and “bad” when switched to NVidia 540
On Sun, 2011-10-09 at 04:53 +0200, Rishabh Taneja wrote:
Hi Jeremy,
I am a newbie in osg. I am working on a project to build a virtual
environment.After trying a lot, I am not able to create first person
experience in my environment. Can you help me out in this regard.
Sure, do you have
On Tue, 2011-10-11 at 04:08 +0200, dan marshal wrote:
Very sorry!
If I create a window using:
osgViewer::Viewer viewer;
osgWidget::WindowManager* wm = new osgWidget::WindowManager(
viewer,
WINDOW_WIDTH,
WINDOW_HEIGHT,
MASK_2D
);
..
12.10.2011 20:45, Wojciech Lewandowski wrote:
So if you are on Linux and have a minute please let me know how the test
passed on your machine ;-)
Hi, Wojtek,
gentoo x86_64
GeForce 9600 GT
270.41.06
good result
Mikhail.
___
osg-users mailing list
On 10/12/2011 9:41 AM, Chris 'Xenon' Hanson wrote:
On 10/12/2011 8:31 AM, Joshua Cook wrote:
To make a long story short COIN was failing in a bad way but the standard
notify message at the INFO level is:
DynamicLibrary::failed loading osgPlugins-3.0.0/osgdb_ivd.dll
Warning: Could not find
J.P.
Thanks for sharing...
-Shayne
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of J.P.
Delport
Sent: Wednesday, October 12, 2011 10:45 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] [osgCompute]
I finally got around to updating the links on my download page to point to
the 3.0.1
binaries that were made back in August. Previously I was hosting only the buggy
3.0.0 release.
You can access them here:
Hi. Noob here. I'm not sure if this is intended to be a help forum, but I can't
find one so I'm posting here. I just installed the OSG binaries from the Debian
repository, and I'm trying to follow the instructions for running the examples,
but
Unix, bash: export
Hi,
I followed the osgParticle example to achieve some simple fire effects. But I
find it difficult for me to build a tail flame effect. I mean, how should I set
those parameters like size range, radius and life time to achieve a decent tail
flame effect? Does anyone have any ideas?
Thank
On 10/12/2011 1:11 PM, Chris 'Xenon' Hanson wrote:
I finally got around to updating the links on my download page to point to
the 3.0.1
binaries that were made back in August. Previously I was hosting only the buggy
3.0.0 release.
You can access them here:
On 10/11/2011 3:20 PM, James Morgan wrote:
Hi. Noob here. I'm not sure if this is intended to be a help forum, but I
can't find one so I'm posting here. I just installed the OSG binaries from
the Debian repository, and I'm trying to follow the instructions for running
the examples, but
Hi,
I'm trying to incorporate the LispSM shadow technique into my renderer (osg
2.8.2, SceneView-based) but can't get the shadows to work when added under an
RTT camera (FBO). I came across this thread
http://forum.openscenegraph.org/viewtopic.php?t=8347 that seems to describe my
problem
Hi all -- I'm pleased to announce that osgBullet v2.0 has release candidates
available. I hope some of you will join in the testing of this, the first major
refresh of osgBullet since its debut.
Grab the featured download from osgbullet.googlecode.com, or check out from this
URL:
Hi Sobeit,
osgParticle in it's present form isn't great for simulating fire
effects being emitted by fast moving objects. For now I'd recommend
implementing your own custom osg::Geometry and shader or update
callback for the animation.
Robert.
On Tue, Oct 11, 2011 at 11:47 AM, Sobeit Wang
Thanks Chris :-)
On Wed, Oct 12, 2011 at 8:11 PM, Chris 'Xenon' Hanson
xe...@alphapixel.com wrote:
I finally got around to updating the links on my download page to point to
the 3.0.1
binaries that were made back in August. Previously I was hosting only the
buggy 3.0.0 release.
You can
Hi Craig,
I would recommend using OSG-3.0.1 as their are improvements in shadow
support, I would also recommend using osgViewer rather than SceneView.
If you are happy using the svn/trunk version of the OSG then the new
osgShadow::ViewDependentShadowMap implementation will probably be your
best
Hi,
On 12/10/2011 18:45, Wojciech Lewandowski wrote:
So if you are on Linux and have a
minute please let me know how the test passed on your machine ;-)
tested on two more for you, both Debian 32-bit.
1:
dual nvidia GTS250s, driver 270.41.19, good result across 4 screens.
2:
nvidia 9600GT,
34 matches
Mail list logo
