Stuart Buchanan wrote
>
> --- On Wed, 23/7/08, Vivian Meazza wrote:
> > 3d clouds have not been ported to osg. At the current rate
> > of progress - sometime in the next decade :-).
>
> Progress is marginally better than that - I've ported the code and have
> even got it to compile.
>
> I'm now
Hello Stuart,
BTW
as 3d clouds seems used multipass rendering maybe
http://projects.tevs.eu/osgppu will be of some help.
Regards
Sergey
On Fri, Jul 25, 2008 at 1:12 AM, Stuart Buchanan
<[EMAIL PROTECTED]> wrote:
> --- On Wed, 23/7/08, Vivian Meazza wrote:
>> 3d clouds have not been ported to os
--- On Wed, 23/7/08, Vivian Meazza wrote:
> 3d clouds have not been ported to osg. At the current rate
> of progress - sometime in the next decade :-).
Progress is marginally better than that - I've ported the code and have even
got it to compile.
I'm now at the stage of crashes-on-startup whic
Am Mittwoch, den 23.07.2008, 15:22 +0200 schrieb Erik Hofman:
> Detlef Faber wrote:
>
> > This is most likely sorting order. I usually fix this by putting the
> > transparent parts in a seperate xml file and load it at the very end of
> > my model.xml file. This works with plib too.
> >
> > Avoi
Erik Hofman wrote
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:flightgear-
> [EMAIL PROTECTED] On Behalf Of
> Sent: 23 July 2008 14:22
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] FlightGear OSG
>
> Detlef Faber wrote:
&g
Detlef Faber wrote:
> This is most likely sorting order. I usually fix this by putting the
> transparent parts in a seperate xml file and load it at the very end of
> my model.xml file. This works with plib too.
>
> Avoid transparent parts in textures. Weird things can happen.
Ok, thanks for th
Am Mittwoch, den 23.07.2008, 14:21 +0200 schrieb Erik Hofman:
> AJ MacLeod wrote:
> > The F-16 looks good here - the only transparency problem I can find is with
> > the star and bars markings (bottom right of f16.rgb) and that could easily
> > be
> > worked round by removing the transparency in
AJ MacLeod wrote:
> The F-16 looks good here - the only transparency problem I can find is with
> the star and bars markings (bottom right of f16.rgb) and that could easily be
> worked round by removing the transparency in that part of the texture.
>
> It sounds like you're seeing something much
On Wednesday 23 July 2008 10:48:23 Erik Hofman wrote:
> * I don't have 3d clouds and shrub/tree cover anymore.
>Is this based on shaders these days?
I've completely forgotten how they work, but we do have (much improved, IMO)
tree coverage. As Vivian mentioned, no 3d clouds or shadows at the
On Wed, 23 Jul 2008, Erik Hofman wrote:
>> Ordering transparencies is handled automatically, which can lead to
>> unexpected problems - I had to break the Seahawk canopy into many separate
>> objects to ensure that objects inside were visible, but otherwise it usually
>> works well.
>
> Odd, I kee
Vivian Meazza wrote:
> 3d clouds have not been ported to osg. At the current rate of progress -
> sometime in the next decade :-).
That's a pity.
> Rain/snow should work nicely: has your osg version got all the plugins
> included, and are they in the path?
As far as I can tell everything is ins
"Vivian Meazza" wrote:
> 3d clouds have not been ported to osg. At the current rate of progress -
> sometime in the next decade :-).
Well, things would probably perform much better if not a little crowd
of only very few people - including yourself - would have been so
efficient in scaring most of
Erik Hofman wrote:
> Hi,
>
> Now that I've installed the CVS version of FlightGear I noticed a few
> things;
>
> * I don't have 3d clouds and shrub/tree cover anymore.
>Is this based on shaders these days?
>
> * Rain/Snow is rendered like dots on my system (not like the screenshots
> I've
Hi,
Now that I've installed the CVS version of FlightGear I noticed a few
things;
* I don't have 3d clouds and shrub/tree cover anymore.
Is this based on shaders these days?
* Rain/Snow is rendered like dots on my system (not like the screenshots
I've seen) and doesn't originate at the
pr
On Fri, 10 Nov 2006 07:45:23 + (UTC)
Martin Spott wrote:
> Chris Metzler wrote:
>
> > Debian's package of freeglut is an exception to this -- the various
> > freeglut problems that have manifested themselves in fgfs have been
> > fixed with local patches. I've been using freeglut 2.4 with no
Chris Metzler wrote:
> Debian's package of freeglut is an exception to this -- the various
> freeglut problems that have manifested themselves in fgfs have been
> fixed with local patches. I've been using freeglut 2.4 with no
> problems at all for a very long time.
Hmmm, when I look at the Debia
On Thu, 9 Nov 2006 22:48:59 -0600
Curtis Olson wrote:
>
> Really? You can do full screen with no window manager adornments? It
> doesn't screw up the requested resolution and give you a weird screen
> and then leave you in the wrong resolution?
Yeah, it works absolutely fine in fullscreen/game-m
On 11/9/06, Chris Metzler <[EMAIL PROTECTED]> wrote:
Debian's package of freeglut is an exception to this -- the variousfreeglut problems that have manifested themselves in fgfs have beenfixed with local patches. I've been using freeglut 2.4 with noproblems at all for a very long time.
Really? Yo
On Thu, 9 Nov 2006 09:48:51 -0600
Curtis Olson wrote:
>
> For what it's worth. The full screen (game) mode of freeglut (any
> version) is horribly broken under unix.
Debian's package of freeglut is an exception to this -- the various
freeglut problems that have manifested themselves in fgfs have
I should double check, but I believe I'm running glut-3.7 on my home machine and didnt' have any build problems (Fedora Core 6.)For what it's worth. The full screen (game) mode of freeglut (any version) is horribly broken under unix. SDL full screen works fine, but locks out all other heads on a
Quoting Martin Spott :
> Hi Jon, Frederic,
>
> Jon Stockill wrote:
> > Jon Stockill wrote:
>
> I didn't ever recieve this first EMail
>
> > I forgot to add - commenting out the #undef APIENTRY line in glut.h
> > allowed me to complete the build.
>
> I'm not still there but at least the ATC st
Hi Jon, Frederic,
Jon Stockill wrote:
> Jon Stockill wrote:
I didn't ever recieve this first EMail
> I forgot to add - commenting out the #undef APIENTRY line in glut.h
> allowed me to complete the build.
I'm not still there but at least the ATC stuff compiles fine after
following your re
Jon Stockill wrote:
> No, it's gcc-3.4.6, but if you're having the problem on IRIX then that is
> a pointer - slackware uses glut - not freeglut, and I suspect that IRIX
> uses glut too. Could this be caused by header differences? Has anyone else
> successfully built FlightGear-OSG on a system tha
On Wed, November 8, 2006 4:50 pm, Martin Spott wrote:
> This is _excellent_ because of two reasons:
> 1.) It releaves the bug from showing up only on IRIX/MIPSpro - where I
> ran into it right after the OSG port appeared in FlightGear CVS (I guess
> Frederic will remember),
> 2.) GCC's error messa
Quoting Jon Stockill :
> Frederic Bouvier wrote:
> > It looks like the APIENTRY symbol is not defined or has been #undef'ed
> > somewhere.
> > The second guess seems the most probable, as osg/GL defines APIENTRY for
> non
> > Win32 environments, and osg/BufferObject includes osg/GL. On MSVC, I
> d
Hi Jon !
Jon Stockill wrote:
> if g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src
> -I/usr/local/include -I/usr/X11R6/include -g -O2 -D_REENTRANT -MT
> atis.o -MD -MP -MF ".deps/atis.Tpo" -c -o atis.o atis.cxx; \
> then mv -f ".deps/atis.Tpo" ".deps/atis.Po"; else
Frederic Bouvier wrote:
> It looks like the APIENTRY symbol is not defined or has been #undef'ed
> somewhere.
> The second guess seems the most probable, as osg/GL defines APIENTRY for non
> Win32 environments, and osg/BufferObject includes osg/GL. On MSVC, I
> discovered
> that glut.h included by
It looks like the APIENTRY symbol is not defined or has been #undef'ed
somewhere.
The second guess seems the most probable, as osg/GL defines APIENTRY for non
Win32 environments, and osg/BufferObject includes osg/GL. On MSVC, I discovered
that glut.h included by plib/pu.h #undef it. I am clueless w
I'm attempting to build the current cvs version of flightgear on a
slackware 11.0 system. OSG and friends built from
OSG_OP_OT-1.2-Flightgear.tar.gz without issue. A fresh checkout of
SimGear into a new directory also gave no problems, however when
attempting to build FlightGear I get the follo
29 matches
Mail list logo
