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 in the
On Sat, 14 Apr 2012, Frederic Bouvier wrote:
Fred, is there a reason the shadows on the instrument faces are so
jumpy?
Probably :) one reason is the moving sun that few other games have
(not speaking of flight simulators, of course)
Ok. :) I noticed the Anteworld demo of Outerra has the
I have the same bug when the skydome scattering shader is enable.
Are you sure you have disable skydome scattering shader ?
Look, I literally wrote the part of the effect file that controls what shaders
run when the skydome shader is enabled and what shaders don't, I did a fair
share of the
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
On Fri, 13 Apr 2012 06:23:23 +, Renk wrote in message
e495a106ff5f31448739e79d34138c190ec04...@mbs3.ad.jyu.fi:
Here is a video with a steady view to see shadow stability.
Okay, thanks, that's helpful. My flickering is a bit worse than in
the first case in this video, but not much.
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 in the
sunlight shader with
I think that is what we have for now. You can do better by increasing
your shadow map size to 8192 or 16384, but at the 16384 resolution my
performance goes into the tank, and at 8192, there are still many shadow
artifacts due to lack of resolution. (clearly blocky/xelated/aliasing
edges,
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 have no chance of seeing
Thorsten wrote:
I think that is what we have for now. You can do better by increasing
your shadow map size to 8192 or 16384, but at the 16384 resolution my
performance goes into the tank, and at 8192, there are still many
shadow artifacts due to lack of resolution. (clearly
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 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
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 in the screen edges show the same image -
not so on Fred's videos - is this the intended
The disappearing shadow was caused by the sun camera and range animation
and was fixed a while back - can you confirm that you are using the very
latest fg/sg/fgdata? And it's probably worth checking that you have the very
latest nVidia drivers.
FG, SG and FGData are pulled and
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 in the screen edges show the same image
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
On Thu, 2012-04-12 at 10:43 +0200, Erik Hofman wrote:
even GL_RGB16 works.
And therefore I propose this patch.
Erik
diff --git a/src/Main/renderer.cxx b/src/Main/renderer.cxx
index 1c6e77b..1c5ea0a 100644
--- a/src/Main/renderer.cxx
+++ b/src/Main/renderer.cxx
@@ -65,6 +65,7 @@
#include
On Thu, 2012-04-12 at 11:02 +0200, Frederic Bouvier wrote:
De: Erik Hofman e...@ehofman.com
even GL_RGB16 works.
For all the buffers or only the normal buffer ?
I only tested the normal buffer.
You're not supposed to have multiple render target of different element
size. RGBA8 = 32bits,
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 with
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
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 and I don't think he had these
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
On Thu, 2012-04-12 at 11:35 +0200, Frederic Bouvier wrote:
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 ?
On Thu, 2012-04-12 at 11:31 +0200, Erik Hofman wrote:
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
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
On Thursday 12 April 2012 11:24:23 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 and I don't think he had these
The amount of shadow I see depends on the angle of the view axis
with the sunlight direction - under some angles I see dark
shadows, under some
angles I see no shadows at all
Hi Thorsten,
I have the same bug when the skydome scattering shader is enable.
Are you sure you have disable
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)
The first line says it all.
Okay... so what does it mean?
I'd first try to reduce the size of the shadow map :
--prop:/sim/rendering/shadows/map-size=1024
No success, problem persists.
or reduce the window size : --geometry=800x600
to reduce the memory footprint.
Same as above, problem
On Wed, 2012-04-11 at 06:25 +, Renk Thorsten wrote:
The first line says it all.
Okay... so what does it mean?
I'd first try to reduce the size of the shadow map :
--prop:/sim/rendering/shadows/map-size=1024
No success, problem persists.
or reduce the window size :
On Wed, 2012-04-11 at 06:25 +, Renk Thorsten wrote:
The first line says it all.
Okay... so what does it mean?
I'd first try to reduce the size of the shadow map :
--prop:/sim/rendering/shadows/map-size=1024
No success, problem persists.
or reduce the window size :
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
Be sure I value your feedback, but we are exploring new lands here.
There is not so much OSG deferred rendering example or real
application around, so please be forgiving.
And I don't think Flightgear is unusable for anybody. The Rembrandt
renderer is optional and the classical/2.6 renderer
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
the --bpp=32 option to the fgfs
Thorsten wrote:
-Original Message-
From: Renk [mailto:thorsten.i.r...@jyu.fi]
Sent: 11 April 2012 09:33
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] No Rembrandt here...
Be sure I value your feedback, but we are exploring new lands here.
There is not so
Vivian, or anyone else with optional-Rembrandt experience, feel free to add
some instructions on how to
make an aircraft support both renderers to
http://wiki.flightgear.org/Project_Rembrandt#Porting_aircraft
So we can forward aircraft devs to that (once Rembrandt is stable/complete).
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 that was
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 that
On Wed, 2012-04-11 at 14:15 +0200, Frederic Bouvier wrote:
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
Hi Thorsten,
I think that is what we have for now. You can do better by increasing your
shadow map size to 8192 or 16384, but at the 16384 resolution my
performance goes into the tank, and at 8192, there are still many shadow
artifacts due to lack of resolution. (clearly blocky/xelated/aliasing
Just freshly pulled and compiled GIT, fresh FGData master, trying to start with
--enable-rembrandt results in garbage on the screen and an impressive list of
errors - (I've omitted messages with meaning known to me in the following as
well as repetitions). Running without Rembrandt looks fine
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
43 matches
Mail list logo
