On 03/07/2019 21:47, Tomas Eilsoe wrote:
We observe a large period of waiting between the cull and the draw calls, which
seems weird. See attached pic.
I suspect that this is because of vsync; your frame rate is ~60hz which
is likely the monitor frequency.
With my system (AMD R9-290) I
On 26/01/2019 20:38, Robert Osfield wrote:
I have a few more fixes to the 3.6 branch, so have gone ahead and
tagged 3.6.4-rc3:
I've extensively tested FlightGear against 3.6.4-rc3 (several hundred
hours of flight time) and so far it's been rock solid; the change (from
our side) to using the
Hi Robert;
As a general comment, if you could use the OpenSceneGraph-3.6 branch
I'm still using 3.7 - I'll switch over to 3.6 soon; although it's a bit
tedious because I have to rebuild everything and it takes a good few hours.
base to work from. I'd also recommend checking the whole
I've just got another of these problems.
This is after changing all of the osgDB::read into osgDB::readRef
(simgear commit cb024dd82d4c384df0b599640a98e762fbf66688) and 5days of
flight time testing (not all the same run, FG was restarted many
times) I've hit what looks like a the same problem as
On 17/01/2019 14:39, Voerman, L. wrote:
I am out of suggestions, but here are a few questions that I can come
up with:
Thanks; much appreciated.
- did the problematic node come out of the cache, or did it come fresh
from disk?
(modelResult._status has this info)
modelResult
Voerman, L. wrote:
Hi Richard,
I can't see how you can get a segfault on the line you indicate, so I
guess the node is somehow corrupted and the segfault is somewhere in
the copyOp.
I can only guess at what might be going wrong there, but my first
guess would be the DEEP_COPY_USERDATA
On 15/01/2019 09:03, Robert Osfield wrote:
illustrated it well) and I'm currently flying one of my long test routes.
Fingers and toes crossed.
..and alas after 30h I've got a similar looking problem; the pattern is
the same i.e. DatabasePager loading something whilst ObjectCache is
Thanks Robert and Laurens for your responses.
It all makes a lot of sense and it is the solution that I was looking
for all along but failed to find because I didn't look hard enough even
though I should have been able to figure it out - so thanks for the
guidance. Most of my effort went into
On 11/01/2019 07:38, Robert Osfield wrote:
If you are able to characterise what is going on then let me know and
I may be able to help spot a solution. Having a small example that
For some reason my last message doesn't seem to have made it to this
list; it's on the forum[1]
I've diagnosed
Chris Hanson wrote:
> Ok. Is this a recent issue or do you know when it appeared? That's some
> delicate code in there...
Yeah I noticed that there's some complex code and thread sensitive (i.e.
delicate) stuff; it's taken me a long time to figure out what it's doing and
why it is being
Chris Hanson wrote:
> Due to the domain complexities, this is REALLY something probably the
> FlightGear community knows anything about.enegraph.org[/url]
>
I'm a FlightGear core developer and I can confirm that this is something that
we know about and I'm trying to fix.
Cheers
--Richard
On 10/01/2019 17:08, Robert Osfield wrote:
Hi Richard,
The info you've provided doesn't give us much to go on to understand
This is following on from my (somewhat lengthy) message[1] on
2019-01-08, 00:15Z which has context at the start of that message, but
for ease of reading it is as below.
I've now wired in the ReadWriteMutex and initial impressions are promising;
each one of the "expired cannot check for expiry" is a potential gateway into
the problem (assuming of course that I'm right about what the problem is).
Code:
165.86 [WARN]:OSG
Using osg master; self built; application FlightGear; Win32 x64; MSVC 2015.
In FlightGear when OSG warning Warning: deleting still referenced object
... the final reference count was" is detected in our NotifyHandler we
throw an exception (probably the only reliably thing to do, as this
14 matches
Mail list logo
