Hi Michael,
It's been a long time since I've touched the ffmpeg plugin, but here is how it
was:
1/ when the video sound is being played, the video time is synchronized with
the audio player (this tries to keep the video tightly synchronized with the
audio track);
2/ when there is no video
Hi Serge,
Robert is right, SDL only provides a very low-level sound API. If you have
several sounds, you need to write your own software mixer.
SDL advantage is that it's very easy to use. Because it's so low level, it does
not have obscure side effects, which is what you want when you develop
To: OpenSceneGraph Users
Subject: Re: [osg-users] TriStripVisitor issue
On Tue, Nov 24, 2009 at 4:59 PM, Tanguy Fautre
tang...@aristechnologies.com wrote:
I'll do these modifications and check them tonight when I'm back home.
To speed things up (and because we're going to backport OSG changes
Subject: Re: [osg-users] TriStripVisitor issue
Hi Tanguy,
On Wed, Nov 25, 2009 at 12:27 PM, Tanguy Fautre
tang...@aristechnologies.com wrote:
I've sent it to you yesterday on your Gmail address. Can you confirm
you've received it?
Yes, I received it thanks. Just been juggling other tasks
so I'm not best placed to
answer the low level questions, but... the original author of the cdoe
Tanguy Fautre is now an OSG user and I believe still on the list so
perhaps he'll be able to chip in ;-)
Robert.
On Mon, Nov 23, 2009 at 11:08 AM, Emmanuel Roche
roche.emman...@gmail.com wrote
Hi Robert,
http://users.telenet.be/tfautre/softdev/tristripper/
The latest revision is 1.10, Beta 5 (09/06/2005). Don't let the Beta
name scare you, it's actually probably the most stable release due to
several bug fixes.
http://users.telenet.be/tfautre/softdev/tristripper/tristripper-1.1.0-be
PM, Tanguy Fautre
tang...@aristechnologies.com wrote:
http://users.telenet.be/tfautre/softdev/tristripper/
Thanks the link and explanation.
After a quick look at the header, I've noticed protections against
min/max macros that will cause a hard failure when those are detected
(which you
Hi,
I've used an osg::Polytope to test whether a given convex volume was
colliding against a BoundingBox. Unfortunately it wouldn't work. I've
tracked the problem down to Plane::intersect().
/** intersection test between plane and bounding sphere.
return 1 if the bs is
orientation. Depending on the plane orientation its possible to know
before hand which corners of axis aligned bounding box will represent
most extreme points of the box.
Cheers,
Wojtek
- Original Message -
From: Tanguy Fautre mailto:tang...@aristechnologies.com
Hi,
I need to check whether an object occludes another object behind it. To
do so, I currently use a class derived from osgShadow::OccluderGeometry
to compute the occlude silouhette from the camera point of view, and
create an osg::Polytope from that silouhette.
Going through
] On Behalf Of Tanguy
Fautre
Sent: 06 August 2009 13:59
To: OpenSceneGraph Users
Subject: Re: [osg-users] Deadlock when loading osg.dll, singletons are
evil
Hi Robert,
We've got a custom build of OSG where we've commented out all the unsafe
getenv (we do not use env variables in our application anyway
Hi Robert,
From our SVN log I've extracted a unified diff of the modifications I've
had to make on our branch of OSG (i.e. a stabilized trunk snapshot taken
around OSG 2.9.3). This should give a fair idea of the places where I
found a potentially dangerous getenv(). See attached file.
Be
Hi Robert,
You do have to understand that what is currently happening is an
implicit init/destroyOsg through DllMain. The problem is that DllMain is
full of limitations. Only a handful of kernel functions can be safely
called in DllMain. Worse, Microsoft in all their wisdom does not provide
the
Hi Daniel,
Your proposed solution looks like a variant of the Double Checked Locking.
Unfortunately, this design pattern is very subtly broken and not thread safe.
See http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf for more
information.
I've however shown this example just to
Hi Robert,
Unfortunately serializing the access to getenv() is not likely to solve
the issue. The problem is not that OSG calls several getenv() in
parallel, the problem is that getenv() should not be called *at all* in
DllMain().
Serializing getenv() in OSG does not guarantee that another C
Hi Robert,
As you said, doing (2)
const char * getSingletonGlExtensionDisable()
{
ScopedLock lock(s_mutex);
static const char * env = getenv(OSG_GL_EXTENSION_DISABLE);
return env;
}
instead of (1)
static const char * env = getenv(OSG_GL_EXTENSION_DISABLE);
Ensures that the
Hi Robert,
We've got a custom build of OSG where we've commented out all the unsafe
getenv (we do not use env variables in our application anyway).
I'm gonna give your patch a few runs. In theory, it should not deadlock
(considering all the other unsafe getenv are already commented out).
Hi Robert,
It is indeed a Windows specific issue. If you get the chance to test the
example on a Windows machine, it would really be appreciated. Aymeric and I
have spent 3 days tracking, understanding and reproducing the problem. As a
consequence, a fair amount of detailed technical
Hi guys,
We're having the same problem here. Textures are corrupted or are
showing the wrong image when the viewer is destroyed and re-created.
I've been tracking it for a week now. Here is the simplified core logic
of the application that shows the problem.
For (;;)
{
{
Hi Robert,
Thanks for the explanation. It clears quite a lot of confusion.
I've added the stopThreading(), and this build is going to go through a
test cycle tonight, so I will know fairly soon if the problem still
appears.
Cheers,
Tanguy
-Original Message-
From:
Hi Gerwin,
It's a bit of a tricky situation. The actual content of the alpha
channel mainly depends on FFmpeg implementation (and not osg). If I
remember correctly, the obsolete colour conversion routines set the
alpha value to 1 when the video was only RGB, while the libswscale
routines set it
We've tried to temporarily fix the problem on our side by commenting out
osg::DisplaySettings::readEnvironmentalVariables() implementation.
But the deadlock was not gone, now it locks on the following line:
Glextensions.cpp, line 42 (oh, the irony)
static const char* envVar =
Hi,
We've encountered several times a random deadlock that would happen when
starting our application. After some playing around, we've identified
the problem to be quite a subtle one.
Here is what's happening. When osg.dll (in our case the full name is
osg59-osgd.dll) gets loaded, it
Hi J-S,
Your questions are quite legitimate. I'll try to answer them to my best
knowledge.
1.
The DllMain problem is quite well documented (cf. the MSDN links from my
previous post). The thing is that an illegal use of DllMain is quite similar to
a race condition. Most of the time,
Hi all,
I share the opinion that osgText appearance is suboptimal. We've also
got several complains from our Creative department on the look of the
text in our engine.
I confirm that the cause of the problem is as described by Mark
Having written my own text renderer using OpenGL and FreeType,
Hi Garrett,
A bit OT, but which part of the C standard says that all uninitialized
variables shall default to 0? The only zero initialization guarantee of
the C standard I know of is related to static variables (which MSVC
supports).
If what you say about FFmpeg expected C behaviour is
This is similar to C++03,
ISO/IEC 14882-2003 Section 8.5 Initializers
... if no initializer is specified for a nonstatic object, the object
and its subobjects, if any, have an indeterminate initial value
T
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
Hi Paul,
The thing is that MSVC supports most of the C99 features indirectly, as
they are backported from C++ (e.g. one-line comments, relaxed variable
declaration requirements, etc). Most people have been using these on
MSVC (and GCC) for C code well before the C99 standard was put in place.
...
:)
Any idea on how difficult it should be to implement the pause feature ?
On Tue, Jun 23, 2009 at 12:26 PM, Tanguy Fautre
tang...@aristechnologies.com wrote:
Hi,
When the ffmpeg plugin was integrated into osg, the pause feature was
not implemented. I'm not sure anyone has implemented it since
...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert
Osfield
Sent: Tuesday 05 May 2009 16:52
To: OpenSceneGraph Users
Subject: Re: [osg-users] OSG 2.8.1
Hi Tanguy,
On Tue, May 5, 2009 at 4:22 PM, Tanguy Fautre
tang...@aristechnologies.com wrote
I have to admit my experience backs up Michael claims.
Checked Iterators (in release) can have a significant impact on performance
depending on how you use iterators. Most STL calls have been optimized by MS to
have almost a 0% overhead with checked iterators enabled. Code directly using
Hi J-S,
We've been disabling checked iterators in our products, so I know the burden of
maintaining third party libraries that are correctly compiled with the correct
options. In fact, it's sometimes so subtle that it took us about 2 months to
find all the issues on what should be a trivial
Hi J-S,
FFmpegDecoder.cpp :
- bool FFmpegDecoder::readNextPacketNormal() [Line 246 to 308]
- bool FFmpegDecoder::readNextPacketEndOfStream() [Line 312 to 320]
More precisely, I wonder about the API validity of the following code in the
case of a streaming video. FFmpeg documentation is quite
Hi Jean-Sebastien,
The osgFFmpeg plugin was written with a file source in mind. By default when it
encounters an EOF, it will either loop the video or stop playing (depending on
the ImageStream settings).
This behaviour may probably be incorrect with streaming sources. As you said,
one needs
Hi Sherman,
VS2008 has been slowly adopted by C++ developers, because when compared
to VS2005 it does not features anything new that is easily visible.
My experience is that if you get the choice between VS2005 and VS2008,
go for VS2008. It's more stable in general (the C++ compiler and the C++
Hi,
When doing GUI elements in OpenGL, it's particularly useful to exactly
control the rendering order. Usually, this goes like this:
glDepthMask(0);
glDisable(GL_DEPTH_TEST);
glDisable(GL_LIGHTING);
glEnable(GL_BLEND);
/* Render GUI back to front */
can create
own bins, set the overall render order.
Within a single geometry the order is drawn in the order that the
primitives are placed in the geometry, so perhaps this is sufficient for
your purposes.
Robert.
On Thu, Apr 2, 2009 at 11:02 AM, Tanguy Fautre
tang...@aristechnologies.com wrote
-users-boun...@lists.openscenegraph.org] בשם Tanguy Fautre
נשלח: Thursday, April 02, 2009 2:27 PM
אל: OpenSceneGraph Users
נושא: Re: [osg-users] Controlling the rendering order
Hi Robert,
Do you suggest I create an additional bin type (e.g. GUI_ELEMENT_BIN) in
addition to OPAQUE_BIN
...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert
Osfield
Sent: Thursday 02 April 2009 12:46
To: OpenSceneGraph Users
Subject: Re: [osg-users] Controlling the rendering order
HI Tanguy,
2009/4/2 Tanguy Fautre tang...@aristechnologies.com
Do you suggest
Hi Robert,
Chasing a set of bugs, I'm very sceptical about the update logic of our
application. In a nutshell, here is currently what we are doing:
while (! done)
{
const double time = elapsedTime();
updateScene(time);
Hi guys,
inflateInit_ sounds very much like an API entry point in zlib.
Tanguy
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield
Sent: Friday 20 March 2009 08:55
To: OpenSceneGraph Users
Subject: Re: [osg-users]
Wow! That was unexpected!
T
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield
Sent: Tuesday 10 March 2009 16:09
To: OpenSceneGraph Users
Subject: Spam: [osg-users] FFmpeg has a stable
Hi,
From what I understand, an ImageStream indicates that the image as been
changed by calling the dirty() method. From there, a texture will update
its content with the new image when the scenegraph is traversed.
The problem is that I've not found any way to synchronize the point
where
Hi Robert,
It's then probably a good idea to update the ffmpeg plugin to also use a
pointer swap.
The current implementation of the ffmpeg plugin is not optimal. Internally
there are already two buffers (a private and a public one), because of the
colour conversion routines, synch issues, and
Hi all,
Some dll are actually not needed in this package. Basically, they're just
failed symbolic links (on Windows, the build system copy the files).
You can safely delete the following files from the ffmpeg package.
avcodec-51.71.0.dll
avcodec.dll
avdevice-52.1.0.dll
avdevice.dll
Hi J-S,
I'd be very surprised if the ffmpeg plugin supports streaming out of the box
(although you never know). We've surely never tested it with streamed videos.
FFmpeg decoding streamed videos should not be a problem. The
networking/protocol part of streaming is another matter. I think it's
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of J.P.
Delport
Sent: Tuesday 24 February 2009 06:53
To: OpenSceneGraph Users
Subject: Re: [osg-users] Loading movie
Hi Tanguy, Robert,
Tanguy Fautre wrote:
Hi
Hi Robert, J.P.,
I'm checking with my boss whether we can opensource our FFmpeg plugin.
We still haven't implemented the pause() method (and related behaviour), but
the rest is pretty stable.
T
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
Hi Robert, J.P,
That's one of the tutorials I've used to implement our plugin; probably the
best I could find. It's a good start, but I found their video/audio
synchronization to be pretty bad in pratice. I actually rewrote that part from
scratch.
T
-Original Message-
From:
...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Tanguy Fautre
Sent: Monday 23 February 2009 14:52
To: OpenSceneGraph Users
Subject: Spam: Re: [osg-users] Spam: Re: Loading movie
Hi Robert, J.P.,
I'm checking with my boss whether we can opensource our FFmpeg plugin
...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield
Sent: Monday 23 February 2009 15:20
To: OpenSceneGraph Users
Subject: Spam: Re: [osg-users] Loading movie
Hi Tanguy,
On Mon, Feb 23, 2009 at 3:01 PM, Tanguy Fautre
tang...@aristechnologies.com wrote
Hi Mattias,
About the 3rdParty VC9 SP1 binaries...
Release build seems fine (no warning nor errors).
Debug build still shows some warnings:
- osgdb_tiffd.dll: warning LNK4098: defaultlib 'MSVCRT' conflicts with
use of other libs; use /NODEFAULTLIB:library
- osgdb_jpegd.dll: warning LNK4099:
Hi Vincent,
Be careful that you respect the ODR (One Definition Rule). Check that
you're not compiling your application with different settings. If I had
to do a wild guess, I might say you're using mixing Debug/Release builds
or that debug/checked iterators are also mixed up.
Cheers,
application launch
correctly.
It appears that my std::string problem is solved too
\o/
But I know (I hope) it is possible to debug an application based on DLL
(release) ... isn't it ?
Thanks, I will continue going deeply in this problem.
Vincent.
2009/2/17 Tanguy Fautre tang...@aristechnologies.com
Hi
Hi,
I'm encountering a segfault in several applications that use osgShadow
when the application is closing. I've reduced the problem to a very
simple example using osgShadow (see attachment).
I'm using OSG 2.8.0 with VC9. The example program only crashes for me in
Debug mode (the failure is just
, it just introduces new ones.
Robert.
On Thu, Feb 12, 2009 at 12:00 PM, Tanguy Fautre
tang...@aristechnologies.com wrote:
Hi,
I know this is a bit OT, but talking about OSG design... What about
dropping the singleton pattern entirely?
The more I use it or the more I encounter it, the more I
.
On Thu, Feb 12, 2009 at 4:26 PM, Tanguy Fautre
tang...@aristechnologies.com wrote:
It seems to me that OSG often uses singletons as a user convenience.
For example, because the osgDB registry is a singleton, one can simply write:
osgDB::readNodeFile(file_path);
Instead of having to have
-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield
Sent: Wednesday 04 February 2009 12:40
To: OpenSceneGraph Users
Subject: Spam: Re: [osg-users] MSVC v9
Hi Tanguy,
On Wed, Feb 4, 2009 at 12:22 PM, Tanguy Fautre
tang...@aristechnologies.com wrote:
Robert, do you thing
to the VS compile options in
OpenSceneGraph/CMakeLists.txt. One could make these extra build
options, optionally so that you can toggle them on/off from with
ccmake/CMakeSetup.
Robert.
On Wed, Feb 4, 2009 at 2:37 PM, Tanguy Fautre
tang...@aristechnologies.com wrote:
Hi Robert,
It's not a small
Hi J-S,
The bug is apparently triggered by a very specific set of conditions. Most
common programming patterns will actually result in the compiler generating the
correct code. If you search the thread, you'll find more detailed explanations
as well as an example program.
I do not expect
I’ve submitted the bug to Microsoft.
Hopefully they will be able to further enlighten us on the issue.
Robert, do you thing the problem may be serious enough to possibly motivate a
code change for all operators of Vec3f and co as a workaround?
I've already posted it:
http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2009-January/022302.html
I've changed the subject line to be more explicit given the recent findings.
Maybe this was a mistake. ;-)
Cheers,
T
-Original Message-
From:
Hi Guy,
I was able to reproduce the problem on my computer too.
You got my colleagues and I quite puzzled. At this point it's very
tempting to say it's a compiler bug.
I'll do some more investigation. If you don't mind, I'll submit this bug
to Microsoft if we cannot fix it.
Tanguy
Apparently, it's also broken on VC8.
I've reduced the size of the example program, removed the OSG
dependency, and getting ready to submit to MS.
T
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Tanguy
Fautre
Sent
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Tanguy
Fautre
Sent: Thursday 29 January 2009 12:23
To: OpenSceneGraph Users
Subject: Re: [osg-users] MSVC v9
Apparently, it's also broken on VC8.
I've reduced the size
for the previous empty email. Hit the send button a bit too
quickly.
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Tanguy
Fautre
Sent: Thursday 29 January 2009 12:23
To: OpenSceneGraph Users
Subject: Re: [osg-users] MSVC v9
Hi Guy,
AFAIK this should work. Could you reduce that problem to a small example
program so we could actually review the code?
Cheers,
Tanguy
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Guy
Wallis
Sent:
Hi,
I've been using VC90 with OSG 2.7.8 for several weeks now, and I've
noticed several warnings at compile time using these 3rd Party libraries
(http://www.openscenegraph.org/projects/osg/wiki/Community/People/Mattia
sHelsing).
Libtiff.lib seems to be incorrectly linked with the debug CRT.
This might shed some light on the matter:
http://developer.nvidia.com/object/General_FAQ.html#t6
T
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Rosario
Leonardi
Sent: Monday 12 January 2009 14:34
To: OpenSceneGraph Users
you please send the complete file to osg-submissions.
See here
http://www.openscenegraph.org/projects/osg/wiki/MailingLists/Submissions
Protocol
jp
Tanguy Fautre wrote:
Hi,
I think I found the bug. Fixed implementation attached.
If you look at the implementation of the function
osgViewer
with these modifications, what should I do for them to be
integrated back into the trunk?
Cheers,
Tanguy
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tanguy Fautre
Sent: Friday 28 November 2008 15:21
To: osg-users@lists.openscenegraph.org
Cc: Neil Groves
Subject: Spam
Hi Brian,
Are you sure about Boost 1.36 defining _SCL_SECURE=0 and
_HAS_ITERATOR_DEBUGGING=0? I just made a search with _SCL_SECURE on Boost 1.36
sources and came up with nothing.
Our experience with Visual Studio 2005 and higher is the following.
By default, in Debug, VC defines:
Hi,
Has anyone been able to successfully use
osgViewer::View::computeIntersections() taking a node path argument on a
non-trivial scenegraph?
I currently have a fairly complex scenegraph, but I only want a small
part of it to collide with computeIntersections. When I use
computeIntersections
73 matches
Mail list logo