Discussion:
Fwd: [flightgear:codetickets] #1976 Please Re-Instate the Random Vegetable Slider
(too old to reply)
James Turner
2017-06-30 12:19:03 UTC
Permalink
Would anyone more knowledgeable about the rendering dialog care to respond to this ticket?

Kind regards,
James
Subject: [flightgear:codetickets] #1976 Please Re-Instate the Random Vegetable Slider
Date: 29 June 2017 at 16:06:21 BST
[codetickets:#1976] <https://sourceforge.net/p/flightgear/codetickets/1976/> Please Re-Instate the Random Vegetable Slider
Status: New
Milestone: 2016.3
Created: Thu Jun 29, 2017 03:06 PM UTC by Huntley Palmer
Last Updated: Thu Jun 29, 2017 03:06 PM UTC
Owner: nobody
Random vegetation value has a critical effect on frame rate. For the user of an average powered setup, fractional numbers below 1.0 can make the differnce between useable and non. With the slider, 0.1 yielded a pleasing visual with still useable frame rates. With the new menu, 0.5 is the permitted minimum.
Now, with random vegetation disabled my frame rate / spacing is 30/48 and as soon as random vegetation is set to the lowest I'm permitted to set, fram rate is 19/68. I'm able to counter this with command line options but many people don't know how.
Please put the slider back in play, preferably with a log scale so those of us with less than stellar performance can use this feature.
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/flightgear/codetickets/1976/ <https://sourceforge.net/p/flightgear/codetickets/1976/>
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/ <https://sourceforge.net/auth/subscriptions/>
Emilian Huminiuc
2017-06-30 12:39:48 UTC
Permalink
Post by James Turner
Would anyone more knowledgeable about the rendering dialog care to respond
to this ticket?
Kind regards,
James
Subject: [flightgear:codetickets] #1976 Please Re-Instate the Random
Vegetable Slider Date: 29 June 2017 at 16:06:21 BST
[codetickets:#1976]
<https://sourceforge.net/p/flightgear/codetickets/1976/> Please
Re-Instate the Random Vegetable Slider
Status: New
Milestone: 2016.3
Created: Thu Jun 29, 2017 03:06 PM UTC by Huntley Palmer
Last Updated: Thu Jun 29, 2017 03:06 PM UTC
Owner: nobody
Random vegetation value has a critical effect on frame rate. For the
user
of an average powered setup, fractional numbers below 1.0 can make the
differnce between useable and non. With the slider, 0.1 yielded a
pleasing visual with still useable frame rates. With the new menu, 0.5
is
the permitted minimum.
Now, with random vegetation disabled my frame rate / spacing is 30/48
and
as soon as random vegetation is set to the lowest I'm permitted to set,
fram rate is 19/68. I'm able to counter this with command line options
but many people don't know how.
Please put the slider back in play, preferably with a log scale so those
of us with less than stellar performance can use this feature.
I'm ot gonna comment on the rendering dialog design as this was Stuart's
decision IIRC.
Since it's been a few years since I last mentioned this, could I remind you
of the simple yet effective way of removing almost all of the performance
hit of the vegetation by reenabling display lists for them.
I know your argument that display lists are ancient and probably converted
by the gpu into something more modern and that this would introduce some
overhead, but I've been running the "hack" locally and have not seen any
issue with it even on _modern_ cards for all these years since I last
mentioned this, even with very high tree densities. i.e. the perf hit of
tree density 10 or max was similar on an ancient 8800GT and on a more
modern 760gtx, and almost negligible fro what used to be density 5 or less
(nevermind that density >3 doesn't make much sense since it creates many
almost entirely overlapping trees)
To achieve this line 148 in simgear/scene/tgdb/TreeBin.cxx needs to be
commented-out/removed
(VBOs would probably be a saner approach, but every time I tried them they
would cause a segfault in the trees/vegetation case)
I'm attaching the "patch".
Regards,
Emilian
You can see here

http://s.go.ro/t31y96eu

what kind of densities become "workable"
Those also include an experiment of using a bunch of trees / sprite instead of
isolated trees.


Regards,
Emilian
Stuart Buchanan
2017-07-04 08:02:03 UTC
Permalink
Hi Emilian,
Since it's been a few years since I last mentioned this, could I remind you
of the simple yet effective way of removing almost all of the performance
hit of the vegetation by reenabling display lists for them.
I know your argument that display lists are ancient and probably converted
by the gpu into something more modern and that this would introduce some
overhead, but I've been running the "hack" locally and have not seen any
issue with it even on _modern_ cards for all these years since I last
mentioned this, even with very high tree densities. i.e. the perf hit of
tree density 10 or max was similar on an ancient 8800GT and on a more
modern 760gtx, and almost negligible fro what used to be density 5 or less
(nevermind that density >3 doesn't make much sense since it creates many
almost entirely overlapping trees)
To achieve this line 148 in simgear/scene/tgdb/TreeBin.cxx needs to be
commented-out/removed
(VBOs would probably be a saner approach, but every time I tried them they
would cause a segfault in the trees/vegetation case)
I'm attaching the "patch".
Sorry - either my memory is bad, or I missed that discussion years ago.

Unless someone object vociferously, I'll test this myself and enable it.

-Stuart
Emilian Huminiuc
2017-07-04 08:16:12 UTC
Permalink
Post by Stuart Buchanan
Hi Emilian,
Sorry - either my memory is bad, or I missed that discussion years ago.
Unless someone object vociferously, I'll test this myself and enable it.
-Stuart
Hi Stuart,

IIRC the discussion got sidetracked as we both tried doing_the_right
_thing[tm] aka enabling VBOs on trees too
(as they are done for random-buildings), and hit the same issue with FG
segfaulting.

Thanks for looking at it again.

Regards,
Emilian
Stuart Buchanan
2017-07-04 20:50:14 UTC
Permalink
Post by Emilian Huminiuc
IIRC the discussion got sidetracked as we both tried doing_the_right
_thing[tm] aka enabling VBOs on trees too
(as they are done for random-buildings), and hit the same issue with FG
segfaulting.
Thanks for looking at it again.
Ah, the perfect being the enemy of the good :)

This is committed. Please shout if anyone sees any artifacts or
poor behaviour.

Note that I've also just committed a change to the density drop-downs
in the rendering dialog to provide more granularity. So ensure you're
making an apples-to-apples comparison.

-Stuart

Thorsten Renk
2017-06-30 18:13:02 UTC
Permalink
Post by James Turner
Would anyone more knowledgeable about the rendering dialog care to respond to this ticket?
Stuart designed the present version. We can go and argue for hours whether
it adds clarity to set just a couple of discrete values, or whether we
should use a slider or enter a number for really fine control, or use a
log slider,..., Stuart has one opinion, I have another one,... so lets
agree we can have different opinions on what's best.

The fact of the matter is that you don't need to adjust vegetation all the
time but typically once per FG version - and that you can do that at any
precision you like with the property browser or the commandline if you
need to.

So I see this ticket as just a dissenting opinion to the current design -
and if we were to vote, we could probably get a handful more different
options supported by different people. We need to solve this one way or
the other, and the current way seems workable for me and anyone who cares
can fine tune via commandline or property browser.

I don't see any compelling reason to revert to the old scheme, the new
scheme has its advantages and disadvantages just as the old had. At least
the GUI seems more
streamlined now.

* Thorsten
Stuart Buchanan
2017-07-02 21:07:02 UTC
Permalink
Hi All,

Apologies for the delay in responding to this. To much on.
Post by Thorsten Renk
Post by James Turner
Would anyone more knowledgeable about the rendering dialog care to respond
to this ticket?
Stuart designed the present version. We can go and argue for hours whether
it adds clarity to set just a couple of discrete values, or whether we
should use a slider or enter a number for really fine control, or use a log
slider,..., Stuart has one opinion, I have another one,... so lets agree we
can have different opinions on what's best.
The fact of the matter is that you don't need to adjust vegetation all the
time but typically once per FG version - and that you can do that at any
precision you like with the property browser or the commandline if you need
to.
So I see this ticket as just a dissenting opinion to the current design -
and if we were to vote, we could probably get a handful more different
options supported by different people. We need to solve this one way or the
other, and the current way seems workable for me and anyone who cares can
fine tune via commandline or property browser.
While I agree entirely with what Thorsten has written, it may be that
the discrete
values that we have at present (0, 0.5, 1.0, 4.0, 10.0) aren't a
useful set, and
it may be better to offer something like (0, 0.2, 0.5, 1.0, 2.0, 4.0)
to give better
granularity at the lower end of the range.

I'll take a look.

-Stuart
Loading...