--enable-rembrandt
--prop:/sim/rendering/shadows/enabled=true
--prop:/sim/rendering/shadows/num-cascades=1
--prop:/sim/rendering/shadows/cascade-far-m=50
should be: --prop:/sim/rendering/shadows/cascade-far-m[0]=50
--prop:/sim/rendering/shadows/map-size=2048
Voila, your weekly screenshot(s):
http://foxtrot.mgras.net/bitmap/FGFS/fgfs-rembrandt_04.0.png
http://foxtrot.mgras.net/bitmap/FGFS/fgfs-rembrandt_04.1.png
Looks like there is some progress, isn't it ?
Debian Linux/AMD64, Nvidia GeForce 7950 GT, closed source driver
version 295.40.
Hi Heiko,
What do I miss? Where am I wrong? Do we get something like back with
the next release in less than 3 months?
In case you didn't notice, Thorsten screenshots are from altitude, not
from the ground, with more clouds on screen, and at dusk or dawn.
Put yourself in the same conditions
Scott,
I searched and can't find anything to do this, but just wanted to
make sure it doesn't exist.
I have a property /instruments/b/index let's say it has a int value
of 1 In my animation XML file I need to access an array, with the above
property being used as the index.
something
Thorsten,
One comment - to avoid any problems with merge requests being
lost/ignored - who is this 'aimed' at? I.e who needs to review it
and decide? I don't feel qualified, for example :)
(But maybe I just merge it and see who complains ;)
Not that you need to pick on
Thorsten,
One comment - to avoid any problems with merge requests being
lost/ignored - who is this 'aimed' at? I.e who needs to review
it
and decide? I don't feel qualified, for example :)
(But maybe I just merge it and see who complains ;)
Not that you need
It also seems that some model are not lighted anymore :
http://frbouvi.free.fr/flightsim/fgfs-haze-1.3.gif
The only place models get the effect is if they go via
Effects/model-default.eff if they're using their own effect file
they are not in the scheme.
I was speaking about the
Presumably all these effects could actually be done as one
screenspace pass?
Please elaborate
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has
I usually commit Thorsten's work. Will have a look in the next days.
This is in git now, with the duplicated technique removed
-Fred
--
Live Security Virtual Conference
Exclusive live event will cover all the ways
That problem goes away if landmass shader is disabled. The strange
thing is that when set to some value, the problem appears but as soon as
you click on the landmass slider, without changing the value, the
problem goes away too.
Is this anything I could have caused? Because I have no
I have no idea too. It looks like an uninitialized value that get
one when we click on the slider. Do you reproduce the problem I see ?
For some (yet to be determined) reason the shader settings are not
archived on Flightgear exit in my local devel branch since my
next-to-last update
Do you reproduce the problem I see ?
Okay, found the problem with userarchive and eliminated it Now I
see the same thing you describe, the model shader doesn't start up
correctly, but all goes well once one just clicks the slider. The
model shader doesn't seem to be doing anything at
Hi Stuart,
On Wed, Apr 25, 2012 at 10:33 AM, Renk Thorsten wrote:
Hm... I'm getting good performance, but the rendering of the random
buildings do not seem to go via model-default.eff - they respond
to the normal visibility, but not to the terrain haze layer, so
they remain visible when
One comment - to avoid any problems with merge requests being
lost/ignored - who is this 'aimed' at? I.e who needs to review it
and decide? I don't feel qualified, for example :)
(But maybe I just merge it and see who complains ;)
Not that you need to pick on any one person, but if
Thorsten,
One comment - to avoid any problems with merge requests being
lost/ignored - who is this 'aimed' at? I.e who needs to review it
and decide? I don't feel qualified, for example :)
(But maybe I just merge it and see who complains ;)
Not that you need to pick on any one
Hi Thorsten,
Can you get a backtrace?
I can try if you tell me what I need to do...
I've made a change to the startup sequence,
yesterday, but I would expect it to crash later (after scenery
loading),
ten seconds sounds too early.
Misunderstanding: After scenery loading and I
Hi James,
just a guess here, but in the past, I had to fix issues brought when converting
raw pointers to smart pointers and ending up deleting the pointer given by the
smart pointer explicitly. For example :
SGSharedPtrMyClass myPtr = new MyClass;
then
delete myPtr;
or
delete myPtr.get();
James,
I wasn't affected by a crash until I realized that hashForAirport was never
called. Then I enabled animated jetways and the segfault came, after few
successful calls.
I am not able to tell why though
HTH
-Fred
Emilian,
All the sine stuff happens in the fragment shader, so performance is
directly related to the amount of screen pixels covered by water, not on the
amount of vertices. Maybe just testing the pixel depth against the fog
distance
might bring some performance in fogged scenarios, where
De: Martin Spott
Frederic Bouvier wrote:
This shader error affects shadow rendering and for now, I don't
have a replacement. The only thing I can propose for this kind
of card, is to disable shadow rendering :
--prop:/sim/rendering/shadows/enabled=false
Here's your weekly
Gene Buckle
On Thu, 12 Apr 2012, Frederic Bouvier wrote:
Here is a video with a steady view to see shadow stability.
http://youtu.be/JtEXIn2yL94
I also added 3 different sequences with different levels of
filtering.
Filtering is not yet configurable but is selectable
Will try. In any case, the information that some fallback code is
probably be running is helpful already, I should be able to check
this easily by setting gl_FragColor to blue in the shader that ought
to be running and investigate from there.
If you can post a screenshot with the buffers
De: Renk Thorsten
To be safe you need to limit yourself to 32 float varyings.
Note: a vec3 counts as 3 float varyings, a vec4 as 4 etc.
Okay thanks, then I am safe. Btw (spotted this while checking) - is
there any particular reason to compute a normal from gl_Normal in
the vertex
Actualy it makes assumptions about the lighting scheme used, and it
boosts the visible reflection of the sun using a texture instead
of the light's specular in the specular pass.
That gets to be less aparent in the Rembrandt specular pass.(That
would be easily converted by using the sun
De: James Turner
On 12 Apr 2012, at 08:24, Renk Thorsten wrote:
3) On my box, all three panels in the screen edges show the same
image - not so on Fred's videos - is this the intended behaviour?
This is the important one - it means the multiple render targets
isn't working, so you
De: Erik Hofman e...@ehofman.com
On Thu, 2012-04-12 at 10:35 +0200, Erik Hofman wrote:
On Thu, 2012-04-12 at 10:29 +0200, Erik Hofman wrote:
On Thu, 2012-04-12 at 09:01 +0100, James Turner wrote:
On 12 Apr 2012, at 08:24, Renk Thorsten wrote:
3) On my box, all three panels
De: Erik Hofman e...@ehofman.com
On Thu, 2012-04-12 at 11:02 +0200, Frederic Bouvier wrote:
What is your card brand and model ?
It's a NVidia GeForce 9600GT
I think Emilian has the same card and I don't think he had these
problems. Maybe it's a good idea to collect user experience
The driver is somewhat older - as with anything which works fine on
my computer, I'm reluctant to fiddle with it because on past
occasions I have found myself struggling for a few days just to
restore the previous state of the system when an update went wrong,
and I simply don't have the
De: Erik Hofman
On Thu, 2012-04-12 at 11:24 +0200, Frederic Bouvier wrote:
De: Erik Hofman e...@ehofman.com
On Thu, 2012-04-12 at 11:02 +0200, Frederic Bouvier wrote:
What is your card brand and model ?
It's a NVidia GeForce 9600GT
I think Emilian has the same card
I came across a blog post that compares multiple ways to compress
the normals in an 8bit texture and I will try that shortly.
That might be a good idea, at least to save texture memory.
This blog entry is now cited as reference in the Rembrandt wiki page.
-Fred
Thorsten,
I'll add that you get that either if an effect not converted to
Rembrandt is used, or if the default shader has a build error and
OSG fallback to fixed functions. So if the lightfield or the skydome
is not enabled, check the console for a shader build error.
Another possibility is
1) The shadows around the aircraft have a ragged egde. That I
understand is a function of the shadow map size. I can't go beyond
4096, I get an error on the console trying to go higher - but 4096
works fine with acceptable framerates, the edge is just a limit of
my GPU and that is okay.
2)
De: Erik Hofman
On Wed, 2012-04-11 at 06:25 +, Renk Thorsten wrote:
The first line says it all.
Okay... so what does it mean?
It means that a required Framebuffer Object failed to
setup and the fallback isn't OK for Rembrandt.
I'd first try to reduce the size of the shadow
Hi Erik,
De: Erik Hofman
On Wed, 2012-04-11 at 10:18 +0200, Frederic Bouvier wrote:
I have to make guess as I don't have a card that exhibit that
issue.
You can try to edit fg/src/Main/renderer.cxx and change
GL_DEPTH_COMPONENT32 to GL_DEPTH_COMPONENT24. You may also try to
add
On Wed, 2012-04-11 at 13:35 +0200, Frederic Bouvier wrote:
Hi Erik,
With this patch you are trading a bug for a bug. Assigning the
same attachment to three buffers as the same effect than assigning
three different values to the same variable.
I was already afraid something like
I presume you need to start cmake in the correct VS2010 environment. If you try
to enter cl in the command line and it replies Command not found, you need
to locate vsvars32.bat and run it in your command line session.
Jenkins build log, available here (for build 216) :
Hi Thorsten,
The first line says it all.
I'd first try to reduce the size of the shadow map :
--prop:/sim/rendering/shadows/map-size=1024
or reduce the window size : --geometry=800x600
to reduce the memory footprint.
You have a laptop right ? Maybe you have shared memory between the
CPU and
Hi Olaf,
De: Olaf Flebbe f...@oflebbe.de
VC2010 express is only able to generate 32bit programs
Regards,
-Fred
Hi,
One can use the Windows SDK
http://www.microsoft.com/download/en/details.aspx?displaylang=enid=8442
GRMSDKX_EN_DVD.iso to generate 64 Bit Windows Executables.
I won't get the chance to fix this until after the weekend, but in
the meantime at least the Rembrandt performance problems with
random vegetation should be resolved.
Already fixed ;)
Regards,
-Fred
--
Better than
I should raise the point now before things get too complicated to change.
In case you didn't notice, aircraft with Rembrandt lights now exhibit big grey
blobs in the 3d preview of fgrun.
So we should think of a way to identify these objects and remove them in fgrun.
The simplest way is a
That's a possibility (I forgot that one) but it only apply to submodels, right
?
-Fred
- Mail original -
De: Clement de l'Hamaide clem...@hotmail.fr
À: flightgear-devel@lists.sourceforge.net
Envoyé: Jeudi 5 Avril 2012 15:59:18
Objet: [Flightgear-devel] Rembrandt aircraft and
I don't remember every thing I did 5 years ago.
Thank you for refreshing my memory
So please, aircraft developers (Vivian, Gijs, Emilian, ...), use the
nopreview/ tag
Regards,
-Fred
- Mail original -
De: Clement de l'Hamaide clem...@hotmail.fr
À:
- Scenery-terrain seems to cast shadows. Visible especially shortly
before dawn or shortly after dusk. Great feature if so, but seems
also need a lot of perfomance. Maybe it can be made switchable?
- Comparing different aircraft-models showed me, that not the general
number of vertices or
- Scenery-terrain seems to cast shadows. Visible especially shortly
before dawn or shortly after dusk. Great feature if so, but seems
also need a lot of perfomance. Maybe it can be made switchable?
- Comparing different aircraft-models showed me, that not the
general number of
Hi James,
a quick reply, to say that most likely, the shader with a problem is
sunlight.frag
Regards,
-Fred
- Mail original -
De: James Turner zakal...@mac.com
À: FlightGear developers discussions
flightgear-devel@lists.sourceforge.net
Envoyé: Mercredi 4 Avril 2012 15:49:33
in the image in sunlight.frag so this is not the
problem but the inputs are weird, so is the lighting.
You disabled *all* shaders, right ?
Regards,
-Fred
- Mail original -
De: Frederic Bouvier fredfgf...@free.fr
À: FlightGear developers discussions
flightgear-devel
- more feedback
On 4 Apr 2012, at 15:56, Frederic Bouvier wrote:
The shadow is rendered in the image in sunlight.frag so this is not
the
problem but the inputs are weird, so is the lighting.
You disabled *all* shaders, right ?
Just made (and pushed) a Simgear tweak to identify
@lists.sourceforge.net
Subject: Re: [Flightgear-devel] Apologies to Fred - more feedback
On 4 Apr 2012, at 15:56, Frederic Bouvier wrote:
You disabled *all* shaders, right ?
--prop:/sim/rendering/shaders/quality-level=0
In my fgfsrc.
James
On 4 Apr 2012, at 17:00, Frederic Bouvier wrote:
Thank you James,
Can you push that to gitorious ?
Done.
Looking at the language docs, 'varying' in a fragment shader really
is a synonym for 'in', and hence, it makes sense (to me) that
assignment to an input is disallowed
Hi Stuart,
On Wed, Apr 4, 2012 at 5:05 PM, Frederic Bouvier wrote:
You may also want to disable vegetation for better performance :
--prop:/sim/rendering/random-vegetation=0
Regards,
-Fred
Fred,
I'd like to help out fixing bugs/limitations in Rembrandt. Given
I wrote
On 4 Apr 2012, at 17:22, Frederic Bouvier wrote:
It was part of a fix I pushed late yesterday night. My NVidia
driver
didn't protest though.
Thank you for finding this and for the debugging help.
No problem, delighted to help any way I can.
I wasn't complaining at you, more
De: Anders Gidenstam
On Wed, 4 Apr 2012, James Turner wrote:
Guessing that writing to a 'varying' might be the issue, I made a
temporary:
vec3 normal2 = (2.0 * gl_Color.a - 1.0) * ecNormal;
gl_FragData[0] = vec4( (normal2.xy + vec2(1.0,1.0)) * 0.5,
0.0, 1.0 );
De: Martin Spott
Frederic Bouvier wrote:
You can try the last code with
--prop:/sim/rendering/no-16bit-buffer=true
jive: 12:18:06 ~ find .fgfs*
find: No match.
jive: 12:18:17 ~ env | grep \^FG
FG_HOME=/opt/FlightGear
FG_ROOT=/home/martin/SCM/FlightGear/fgdata
jive: 12:18:19 ~ fgfs
De: Stuart Buchanan stuar...@gmail.com
On Wed, Apr 4, 2012 at 5:40 PM, Frederic Bouvier wrote:
As for the performance, I have a vague recollection that you
say that the trees are first drawn alpha-tested and then
alpha-blended. Can you elaborate on this if it's true ?
Yes. There's
Hi,
We have a comics here where the main character is named Lucky Luke. He is a
cowboy who run after the evil Dalton brothers and is famous to fire faster than
his shadow.
Do we want objects ahead of their shadows and play Lucky Luke in fg ?
Rendering half the scene in the shadow map is not
Each aircraft in the inventory needs checking for 2 sided faces,
panel lights need converting, and nice to have are nav. lights and
landing lights. Much of the shared and scenery models need similar
checking: the windsock is an obvious one.
Can you imagine the task for USS Vinson?
Yes, X-Plane 10 also makes use of deferred shading. They just named
it Global Lighting/HDR. Framerates aren't better there as in FGFS as
now.
The difference is only that landinglights there looks much smoother
(no hard edges)
This is just designers' art. The light poles don't have hard
De: Martin Spott
Frederic Bouvier wrote:
You can try the last code with
--prop:/sim/rendering/no-16bit-buffer=true
jive: 12:18:06 ~ find .fgfs*
find: No match.
jive: 12:18:17 ~ env | grep \^FG
FG_HOME=/opt/FlightGear
FG_ROOT=/home/martin/SCM/FlightGear/fgdata
jive: 12:18:19
With Rembrandt, brightness of the scenery seems to depend on the
view's pitch angle a lot. So, when you fly along and pitch up/down
heavily (take the ufo), you see the ground becoming brighter and
darker. It mainly seems to affect the bright (non-shadow) areas.
I believe it was fixed by
P.S.: If you'd like me to test on the Nvidia 7950 GT again, please
yell at me.
You can try the last code with --prop:/sim/rendering/no-16bit-buffer=true
Regards,
-Fred
--
This SF email is sponsosred by:
Try
The light animation is now functional. As an example, the airport
light pole has been converted, and is visible near the maintenance
building at KSFO.
A new option: /sim/rendering/no-16bit-buffer=true is available for
GPU that emit 0x8cda at FBO setup. It should produce ugly specular
though.
The lighting problem has been fixed and the shadows are in since
this morning. Shadow resolution is configurable in the preferences
by changing /sim/rendering/shadows/map-size before starting fgfs.
I'll try to add a listener to make it settable at run-time.
Next step will be to add lighting
Hi Martin,
- Mail original -
De: Martin Spott
Martin Spott wrote:
http://foxtrot.mgras.net/bitmap/FGFS/fgfs-rembrandt_01.png
Default console output is here - nothing particularly exciting:
http://foxtrot.mgras.net/bitmap/FGFS/fgfs-rembrandt_01.txt
The interesting part is
What is the exact g-buffer format rembrandt tries to set up?
NV4x/NV5x have some serious restrictions.
1 attachment is RG16 (normals.xy)
2 attachments are RGBA8 (diffuse color, and monochrome specular, emissive and
shininess)
1 GL_DEPTH_COMPONENT32 (depth)
Regards,
-Fred
The first batch of sources has been pushed to gitorious. These commits are
intended mainly to check that the classical (forward) renderer is not broken
and works as usual. They will also permit one to challenge his GPU and see
how it behaves in front of the beast.
In the plan exposed previously
De: James Turner
On 25 Mar 2012, at 18:49, Frederic Bouvier wrote:
The Rembrandt renderer is enabled with the --enable-rembrandt
option.
*ALL SHADERS SHOULD BE SET TO OFF* unless someone want to begin to
convert other shaders.
On Ati 5770 / Mac / OSG 3.0.1, this is basically alive
- Mail original -
De: James Turner zakal...@mac.com
À: FlightGear developers discussions
flightgear-devel@lists.sourceforge.net
Envoyé: Dimanche 25 Mars 2012 21:51:19
Objet: Re: [Flightgear-devel] [Rembrandt] the plan
On 25 Mar 2012, at 20:39, Frederic Bouvier wrote:
It means
Thanks, I prefer that one ;-)
-Fred
- Mail original -
De: Olaf Flebbe f...@oflebbe.de
À: FlightGear developers discussions
flightgear-devel@lists.sourceforge.net
Envoyé: Vendredi 9 Mars 2012 23:00:47
Objet: Re: [Flightgear-devel] Rembrandt feedback (was: Project Rembrandt -
De: Erik Hofman
On Wed, 2012-03-07 at 11:54 +0100, Gijs de Rooy wrote:
Martin wrote:
On my (my wife's) system (Linux Nvidia proprietary driver) this
change
turns PAPI/VASI lights into huge, illuminated baloons. Therefore
I
strongly propose to just revert this change.
De: thorsten i renk
I think that you have to add new techniques (an XML element) to
existing effect file. You leave the current technique intact and
copy/paste it in the same file, add or change what is needed and
Modify its predicate.
Look at model-default.eff that implements 2
Techniques (with their predicate) are tested in
ascending order of their index (the n attribute), so you can
create a new technique with a lower index than the one for the
current technique and add a predicate that test (for example)
/sim/rendering/lightfield.
Thanks Frederic - this
Hi Lauri,
Hi all.
3. define an XML format for describing the two possible rendering
pipelines (the current and new). The format will introduce
optional elements (such as shadows, ambient occlusion, glow).
I want to point out my work on my newcameras branch:
Now that the introduction of Rembrandt next, provided that the current
operation is retained, has been accepted, it is time to outline the plan that I
intend to apply:
1. update SimGear with additions made on the effects and animations (done). The
changes include the creation of positioned
So may I ask a kind soul with write access to the data repository, or
capable of submitting a merge request, to review all effect files
and add the test of the new property to every technique of every
effect, and add a new predicate to technique not having one for the
moment. The code snippet
Hi Olaf,
not all shader are converted, so you'd better disable all of them (Hinted by
the error in GEOMETRY that is not used in Rembrandt)
The 'unsigned' error shows that the driver is lacking, or maybe a declaration
is missing. OSG defines an uniform of type 'unsigned int'
The error on image
Am 06.03.12 23:09, schrieb Olaf Flebbe:
PixelBufferCocoa :: realizeImplementation not implemented yet
Hi Fred
Just curious about this line, do you think recent osg cocoa windowing
under OSX will be supported by rembrandt?
Sorry Yves, I have no idea. This error message seems to imply
Hi Olaf,
maybe I can tell you from a screenshot. From memory, we need at least
GL_ARB_framebuffer_object and float_texture
I don't know what extension or declaration is required to have unsigned int
uniforms (osg_FrameNumber in src/Main/CameraGroup.cxx)
Regards,
-Fred
- Mail original
Hi Thorsten,
De: thorsten i renk
I agree that we should merge the project rembrandt work sooner
rather than later. However, we should also take some time and
effort to make sure Thorsten's sky/haze/horizon effects are
accounted for as well. I don't know what issues we will find
Do you mean that v1.1 as posted on the forum can't be committed
as is to git ?
Technically it could, but at the expense of forcing everyone to use
lightfield shaders. It overwrites for instance the default terrain
and model shaders.
The reason why this is implemented in that way is
As a migration path, I verified that my changes to simgear are
compatible with the current next branch. If there is no objection,
I will commit these changes to gitorious and begin to prepare
the flightgear code in a way that would allow to keep the current
renderer.
As I received no
Hi Curt,
De: Curtis Olson
On Sun, Mar 4, 2012 at 9:25 AM, Frederic Bouvier wrote:
As a migration path, I verified that my changes to simgear are
compatible with the current next branch. If there is no
objection,
I will commit these changes to gitorious and begin to prepare
But whenever talking about git rebase one should mention that THOU
SHALT NOT rebase a branch which you've ever pushed. Because if
someone ever pulled your
What I always do, before pushing an update for the next branch is:
As stated previously, a code that is not run is unlikely to be
Hi,
in preparation to the introduction of Rembrandt in the main branch, we should
ensure that effect will be compatible with the current renderer. For that, I
added a new property to preferences.xml and modified Effects/model-default.eff
to test this new property. It will be also available to
De: Torsten Dreyer
Hi Fred,
today, I tried Rembrandt on two Linux machines, both running 64bit
openSUSE 12.1 (this is Linux) with nvidia'd driver 295.20.
FlightGear ist started in windows mode.
1.) My Notebook having a Intel dual core@1.6GHz, 4GB RAM and a
GeForce Go 7400 with 256MB
De: Torsten Dreyer
Am 02.03.2012 19:03, schrieb Frederic Bouvier:
Now that release 2.6 is out, perhaps it is time to discuss further
developments concerning project Rembrandt.
Although it may already produce pretty images when used by a
talented designer (see for example the P92
- Mail original -
De: Torsten Dreyer tors...@t3r.de
Am 03.03.2012 12:33, schrieb Frederic Bouvier:
But just curious : how many of you reviewed the current code ?
n+1
Just checked out your project/rembrandt branches. Code compiles fine
on
64bit openSUSE 12.1 with OSG from
De: ThorstenB
Also, the project is quite good in finding issues, once new stuff is
in git. But, generally we are not so good in fixing problems then.
Notoriously, everyone has just too little spare time ;-), so a lot of
issues just starve in the tracker. And with hard-core OSG stuff,
Maybe there is a missing dependency that silently discard genapt from the build
Regards,
-Fred
- Mail original -
De: Jason Cox
À: flightgear-devel@lists.sourceforge.net
Envoyé: Samedi 3 Mars 2012 23:41:41
Objet: [Flightgear-devel] terragear not building and installing genapts
Hi
Now that release 2.6 is out, perhaps it is time to discuss further developments
concerning project Rembrandt.
Although it may already produce pretty images when used by a talented designer
(see for example the P92), it is however, not usable by most people.
The Wiki page summarizes the list of
De: Anders Gidenstam
On Fri, 2 Mar 2012, Frederic Bouvier wrote:
* Register all transparent surfaces
Just a quick question: Doesn't OSG already detect translucent meshes
and treat them differently from the rest during rendering? Hence,
couldn't this classification be done more
Curt and Stuart are promoting FligthGear live right now!
Do they have a recording available for download ?
Try :
http://fr.twitch.tv/fsbreak/b/309747803
-Fred
--
Virtualization Cloud Management Using Capacity
Hi Gene,
It appears that the windows-release target rebuilds _everything_
regardless of whether or not it's necessary. This build gets
triggered multiple times for some reason and due to disk
thrashing, renders the machine basically unusable until it's done.
Since this machine also
I just don't understand why these submissions are not just refused with a baked
reply. You all are burning yourself and then will blame the community as a
whole in anger.
Please enforce the rules !
Regards,
-Fred
Gijs de Rooy gijsr...@hotmail.com a écrit :
Oliver wrote:
Goind to post it
Hi,
I am away from my computer so I can comment specifically any point, but I have
few questions :
1. did these problem occurs in the release candidates or are specific to the
final version ?
2. We know that you didn't install in Program Files but we don't know where
exactly. Could there be
Pushing most of the haze shader computation from the vertex to the
fragment level would seem to suggest an approximately constant cost
for the haze for the same view regardless of scenery complexity since
the number of hazy fragments remain about the same.
Thanks for the explanations -
Pushing most of the haze shader computation from the vertex to
the fragment level would seem to suggest an approximately constant
cost for the haze for the same view regardless of scenery complexity
since the number of hazy fragments remain about the same.
Thanks for the
And they even have an old screenshot of FGSD showing LFPX (the airfield where I
used to fly in RL)
ROFL
-Fred
--
Try before you buy = See our experts in action!
The most comprehensive online learning library for
Hi Robert,
De: Robert
Hi everybody,
since one or two weeks I have the following problem:
When I start fgfs it tells me that it needs version 2.7.0 of fgdata
and quits immediately.
I am using SimGear/Flightgear next branch, and fgdata master
branch.
After maually changing the
You can try to switch on ENABLE_UIUC_MODEL too as one of the undefined relates
to uiuc
-Fred
- Mail original -
De: D-NXKT
Objet: [Flightgear-devel] LaRCsim broken?
Hello Fred,
thanks for your reply. I wasn't aware of this option.
I assume configuring fg with Cmake means
Make sure that LaRCsim is selected when configuring fg with Cmake
Regards,
-Fred
- Mail original -
De: D-NXKT d_n...@yahoo.de
À: flightgear-devel@lists.sourceforge.net
Envoyé: Mardi 31 Janvier 2012 01:02:27
Objet: [Flightgear-devel] LaRCsim broken?
Hello,
could it be that
101 - 200 of 887 matches
Mail list logo
