Hi Jason,
On Fri, Feb 27, 2009 at 9:14 PM, Jason Daly jd...@ist.ucf.edu wrote:
So, is it your intention that the AudioSink interface would be implemented
by another plugin (e.g.: an openal plugin)?
That's a very good question... how to do we provide an AudioSink, and
how far should we go in
Hi Per,
I'm a bit rusty on this topic, too many topics coming flying by each
day that niche stuff drops out of focus quite quickly...
Something I can answer right away is to to explain the relationship
between the CullingSet CullingMode and CullingMask. The Mode is the
base mode that specifies
HI Christian,
The way to use a mask like this would be to read an osg::Image and
read from it directly. There is no reason to require the use
Texture2D - this is only required if you want to do operations down on
the GPU. osg::Image does have access methods for getting individual
pixels.
Hi JS,
On Fri, Feb 27, 2009 at 9:26 PM, Jean-Sébastien Guay
jean-sebastien.g...@cm-labs.com wrote:
OK, seems I understand the basics after all. So why are competing standards
a bad thing if they're inherent to the nature of open standards? Or
conversely, why are open standards so desirable if
On Sat, Feb 28, 2009 at 6:49 AM, J.P. Delport jpdelp...@csir.co.za wrote:
Hi,
I think you might be running into the corner equalisation bug.
Search osg-submissions for the thread
vpb - fix for corner equalisation
The fix is not yet merged in vpb.
I will be back on VPB very soon, so will
HI Alejandro,
Which version of ffmpeg do you have installed?
As J.P. mentioned ffmpeg is a bit of moving target and were' only just
getting into learning about FFmpeg foibles. We'll probably need to
add version checking into our FindFFmpeg.cmake to avoid these issue.
Also migrating the code
Hi Robert,
if you compile newer ffmpeg without GPL functions, it still has its own
versions of the swscale functions implemented. You then just do not link
to the (maybe faster) GPL swscale library. I've tested this on Debian
and it worked for our app.
I'll send some references and code
Hi,
J.P. Delport wrote:
Hi Robert,
if you compile newer ffmpeg without GPL functions, it still has its own
versions of the swscale functions implemented. You then just do not link
to the (maybe faster) GPL swscale library. I've tested this on Debian
and it worked for our app.
I'll send
Hi,
I'll send some references and code later.
See e.g. here:
http://lists.mplayerhq.hu/pipermail/libav-user/2008-November/001618.html
and
http://lists.mplayerhq.hu/pipermail/libav-user/2008-June/000683.html
e.g.
img_convert vs swscale
---8---
#if defined IPF_USE_SWSCALE
int err =
jonim8or wrote:
I have the same problem, with lights switching on and off for one shape in my
scene.
I have a similar problem in a scene with large flat terrain areas. When there
is no vertex in close view it seems that OpenGL can't determine the appropriate
lighting for the surface and
Hi Robert and Jason,
Sorry I came late, but did you try osgAL? I worked a bit on it and used osgAL
on top of both OpenAL and OpenAL-Soft, and it worked very well. osgAL also
contains OpenAL++, which is a layer ontop of OpenAL. That should be interesting
to merge what you did with osgAL, isn't
Hi guys, i found tow bugs in plugin-gz in osg2.8.
1. ln174 in ReaderWriterGZ.cpp
std::ifstream fin(fileName.c_str()); // error code
std::ifstream fin(fileName.c_str(),
std::ios_base::in|std::ios_base::binary);// should be opend as binary
2. ln260 in ReaderWriterGZ.cpp
Hi Renliwei
Yes bugs can be reported to this list,
If you're also providing a fix for a bug you have come across then see this
page
http://www.openscenegraph.org/projects/osg/wiki/MailingLists/SubmissionsProt
ocol
It contains the instructions on the correct way to submit the fix or
HI J.P,
Thanks for the links and pointers. When I get back to coding I'll
have a look at making the changes to swscale.
The other route would be to do the colour conversion down on the GPU,
but this would have to be just an option.
Robert.
On Sat, Feb 28, 2009 at 10:38 AM, J.P. Delport
Hi Jason,
Ever try DosBox ( http://dosbox.com/information.php?page=0 ) ?
Yes, of course, but running it on the real hardware is its own reward.
:-) Plus, I hate how nothing in DosBox really runs that well (even
something that ran well on a 486DX/33 has trouble in DosBox, and I have
to
Hi Robert,
Competing standards are a bad thing as it breaks interoperability and
divides the market place into targeting one or other, or both
standards.
I understand your points, but I don't see how that's different from any
market... I could give lots of examples of similar competition:
Hi Paulo,
What am I doing wrong? Do I need to call some method to flag that the
array changed?
Yep, good intuition: _geometry-dirty();
Also, since you're changing the vertices each frame, set
_geometry-setUseDisplayList(false); or otherwise you'll get bad
performance.
Hope this helps,
I understand. And what about using code from osgAL for your needs?
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
Le Sat, 28 Feb 2009 14:02:51 +0100, Robert Osfield robert.osfi...@gmail.com a
écrit:
Hi Sukender,
On Sat, Feb 28, 2009 at 11:16 AM,
Hi,
it worked just fine.
I guessed so, because I noticed the dirty method not on the geometry but
on the vertex array autocomplete,
I was asking because sometimes the documentation has only the code
listing and not an actual explanation.
I guess I could have tried it, but it was also to
Thanks JP, I wasn't aware of that bug. The patch fixed the artifacts I
was seeing.
Ken.
J.P. Delport wrote:
Hi,
I think you might be running into the corner equalisation bug.
Search osg-submissions for the thread
vpb - fix for corner equalisation
The fix is not yet merged in vpb.
jp
Robert,
Thank you for your post and information. I tried another make and here are
the results:
...
[ 49%] Built target example_osgwidgetstyled
[ 49%] Built target example_osgwidgettable
[ 49%] Built target example_osgwidgetwindow
[ 49%] Built target example_osgpdf
[ 49%] Built target
Pardon the elementary question...I'm a newbie with OSG and VPB. I've search
around but haven't found a simple example that illustrates what I'd like to do.
Essentially, I've built a VPB whole-earth database and got it loaded in my
application. There are two things I'd like to do at this
Re #1: Your whole-earth database is in geocentric (earth-centered XYZ)
coordinates. In the class osg::EllipsoidModel (in osg/CoordinateSystemNode)
there are functions to convert from lat/long to geocentric and back. You can
these to calcuate the XYZ at which to place your model. Then use the XYZ
EllipsoidModel and CoordinateSystemNode also provide you with a local up
vector, which will be a component of the orientation part of your
MatrixTransform.
Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com http://www.skew-matrix.com/
+1 303 859 9466
_
From:
Skylark wrote:
Yep, good intuition: _geometry-dirty();
Also, since you're changing the vertices each frame, set
_geometry-setUseDisplayList(false); or otherwise you'll get bad
performance.
Thanks for the tip about the futility of a display list in this case. I have a
sky dome that
Hi Robert,
I updated ffmpeg a month and a half ago in order to be able to encode
videos to h264, so I need that version, I can't downgrade it. It is
SVN-r17646.
I agree on not using deprecated functions.
Best regards,
-- A.
On Sat, Feb 28, 2009 at 3:33 AM, Robert Osfield
Hi Steven,
Thanks for the tip about the futility of a display list in this case. I have a sky dome that follows the
camera so your comment has helped me. But I can't find any reference to a dirty function. Do
you mean dirtyBounds (which I do use) or am I missing something ? There is
Ugh...
I just checked my PATH and noticed OpenSceneGraph/bin was missing, so I added
that and all the Examples ran.
It is the simple things...
--- On Sat, 2/28/09, Jason Rupert jasonkrup...@yahoo.com wrote:
From: Jason Rupert jasonkrup...@yahoo.com
Subject: [osg-users] Problem executing a few
28 matches
Mail list logo
