Hi,
Thanks for the testing and support guys. The sliding helicopters where
really frustrating for me too.
I liked Alex's screenshot, that requires some skill...
I will go through some comments below:
Brandano wrote:
As far as keyboard brake input, i believe this calls for some sort of
Hi,
A long time ago I started working on a different implementation for
YASim static friction. With help from Csaba and Mathias Fröhlich the
patch worked but I never finished polishing it to submit a final
version. I finally got back to it and, although it is working on my
tests, I am not sure it
Durk Talsma wrote:
Hi Curt,
A shakey power supply would indeed be my alternative hypothesis.
Hi Durk,
I am not an electronics expert but I guess the temperature will affect
the power supply too. And I think modern CPU/MB have temperature check
built in and slow the clock to compensate.
jean pellotier wrote:
Are you seeing any error messages in the console at all?
Usually if there is a shader issue, then some error messages are displayed
there.
However the colour problems you are seeing are quite strange.
Hi,
I just upgraded my computer and got an ATI video card for
Diogo Kastrup wrote:
On an unrelated issue, I am not sure if this is a problem with ATI cards,
but I got
frustrated with the frame-rate I got after the upgrade. I was getting around
30-40 fps
with the old machine and now it is around 35-45 with a intel I-7 860, ATI
HD4890, 4gB
DDR3
Strange indeed.
The details of the pall seem to depend on time of
day (angle of sun?).
The pall depends very stronly on direction of view.
For some directions, the pall is not noticeable, but
panning the view a tiny amount brings the pall back
in full force.
I am not familiar with
Tim Moore wrote:
One thing to try is #ifdef ing out the parts of the fragment shaders
that refer to OpenGL state.
So, turn off 3D clouds and trees.
In default.frag and mat-anim.frag, #ifdef or comment out the clause
that begins
if (gl_FrontMaterial.shininess 0)
I just tried this with no
Hello Mathias,
I am trying to use the get_body method in that old gear friction patch
of mine but I am having some trouble. I think the returned bodyToWorld
matrix is just the orientation of the carrier, without the translation.
Is this correct or is just my lousy math bugging me? If this is the
Mathias Fröhlich escreveu:
Prototyped and checked in.
I don't claim that it is bug free. So help chasing them :)
Feel free to ask if something is too bad documented or does not work as
expected.
Hi Mathias,
I am sorry for the delay, finally I could get back to this. Besides
moving to a
Hello,
Mathias Fröhlich wrote:
Ok, I am working on a major overhaul to speed up and generalize the ground
intersection stuff.
So parts of what you code is already covered by that more general approach.
When I look at your patch, the only thing that is missing so far in the
ground
Csaba, thank you very much for testing. See my comments below.
Em Seg, 2009-02-23 às 04:59 +0100, Csaba Halász escreveu:
I tested with the bo105 on solid ground first. It doesn't move an inch
with engines shut down. During startup, it doesn't turn either. The
s76c (which has wheels instead of
Em Seg, 2009-02-23 às 17:58 -0300, Diogo Kastrup escreveu:
The carrier sailing out from underneath is strange, it looks like the
groundcache can't finding a intersection with the ground for these
aircrafts and it is using a fallback value. Can someone check if this
happens without my patch
Hello,
I finally got this working with the carrier, here is the patch. Please
let me know what you guys think about it.
Features:
- No more sliding when should be stopped.
- better behavior when cornering
- better braking behavior *
Problems:
- More information about the brake system is needed
Em Qui, 2009-02-05 às 11:34 +, Martin Spott escreveu:
To put it a bit provoking (no personal offense intended!) for the sake
of getting the status right, this looks to me that we're never going
to
have this feature of proper tire/ground reaction simulation in
FlightGear simply because the
Hello,
I have posted on this list before but I guess I never introduced myself.
I am a Brazilian system analyst with experience in C programming and a
little C++. I have no real pilot experience and no physics formation.
I have a crude patch to improve gear friction in yasim using the method
Em Seg, 2009-02-02 às 20:02 +0100, Melchior FRANZ escreveu:
The problem is that I have to keep the stuck point moving with the carrier
but the carrier update is not on the same frequency than the FDM
update.
A dependency on the AI update rate would probably not be very
welcomed. BTW: I
Em Qua, 2008-02-06 às 16:57 +0100, Frederic Bouvier escreveu:
Are you aware of this tool : http://dryad.stanford.edu/
Or this one: http://arbaro.sourceforge.net/
Diogo
-
This SF.net email is sponsored by: Microsoft
Defy
Hi,
This is a revival of the old thread small bug in YASim-gears. I'm
trying to improve the static gear friction using the damped spring (1 cm
length) around a stuck point method cited by Andy Ross. The patch is
already in the works and somewhat functional, but I could use some help
in the
Alex Romosan wrote:
still trying to figure out the real reason why the nvidia driver is
slow when we enable GL_POINT_SMOOTH in fgfs (and learning a lot more
about openGL then i ever wanted to know).
I've modified your test program to follow what is done in flightgear,
and looks like the
Erik Hofman wrote:
Ok, I've added support for point sprites. I does indeed increase the
framerate in my PC.
I find this a rather peculiar extension though. Especially since SGI
has
always been using point sprites without naming them.
You know, there's this thing about points, if you
20 matches
Mail list logo
