> 2. Slider in Advanced Weather - Advanced Settings - sets a max value .
> The
> displayed vis in the min value of this and the value derived by Advanced
> Weather. (Is this true? I'm only inferring this).
True.
> 3. Checkbox named realistic visibility in Advanced Weather - Advanced
> Settings.
> While I think that sometimes Thorsten may give
> people more benefit of the doubt...
After sleeping over it, I have to admit that Stefan is right.
I was angry about the way the discussion was turning away from being
productive, and that colored my response to Lorenzo, which is not how thin
Let's please be honest here.
> I'll repeat it once more, I don't have a personal problem with you, I
> have a problem with your methods, and AFAIK I'm not the only one, but
> (un)fortunately, the other ones chose to stay silent...
If you refer to my methods of coding, I don't think we've had
> Buildings/trees are generated at tile load time currently, and remain
> resident
> in memory, for as long as the tile is loaded. If you don't se them on
> screen
> doens't mean they're not there.
Yes, but strangely enough, this part of the discussion happened to be about LOD
systems and per
Emilian, just up-front to keep this discussion focused on what it actually is
about:
Do you, or do you not agree that 20 (or 16) km terrain loaded regardless of
the visibility is a sane value? Somehow, you still haven't really answered the
question, you're just expressing unspecified 'concern
> Actually, I think what he tried to suggest was, that the needs of
> visuals and the needs equipment like radar should not be mixed. For visuals
> we need
> the terrain and all the objects like trees and buildings which are hard on
> performance.
It's a fact that the distances out to which
> -> Assumes that we want to set the limits by equipment (radar) rather
> than visuals, although we've just said we don't want to do this because
> of memory issues, and I've listed several points besides radar why I'd
> like to do it.
On re-reading, this sounds pretty hilarious...
What I m
> Straw man ?!?!?
> http://en.wikipedia.org/wiki/Straw_man [See :: structure point 2.5] and
> you will understand that simplifying my point of view trying to
> invalidate it is ... a straw man technique.
> Are you so sure that it is not what you have done concluding rushy that
> I do not had read t
> ..a point I forgot to make: you (or your MUA?) don't attribute
> properly what I wrote below, which may be part of the thread
> breaking problem.
Arnt, you do know that 'you' in the English language doesn't necessarily refer
to you personally, but that it doubles as an unspecified 'one'?
If I
> Have you ever read the getstart.pdf? apparently not.
I've read it once, a long while ago. But I don't feel bound by what it says, in
my view the logic is that we implement what's reasonable, then change the
documentation accordingly, not that we first have a documentation as god-given
and onl
> ..a pointer to your previous message would help here, this thread
> is broken (in at least my MUA) and getting hard to follow.
Maybe we just have some cultural misunderstandings?
The way I see it - if you want to make a statement in a discussion, you have to
read what has been said before. No
> the reason to be of the EQUIPMENT is to override the limit of the EYE
> vision.
> Are we doing the error to merging this two ?
Would you mind reading the previous messages in the thread? I don't mean to be
impolite, but I really don't want to write everything twice. Thanks.
* Thorsten
> Another option would be to move the visibility control to a dialog, with
> a slider / spin box, and explicitly disable it when advanced weather is
> selection. Then we could lose the keybinding completely, which is
> something I want to move towards for options that are infrequently used,
> I was talking about the 16km value (sorry for not being more clear about
> that) and see below for the huge value.
Let me get this straight. You state that the 16 km are a pretty sane value. The
proposal being discussed is to load terrain to 20 km no matter what the
visibility is. Vivian ha
> Why should those users be forced to give up on those goodies just
> because one
> part of the rendering scheme doesn't want to play by the rules? Even
> more so when there's no indication that happens...
>
> The default max visibility value is a pretty sane default, and simply
> increasing t
> I was not referring to a frame rate issue, but FG running out of memory.
>
> http://www.flightgear.org/forums/viewtopic.php?f=5&t=18913&p=177392#p177392
>
> It is rare to see that happening using the current scenery, but here if I
> select random buildings and objects with a high value for trees,
> Hey guys, I have been trying to work on some textures for NZ, but I
> cannot
> find the land-class via cntrl.alt.click.
> I have tried multiple aircraft, can anyone help?
It's an ufo feature...
* Thorsten
--
Everyone
Vivian:
> There seem to be significant issues with the loading of terrain. If we
> load too much, the frame rate drops, if we load too little it looks poor, and
>
> AG radar doesn't work. Actually. We don't load enough for AG radar to work
> realistically in any case. We probably need somethi
Vivian wrote a while ago:
> I've only tested Atmospheric Light Scattering for about 10 mins - and so
> far I've discovered that the Cat III scenario looks decidedly odd with a
> clear circle around my aircraft on the ground and black skies.
I've taken a few hours to look into low visibility
> Did you test your airfield grass with some of the newer generated terrain
> (LOWI in my case)?
No, I didn't. Shouldn't make a difference for rendering purposes how you
created it, at this stage it's all vertices and pixels and the shaders don't
care where they come from or how they connect.
> I'm not sure this is necessary. I think an opt-in checkbox would
> suffice. After all FlightGear has been around for personal experiments
> for a very long time. So why not this option.
I don't mind leaving it - the rational for deleting it is that the texture
sheets take up space and download
Okay, after sleeping over this and going over all the feedback on this list:
My original idea was that the whole concept of a continuous season model in
combination with a user-customizable environment by pixel processing is a big
thing - I doubt many other simulators have something like this (
It seems we have some cases where the ufo trick ctrl-alt-click does not report
the correct landclass - I would assume that the underlying call is geodinfo()
going wrong.
http://www.flightgear.org/forums/viewtopic.php?f=5&t=19113
The theme seems to be that if I have two different materials def
> ..the obvious way to control all this, is use e.g. FG time
> and METAR history to set up a credible scenery appearance.
Right, so we somehow get the METARs for the last month for a location, have the
environment model run the consequences and use that. Sounds not so easy to me.
But... I never
> What I expected was that having selected Regional scenery, then the
> slider would give me reasonable results for my region. Perhaps that's simply
> too
> difficult, or the region is defined too widely. I also see that the
> regional scenery for the area is wrong as well, but I'm working on
Just what is it you want to customize?
Consider a simple 'snow in the mountains'. You can have
* early snow up north, the leaves have just started turning and the snow is on
slightly yellowish trees up the slopes, no snow on green trees down
* one day later - a bit of snow is still on the groun
> In general, giving users choice is bad. What developers should do, is
> figure out what the user *wanted*, and then do it. Excessive choices /
> options / preferences are a failure to be sufficiently smart, about what
> the user actually wants.
I disagree with this on a very general basis.
> ..maybe in the old days, nowadays, some grass is green, most
> of it, say 4/5 is a pale dull yellow when the snow comes.
> Climate change, grass grows about 3 months longer now, than
> in the 1960-ies when grass was cut once, nowadays farmers get
> 3 harvests.
The whole discussion brings again a
>> OK, now I understand. Here's a screenshot:
>>
>> https://dl.dropbox.com/u/57645542/fgfs-screen-099.png
>>
>> It's not good for UK - but I guess we can fix that eventually.
Do you have any reference material how autumn/winter colors in the UK should
look like?
> ..desert? Severe drought?
-
> I think I must have something wrong here: much of the textures which were
> green turn a horrid brown colour, it looks like nothing I have ever seen
> on the ground in the UK. Is that what is intended?
That'd depend on the slider position and the landclass I guess - no way to tell
without a
I've just pushed the current state of the autumn color model where the amount
of coloring is encoded in the texture alpha channel. I've tried to be very
conservative and pushed alternative textures (marked with *-autumn.png) where
this is done - I could not see any negative effects in the defau
> If you want all of them you should be able to cherry-pick the commits _in
> order_ or, alternatively, you could just checkout the final state of the
> files from master as you suggested above.
I can't cherry-pick them no matter what order I try. Basically I want
commit 0b8c17ba7437cb09c40c3754
> Something along these lines:
>
> $ git branch my-2.10.0 origin/release/2.10.0
>
> $ git checkout my-2.10.0
>
> Find the commit ids of the bug fix commits on the master branch
>
> $ git log master
>
> Cherry pick these to your local release branch
>
> $ git cherry-pick
Okay, as usualy this is n
Could anyone perhaps instruct me how to push onto the release branch? I have
committed a couple of shader bugfixes to the master branch which should go to
release as well, but I don't have a local release branch by default, so I'm
unsure what to do. Or is the idea that only a subset of comitter
> I think the foam texture is still read in a conditional, based on
> distance.
> (water-lightfield.frag/water-lightfield_lr.frag lines 422-434)
You got me there :-) But it turned out not to be the problem... the problem was
that
if (condition) {do_stuff();}
(...)
if (condition) {do_other_stu
> Cannot reproduce here on today's GIT.
>
> Given the intermitent nature of it, I have a possible culprit (but
> you're not
> going to like it):
> -try with the texture fetches outside of the conditionals, see if you
> (or the reporter) can still reproduce it.
I think I told you a while ago t
> Should we think about some kind of tool to find flightgear lint like
> this? What would the tool have to do?
>
> Renk, What steps did
> you take to find candidates for deletion and to verify the
> weather is not used?
Well, I introduced these textures and models in the first place, I also have
I've received two bugreports in the forum for which I would like to ask some
advice here:
1) The ultra terrain shader makes runway designation signs go away:
http://www.flightgear.org/forums/viewtopic.php?f=47&t=18999
It would appear that all the sign boards in airports are driven to grey whe
Here's a list of objects which I have tested to be safe to remove from
/Models/Weather/ - all in all ~19MB. If no one else has objections, as far as
I'm concerned they can go.
* Thorsten
altocumulus_textures.dds
altocumulus_textures.rgb
cumulonimbus1.ac
cumulonimbus1.xml
cumulonimbus2.ac
cumul
>> If so, we should definitely remove the "experimental" label from the
>> rendering dialog, and possibly change this to the default renderer and
>> have a discussion about whether to retire the previous scheme.
> I've only tested Atmospheric Light Scattering for about 10 mins - and so
> far I
> 4. Models/Weather - 76 MB - As asked are BOTH duplicate
> dds and rgb files needed, or could a release work with only
> one or the other?
> 5. And now I find in both Textures and Textures.high
> the same duplication of dds and png files. Again
> are BOTH really required for a release?
> 6. Are
I've just pushed the first version of the model shader for Atmospheric Light
Scattering. It should do random buildings with reflections and all aircraft
using the model-combined.eff without normal mapping. The shader still has some
quirks, but they're hard to spot if you don't look for them ;-)
> I'm not sure if I'm doing something wrong here: we now have so many
> different options, but getting snow by method 2 or 3 results in deciduous
> trees in full leaf with snow coverage on the ground. Not an impossible
> scenario, but bare trees are more likely. Is this a bug?
It's actually... pre
> Are the Winter textures still needed?
In a sense they were never really needed... for instance I have never used them.
Just to summarize the options we have to generate snow:
1) Winter textures
They are base texture sheets with snow painted on, which means they have a
fixed snowcover and no
Following a forum bug report
http://www.flightgear.org/forums/viewtopic.php?f=68&t=18924
I had a look at random buildings in Atmosperhic Light Scattering (which I
normally don't use).
I just pushed a fix
* ensuring that the Mie angle gets correctly to the fragment shader
* and simplifying the f
> It does run on my Win 7 laptop with nvidia graphics hardware (and nvidia
> graphics drivers installed.) I will get it uploading ... 740Mb! So much
> for the CD distribution. :-) Didn't Bill Gates famously say 640Mb should
> be enough for anyone?
Um... which reminds me - I had on my old comput
> You may be right that I did not pick the exactly right person for every
> line of code.
> But I also did not get the completely wrong one as you never cared for
> the state of the art even if being pointed to.
Quoting myself:
"You did no such thing, Mathias. You gave a completely incomprehe
> After some discussion / observation, I am going to change the default
> shader level for 2.10 (and probably next) to '1' instead of '3'
(...)
> Comments / objections?
Complete agreement, after looking at the Intel and Mac problems in the forum, I
was about to suggest the same thing.
* Thorst
Ah, now I understand what Mathias is after:
> That would be ok if this would be optional in the sense that it does not
> impact what is there performance wise. But since this is all runtime
> configured
> by an uebershader with a lot of uniforms this is not the case. Any
> additional
> featur
> No, I think what he meant is that (without me ever even seeing shader
> code)
> something like:
> if (enable_light_scattering) {
> a = b + c;
> }
> compromises performance, even if light_scattering is disabled because the
> compiler would assign registers to this code (the a = b + c), even
Dear Mathias,
> But what I saw lately - especially from this finish guy - is noting close
> there.
I continue to have a name (which is Thorsten), that name doesn't actually sound
very Finnish, and that would be because I am actually German (I do live in
Finland). There's no need to pretend you
I've managed to adapt the model ubershader for Atmospheric Light Scattering in
the last few days. The results look pretty nice (performance consumption is
probably not so nice though):
http://users.jyu.fi/~trenk/pics/IAR80-sunrise.jpg
So now we can have atmospheric light scattering skydome, gr
> I see applications that care for stable 60 hz. If you get for one frame
> 59 hz they have too much jitter and look for an other renderer.
>
> What I really do not like is that people purely push in the direction
> they just like more.
Beats me when this has ever been a problem. My first co
> Well, if you ask in that way, then the question is:
> Do we need 10 different flavours of rock?
If we want to look a scene roughly as it would in the location, the answer is
yes - volcanic rock on Hawaii looks very different from Alpine rock in France.
Rock in Iran looks very different again.
> Yes. Any uniform needs to be handled by the driver. And any of them
> takes cpu
> cycles to load. I think having lots of them is one factor that accounts
> for
> the long draw times I see here. Looking at profiles the function
> collecting
> them and putting it into a buffer for use in the
I'd like to ask for a few opinions.
The problem: Vertex shader coordinates are continuous only within a terrain
tile, so the noise distributions we use show discontinuities across terrain
tiles - seen most prominently in snow or fog patches.
The solution: Emilian and Fred have figured out a wa
> For example here on an nvidia 8800GT with 313.09 linux driver I have:
>
> MAX_VERTEX_UNIFORM_COMPONENTS 4096
> MAX_FRAGMENT_UNIFORM_COMPONENTS 2048
Nevertheless, that would make 50 seem a rather harmless number. Especially when
I'm going to assume that no one with a much older card will be able
I've recently come across the idea of using one generic sand or rock texture
and selecting the particular hue desired by multiplying every pixel value with
an (rgb) vector - so rather than two different-colored sands, we'd just store
one texture and three numbers on disk (and potentially in GPU
I was wondering if anyone has experience with the stereoscopic view modes of
FG. Coming with my new laptop were very fancy NVidia IR synchronized LCD
shutter glasses for 3D vision, and I've used them to have a look at some 3D
movie clips, which was sort of impressive. Unfortunately, they don't
> BTW: I've been discussing with the terragear guys something similar,
> with a
> texture encoding material info accompanying the btg, and being generated
> at scenery build time.
> This texture would use a secondary set of texture coordinates, relative
> to in-tile position, and would be re
> By the way, do you know this book ?
> http://books.google.fr/books/about/Texturing_and_Modeling.html?id=bDlSJd8GfMcC&redir_esc=y
No, I don't. I have never read much about scenery texturing. (I mostly make it
up as I go - my greatest wish would anyway be an artist and a decent database
to ext
> Geometry shader can also process adjacency information if provided by the
> CPU through special primitives (GL_TRIANGLES_ADJACENCY and
> GL_TRIANGLE_STRIP_ADJACENCY)
Oh, right - a geometry shader can probably receive a triangle as input, compute
its center of gravity, shift all vertices outward
Hi Stuart,
> That sounds like an excellent plan. Let me know how I can help.
yes, I could definitely need a hand... Now since the holiday period is over, my
coding time just decreased dramatically... So, if you like, I could give you
what I have in terms of autumn colors and hires terrain shad
> Agreed, this stuff is all about plausible heuristics, but I think this
> one fails the 'plausible in enough areas' test. Hopefully we'll (soon)
> be able to suggest land cover updates to fix any areas with these kind
> of data issues, once the world scenery rebuild completes.
Somewhat iro
> We have to accept some inconsistencies if we want even vaguely tolerable
> performance, and pretty much everything you said convinces me we should
> switch to the 'b' approach, or family of them (see below), as the
> default option after 2.10, to get as much test and feedback as possible
> The landmass shader looks like you fixed something :)
Great to hear - so presumably it was the things Emilian identified (?!)- I
haven't fixed anything else.
> Flickering is gone in all settings and i have only some small artifacts
> visible in the distance while having snow cover and fog. Lo
> What's the a / b performance impact?
All to be taken with some caution, since it seems to be very hardware dependent
how expensive certain options are. For my new GTX 670M, I can't measure
performance without external tools because any terrain is always rendered with
vsync of 60 fps, and only
> Perhaps we could use something similar for the trees? I.e. pass in a
> uniform indicating which fraction of the texture sheet on the x-axis
> should be color-rotated. The uniform can be taken from a property on
> the material definition.
Ah, that's clever - I think that would do just fine. T
> Stuart, one thing that caught me out earlier today with using 2D cloud
> layers - while using a 2D layer and modifying visibility inside the
> layer is working quite well, the edge (moving vertically) is very sharp.
> I wonder if there's some technique to perturb the top and bottom of the
It has emerged from forum discussions that gathering the goals for developers
so that people can synchronize efforts better and users know what to expect
would be a good idea. I've sort of been trying to do that previously, so I
might as well continue, even if it's a bit early and 2.10 isn't ro
> Apparently that's ok now, another issue cropped up in the
> urban-lightfield
> shader, something wrong with an #if:
>
> FRAGMENT glCompileShader
> "/home/chris/FlightGear/Shaders/urban-lightfield.frag"
> FAILED
> FRAGMENT Shader "/home/chris/FlightGear/Shaders/urban-lightfield.frag"
> infol
Well, we did have
greater
0.01
everywhere in the cloud effect files. So it's not clear to me how transparent
fragments should even make it to the shader (?). Maybe I'm still confused about
something...
* Thorsten
-
> There are many issues and tradeoffs with mesh simplification. There are
> many algorithms and approaches, each with their own unique strengths and
> weaknesses. Challenges include finding a strategy to hide the cracks
> between adjacent tiles draw with different levels of details (and
> possi
> - no errors on the console
> - latest drivers for the ati card (tested with all ati drivers from 2012
> for win7 64bit)
> - the artifacts show up if the landmass shader is over 3 (counting from
> left / starting with 0)
> - the artefacts show up if the transition shader is over 1 / at 2 only
>
> Those are fixed, but you still have some implicit casts/coversions in
> there,
> those are tolerated by the nvidia compiler but not by other drivers:
> http://dpaste.com/845842/
Aw, a forgotten decimal point - that's picky. Okay, how about now?
* Thorsten
-
> Thorsten, from discussion on irc, it seems you're assigning to a varying
> in
> the fragment shaders. See this log: http://dpaste.com/845317/
> Most likely the other errors will go away once you fix that.
Thanks, the log was very helpful - please pull and try again, at least the
assignment to
> With an ati 5870 on win7 64bit the transition effect is not working as
> expected.
> I get what is best described as fast flickering artifacts... but have a
> look at the screen shoots yourself.
> http://i217.photobucket.com/albums/cc283/oliunterderbruecke/flightgear/fgfs%20bugs/fgfs2012-12-1323-
If anyone likes flying in Iceland - the current state of Iceland regional
texturing is now on GIT with the region-specific materials file - use with
Atmospheric Light Scattering, Transition Effects to max. for best effect -
otherwise the endless lava fields and glaciers have very strong tiling
> In some cases, the used algorithm is plain wrong as we
> know by definition (ICAO rules) the propagation of the radio signal.
Um... I would like to understand this statement. The algorithm has a physics
model in. I am no expert in radio propagation, but after doing a bit of
reading, by usual F
Forum:
> by zakalawe on Wed Dec 12, 2012 4:46 pm
> I've pushed a fix (to SG) for the sound issue. Better to report such issues
> via the developer list in the future, I don't check topics here.
Jenkins FlightGear-Win64-CMake build history:
> #220 (pending - All nodes of label 'x64' are offl
> I corrected it some minutes ago and hope everything is fine
> again.
Huh, that was fast, thanks. Airport green is looking good here.
* Thorsten
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Rem
During the last weeks, someone added the 'Grass' landclass to the 'grass_raw'
materials declaration and the 'Dirt' landclass to the 'dirt_rwy' declaration
in/ Materials/regions/materials.xml.
I would like to undo the changes, or discuss other solutions to fix the
problems caused by them - my G
>> My suggestion is to include this feature, leave it off, and let anyone
>> interested turn it on.
+1
There may be many reasons to reject code, but they roughly fall into two
categories: 1) the idea itself which is coded is not acceptable or 2) the
actual implementation is not acceptable (unst
Please let me be very clear about a few things.
This is not about lack of praise or thanks - I'm doing weather and light mainly
because I like doing it, because I like to see if I can capture the essence of
a scene I see in real life in shader code. I am passionate and excited about
that, and
Me asking a genuine question:
> Why do I need to make a song and dance to get the last stable under
> Linux when it works no fuss under Windows? Are we genuinely unable to
> provide a working generic 32 and a 64bit set of binaryies for Linux? I
> know that lib paths and versions are differen
> Personally I find a collection of independent requests much easier to
> deal with than one 'all my recent work' submission. Eg I'm interested in
> your work to early-Z-fill the trees, but the rest of the request, I'm
> not 'qualified' to make any judgement about.
Difficult to do in this ca
>
> That was caused by your previous merge request, which was resolved
> without
> proper testing I guess.
> There's a bugreport about that
> http://code.google.com/p/flightgear-bugs/issues/detail?id=836
>
> Which was marked as fixed, but obviously it isn't.
Thanks for letting me know. Commentin
> I've created a merge request
> https://www.gitorious.org/fg/fgdata/merge_requests/183
> containing lots of my recent shader work(...)
Um... what should I do with this? I've gotten one comment pointing to a problem
with the urban shader, but I can reproduce the same problem on a pristine
master
> I have no idea
> though about Nasal terrain sampling performance.
Pretty good these days - whenever a convective weather system is set up, we use
about O(1000-2000) terrain elevation sampling points to generate the
cloud-terrain interaction, they're done at a rate of 20 per frame. On my old
> No it doesn't. There's nothing preventing us from providing packages for
> older
> distribution versions.
This sounds very neat, and if this works in practice, then I take my comment
back - being able to get an rpm for any major Linux distribution would be
equivalent to the Windows installer
> Binary releases on Linux are /possible/ but a pain - working with each
> distro's packaging system is definitely the way to go, in my opinion.
That basically seems to require that everyone who wants most recent FG needs to
update to most recent Linux. Which is something which according to my
> * strange bug - all generated clouds (on Linux and Wndows) used only one
> texture of a multi-texture sheet, which gives some odd repetitions. This
> may be something trivial (my binary and FGData snapshots are a few days
> apart) so if there's been work on clouds in the mean time it could
So, some of my impressions of how FG runs on the GeForce 670M (Windows).
* in default terrain (I did Nevada, going with the F-16 from KNID to KLSV), all
procedural effects in atmospheric light scattering on, some snow on the Sierra
Nevada, 120 km max. visibility range, some Cirrus cloud develop
So, I finally broke down over the weekend, getting so frustrated with a the GPU
not powering up under Linux that I installed FG on Windows.
If I want to get FG last stable under Fedora 17, I have to compile it myself,
only 2.6 is on the repo. The process is probably similar to compiling current
> I'm not sure if the settings suggested there still work with current
> drivers, but it's a start.
Nope - the available options for the newer driver are quite different. Also,
the problem is not that the PowerMizer defaults to adaptive - it doesn't, I can
change its setting. It just never mak
I guess I need some help here... I've finally managed to compile FG on the new
computer, then copy my FGData here, and... it works. But the framerate is
abysmally bad.
It doesn't seem to be Flightgear though... When I open the NVIDIA X Server
Settings while FG is running, I can see the various
> If you *have* set SIMGEAR_DIR or other settings, I'd recommend erasing your
> build
> directory and running cmake from clean - it 'remembers' previous values in
> the build dir's cache.
Ah, that's how it's supposed to be... I've now hacked my way through by adding
the path explicitly to Fin
I'm just trying to get a working devel environment on my new machine, and I've
succeeded in compiling simgear, but flightgear refuses the cmake configuration.
Basically I want to have the simgear libs inside a user directory and not
system-wide. So what I did is cloning the repositories, changi
I've created a merge request
https://www.gitorious.org/fg/fgdata/merge_requests/183
containing lots of my recent shader work, including
* ambient and cloud shadow correction to blue-grey hue
* more pre-dawn illumination
* procedural snow
* a hires grass texture overlay effect for airport grass re
Stuart wrote:
> Personally I'd really like to see the rendering systems unified, even
> though I don't have enough GPU to run them both together (or indeed
> Rembrandt with shadows). It's just make for a more consistent
> experience. (...)
> I had a look at this a couple of weeks ago but
> didn
101 - 200 of 415 matches
Mail list logo
