quesa-develop — Mailing list for Quesa development

Re: Optimisation

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

On Wednesday, April 7, 2004, at 07:25  am, Dair Grant wrote:

> Roger Holmes wrote:
>
>> In the current cvs source, TQ3ViewData has a field viewState which
>> is used to switch into the appropriate piece of code whenever an
>> object is submitted, including objects within groups in retained mode.
>> ..My version adds a pair of pointers to functions, one for immediate
>> mode and one for retained mode. Whenever viewState gets changed
>> then so do the two function pointers.
>
> OK.
>
>
>> e3view_submit_object disappears entirely and E3View_SubmitRetained
>> and E3View_SubmitImmediate become simply calls to the appropriate
>> function pointer. All the tests at the bottom of E3View_SubmitRetained
>> are rolled into the routines which get vectored to. There are two for
>> each value of viewState, including the 'Error' and 'BadMode' cases.
>
> Not sure I follow this bit - e3view_submit_object currently switches on
> viewMode rather than viewState, and also does some pre/post setup for
> picking.

Oops, I meant viewMode not viewState throughout my original e-mail. They
both get set at the same time and I clicked (and copied) the wrong one 
in the
source before pasting multiple times into the e-mail. I am not so 
sloppy when
I am programming I hasten to add.

>
> Where does that code get moved to, if e3view_submit_object is no longer
> there?

Firstly the call to E3ClassTree_GetClassByType.
In immediate mode,  it gets moved into each of the routines which get 
vectored to.
In retained mode, it is unnecessary as we have theObject->theClass 
which is a
benefit of the optimisation I forgot about.

The switch is replaced by a jump via one of the function pointers. The 
calls
to E3ClassTree_GetMethod are in the routines jumped to. The default case
jumps to the 'BadMode' routine, though this seems hardly necessary as 
the
view mode is known to be only ever kQ3ViewModeInactive, 
kQ3ViewModeDrawing,
kQ3ViewModePicking, kQ3ViewModeWriting or kQ3ViewModeCalcBounds.
I retained it as I went for safety where it would not compromise speed 
in any way.

The test if  instanceData->viewMode == kQ3ViewModePicking is now
redundant as the picking routines knows it is true and the other methods
know it is false. The test of instanceData->pickDecomposeCount == 0
gets put into the picking routines, as does the call to 
E3View_PickStack_SaveObject.

The test of submitMethod and the subsequent call etc. get moved into 
each of
the routines we vector to.

The test if instanceData->viewMode == kQ3ViewModePicking is again always
true in the picking routine and false elsewhere so is redundant. The 
second test
of instanceData->pickDecomposeCount and call to 
E3View_PickStack_SaveObject
get moved into the picking routines, though I toyed with the idea of 
doing the test
only once and having 'then' and 'else' clauses which included the 
submitMethod test
and call, but I rejected this as I was not ABSOLUTELY sure that 
pickDecomposeCount
could not change in the submit method itself. I have not profiled 
picking as it is
reasonably fast, it was retained mode drawing I was speeding up and I 
wanted
to make sure nothing else was slower, and if possible, faster.

>
>> The benefits are faster execution, a simpler stack crawl when you are
>> debugging. The only slight downside is that e3view_submit_begin is a
>> little bit bigger and that there is no central submit routine where
>> code could be placed.
>
> Hmm, the retained path also has pre and post render callbacks to the
> app, so do the get duplicated into the function pointers?

In only the retained mode render function as we know that the test of
instanceData->viewMode == kQ3ViewModeDrawing is false elsewhere
in retained mode, and that it is not needed in immediate mode. In the
source I sent you this is further optimised by a check to see if there
is a set on the object but I do not include that optimisation in this
set of changes.

> Perhaps I've misunderstood the change - is it in the set of source you
> sent me previously?

Yes. I think its my muddling of mode/state in the description which
is confusing you.

>  If so I'll take a read through it: to be honest it
> sounds like a bit of a micro-optimisation though, i.e., we're removing
> the overhead of calling e3view_submit_object but are still doing all 
> the
> same work - so the only thing that gets saved is the overhead of the
> function call?

No, a lot more than that. The switch, several tests, the call to
E3ClassTree_GetClassByType and for me it seems a lot cleaner
way of coding it, though there is nothing wrong with the original,
its just that things have got tacked on afterwards. When I step through
it whilst debugging, I keep thinking "Oh, get on with it, why is there
so much overhead before actually doing the real work?". The fact
that it shows up in 'Shark' is a good reason too!

Roger.

Re: Optimisation

[Dair G. <da...@re...>]

Roger Holmes wrote:

>In the current cvs source, TQ3ViewData has a field viewState which
>is used to switch into the appropriate piece of code whenever an
>object is submitted, including objects within groups in retained mode.
>..My version adds a pair of pointers to functions, one for immediate
>mode and one for retained mode. Whenever viewState gets changed
>then so do the two function pointers.

OK.


>e3view_submit_object disappears entirely and E3View_SubmitRetained
>and E3View_SubmitImmediate become simply calls to the appropriate
>function pointer. All the tests at the bottom of E3View_SubmitRetained
>are rolled into the routines which get vectored to. There are two for
>each value of viewState, including the 'Error' and 'BadMode' cases.

Not sure I follow this bit - e3view_submit_object currently switches on
viewMode rather than viewState, and also does some pre/post setup for
picking.

Where does that code get moved to, if e3view_submit_object is no longer
there?


>The benefits are faster execution, a simpler stack crawl when you are
>debugging. The only slight downside is that e3view_submit_begin is a
>little bit bigger and that there is no central submit routine where
>code could be placed.

Hmm, the retained path also has pre and post render callbacks to the
app, so do the get duplicated into the function pointers?

Perhaps I've misunderstood the change - is it in the set of source you
sent me previously? If so I'll take a read through it: to be honest it
sounds like a bit of a micro-optimisation though, i.e., we're removing
the overhead of calling e3view_submit_object but are still doing all the
same work - so the only thing that gets saved is the overhead of the
function call?


-dair
___________________________________________________
mailto:dair+refnum.com       http://www.refnum.com/

[ quesa-Bugs-923526 ] Transparent objects became less shiny

[SourceForge.net <no...@so...>]

Bugs item #923526, was opened at 2004-03-25 14:45
Message generated for change (Comment added) made by jwwalker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=923526&group_id=45158

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: James W. Walker (jwwalker)
>Assigned to: James W. Walker (jwwalker)
Summary: Transparent objects became less shiny

Initial Comment:
There seems to have been a change in the way that transparency 
interacts with specular color.  When I view a TriMesh object using a 
Quesa library built in Nov. 2003, it looks shinier than when I view 
it with a Quesa library build in Feb. 2004.  This change has been 
observed on both Mac and Windows.  I'd like to get back to the old 
behavior so that previously created objects will not need to be 
tweaked.

----------------------------------------------------------------------

>Comment By: James W. Walker (jwwalker)
Date: 2004-04-06 17:23

Message:
Logged In: YES 
user_id=433183

Actually, Quesa was never really handling specular color on transparent 
objects, it's just that there was sometimes a specular color left over from 
the last opaque object.  Now Quesa records specular color when 
buffering transparent primitives, and uses an extra pass through the 
buffered primitives to draw specular highlights.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=923526&group_id=45158

Re: Problems Building on Linux

[Jonathan J. <jo...@re...>]

On Apr 6, 2004, at 12:31 PM, Jose' Cruanyes wrote:
> Versions of automake-autoconf prior to 1.6 or so doesn't likes 
> multilevel directories
> try upgrading automake

Thanks! That did it (or at least seems to have done it). I need to 
emerge more often ;)

-Jon

Re: Problems Building on Linux

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

On Apr 6, 2004, at 7:05 PM, Jonathan Johnson wrote:

>
> On Apr 3, 2004, at 3:12 AM, Jose' Cruanyes wrote:
>
>>
>> On Apr 3, 2004, at 10:33 AM, Jose' Cruanyes wrote:
>>
>>> while trying to reproduce your problem I've had problems because my 
>>> line endings were Mac, maybe this is your case too
>>>
>>>
>>
>> Ooops... the unix archive for Quesa d18 has mac line endings...
>
> Well, that works better, but now I'm getting these errors:
>
> localhost Scripts # sh buildUnix.sh
> /home/fishy/quesa_1.6d18/Development/Projects/Unix 
> /home/fishy/quesa_1.6d18/Development/Projects/Unix/Scripts
> automake: configure.in: installing `./install-sh'
> automake: configure.in: installing `./mkinstalldirs'
> automake: configure.in: installing `./missing'
> configure.in: 228: installing `./config.guess'
> automake: Makefile.am: not supported: source file 
> `${QUESAAPI}/Quesa.h' is in subdirectory
> automake: Makefile.am: not supported: source file 
> `${QUESAAPI}/QuesaCamera.h' is in subdirectory
> automake: Makefile.am: not supported: source file 
> `${QUESAAPI}/QuesaController.h' is in subdirectory
> automake: Makefile.am: not supported: source file 
> `${QUESAAPI}/QuesaCustomElements.h' is in subdirectory
> automake: Makefile.am: not supported: source file 
> `${QUESAAPI}/QuesaDrawContext.h' is in subdirectory
> automake: Makefile.am: not supported: source file 
> `${QUESAAPI}/QuesaErrors.h' is in subdirectory
> ( it continues to list what looks to be every source file )
>
> Any ideas?
>

Versions of automake-autoconf prior to 1.6 or so doesn't likes 
multilevel directories
try upgrading automake

read the INSTALL.fullDist (and suggest changes to it)


Pax et Bonum

# dott. Jose' Cruanyes Aguilar  -  C.E. Soft srl
#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
#   02,33603122                0372,460602

Re: Problems Building on Linux

[Jonathan J. <jo...@re...>]

On Apr 3, 2004, at 3:12 AM, Jose' Cruanyes wrote:

>
> On Apr 3, 2004, at 10:33 AM, Jose' Cruanyes wrote:
>
>> while trying to reproduce your problem I've had problems because my 
>> line endings were Mac, maybe this is your case too
>>
>>
>
> Ooops... the unix archive for Quesa d18 has mac line endings...

Well, that works better, but now I'm getting these errors:

localhost Scripts # sh buildUnix.sh
/home/fishy/quesa_1.6d18/Development/Projects/Unix 
/home/fishy/quesa_1.6d18/Development/Projects/Unix/Scripts
automake: configure.in: installing `./install-sh'
automake: configure.in: installing `./mkinstalldirs'
automake: configure.in: installing `./missing'
configure.in: 228: installing `./config.guess'
automake: Makefile.am: not supported: source file `${QUESAAPI}/Quesa.h' 
is in subdirectory
automake: Makefile.am: not supported: source file 
`${QUESAAPI}/QuesaCamera.h' is in subdirectory
automake: Makefile.am: not supported: source file 
`${QUESAAPI}/QuesaController.h' is in subdirectory
automake: Makefile.am: not supported: source file 
`${QUESAAPI}/QuesaCustomElements.h' is in subdirectory
automake: Makefile.am: not supported: source file 
`${QUESAAPI}/QuesaDrawContext.h' is in subdirectory
automake: Makefile.am: not supported: source file 
`${QUESAAPI}/QuesaErrors.h' is in subdirectory
( it continues to list what looks to be every source file )

Any ideas?

Thanks in advance,
Jon

Re: transparency & specularity

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

On Apr 5, 2004, at 5:35 PM, Frank C wrote:

>> In the current design, all the transparent triangles are saved in a 
>> buffer and drawn at the end of the rendering pass.  There is no 
>> indication of whether Phong illumination was on or off when a 
>> particular triangle was added to the buffer, though it wouldn't be 
>> difficult to add that.
>
> I think it would be necessary to add that distinction, otherwise it 
> would break expected behaviour when using Lambert or null shaders on 
> transparent geometry.

You're right.  In the code I just checked in, the extra specular 
rendering is only done on triangles that were submitted with Phong 
rendering (and fill style == filled.)
--
<http://www.jwwalker.com/>

Re: transparency & specularity

[Frank C <li...@si...>]

On 5-Apr-04, at 12:20 PM, James W. Walker wrote:

> On Apr 4, 2004, at 11:50 PM, Frank C wrote:
>
>> Is a global switch really necessary? Quesa/QD3D already allows you to 
>> control Phong shading per-group, so it's already possible to turn off 
>> specularity on a per-object basis (regardless if they're transparent 
>> or not). You could also use the specular colour as a hint, and turn 
>> off the extra processing when it's pure black, since the end result 
>> would be the same.
>
> In the current design, all the transparent triangles are saved in a 
> buffer and drawn at the end of the rendering pass.  There is no 
> indication of whether Phong illumination was on or off when a 
> particular triangle was added to the buffer, though it wouldn't be 
> difficult to add that.

I think it would be necessary to add that distinction, otherwise it 
would break expected behaviour when using Lambert or null shaders on 
transparent geometry.

Frank.

Re: transparency & specularity

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

On Apr 4, 2004, at 11:50 PM, Frank C wrote:

> Is a global switch really necessary? Quesa/QD3D already allows you to 
> control Phong shading per-group, so it's already possible to turn off 
> specularity on a per-object basis (regardless if they're transparent 
> or not). You could also use the specular colour as a hint, and turn 
> off the extra processing when it's pure black, since the end result 
> would be the same.

In the current design, all the transparent triangles are saved in a 
buffer and drawn at the end of the rendering pass.  There is no 
indication of whether Phong illumination was on or off when a 
particular triangle was added to the buffer, though it wouldn't be 
difficult to add that.  And of course some triangles in the buffer may 
have black specular color and some not.
--
<http://www.jwwalker.com/>

Re: transparency & specularity

[Frank C <li...@si...>]

On 5-Apr-04, at 12:53 AM, James W. Walker wrote:

> On Mar 28, 2004, at 1:11 AM, Frank C wrote:
>
>> It could be that the specular highlights you see in old builds may be  
>> an errant state left over from some solid geometry, rather than  
>> specular settings specific to the transparent geometry.
>
> I think you're right.  Apparently Quesa doesn't really have any  
> provision for specular highlights on transparent material.  I found a  
> hint about how to do it:  
> <http://www.opengl.org/resources/faq/technical/ 
> transparency.htm#blen0030>
>
> I now have some code that renders shiny transparent stuff fairly  
> nicely, but I wonder whether it should be an option, since there is a  
> cost.  In a quick test in Geom Test, the frame rate went from about  
> 355 FPS down to 325 FPS when I added the extra shininess processing.   
> I could make it a renderer option, like the depth of the depth buffer.  
>  Opinions, anyone?

Is a global switch really necessary? Quesa/QD3D already allows you to  
control Phong shading per-group, so it's already possible to turn off  
specularity on a per-object basis (regardless if they're transparent or  
not). You could also use the specular colour as a hint, and turn off  
the extra processing when it's pure black, since the end result would  
be the same.

Frank.

Re: transparency & specularity

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

on Sun, Apr 4, 2004 James W. Walker may have said:

>I now have some code that renders shiny transparent stuff fairly  
>nicely, but I wonder whether it should be an option, since there is a  
>cost.  In a quick test in Geom Test, the frame rate went from about 355  
>FPS down to 325 FPS when I added the extra shininess processing.  I  
>could make it a renderer option, like the depth of the depth buffer.   
>Opinions, anyone?

An option sounds good...but that brings up a question; should options
like this be on or off by default?

My thought is on, but that there should be a single call to turn off all
costly options for those programs interested mainly in speed.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Lane Roathe, President                          Ideas From the Deep
<mailto:la...@if...>                          <http://www.ifd.com>
___________________________________________________________________
When we drive on parkways, park in driveways, and never obey the speed
limit, is it any wonder our children have trouble with right and wrong?

Re: transparency & specularity

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

On Mar 28, 2004, at 1:11 AM, Frank C wrote:

> It could be that the specular highlights you see in old builds may be  
> an errant state left over from some solid geometry, rather than  
> specular settings specific to the transparent geometry.

I think you're right.  Apparently Quesa doesn't really have any  
provision for specular highlights on transparent material.  I found a  
hint about how to do it:  
<http://www.opengl.org/resources/faq/technical/ 
transparency.htm#blen0030>

I now have some code that renders shiny transparent stuff fairly  
nicely, but I wonder whether it should be an option, since there is a  
cost.  In a quick test in Geom Test, the frame rate went from about 355  
FPS down to 325 FPS when I added the extra shininess processing.  I  
could make it a renderer option, like the depth of the depth buffer.   
Opinions, anyone?
--
<http://www.jwwalker.com/>

Re: Problems Building on Linux

[Jonathan J. <jo...@re...>]

On Apr 3, 2004, at 3:12 AM, Jose' Cruanyes wrote:

>
> On Apr 3, 2004, at 10:33 AM, Jose' Cruanyes wrote:
>
>> while trying to reproduce your problem I've had problems because my 
>> line endings were Mac, maybe this is your case too
>>
>>
>
> Ooops... the unix archive for Quesa d18 has mac line endings...
>
> try
>
> perl -pi -e 's/\r/\n/g' *
>
> on both the Unix and Scripts folders

Thanks, I'll try that out on Monday, and let you know the result.

-Jon

Re: Problems Building on Linux

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

On Apr 3, 2004, at 10:33 AM, Jose' Cruanyes wrote:

> while trying to reproduce your problem I've had problems because my 
> line endings were Mac, maybe this is your case too
>
>

Ooops... the unix archive for Quesa d18 has mac line endings...

try

perl -pi -e 's/\r/\n/g' *

on both the Unix and Scripts folders

Pax et Bonum

# dott. Jose' Cruanyes Aguilar  -  C.E. Soft srl
#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
#   02,33603122                0372,460602

Re: Problems Building on Linux

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

if you have to remove the exit statement is because the first pushd 
fails

try to execute the pushd statement alone and see why it fails

while trying to reproduce your problem I've had problems because my 
line endings were Mac, maybe this is your case too

On Apr 2, 2004, at 11:58 PM, Jonathan Johnson wrote:

> Hi,
>
> I'm fairly new to building Quesa, but the changes to how it builds 
> between d17 and 18 are causing grief here. Here's what I do:
>
> localhost fishy # tar -xzf quesa_1.6d18.tar.gz
> localhost fishy # cd quesa_1.6d18
> localhost quesa_1.6d18 # cd Development/
> localhost Development # cd Projects/
> localhost Projects # cd Unix/
> localhost Unix # cd Scripts/
> localhost Scripts # sh prepareUnixTree.sh
>
> At this point, it doesn't do anything. If I modify prepareUnixTree.sh 
> and remove the "|| exit" statement from the first pushd statement, it 
> then does this:
>
> localhost Scripts # sh prepareUnixTree.sh
> /home/fishy/quesa_1.6d18/Development/Projects/Unix 
> /home/fishy/quesa_1.6d18/Development/Projects/Unix/Scripts
> /home/fishy/quesa_1.6d18/Development/Projects/Unix/Source 
> /home/fishy/quesa_1.6d18/Development/Projects/Unix 
> /home/fishy/quesa_1.6d18/Development/Projects/Unix/Scripts
> /home/fishy/quesa_1.6d18/Development/Projects/Unix 
> /home/fishy/quesa_1.6d18/Development/Projects/Unix/Scripts
> /home/fishy/quesa_1.6d18/Development/Projects/Unix/Examples 
> /home/fishy/quesa_1.6d18/Development/Projects/Unix 
> /home/fishy/quesa_1.6d18/Development/Projects/Unix/Scripts
> /home/fishy/quesa_1.6d18/Development/Projects/Unix/Examples/Models 
> /home/fishy/quesa_1.6d18/Development/Projects/Unix/Examples 
> /home/fishy/quesa_1.6d18/Development/Projects/Unix 
> /home/fishy/quesa_1.6d18/Development/Projects/Unix/Scripts
> /home/fishy/quesa_1.6d18/Development/Projects/Unix/Examples 
> /home/fishy/quesa_1.6d18/Development/Projects/Unix 
> /home/fishy/quesa_1.6d18/Development/Projects/Unix/Scripts
> /home/fishy/quesa_1.6d18/Development/Projects/Unix 
> /home/fishy/quesa_1.6d18/Development/Projects/Unix/Scripts
> /home/fishy/quesa_1.6d18/Development/Projects/Unix/Scripts
>
> That makes sense! So, now I try "sh buildUnix.sh", and I see nothing 
> happen. So I do the same removal of || exit that I do in 
> prepareUnixTree, and I get this:
>
> localhost Scripts # sh buildUnix.sh
> /home/fishy/quesa_1.6d18/Development/Projects/Unix 
> /home/fishy/quesa_1.6d18/Development/Projects/Unix/Scripts
> automake: configure.in: `PACKAGE' not defined in `configure.in'
> automake: configure.in: `VERSION' not defined in `configure.in'
> automake: configure.in: installing `./install-sh'
> automake: configure.in: installing `./mkinstalldirs'
> automake: configure.in: installing `./missing'
> automake: no `Makefile.am' found or specified
> automake: configure.in: `PACKAGE' not defined in `configure.in'
> automake: configure.in: `VERSION' not defined in `configure.in'
> automake: no `Makefile.am' found or specified
> /home/fishy/quesa_1.6d18/Development/Projects/Unix/Examples 
> /home/fishy/quesa_1.6d18/Development/Projects/Unix 
> /home/fishy/quesa_1.6d18/Development/Projects/Unix/Scripts
> automake: configure.in: `PACKAGE' not defined in `configure.in'
> automake: configure.in: `VERSION' not defined in `configure.in'
> automake: no `Makefile.am' found or specified
> automake: configure.in: `PACKAGE' not defined in `configure.in'
> automake: configure.in: `VERSION' not defined in `configure.in'
> automake: no `Makefile.am' found or specified
> /home/fishy/quesa_1.6d18/Development/Projects/Unix 
> /home/fishy/quesa_1.6d18/Development/Projects/Unix/Scripts
> make: *** No targets specified and no makefile found.  Stop.
> /home/fishy/quesa_1.6d18/Development/Projects/Unix/Scripts
>
> I have no idea what's going on now. I'm not familiar with the whole 
> automake or autoconf procedures, so forgive me if I've forgotten 
> something silly. What have I done wrong, or what should I be doing?
>
> Thanks,
> Jon
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>
>
Pax et Bonum

# dott. Jose' Cruanyes Aguilar  -  C.E. Soft srl
#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
#   02,33603122                0372,460602

Problems Building on Linux

[Jonathan J. <jo...@re...>]

Hi,

I'm fairly new to building Quesa, but the changes to how it builds 
between d17 and 18 are causing grief here. Here's what I do:

localhost fishy # tar -xzf quesa_1.6d18.tar.gz
localhost fishy # cd quesa_1.6d18
localhost quesa_1.6d18 # cd Development/
localhost Development # cd Projects/
localhost Projects # cd Unix/
localhost Unix # cd Scripts/
localhost Scripts # sh prepareUnixTree.sh

At this point, it doesn't do anything. If I modify prepareUnixTree.sh 
and remove the "|| exit" statement from the first pushd statement, it 
then does this:

localhost Scripts # sh prepareUnixTree.sh
/home/fishy/quesa_1.6d18/Development/Projects/Unix 
/home/fishy/quesa_1.6d18/Development/Projects/Unix/Scripts
/home/fishy/quesa_1.6d18/Development/Projects/Unix/Source 
/home/fishy/quesa_1.6d18/Development/Projects/Unix 
/home/fishy/quesa_1.6d18/Development/Projects/Unix/Scripts
/home/fishy/quesa_1.6d18/Development/Projects/Unix 
/home/fishy/quesa_1.6d18/Development/Projects/Unix/Scripts
/home/fishy/quesa_1.6d18/Development/Projects/Unix/Examples 
/home/fishy/quesa_1.6d18/Development/Projects/Unix 
/home/fishy/quesa_1.6d18/Development/Projects/Unix/Scripts
/home/fishy/quesa_1.6d18/Development/Projects/Unix/Examples/Models 
/home/fishy/quesa_1.6d18/Development/Projects/Unix/Examples 
/home/fishy/quesa_1.6d18/Development/Projects/Unix 
/home/fishy/quesa_1.6d18/Development/Projects/Unix/Scripts
/home/fishy/quesa_1.6d18/Development/Projects/Unix/Examples 
/home/fishy/quesa_1.6d18/Development/Projects/Unix 
/home/fishy/quesa_1.6d18/Development/Projects/Unix/Scripts
/home/fishy/quesa_1.6d18/Development/Projects/Unix 
/home/fishy/quesa_1.6d18/Development/Projects/Unix/Scripts
/home/fishy/quesa_1.6d18/Development/Projects/Unix/Scripts

That makes sense! So, now I try "sh buildUnix.sh", and I see nothing 
happen. So I do the same removal of || exit that I do in 
prepareUnixTree, and I get this:

localhost Scripts # sh buildUnix.sh
/home/fishy/quesa_1.6d18/Development/Projects/Unix 
/home/fishy/quesa_1.6d18/Development/Projects/Unix/Scripts
automake: configure.in: `PACKAGE' not defined in `configure.in'
automake: configure.in: `VERSION' not defined in `configure.in'
automake: configure.in: installing `./install-sh'
automake: configure.in: installing `./mkinstalldirs'
automake: configure.in: installing `./missing'
automake: no `Makefile.am' found or specified
automake: configure.in: `PACKAGE' not defined in `configure.in'
automake: configure.in: `VERSION' not defined in `configure.in'
automake: no `Makefile.am' found or specified
/home/fishy/quesa_1.6d18/Development/Projects/Unix/Examples 
/home/fishy/quesa_1.6d18/Development/Projects/Unix 
/home/fishy/quesa_1.6d18/Development/Projects/Unix/Scripts
automake: configure.in: `PACKAGE' not defined in `configure.in'
automake: configure.in: `VERSION' not defined in `configure.in'
automake: no `Makefile.am' found or specified
automake: configure.in: `PACKAGE' not defined in `configure.in'
automake: configure.in: `VERSION' not defined in `configure.in'
automake: no `Makefile.am' found or specified
/home/fishy/quesa_1.6d18/Development/Projects/Unix 
/home/fishy/quesa_1.6d18/Development/Projects/Unix/Scripts
make: *** No targets specified and no makefile found.  Stop.
/home/fishy/quesa_1.6d18/Development/Projects/Unix/Scripts

I have no idea what's going on now. I'm not familiar with the whole 
automake or autoconf procedures, so forgive me if I've forgotten 
something silly. What have I done wrong, or what should I be doing?

Thanks,
Jon

Optimisation

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

Here is a stand alone optimisation which is part of the larger group
of optimisations which I have submitted for approval. This one stands
on its own merit and I would like permission to incorporate it into the
official cvs source. It has been incorporated into the issued version
of Microspot Interiors so it does not seem to cause any problems.

The changes are totally within E3View.c

In the current cvs source, TQ3ViewData has a field viewState which
is used to switch into the appropriate piece of code whenever an
object is submitted, including objects within groups in retained mode.
.My version adds a pair of pointers to functions, one for immediate
mode and one for retained mode. Whenever viewState gets changed
then so do the two function pointers.

e3view_submit_object disappears entirely and E3View_SubmitRetained
and E3View_SubmitImmediate become simply calls to the appropriate
function pointer. All the tests at the bottom of E3View_SubmitRetained
are rolled into the routines which get vectored to. There are two for
each value of viewState, including the 'Error' and 'BadMode' cases.

As the routines know exactly what mode they are in they are quite 
simple,
though they still have to check for nil pointers etc.

The benefits are faster execution, a simpler stack crawl when you are
debugging. The only slight downside is that e3view_submit_begin is
a little bit bigger and that there is no central submit routine where 
code
could be placed. Anything truly common could be put into both the
immediate and retained mode submit routines, though I think that the
code is now stable enough that this would be unlikely.

Can I go ahead with this?

Roger Holmes.

[ quesa-Bugs-922421 ] Severe Memory Leak caused by Resizing View (x86 only)

[SourceForge.net <no...@so...>]

Bugs item #922421, was opened at 2004-03-24 13:01
Message generated for change (Comment added) made by tomsanham
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=922421&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tom Sanham (tomsanham)
Assigned to: Nobody/Anonymous (nobody)
Summary: Severe Memory Leak caused by Resizing View (x86 only)

Initial Comment:
Platform: 
Windows XP
Quesa 1.6d18

To reproduce:

- Load GeomTest.exe
- Open 'Windows Task Manager'
- Resize the GeomTest window repeatedly
- 'Commit Charge' value in the Windows Task Manager 
window increases by a few MB with each resize. This 
lost memory is only reclaimed on quitting GeomTest

----------------------------------------------------------------------

>Comment By: Tom Sanham (tomsanham)
Date: 2004-03-31 15:40

Message:
Logged In: YES 
user_id=982065

More testing has indicated that the problem is related to 
video driver / card. Details are below.

The original machine setup giving the problem described is:

(1) Windows XP Home Ver 2002 SP 1, SiS 650 Rev 00

A second machine with nearly the same setup as the first did 
_not_ give the problem.

(2) Windows XP Home Ver 2002 SP 1, SiS 650 Rev 00

The only significant difference in setup was that machine (1) 
had the latest video drivers installed (SiS650 version 2.22 XP 
drivers) , and machine (2) had the factory video drivers 
installed.

To prove that the new video drivers were the culprit, we 
installed the latest video drivers onto machine (2), and since 
then, this machine gives the problem as well.

Other machines we tested, none of which gave the problem 
are:
(3) Windows XP Home Ver 2002, SP 1,  Graphics: Intel 82845G
(4) Windows XP Home Ver 2002, SP 1,  Graphics: Intel 82845G
(5) Windows XP Pro Ver 2002 SP 1, Graphics: NVIDIA GeForce 
FX5200
(6) Windows 98 SE 4.10.2222A, Graphics: SiS 530 Rev A2


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=922421&group_id=45158

Re: transparency & specularity

[Frank C <li...@si...>]

On 28-Mar-04, at 1:50 AM, James W. Walker wrote:

> I was looking into my bug #923526, and now I'm confused about how 
> transparency and specular color could ever work together.  As I 
> understand it, transparent TriMeshes are rendered late in the 
> rendering process, in IRTransBuffer_Draw and 
> ir_geom_transparent_render.  But these functions do not seem to 
> receive any information about specular color (or specular control).

There was a bug fix a little while back that resets specular 
color/control on each pass (to avoid highlights with null & Lambert 
shaders). It could be that the specular highlights you see in old 
builds may be an errant state left over from some solid geometry, 
rather than specular settings specific to the transparent geometry.

Frank.

transparency & specularity

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

I was looking into my bug #923526, and now I'm confused about how 
transparency and specular color could ever work together.  As I 
understand it, transparent TriMeshes are rendered late in the rendering 
process, in IRTransBuffer_Draw and ir_geom_transparent_render.  But 
these functions do not seem to receive any information about specular 
color (or specular control).
--
<http://www.jwwalker.com/>

[ quesa-Bugs-923593 ] Transparent objects became less shiny

[SourceForge.net <no...@so...>]

Bugs item #923593, was opened at 2004-03-25 17:15
Message generated for change (Settings changed) made by jwwalker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=923593&group_id=45158

Category: None
Group: None
>Status: Deleted
Resolution: None
Priority: 5
Submitted By: James W. Walker (jwwalker)
Assigned to: Nobody/Anonymous (nobody)
Summary: Transparent objects became less shiny

Initial Comment:
There seems to have been a change in the way that transparency 
interacts with specular color.  When I view a TriMesh object using a 
Quesa library built in Nov. 2003, it looks shinier than when I view 
it with a Quesa library build in Feb. 2004.  This change has been 
observed on both Mac and Windows.  I'd like to get back to the old 
behavior so that previously created objects will not need to be 
tweaked.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=923593&group_id=45158

[ quesa-Bugs-923593 ] Transparent objects became less shiny

[SourceForge.net <no...@so...>]

Bugs item #923593, was opened at 2004-03-25 17:15
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=923593&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: James W. Walker (jwwalker)
Assigned to: Nobody/Anonymous (nobody)
Summary: Transparent objects became less shiny

Initial Comment:
There seems to have been a change in the way that transparency 
interacts with specular color.  When I view a TriMesh object using a 
Quesa library built in Nov. 2003, it looks shinier than when I view 
it with a Quesa library build in Feb. 2004.  This change has been 
observed on both Mac and Windows.  I'd like to get back to the old 
behavior so that previously created objects will not need to be 
tweaked.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=923593&group_id=45158

[ quesa-Bugs-923526 ] Transparent objects became less shiny

[SourceForge.net <no...@so...>]

Bugs item #923526, was opened at 2004-03-25 14:45
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=923526&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: James W. Walker (jwwalker)
Assigned to: Nobody/Anonymous (nobody)
Summary: Transparent objects became less shiny

Initial Comment:
There seems to have been a change in the way that transparency 
interacts with specular color.  When I view a TriMesh object using a 
Quesa library built in Nov. 2003, it looks shinier than when I view 
it with a Quesa library build in Feb. 2004.  This change has been 
observed on both Mac and Windows.  I'd like to get back to the old 
behavior so that previously created objects will not need to be 
tweaked.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=923526&group_id=45158

[ quesa-Bugs-922747 ] Orientation style has no effect on trimesh

[SourceForge.net <no...@so...>]

Bugs item #922747, was opened at 2004-03-24 16:35
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=922747&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Frank Condello (pox)
Assigned to: Nobody/Anonymous (nobody)
Summary: Orientation style has no effect on trimesh

Initial Comment:
Orientation styles have no effect on geometry that use the trimesh 
render path. They are handled properly for geometry that use the 
triangle buffer path however.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=922747&group_id=45158

[ quesa-Bugs-922742 ] Alpha textures do not work properly with fog or specularity

[SourceForge.net <no...@so...>]

Bugs item #922742, was opened at 2004-03-24 16:32
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=922742&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Frank Condello (pox)
Assigned to: Nobody/Anonymous (nobody)
Summary: Alpha textures do not work properly with fog or specularity

Initial Comment:
In order to mimic QD3D's pre-multiplied alpha behaviour, Quesa 
resorts to using an additive blend mode for textures with alpha bits 
(GL_ONE, GL_ONE_MINUS_SRC_ALPHA). This works for the most 
part, but results in vertex effects like fog and specular highlights 
being blended additively over entire polygons rather than clipping 
to the alpha channel, as they would when using a blend mode like 
(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA). QD3D does not 
display these artifacts, so binary compatibility is compromised in 
these cases.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=922742&group_id=45158