On Wed, 7 Mar 2012 07:46:37 +1300, Chris wrote in message
cah3ygc2-urb3gpvhuj-cuhn8sosjgvwcns9wyr6ndjp8hog...@mail.gmail.com:
On 7/03/2012 4:42 AM, Arnt Karlsen a...@c2i.net wrote:
On Sat, 03 Mar 2012 21:17:30 +0100, Torsten wrote in message
4f527c5a.5060...@t3r.de:
The screen stays
I think that you have to add new techniques (an XML element) to
existing effect file. You leave the current technique intact and
copy/paste it in the same file, add or change what is needed and
Modify its predicate.
Look at model-default.eff that implements 2 techniques.
Techniques can
De: thorsten i renk
I think that you have to add new techniques (an XML element) to
existing effect file. You leave the current technique intact and
copy/paste it in the same file, add or change what is needed and
Modify its predicate.
Look at model-default.eff that implements 2
I doubt you're going to have an acceptable experience using a deferred
renderer on a go7400, regardless of driver bugs. There's not a lot of
fillrate there.
On 7/03/2012 4:42 AM, Arnt Karlsen a...@c2i.net wrote:
On Sat, 03 Mar 2012 21:17:30 +0100, Torsten wrote in message
Hi Thorsten,
De: thorsten i renk
I agree that we should merge the project rembrandt work sooner
rather than later. However, we should also take some time and
effort to make sure Thorsten's sky/haze/horizon effects are
accounted for as well. I don't know what issues we will find
Do you mean that v1.1 as posted on the forum can't be committed
as is to git ?
Technically it could, but at the expense of forcing everyone to use
lightfield shaders. It overwrites for instance the default terrain and
model shaders.
The reason why this is implemented in that way is that I have
On Monday 05 March 2012 12:02:26 Frederic Bouvier wrote:
Hi Thorsten,
De: thorsten i renk
I agree that we should merge the project rembrandt work sooner
rather than later. However, we should also take some time and
effort to make sure Thorsten's sky/haze/horizon effects are
There is an important issue though, the functions appear to be different
for objects and terrain.
What?? Both model-default.eff and terrain-default.eff refer to
terrain-haze.vert/frag as shaders - how can the fog function be different
if they're using the same shader code???
I think you're
Do you mean that v1.1 as posted on the forum can't be committed
as is to git ?
Technically it could, but at the expense of forcing everyone to use
lightfield shaders. It overwrites for instance the default terrain
and model shaders.
The reason why this is implemented in that way is
On Monday 05 March 2012 13:27:00 thorsten.i.r...@jyu.fi wrote:
There is an important issue though, the functions appear to be different
for objects and terrain.
What?? Both model-default.eff and terrain-default.eff refer to
terrain-haze.vert/frag as shaders - how can the fog function be
On Sat, 2012-03-03 at 22:52 +, Stuart Buchanan wrote:
On Sat, Mar 3, 2012 at 1:36 PM, Erik Hofman wrote:
Personally I would think adding Project Rembrandt will call for
FlightGear version 3.0. So if it is added I would create two branches,
version 3.0 and version 2.7 in which the later
As a migration path, I verified that my changes to simgear are
compatible with the current next branch. If there is no objection,
I will commit these changes to gitorious and begin to prepare
the flightgear code in a way that would allow to keep the current
renderer.
As I received no
On Sun, Mar 4, 2012 at 9:25 AM, Frederic Bouvier fredfgf...@free.fr wrote:
As a migration path, I verified that my changes to simgear are
compatible with the current next branch. If there is no objection,
I will commit these changes to gitorious and begin to prepare
the flightgear code in
Hi Curt,
De: Curtis Olson
On Sun, Mar 4, 2012 at 9:25 AM, Frederic Bouvier wrote:
As a migration path, I verified that my changes to simgear are
compatible with the current next branch. If there is no
objection,
I will commit these changes to gitorious and begin to prepare
the
On Sun, Mar 4, 2012 at 9:59 AM, Frederic Bouvier wrote:
... (Curt wrote) and keep that merged with the next branch.
(Fred wrote) I don't understand what you mean. Do you want me to commit the
work to a new Rembrandt branch and then merge it to the next branch ?
Hi Fred,
As I mentioned in my
Curtis Olson wrote:
I have a local branch I've created here for some experimentation. When
ever I do a git pull from the gitorious repository, I do that in the
next/master branches. Then I switch to my local branch and type git
merge next (or master) to make my local branch up to date with
On Sunday 04 March 2012 17:30:41 Christian Schmitt wrote:
Curtis Olson wrote:
I have a local branch I've created here for some experimentation. When
ever I do a git pull from the gitorious repository, I do that in the
next/master branches. Then I switch to my local branch and type git
Am 04.03.2012 19:00, schrieb Stefan Seifert:
But whenever talking about git rebase one should mention that THOU SHALT NOT
rebase a branch which you've ever pushed. Because if someone ever pulled your
What I always do, before pushing an update for the next branch is:
git checkout next
git pull
But whenever talking about git rebase one should mention that THOU
SHALT NOT rebase a branch which you've ever pushed. Because if
someone ever pulled your
What I always do, before pushing an update for the next branch is:
As stated previously, a code that is not run is unlikely to be
I agree that we should merge the project rembrandt work sooner rather
than
later. However, we should also take some time and effort to make sure
Thorsten's sky/haze/horizon effects are accounted for as well. I don't
know what issues we will find when trying to merge these two efforts, but
De: Torsten Dreyer
Am 02.03.2012 19:03, schrieb Frederic Bouvier:
Now that release 2.6 is out, perhaps it is time to discuss further
developments concerning project Rembrandt.
Although it may already produce pretty images when used by a
talented designer (see for example the P92), it
Stuart Buchanan wrote:
Given that we have 400+ aircraft that need to be updated, I think we
also need clear documentation (on the wiki?) describing the steps you
outline above, and in particular how to register the transparent
surfaces. That probably needs to be in place before the code goes
Is there any chance to make Rembrandt switchable (on/off) at startup?
That should be doable, but not done for the moment. Changes are located
in CameraGroup.[ch]xx and Renderer.cxx for the flightgear side, in
sgmaterial.lib for the simgear side and in Effects/ and Shaders/ for the
data side,
Hi Fred,
On Friday, March 02, 2012 19:03:13 Frederic Bouvier wrote:
thoughts ?
Since we are now at the beginning of a release cycle, I would think now is the
right time.
For the question to preserve both renderers, compatibility of models I think
that we need to preserve both if we cannot
On Sat, 2012-03-03 at 07:25 -0600, Curtis Olson wrote:
I agree that we should merge the project rembrandt work sooner rather
than later. However, we should also take some time and effort to make
sure Thorsten's sky/haze/horizon effects are accounted for as well. I
don't know what issues
-Original Message-
From: Erik Hofman
Sent: Saturday, March 03, 2012 1:36 PM
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] Project Rembrandt - next steps
Personally I would think adding Project Rembrandt will call for
FlightGear version 3.0. So if it is added I
Am 03.03.2012 12:43, schrieb Christian Schmitt:
Stuart Buchanan wrote:
IMO we should bite the bullet and get it into next this week if
possible. There's obviously some risk to our 6 month release
schedules that we'll just have to accept.
I agree here. Let's merge the Rembrandt work
-Original Message-
From: Frederic Bouvier
Sent: Saturday, March 03, 2012 11:33 AM
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] Project Rembrandt - next steps
De: Torsten Dreyer
I don´t know if that already been covered, but is it possible to make a
model
On Fri, 2 Mar 2012 20:51:59 +
Stuart Buchanan stuar...@gmail.com wrote:
Given that we have 400+ aircraft that need to be updated,
Looks like an aircraft needs some maintenance over time. This somehow
bothers the question whether it is wise to collect 300+ rudimentary
aircraft with no
Am 03.03.2012 12:33, schrieb Frederic Bouvier:
But just curious : how many of you reviewed the current code ?
n+1
Just checked out your project/rembrandt branches. Code compiles fine on
64bit openSUSE 12.1 with OSG from trunk.
Running fgfs spits out many messages, most prominent are:
can't
- Mail original -
De: Torsten Dreyer tors...@t3r.de
Am 03.03.2012 12:33, schrieb Frederic Bouvier:
But just curious : how many of you reviewed the current code ?
n+1
Just checked out your project/rembrandt branches. Code compiles fine
on
64bit openSUSE 12.1 with OSG from
De: ThorstenB
Also, the project is quite good in finding issues, once new stuff is
in git. But, generally we are not so good in fixing problems then.
Notoriously, everyone has just too little spare time ;-), so a lot of
issues just starve in the tracker. And with hard-core OSG stuff,
On Sat, Mar 3, 2012 at 1:36 PM, Erik Hofman wrote:
Personally I would think adding Project Rembrandt will call for
FlightGear version 3.0. So if it is added I would create two branches,
version 3.0 and version 2.7 in which the later is switched to bug fixes
only.
Surely a bug-fix 2.7.0 branch
On Fri, 2 Mar 2012, Frederic Bouvier wrote:
* Register all transparent surfaces
Just a quick question: Doesn't OSG already detect translucent meshes and
treat them differently from the rest during rendering? Hence, couldn't
this classification be done more or less automatically and only
On Fri, Mar 2, 2012 at 6:24 PM, Anders Gidenstam wrote:
On Fri, 2 Mar 2012, Frederic Bouvier wrote:
* Register all transparent surfaces
Just a quick question: Doesn't OSG already detect translucent meshes and
treat them differently from the rest during rendering? Hence, couldn't
this
On Fri, Mar 2, 2012 at 6:03 PM, Frederic Bouvier wrote:
Now that release 2.6 is out, perhaps it is time to discuss further
developments concerning project Rembrandt.
Although it may already produce pretty images when used by a talented
designer (see for example the P92), it is however, not
De: Anders Gidenstam
On Fri, 2 Mar 2012, Frederic Bouvier wrote:
* Register all transparent surfaces
Just a quick question: Doesn't OSG already detect translucent meshes
and treat them differently from the rest during rendering? Hence,
couldn't this classification be done more or
Am 02.03.2012 19:03, schrieb Frederic Bouvier:
Now that release 2.6 is out, perhaps it is time to discuss further
developments concerning project Rembrandt.
Although it may already produce pretty images when used by a talented
designer (see for example the P92), it is however, not usable by
38 matches
Mail list logo
