quesa-develop — Mailing list for Quesa development

Re: Issue with transparency and lighting

[Roger H. <rog...@mi...>]

On 22 Aug 2009, at 17:25, James W. Walker wrote:

>
> On Aug 22, 2009, at 1:48 AM, Roger Holmes wrote:
>
>>
>> On 22 Aug 2009, at 01:25, James Walker wrote:
>>
>>> I thought I was correctly handling transparency with multiple
>>> lighting
>>> passes in QORenderer::Renderer::RenderTransparent, but it turns out
>>> that
>>> in some cases it can be visibly incorrect.  I'll try to explain a
>>> simplified scenario.
>>>
>>> Suppose we have an nearly-opaque object with color A, and in front  
>>> of
>>> that there is a transparent object with color B.  There are 2
>>> lighting
>>> passes, contributing brightnesses L and M respectively.  Then the
>>> resulting color value ought to be B*(L+M) + (1-alpha)*A*(L+M).
>>
>> For the diffuse component of the lighting, shouldn't that be
>> alpha*B*(L
>> +M) + (1-alpha)*A*(L+M) ?
>
>
> I was assuming premultiplied alpha.

I see. I  always try to keep the alpha channel separate. The saving in  
time is rather small in 3D.

>
>
>> As my renderers are pure software ones, I'm not familiar with
>> glBlendFunc so cannot comment on that but maybe it supports my  
>> version
>> of the formula.
>
>
> Maybe your renderer doesn't have a limit of 8 lights, so you don't
> need multiple passes.

No limit, but to store all the shadow depth buffers I do have to use  
multiple passes when there is insufficient memory to store them. I  
also sometimes have to band the image when high resolution/large image/ 
anti-aliasing. Separate scan lines can be done in separate processors  
if available. Must do a 64 bit version sometime.

>
>
>> The specular component is just added on, not being affected by the
>> alpha.
>
>
>
> I was omitting specular for simplicity.

OK.

>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008  
> 30-Day
> trial. Simplify your report design, integration and deployment - and  
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop

Re: Issue with transparency and lighting

[James W. W. <os...@jw...>]

It occurs to me that a possible solution is to use the accumulation  
buffer, rather than blending, to add the contributions of multiple  
lighting passes.

Re: Issue with transparency and lighting

[James W. W. <os...@jw...>]

On Aug 22, 2009, at 1:48 AM, Roger Holmes wrote:

>
> On 22 Aug 2009, at 01:25, James Walker wrote:
>
>> I thought I was correctly handling transparency with multiple  
>> lighting
>> passes in QORenderer::Renderer::RenderTransparent, but it turns out
>> that
>> in some cases it can be visibly incorrect.  I'll try to explain a
>> simplified scenario.
>>
>> Suppose we have an nearly-opaque object with color A, and in front of
>> that there is a transparent object with color B.  There are 2  
>> lighting
>> passes, contributing brightnesses L and M respectively.  Then the
>> resulting color value ought to be B*(L+M) + (1-alpha)*A*(L+M).
>
> For the diffuse component of the lighting, shouldn't that be  
> alpha*B*(L
> +M) + (1-alpha)*A*(L+M) ?


I was assuming premultiplied alpha.


> As my renderers are pure software ones, I'm not familiar with
> glBlendFunc so cannot comment on that but maybe it supports my version
> of the formula.


Maybe your renderer doesn't have a limit of 8 lights, so you don't  
need multiple passes.


> The specular component is just added on, not being affected by the
> alpha.



I was omitting specular for simplicity.

Re: Issue with transparency and lighting

[Roger H. <rog...@mi...>]

On 22 Aug 2009, at 01:25, James Walker wrote:

> I thought I was correctly handling transparency with multiple lighting
> passes in QORenderer::Renderer::RenderTransparent, but it turns out  
> that
> in some cases it can be visibly incorrect.  I'll try to explain a
> simplified scenario.
>
> Suppose we have an nearly-opaque object with color A, and in front of
> that there is a transparent object with color B.  There are 2 lighting
> passes, contributing brightnesses L and M respectively.  Then the
> resulting color value ought to be B*(L+M) + (1-alpha)*A*(L+M).

For the diffuse component of the lighting, shouldn't that be alpha*B*(L 
+M) + (1-alpha)*A*(L+M) ?

As my renderers are pure software ones, I'm not familiar with  
glBlendFunc so cannot comment on that but maybe it supports my version  
of the formula.

The specular component is just added on, not being affected by the  
alpha.

Roger

Re: Issue with transparency and lighting

[James W. <ja...@fr...>]

James Walker wrote:

> 
> In many cases where I use a texture with an alpha channel, the alpha 
> channel is pretty much either 1 or 0.  In such a case, I think there 
> would be pretty good results if we turned on the alpha test, and let 
> opaque pixels write to the depth buffer, and didn't use blending.

Oops, I shouldn't have said "didn't use blending" there.  Blending, with 
glBlendFunc( GL_ONE, GL_ONE ), would still need to be used to add up the 
contributions of the lighting passes.

-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Issue with transparency and lighting

[James W. <ja...@fr...>]

I thought I was correctly handling transparency with multiple lighting 
passes in QORenderer::Renderer::RenderTransparent, but it turns out that 
in some cases it can be visibly incorrect.  I'll try to explain a 
simplified scenario.

Suppose we have an nearly-opaque object with color A, and in front of 
that there is a transparent object with color B.  There are 2 lighting 
passes, contributing brightnesses L and M respectively.  Then the 
resulting color value ought to be B*(L+M) + (1-alpha)*A*(L+M).  But if 
we have to handle the lights in different passes, the first pass 
produces B*L + (1-alpha)*A*L.  If we use glBlendFunc( GL_ONE, GL_ONE ) 
in the second pass, as RenderTransparent currently does, then we just 
add B*M + A*M, resulting in a total of B*(L+M) + (1-alpha)*A*L + A*M, 
which has too much contribution from A.

I don't see that any choice of blend function will produce the right 
result in all cases.

In many cases where I use a texture with an alpha channel, the alpha 
channel is pretty much either 1 or 0.  In such a case, I think there 
would be pretty good results if we turned on the alpha test, and let 
opaque pixels write to the depth buffer, and didn't use blending.

Thoughts?
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: Other Quesa concerns/suggestions

[James W. <ja...@fr...>]

Stefan Huber wrote:

> I've tested __FAST_MATH__ is on for floats again (Xcode 2.4.1):
> 
> you are right :
> isfinite and isinf work correctly for std::numeric_limits< float 
>  >::infinity()
> 
> but:
> isnan returns 0 (instead of 1) and isfinite returns 1 (instead of 0) for 
> std::numeric_limits< float >::quiet_NaN()
> 
> It seems that inf works but nan does not.
> 

OK, I have turned off GCC_FAST_MATH.

-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: Other Quesa concerns/suggestions

[Stefan H. <st...@to...>]

>Stefan Huber wrote:
>  >>> At least nan, inf, etc. do not work (correctly) when __FAST_MATH__ is on.
>>>  Please tell me more.  How do they work differently when it is off?
>>
>>  About two years ago I ported an app that relies on nan, etc. from CW
>>  to Xcode. The main problem is (as far as I remember) that isnan,
>>  isinf and similar functions always return false if __FAST_MATH__ is
>>  on. Quesa does not use these functions.
>>
>>  BTW CWs "Relaxed IEEE Floating Point" setting works perfectly well with nan.
>
>Quesa does use isfinite, and I'm sure I would have noticed if it wasn't
>working... rendering with shadows requires an infinite yon, and
>E3ViewAngleAspectCamera::GetFrustumMatrix uses isfinite to do the right
>thing in that case.


I've tested __FAST_MATH__ is on for floats again (Xcode 2.4.1):

you are right :
isfinite and isinf work correctly for std::numeric_limits<float>::infinity()

but:
isnan returns 0 (instead of 1) and isfinite returns 1 (instead of 0) 
for std::numeric_limits<float>::quiet_NaN()

It seems that inf works but nan does not.


   Stefan
   http://www.topoi.ch

Re: Other Quesa concerns/suggestions

[James W. <ja...@fr...>]

Stefan Huber wrote:
>>> At least nan, inf, etc. do not work (correctly) when __FAST_MATH__ is on.
>> Please tell me more.  How do they work differently when it is off?
> 
> About two years ago I ported an app that relies on nan, etc. from CW 
> to Xcode. The main problem is (as far as I remember) that isnan, 
> isinf and similar functions always return false if __FAST_MATH__ is 
> on. Quesa does not use these functions.
> 
> BTW CWs "Relaxed IEEE Floating Point" setting works perfectly well with nan.

Quesa does use isfinite, and I'm sure I would have noticed if it wasn't 
working... rendering with shadows requires an infinite yon, and 
E3ViewAngleAspectCamera::GetFrustumMatrix uses isfinite to do the right 
thing in that case.

-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: Other Quesa concerns/suggestions

[Stefan H. <st...@to...>]

>>At least nan, inf, etc. do not work (correctly) when __FAST_MATH__ is on.
>
>Please tell me more.  How do they work differently when it is off?

About two years ago I ported an app that relies on nan, etc. from CW 
to Xcode. The main problem is (as far as I remember) that isnan, 
isinf and similar functions always return false if __FAST_MATH__ is 
on. Quesa does not use these functions.

BTW CWs "Relaxed IEEE Floating Point" setting works perfectly well with nan.

   Stefan
   http://www.topoi.ch

Re: Other Quesa concerns/suggestions

[Sean M. <se...@ro...>]

On 4/27/09 9:20 AM, James W. Walker said:

>> At least nan, inf, etc. do not work (correctly) when __FAST_MATH__  
>> is on.
>
>Please tell me more.  How do they work differently when it is off?

The gcc man page does discuss this somewhat.  It says:

"-ffast-math
Sets -fno-math-errno, -funsafe-math-optimizations, -fno-trapping-math, -
ffinite-math-only, -fno-rounding-math, -fno-signaling-nans and fcx-
limited-range."

Then for -ffinite-math-only it says:

"Allow optimizations for floating-point arithmetic that assume that
arguments and results are not NaNs or +-Infs."

-- 
____________________________________________________________
Sean McBride, B. Eng                 se...@ro...
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montréal, Québec, Canada

Re: Other Quesa concerns/suggestions

[James W. W. <os...@jw...>]

On Apr 27, 2009, at 9:04 AM, Stefan Huber wrote:

> At least nan, inf, etc. do not work (correctly) when __FAST_MATH__  
> is on.

Please tell me more.  How do they work differently when it is off?

Re: Other Quesa concerns/suggestions

[Stefan H. <st...@to...>]

At least nan, inf, etc. do not work (correctly) when __FAST_MATH__ is on.

>gcc's man page says:
>
>"-ffast-math
>Sets -fno-math-errno, -funsafe-math-optimizations, -fno-trapping-math, -
>ffinite-math-only, -fno-rounding-math, -fno-signaling-nans and fcx-
>limited-range.
>This option causes the preprocessor macro "__FAST_MATH__" to be defined.
>
>This option should never be turned on by any -O option since it can
>result in incorrect output for programs which depend on an exact
>implementation of IEEE or ISO rules/specifications for math functions."
>
>I agree 'fast' sounds like a recommendation, they probably should have
>called it GCC_BROKEN_MATH. :)

   Stefan
   http://www.topoi.ch

Re: svn ignores

[Sean M. <se...@ro...>]

On 4/26/09 6:36 PM, James W. Walker said:

>OK, Subversion experts, clue me in.  As you can see in the quesa-cvs  
>mailing list, I tried to set an svn:ignore property on the root  
>directory to make Subversion ignore .mode1v3 and .pbxuser files.  But  
>these files still show up in svn status.

One way to do this is by editing your ~/.subversion/config file and
changing the 'global-ignores' section.

-- 
____________________________________________________________
Sean McBride, B. Eng                 se...@ro...
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montréal, Québec, Canada

Re: svn ignores

[James W. W. <os...@jw...>]

On Apr 26, 2009, at 8:10 PM, Lane Roathe wrote:

> on Sun, Apr 26, 2009 James W. Walker may have said:
>
>> OK, Subversion experts, clue me in.  As you can see in the quesa-cvs
>> mailing list, I tried to set an svn:ignore property on the root
>> directory to make Subversion ignore .mode1v3 and .pbxuser files.  But
>> these files still show up in svn status.
>
> Not an svn expert, but I have found that you have to set it  
> recursively,
> and if anything is already in the repo it will not be ignored.

OK, thanks, I knew the second thing, but not the first.  Making  
recursive changes to the whole repository seems more adventurous than  
I'm ready for, so I'll make finer-grained ignores as the need arises.

Re: svn ignores

[Lane R. <la...@if...>]

on Sun, Apr 26, 2009 James W. Walker may have said:

>OK, Subversion experts, clue me in.  As you can see in the quesa-cvs  
>mailing list, I tried to set an svn:ignore property on the root  
>directory to make Subversion ignore .mode1v3 and .pbxuser files.  But  
>these files still show up in svn status.

Not an svn expert, but I have found that you have to set it recursively,
and if anything is already in the repo it will not be ignored.

Lane Roathe
President    Ideas From the Deep  <http://www.ideasfromthedeep.com>
___________________________________________________________________
Promoting the use of Turn Signals through Violent Video Games!

svn ignores

[James W. W. <os...@jw...>]

OK, Subversion experts, clue me in.  As you can see in the quesa-cvs  
mailing list, I tried to set an svn:ignore property on the root  
directory to make Subversion ignore .mode1v3 and .pbxuser files.  But  
these files still show up in svn status.

Re: Quesa now available by Subversion

[Roger H. <rog...@mi...>]

Thank you very much. I have now successfully checked out the source  
and done a trial change to one file and commit is now greyed in,  
though of course I chose  discard changes.

Soon I will be comparing my local version of Quesa with the official  
one and trying to merge the best bits of yours into mine, and be  
asking which parts of my version you want me to check in.

Thanks again.



On 26 Apr 2009, at 23:13, James W. Walker wrote:

> Set up for Xcode access to Quesa by svn:
>
> * Select the menu item SCM > Configure SCM Repositories... (which  
> may only be available when no projects are open).
> * Click the + under the Repositories list.
> * Enter quesa for the name, and Subversion for SCM system.
> * In the URL field, enter: https://quesa.svn.sourceforge.net/svnroot/quesa
> * If you have write access, also enter user name and password
> * Click the Options tab.
> * Check "Configure SCM Automatically" and any other options that you  
> like.
> * Click Apply or OK.
> * Select the menu item SCM > Repositories
> * In the Repositories window, navigate to trunk/quesa
> * Click the Checkout button on the tool bar, and select a location  
> for the directory

Re: Quesa now available by Subversion

[Lane R. <la...@if...>]

on Sun, Apr 26, 2009 James W. Walker may have said:

>I have set up Subversion access for Quesa

Yea! :)

Lane Roathe
President      Ideas From the Deep   <http://www.ideasfromthedeep.com>
______________________________________________________________________
Since the Internet has no walls or fences, who needs Windows or Gates?

Re: Quesa now available by Subversion

[James W. W. <os...@jw...>]

Set up for Xcode access to Quesa by svn:

* Select the menu item SCM > Configure SCM Repositories... (which may  
only be available when no projects are open).
* Click the + under the Repositories list.
* Enter quesa for the name, and Subversion for SCM system.
* In the URL field, enter: https://quesa.svn.sourceforge.net/svnroot/quesa
* If you have write access, also enter user name and password
* Click the Options tab.
* Check "Configure SCM Automatically" and any other options that you  
like.
* Click Apply or OK.
* Select the menu item SCM > Repositories
* In the Repositories window, navigate to trunk/quesa
* Click the Checkout button on the tool bar, and select a location for  
the directory

Re: Quesa now available by Subversion

[James W. W. <os...@jw...>]

P.S.  I have turned off write access to the CVS repository, even for  
myself, so that nobody will absentmindedly commit new changes to it.

Quesa now available by Subversion

[James W. W. <os...@jw...>]

I have set up Subversion access for Quesa.   I have not turned off CVS  
yet, but unless we run into some roadblock, future updates will only  
go into Subversion.  Commit notices will still show up on the quesa- 
cvs mailing list for now, though it is now a misnomer.

On a Unix command line, checking out Quesa into the current directory  
would be like so:

svn co https://quesa.svn.sourceforge.net/svnroot/quesa/trunk .

(That dot at the end is part of the command, not the end of a sentence.)

Re: Trying to get XCode to work with CVS

[Jose' C. <cru...@ce...>]

Il giorno 24/apr/09, alle ore 18:28, Roger Holmes ha scritto:

>>
>> try ssh rog...@qu... on a terminal to see
>> if you can connect without problems
>
> It said:
>
> Last login: Fri Apr 24 12:47:46 on console
> [Roger-Holmess-Computer-2:~] roger% ssh  
> rog...@qu...
> The authenticity of host 'quesa.cvs.sourceforge.net (216.34.181.109)'
> can't be established.
> RSA key fingerprint is <removed in case it is private>
> Are you sure you want to continue connecting (yes/no)? y
> Please type 'yes' or 'no': yes
> Warning: Permanently added 'quesa.cvs.sourceforge.net,
> 216.34.181.109' (RSA) to the list of known hosts.
> rog...@qu...'s password:
> Permission denied, please try again.
> rog...@qu...'s password:
> Permission denied, please try again.
> rog...@qu...'s password:
> Permission denied (publickey,password,keyboard-interactive).
>
>>
>
>>
>> I'm using keys to connect to sourceforge... I think that passwords
>> are disabled in sourceforge
>
> They used to work.

I've found a little HOWTO that can serve you to setup things (note  
that the ssh and keys issue is not tied to CVS, but is something you  
have to do also for SVN)

http://haacked.com/archive/2005/05/12/ 
QuickstartGuideToOpenSourceDevelopmentWithCVSAndSourceForge.aspx


Pax et Bonum

# Dott. José Cruanyes Aguilar  -  C.E. Soft srl
#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
#   02,3923101                0372,460602
http://www.linkedin.com/in/jcruanyes

Re: Trying to get XCode to work with CVS

[Roger H. <rog...@mi...>]

>
> try ssh rog...@qu... on a terminal to see
> if you can connect without problems

It said:

Last login: Fri Apr 24 12:47:46 on console
[Roger-Holmess-Computer-2:~] roger% ssh rog...@qu...
The authenticity of host 'quesa.cvs.sourceforge.net (216.34.181.109)'  
can't be established.
RSA key fingerprint is <removed in case it is private>
Are you sure you want to continue connecting (yes/no)? y
Please type 'yes' or 'no': yes
Warning: Permanently added 'quesa.cvs.sourceforge.net, 
216.34.181.109' (RSA) to the list of known hosts.
rog...@qu...'s password:
Permission denied, please try again.
rog...@qu...'s password:
Permission denied, please try again.
rog...@qu...'s password:
Permission denied (publickey,password,keyboard-interactive).

>

>
> I'm using keys to connect to sourceforge... I think that passwords
> are disabled in sourceforge

They used to work.

>
>
>
> Pax et Bonum
>
> # Dott. José Cruanyes Aguilar  -  C.E. Soft srl
> #  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
> #   02,3923101                0372,460602
> http://www.linkedin.com/in/jcruanyes
>
>
>
>
> ------------------------------------------------------------------------------
> Crystal Reports &#45; New Free Runtime and 30 Day Trial
> Check out the new simplified licensign option that enables unlimited
> royalty&#45;free distribution of the report engine for externally  
> facing
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop

Re: Other Quesa concerns/suggestions

[James W. W. <os...@jw...>]

On Apr 24, 2009, at 8:56 AM, Sean McBride wrote:

> This option should never be turned on by any -O option since it can
> result in incorrect output for programs which depend on an exact
> implementation of IEEE or ISO rules/specifications for math  
> functions."
>
> I agree 'fast' sounds like a recommendation, they probably should have
> called it GCC_BROKEN_MATH. :)



I would tend to assume that "programs which depend on an exact  
implementation of IEEE or ISO rules/specifications for math functions"  
would not include Quesa.