However, the (so far to me unknown) C++ subrouting actually bringing
clouds into the visibly rendered scenery is even way slower - I can read
the message that the property writing is over after the expected 2.5
seconds, but continue to see clouds appear in the scenery for 30 seconds
and more.
Not sure, maybe it is connected with an other issue we recently
discovered. There are indeed some OSG operations which don't scale
well.
For example, OSG keeps a simple list of references at each shared
model - so each shared model knows all nodes it is shared to. Adding a
new member to the
thorsten.i.r...@jyu.fi wrote:
However, the (so far to me unknown) C++ subrouting actually bringing
clouds into the visibly rendered scenery is even way slower - I can read
the message that the property writing is over after the expected 2.5
seconds, but continue to see clouds appear in the
Op 15-11-10 11:19, Martin Spott schreef:
This effect of 'asynchronously', 'delayed' loading of 3D models sounds
quite familiar to me and might reflect an intended feature in order to
save the framerate in these moments when a densely modelled chunk of
Scenery appears in the view.
Do 3D
With regard to the speed of loading models from Nasal into the scenery I
was writing about a while ago, I have made some discovery yesterday.
I was testing a setup in 2.0.0 with some heavy numerics running on the
second CPU, and this pushed the behaviour of the framerate into the
behaviour I was
From: thorsten.r...@jy... - 2010-11-12 10:13
I still have no real understanding why this is so, or why loading a large
number of *identical* models into the scenery should take a long time (I
would think that one can make use of the fact that there are really
multiple copies of the same model
6 matches
Mail list logo
