Re: [Flightgear-devel] simgear zlib 1.2.6 lowlevel

[Olaf Flebbe <fgfs@of...>]

Hi,

I cannot reproduce the problem, since I do not use MacPorts. IMHO we should simply copy from OSG CMakeModules/FindZLIB.cmake  to Simgear CMakeModules, in order to force same semantics on OSG and Simgear.

Greetings
Olaf
> 
> Hi James
> 
> Didn’t dive into but noticed OSG has probably a more sophisticated cmake 
> zlib check already. Maybe it’s worth to have a look there?
> 
> 

Olaf

Re: [Flightgear-devel] [Rembrandt] the plan

[Frederic Bouvier <fredfgfs01@fr...>]

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.

Regards,
-Fred


> 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 example in the repository.
> 
> Martin: I know you prefer to handle shared model modification
> but I would like to commit a quick example : the apt-light model.
> So please forgive me :)
> 
>  
> > 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 (see below), I skipped step 3.
> > (define an XML format for a configurable renderer) as it appears 
> > to be more involved than expected. So what you have is a buggy 
> > step 5. :) Buggy because for some reason, sun light depends on 
> > the orientation of the camera. But you should get an image.
> > 
> > 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.
> >
> >
> > 
> > > 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" uniforms, ie on which applies a MODELVIEW matrix 
> > > transformation, which serve to indicate the position of light 
> > > sources in the shaders, and "light" animations (spot and point).
> > > 
> > > 2. modify the Renderer class to separate from the scenegraph,
> > > terrain and models on one hand, the skydome and stars on the 
> > > other, and finally the clouds. These three elements are passed 
> > > to the CameraGroup class in order to be treated separately in 
> > > the new rendering engine (and put together in the current one).
> > > 
> > > 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).
> > > 
> > > 4. modify the base effects for defining the techniques that apply
> > > to one or the other renderers (a request for assistance has already
> > > been sent to prepare the work and ensure that existing effects
> > > does not apply to new rendering mode).
> > > 
> > > 5. implement in the new rendering engine the basic lighting
> > > equation (ambient + diffuse + specular)
> > > 
> > > 6. add the shadows
> > > 
> > > 7. add light management
> > > 
> > > 8. with the help of Thorsten, add atmospheric scattering, haze
> > > and the light field
> > > 
> > > 9. add the ancillary effects (ambient occlusion and glow)
> > > 
> > > 10. help migrate models and effects
> > > 
> > > I certainly forgot something. Let the discussion plug the holes

Re: [Flightgear-devel] [Rembrandt] the plan

[Frederic Bouvier <fredfgfs01@fr...>]

> 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

[Flightgear-devel] Rembrandt - Some Feedback

[Heiko Schulz <aeitsch_13@ya...>]

Hello,

I updated my FGFS yesterday and today, after a whole while.
Of course I tried Rembrandt and I'm impressed- finally shadows again!
Rembrandt does work here without any error messages.
(DualCore 2,6 Ghz, 4GB RAM, Nvidea GeForce GTX460)

What I noticed is, that Anti-Aliasing does not work, and the quality of the shadows is not good yet, though using the 4096px-size. 
See image [1] below.
Changing shadow size at runtime gives me following error message:
"Warning: detected OpenGL error 'invalid operation' at after RenderBin::draw(..)"

Sometimes I see some Z-fighting, but can be explained with the strobes/beacon animation.
What I do like is, that even the cockpit has now self-shadowing- can look great!
See Image [2] below

RAM-Usage looks o.k. to me, not much different as before.

Framerate-Perfomance is different:
With default sceneries, disabled random vegetation and disabled randon objects I get between 30-60fps, depending on view and complexity of the aircraft.

With enabled random-vegetation framerates goes down to less than 30-15fps, so about the half I got before.
The density of random vegetation is set 1.0.
That's something I did not expected, as the 3d-clouds doesn't show this behavior.

To my surprise some aircraft does not have any problems with random vegetation enabled:
First I thought that if an aircraft has the more faces the more power we need to achieve a good frame rate, but looking at the RAH66 from the forum, the B1b "Bone" or a converted MSFS-model with about 50000vertices it seems not the case.
On the other side the C337G or the C172p has a quite bad framerate compared with.
 
Maybe face-numbers, number of objects objects or xml's as reason-  I don't know, I will test it deeper and provide the numbers here.


The 3d-clouds shows some z-fighting as well, and the draw order seems to be broken. See image [3] below

With Rembrandt disabled, some shaders are broken, I already filed a bug-report, and work is going on there.

It looks promising, but also still like a long way to go, especially as many aircraft and shaders has to be adapted.

[1]http://www.hoerbird.net/fgfs-screen-588.jpg
[2]http://www.hoerbird.net/fgfs-screen-586.jpg
[3]http://www.hoerbird.net/fgfs-screen-587.jpg

Cheers
Heiko







still in work: http://www.hoerbird.net/galerie.html
But already done: http://www.hoerbird.net/reisen.html

Re: [Flightgear-devel] Segmentation fault after setting new time of day

[Erik Hofman <erik@eh...>]

On Sat, 2012-03-31 at 11:29 +0200, Erik Hofman wrote:

> Looks like something has changed in relation to avionics sounds since
> commenting out line 156 of Sound/fg_fx.cxx fixes the problem while
> suspending the aircraft effects (pause) still works.

Ah found it, it was caused by the way AI models are handled now. A fix
is in git.

Erik

(Sometimes it's difficult to detect if your own development work on a
related project is causing the problem)

Re: [Flightgear-devel] Segmentation fault after setting new time of day

[Erik Hofman <erik@eh...>]

On Fri, 2012-03-30 at 13:16 +0200, Erik Hofman wrote:
> Hi,
> 
> I was wondering, after pulling simgear and flightgear from git since a
> long time I now get a segmentation fault when changing the time of day
> using the menu structure.
> 
> It seems to be related to SampleGroup::suspend and at first I thought it
> might be a problem with my own AeonWave-OpenAL implementation but I seem
> to get the same behavior with OpenAL-Soft.
> 
> Does anybody else see this or am I the only one with this problem?

Looks like something has changed in relation to avionics sounds since
commenting out line 156 of Sound/fg_fx.cxx fixes the problem while
suspending the aircraft effects (pause) still works.

Erik

Re: [Flightgear-devel] [Rembrandt] the plan

[James Turner <zakalawe@ma...>]

On 30 Mar 2012, at 16:03, Frederic Bouvier wrote:

> 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.

Basically works here, but the shadow seems to be drawn with Z-fighting:

	http://files.goneabitbursar.com/fg/rembdrandt-shadows-ati5770-mac.png

If I move the aircraft, I can see the whole shadow is defined, but sometimes being drawn underneath the terrain surface.

Ati 5770 Mac  as before. Changing the shadow map size from 4096 to 8192 didn't make any difference to the issue.

James