quesa-develop — Mailing list for Quesa development

Re: [OT] QD3D not returning a Renderer Object

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

Tom Sanham wrote:

>> Q3Renderer_NewFromType(kQ3RendererTypeInteractive) always returns 0
>> if the app was run from the Shortcut in the start bar, (as installed
>> from .msi file). Obviously this causes the app not to work.
>>
>> However, all works fine if the app icon was double-clicked.
>
>One more clue I have just found - the problem only occurs when
>QD3D.dll and related files are in their default location
>(WINDOWS\SYSTEM), but works fine if these files are placed in the
>application directory.

Hmm, the only thing I can think of is that the PATH environment variable
is different when launched from a shortcut vs double-clicked?

Which would be a little odd, but it does sound like the problem is the
library isn't being found; and as far as I know Windows just does a
normal "grab a list of paths from an environment variable and check each
directory" when resolving shared libraries.


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

Re: Question on transparent camera transformed objects.

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

=46rank Condello wrote:

>> I wasn't sure that we had a consensus that it was the right thing to =20
>> do, since in at least one case the centroid method looks worse than =20
>> the current method.
>
>Which case was that? I can't seem to render anything properly with the =20
>current code. Triangles pop unpredictably at the slightness change in =20
>the viewport... From my perspective, your centroid code is the lesser =20
>of two evils :)

I think it was either the cone or the box; it was discussed previously
on the list.

I know you're keen to get a new sorting algorithm in place, but the
problem is the proposed change (a centroid sort) fixes your case but
makes others worse. In which case we're just swapping one problem for
another, and we'll be having this conversation again in 6 months. :-)


You seem to have a good grasp of the issues involved in ITransparent.c,
including what you'd like to see re state saving, so if you want to
provide a replacement for the core submit routine in there then please
do.

It should fix whatever problems you're seeing, and not make any current
situations (GeomTest, and whatever other apps people want to test with;
oh for a test suite ;-) worse.


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

Re: Question on transparent camera transformed objects.

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

=46rank Condello wrote:

>This would be a temporary fix at best, but if someone with CVS access=20
>wants to check it in that's fine with me.

So in all the back and forth on this thread, I'm not sure what the final
patch was; can you forward that to me or point me at the bug with it
attached?

I.e., 967773, or 967773 with some modifications? If so, what?


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

Re: [ quesa-Bugs-1032785 ] DrawContext mask image initialisation

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

SourceForge.net wrote:

>Fixed - an internal function, E3DrawContext_InitaliseData, is now used
>to initialise the optional fields when a draw context object is
>created.

Note, I haven't compiled this on non-Mac platforms; please let me know
if it breaks for anyone in case there was a typo.


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

[ quesa-Bugs-895092 ] Edge and point fill styles may render textured.

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

Bugs item #895092, was opened at 2004-02-11 19:44
Message generated for change (Comment added) made by grantd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=895092&group_id=45158

Category: None
Group: None
Status: Closed
Resolution: Works For Me
Priority: 5
Submitted By: Frank Condello (pox)
Assigned to: Nobody/Anonymous (nobody)
Summary: Edge and point fill styles may render textured.

Initial Comment:
Edge and point fill styles are textured if an object has a texture 
shader further down the pipe. e.g. A display group containing an 
edge fill style and a trimesh should render with color info only, but 
a texureshader in the trimesh's attribute set will override the fill 
style's texture state.

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

>Comment By: Dair Grant (grantd)
Date: 2004-10-05 22:52

Message:
Logged In: YES 
user_id=439944

I don't have a QD3D install to compare to, but wouldn't changing this 
preclude having textured lines? (i.e., when submitted as a 
TriMesh+texture+edge style)

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

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

Re: Question on GeomTest.

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

James W. Walker wrote:

>> I was reading the code in GeomTest for "createTestRasterize" and
>> would like to know why you create UV's for the object
=2E..
>It's probably just because of the "Toggle Texture" command in Geom
>Test.  For your own use, I do not think you need UVs on an object that
>will not be textured.

That's correct, the UVs are just there so a texture can be applied; if
you want to rasterise something that's just drawn with simple colours
then you can do without them.


Peter Michelsen wrote:

>That did the job for the top left corner but now the issue moved to the
>bottom right, which would seem more like place.
>
>Anyway it means that my math's can be a little simpler and the=20
>selection rectangle works in all quadrants so I am happy.

The normal offset to apply is 0.375f - google for "opengl 0.375
rasterize" to find some background (basically any offset you apply is a
bit of a compromise, but that's normally most reliable).


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

Re: Caching of Textures in file format

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

Peter Michelsen wrote:

>In QuickDraw3D 1.6 I have been informed there used to be a bug with=20
>caching of textures on saving and loading. We have some code to=20
>overcome this bug, but after some testing it seems that this bug does=20
>not exist in Quesa making this code redundant. Is this correct?

Quite probably - if things seem to be working for you then I'd revert
your workaround, and if you still find a situation where it fails we can
fix it properly. :-)


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

Re: RasteriseCameraTransform

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

Roger Holmes wrote:

>>> If it does, shouldn't Q3Transform_GetMatrix work on it? At present
>>> it gives an assertion error.
>>
>> It should work (i.e., not fail), although it won't return anything
>> sensible. It should call down to e3transform_camera_rasterize_matrix,
>> which will return an identity matrix for want of anything else.
>>
>> Where do you get the assert from?
>
>It asserts that the object is of type transform, but this fails.

I.e., the assert that's firing is the first one inside
Q3Transform_GetMatrix in QD3DTransform.c?

I don't see that fire here (current cvs) - I'm using the following as a
test:

    {   TQ3TransformObject  theTransform;
        TQ3Matrix4x4        theMatrix;
       =20
        theTransform =3D Q3RasterizeCameraTransform_New();
        Q3Transform_GetMatrix(theTransform, &theMatrix);
    }

If I step into that assertion, the transform object has type 'rast' and
its immediate parent is 'xfrm' which is what the assert verifies.


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

[ quesa-Bugs-1032785 ] DrawContext mask image initialisation

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

Bugs item #1032785, was opened at 2004-09-22 16:44
Message generated for change (Comment added) made by grantd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=1032785&group_id=45158

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: bork3d (bork3d)
Assigned to: Nobody/Anonymous (nobody)
Summary: DrawContext mask image initialisation

Initial Comment:
A "malloc debug: double free" occurs in 
Q3Bitmap_Empty. 
The pointer to be freed is garbage due to an uninitialised 
field in a TQ3MacDrawContextData structure declared on 
the stack. This can be fixed where the DrawingContext is 
initialized in e3drawcontext_mac_new().

/* E3MacDrawContext_New is being called without the 
mask image field explicitly set, causing problems in 
Q3Bitmap_Empty.
 * Callers _do_ however set maskState to kQ3False, 
so respect a valid mask image if maskState is kQ3True
 */
if (instanceData-
>data.macData.theData.drawContextData.maskState == 
kQ3False)
  instanceData-
>data.macData.theData.drawContextData.mask.image = 
NULL;

Similar fixes should be applied to other platform specific 
DrawingContext initialisation routines, such as 
e3drawcontext_windc_new() etc


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

>Comment By: Dair Grant (grantd)
Date: 2004-10-05 22:39

Message:
Logged In: YES 
user_id=439944

Fixed - an internal function, E3DrawContext_InitaliseData, is now used to 
initialise the optional fields when a draw context object is created.

This ensures that if maskState is true the app must supply an image, and 
if maskState is false the image will be initialised rather than left with 
random values.

This does mean that creating a draw context with a valid image but with 
maskState set to false will not allow you to turn on the mask by 
changing the maskState field, but I suspect that would have been invalid 
under QD3D too.

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

Comment By: bork3d (bork3d)
Date: 2004-09-23 07:22

Message:
Logged In: YES 
user_id=1126574

> If some client code calls Q3MacDrawContext_New without 
setting
> all the fields of the TQ3MacDrawContextData structure, that's 
their bug, not Quesa's 

The clients that do not initialise the mask bitmap image field are 
actually
internal Quesa calls. For example, Q3Viewer_New and 
Q3DrawContext_New

> 3drawcontext_mac_delete does check the maskState field 
before calling Q3Bitmap_Empty

That's just one path of many to reach Q3Bitmap_Empty and 
there are many code points where the maskState could be 
checked.

The scenario to trigger the bug is:
A DrawContext is created with Q3DrawContext_New
(on Mac this calls E3MacDrawContext_NewWithWindow, 
which allocates a TQ3DrawContextData structure on the stack, 
sets the maskState to kQ3False but does not initialise the 
mask.image field, which ensures the new DrawContext object's 
mask.image is garbage).
Later one replaces the mask with Q3DrawContext_SetMask()
which calls E3Bitmap_Replace(), disposing the garbage mask 
image. 

DrawContext_New takes a TQ3DrawContextData pointer as a 
parameter.
The internal callers of DrawContext_New (and also the sample 
code on which many apps are based) follow a common pattern 
that indicates an implied software contract in the use of 
DrawContext_New():
Clients initialise the maskState field to kQ3False to indicate the 
mask is not used. These clients do not explicitly set the mask's 
bitmap image field to NULL when maskState field is kQ3False and 
pass a stack declared structure that has random values in the 
TQ3Bitmap field of the TQ3DrawContextData.

The implied contract is that if the maskState is kQ3False then 
the mask bitmap will not be accessed. The clients assume that 
just setting maskState to kQ3False is sufficent. This however 
does not mean that Quesa will not access the bitmap, as there is 
at least one case where the bitmap is accessed without regard to 
the maskState flag: Q3DrawContext_SetMask() disposes of the 
old bitmap before installing a new one. This is a problem when 
the old bitmap image field is not a valid pointer.

I assert that the software contract that DrawContext_New will 
create a fully valid DrawContext object requires the mask's 
bitmap image field must initially be NULL if imageState is 
kQ3False. The clients do not explicitly set it, so 
DrawContext_New itself must enforce this condition.

The options to ensure DrawContext_New creates a fully valid 
object are:
1. Require clients must set mask.image to NULL.
2. Ensure the condition internally during DrawContext 
initialisation.

The bottleneck routines (e3drawcontext_PLATFORM_new) are 
the candidates for ensuring mask.image is NULL when the 
maskState is kQ3False.

And finally, what does QD3D do? It accepts TQ3DrawContextData 
with maskState kQ3False and garbage image pointer (witness all 
the sample code that uses this) and Q3DrawContext_SetMask() 
does not deallocate random memory. 
So the condition is enforced in QD3D.

Devil's advocate argument: what if I want to set a mask at 
initialisation but I also set the maskState kQ3False because I 
don’t want to use the mask immediately but will later use 
Q3DrawContext_SetMaskState() to toggle the use of the mask. 
The suggested fix will null the valid bitmap image and cause a 
leak.
The workaround is to use Q3DrawContext_SetMask() after 
creating the DrawContext with null mask.



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

Comment By: James W. Walker (jwwalker)
Date: 2004-09-22 17:27

Message:
Logged In: YES 
user_id=433183

I don't understand this.  If some client code calls 
Q3MacDrawContext_New 
without setting all the fields of the TQ3MacDrawContextData structure, 
that's their bug, not Quesa's.  Furthermore, e3drawcontext_mac_delete 
does check the maskState field before calling Q3Bitmap_Empty.

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

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

Re: Question on transparent camera transformed objects.

[Frank C. <dev...@ch...>]

This would be a temporary fix at best, but if someone with CVS access 
wants to check it in that's fine with me.

Frank.

On 1-Oct-04, at 11:27 AM, Peter Michelsen wrote:

> Hi Frank,
>
> Well, that's done the job. I did have problem with just
> 	
> 	glEnable(GL_LIGHTING);
> 	glEnable(GL_COLOR_MATERIAL);
>
> some of the transparent objects without NULLIllumination setting where 
> turning white but moving glEnable(GL_LIGTHING) and removing 
> glEnable(GL_COLOR_MATERIAL) fixed that.
>
> We are doing a week of test next week, I will let you know how that 
> goes and maybe you could check the change-in.
>
> Once again Thanks.
>
> Peter.
>
>
> On 29 Sep 2004, at 17:20, Frank Condello wrote:
>
>> On 29-Sep-04, at 12:05 PM, Frank Condello wrote:
>>
>>> On 29-Sep-04, at 6:17 AM, Peter Michelsen wrote:
>>>
>>>>> That's correct-  the illumination of the last solid object is 
>>>>> errantly maintained for the entire transparent pass. The bug 
>>>>> report linked above includes a bit of a workaround if your're 
>>>>> using the CVS source.
>>>>
>>>> I have test this solution as list in the bug report ( 96773 ).
>>>>
>>>> Yes it fixes the problem but effects all the other transparent 
>>>> objects, they become white. So not a solution.
>>>
>>> Sorry - I didn't do exhaustive testing with that (it was just off 
>>> the top of my head). You'll need enable lighting for the specular 
>>> pass, or else it'll draw solid. i.e. put:
>>>
>>> 	 	glEnable(GL_LIGHTING);
>>> 	 	glEnable(GL_COLOR_MATERIAL);
>>>
>>> Before the "// Second pass to add specular highlights" bit in 
>>> IRTransBuffer_Draw. That should do it - I think...
>>
>> Actually, that's a little excessive... Just put 
>> "glEnable(GL_LIGHTING);" above the "glBlendFunc( GL_ONE, GL_ONE );" 
>> in the "if (instanceData->transNeedSpecular)" statement. You may need 
>> to re-enable lighting at the bottom as well, but the next solid pass 
>> should get that anyway.
>>
>> I'll add these notes to the bug report, but there are several GL 
>> states (including lighting) that can be cached between triangles to 
>> speed up the transparent renderer by quite a bit.
>>
>> Frank.
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: IT Product Guide on 
>> ITManagersJournal
>> Use IT products in your business? Tell us what you think of them. 
>> Give us
>> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find 
>> out more
>> http://productguide.itmanagersjournal.com/guidepromo.tmpl
>> _______________________________________________
>> Quesa-develop mailing list
>> Que...@li...
>> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on 
> ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give 
> us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out 
> more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>
>

Re: Question on transparent camera transformed objects.

[Peter M. <Pet...@mi...>]

Hi Frank,

Well, that's done the job. I did have problem with just
	
	glEnable(GL_LIGHTING);
	glEnable(GL_COLOR_MATERIAL);

some of the transparent objects without NULLIllumination setting where 
turning white but moving glEnable(GL_LIGTHING) and removing 
glEnable(GL_COLOR_MATERIAL) fixed that.

We are doing a week of test next week, I will let you know how that 
goes and maybe you could check the change-in.

Once again Thanks.

Peter.


On 29 Sep 2004, at 17:20, Frank Condello wrote:

> On 29-Sep-04, at 12:05 PM, Frank Condello wrote:
>
>> On 29-Sep-04, at 6:17 AM, Peter Michelsen wrote:
>>
>>>> That's correct-  the illumination of the last solid object is 
>>>> errantly maintained for the entire transparent pass. The bug report 
>>>> linked above includes a bit of a workaround if your're using the 
>>>> CVS source.
>>>
>>> I have test this solution as list in the bug report ( 96773 ).
>>>
>>> Yes it fixes the problem but effects all the other transparent 
>>> objects, they become white. So not a solution.
>>
>> Sorry - I didn't do exhaustive testing with that (it was just off the 
>> top of my head). You'll need enable lighting for the specular pass, 
>> or else it'll draw solid. i.e. put:
>>
>> 	 	glEnable(GL_LIGHTING);
>> 	 	glEnable(GL_COLOR_MATERIAL);
>>
>> Before the "// Second pass to add specular highlights" bit in 
>> IRTransBuffer_Draw. That should do it - I think...
>
> Actually, that's a little excessive... Just put 
> "glEnable(GL_LIGHTING);" above the "glBlendFunc( GL_ONE, GL_ONE );" in 
> the "if (instanceData->transNeedSpecular)" statement. You may need to 
> re-enable lighting at the bottom as well, but the next solid pass 
> should get that anyway.
>
> I'll add these notes to the bug report, but there are several GL 
> states (including lighting) that can be cached between triangles to 
> speed up the transparent renderer by quite a bit.
>
> Frank.
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on 
> ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give 
> us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out 
> more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>

Re: Patch for bug #901422 (CLAMP_TO_EDGE)

[Daniele C. <dca...@in...>]

The newest function seem work fine..
Daniele
At 17.52 30/09/04, you wrote:
>OK, that looks about right (for the record I get 1.3 on Mac OS X 10.3.5). 
>I had thought OpenGL on Mac OS X was up to 1.4 or better but apparently it 
>differs depending on the card driver.
>
>Regardless, the function below should work in all cases now - perhaps 
>someone can check this in when they have a minute.
>
>Frank.
>
>On 30-Sep-04, at 3:39 AM, Daniele Cavallini wrote:
>
>>I try function with Window 98 and Windows Xp
>>In Window 98 I obtain:
>>openGLVersion = "1.15"
>>majorVers=1
>>minorVers=15
>>
>>In Window Xp
>>openGLVersion = "1.3.3966 winXP Release"
>>majorVers=1
>>minorVers=3
>>
>>Daniele
>>
>>
>>At 20.26 29/09/04, you wrote:
>>>Hmmm, GLUtils_CheckExtensions looks like it has some problems...
>>>
>>>First, the version check is flawed:
>>>
>>>         if ( (majorVers >= 1) && (minorVers >= 2) )
>>>
>>>would make more sense as:
>>>
>>>         if ( (majorVers > 1) || ((majorVers == 1) && (minorVers >= 2)) )
>>>
>>>Or else a version like "2.0" will get bypassed. The minor version can
>>>easily be two digits though, and "15" shouldn't be greater than "2" in
>>>this case, so it's broken anyway...
>>>
>>>Apple's glCheck code converts the GL_VERSION string into a BCD for
>>>comparisons
>>><http://developer.apple.com/samplecode/Carbon_AGL_Full_Screen/ 
>>>listing2.html> Quesa should probably do the same, something like this:
>>>
>>>------
>>>void
>>>GLUtils_CheckExtensions( TQ3GLExtensions* featureFlags )
>>>{
>>>         const char*     openGLVersion = (const char*)glGetString( 
>>> GL_VERSION );
>>>         const char*     openGLExtensions = (const char*)glGetString( 
>>> GL_EXTENSIONS
>>>);
>>>
>>>         short j = 0;
>>>         short shiftVal = 8;
>>>         unsigned short glVersion = 0;
>>>
>>>         // Initialize to default value, all off.
>>>         memset( featureFlags, 0, sizeof(TQ3GLExtensions) );
>>>
>>>         if (openGLVersion != NULL)
>>>         {
>>>                 // Get BCD version.
>>>                 while (((openGLVersion[j] <= '9') && 
>>> (openGLVersion[j] >= '0')) ||
>>>(openGLVersion[j] == '.'))
>>>                 {
>>>                         if ((openGLVersion[j] <= '9') && 
>>> (openGLVersion[j] >= '0'))
>>>                         {
>>>                                 glVersion += (openGLVersion[j] - '0') 
>>> << shiftVal;
>>>                                 shiftVal -= 4;
>>>                         }
>>>                         j++;
>>>                 }
>>>
>>>                 // Check for extensions.
>>>                 if ( glVersion >= 0x0120 ||
>>>                         isOpenGLExtensionPresent( openGLExtensions,
>>>"GL_EXT_separate_specular_color" ) )
>>>                 {
>>>                         featureFlags->separateSpecularColor = kQ3True;
>>>                 }
>>>
>>>                 if ( glVersion >= 0x0120 ||
>>>                         isOpenGLExtensionPresent( openGLExtensions,
>>>"GL_EXT_texture_edge_clamp" ) ||
>>>                         isOpenGLExtensionPresent( openGLExtensions,
>>>"GL_SGIS_texture_edge_clamp" ) )
>>>                 {
>>>                         featureFlags->clampToEdge = kQ3True;
>>>                 }
>>>         }
>>>}
>>>------
>>>
>>>Note: I added the GL_SGIS_texture_edge_clamp check as well. I've
>>>updated my patch archive with these changes, but for some reason I'm
>>>not convinced GL_VERSION is always correct (though Apple seems to
>>>depend on it). What OS are you running that returns OpenGL 1.15?
>>>
>>>Thanks,
>>>Frank.
>>>
>>>On 29-Sep-04, at 12:42 PM, Daniele Cavallini wrote:
>>>
>>>>I am using  OpenGL 1.15. The value is obtained from glGetString(
>>>>GL_VERSION ).
>>>>When exit from  GLUtils_CheckExtensions featureFlags->clampToEdge is
>>>>set to kQ3True;
>>>>I obtain:
>>>>majorVers =  1
>>>>minorVers = 15
>>>>after the step
>>>>int             numScanned = sscanf( openGLVersion, "%d.%d",
>>>>&majorVers, &minorVers );
>>>>It is Correct?
>>>>Daniele
>>>>
>>>>At 18.06 29/09/04, you wrote:
>>>>>No, that'll break it...
>>>>>
>>>>>The value will be false to start (the struct is zeroed in the
>>>>>function) and is set to true if using OpenGL 1.2+. The extension may
>>>>>not exist in an OpenGL 1.2+ implementation though, so you'll be
>>>>>setting it back to false even though it can be handled just fine at
>>>>>that point. The extension check is strictly for older OpenGL versions
>>>>>before the ARB ratified the function.
>>>>>
>>>>>Frank.
>>>>>
>>>>>On 29-Sep-04, at 10:59 AM, Daniele Cavallini wrote:
>>>>>
>>>>>>Question:
>>>>>>Is It better add this "else" in function "GLUtils_CheckExtensions"?
>>>>>>
>>>>>>  if (isOpenGLExtensionPresent( openGLExtensions,
>>>>>>GL_EXT_texture_edge_clamp" ))
>>>>>>         {
>>>>>>                 featureFlags->clampToEdge = kQ3True;
>>>>>>         }
>>>>>>         else
>>>>>>                 featureFlags->clampToEdge = kQ3False;
>>>>>>Daniele
>>>>>>
>>>>>>At 01.50 29/09/04, you wrote:
>>>>>>>Here: <http://chaoticbox.com/quesa901422.zip> is a small patch that
>>>>>>>checks for CLAMP_TO_EDGE and uses it when available for texture
>>>>>>>shaders
>>>>>>>that have a kQ3ShaderUVBoundaryClamp setting. The original report is
>>>>>>>here:
>>>>>>><http://sourceforge.net/tracker/index.php?  >>>> 
>>>>>>>func=detail&aid=901422&group_id=45158&atid=442052>
>>>>>>>
>>>>>>>On a similar note; Is there a better way to submit patches? Do you
>>>>>>>guys
>>>>>>>prefer some sort of diff tool output? If so, please let me know...
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
>Use IT products in your business? Tell us what you think of them. Give us
>Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
>http://productguide.itmanagersjournal.com/guidepromo.tmpl
>_______________________________________________
>Quesa-develop mailing list
>Que...@li...
>https://lists.sourceforge.net/lists/listinfo/quesa-develop
>

Re: Patch for bug #901422 (CLAMP_TO_EDGE)

[Frank C. <dev...@ch...>]

OK, that looks about right (for the record I get 1.3 on Mac OS X 
10.3.5). I had thought OpenGL on Mac OS X was up to 1.4 or better but 
apparently it differs depending on the card driver.

Regardless, the function below should work in all cases now - perhaps 
someone can check this in when they have a minute.

Frank.

On 30-Sep-04, at 3:39 AM, Daniele Cavallini wrote:

> I try function with Window 98 and Windows Xp
> In Window 98 I obtain:
> openGLVersion = "1.15"
> majorVers=1
> minorVers=15
>
> In Window Xp
> openGLVersion = "1.3.3966 winXP Release"
> majorVers=1
> minorVers=3
>
> Daniele
>
>
> At 20.26 29/09/04, you wrote:
>> Hmmm, GLUtils_CheckExtensions looks like it has some problems...
>>
>> First, the version check is flawed:
>>
>>         if ( (majorVers >= 1) && (minorVers >= 2) )
>>
>> would make more sense as:
>>
>>         if ( (majorVers > 1) || ((majorVers == 1) && (minorVers >= 
>> 2)) )
>>
>> Or else a version like "2.0" will get bypassed. The minor version can
>> easily be two digits though, and "15" shouldn't be greater than "2" in
>> this case, so it's broken anyway...
>>
>> Apple's glCheck code converts the GL_VERSION string into a BCD for
>> comparisons
>> <http://developer.apple.com/samplecode/Carbon_AGL_Full_Screen/ 
>> listing2.html> Quesa should probably do the same, something like 
>> this:
>>
>> ------
>> void
>> GLUtils_CheckExtensions( TQ3GLExtensions* featureFlags )
>> {
>>         const char*     openGLVersion = (const char*)glGetString( 
>> GL_VERSION );
>>         const char*     openGLExtensions = (const char*)glGetString( 
>> GL_EXTENSIONS
>> );
>>
>>         short j = 0;
>>         short shiftVal = 8;
>>         unsigned short glVersion = 0;
>>
>>         // Initialize to default value, all off.
>>         memset( featureFlags, 0, sizeof(TQ3GLExtensions) );
>>
>>         if (openGLVersion != NULL)
>>         {
>>                 // Get BCD version.
>>                 while (((openGLVersion[j] <= '9') && 
>> (openGLVersion[j] >= '0')) ||
>> (openGLVersion[j] == '.'))
>>                 {
>>                         if ((openGLVersion[j] <= '9') && 
>> (openGLVersion[j] >= '0'))
>>                         {
>>                                 glVersion += (openGLVersion[j] - '0') 
>> << shiftVal;
>>                                 shiftVal -= 4;
>>                         }
>>                         j++;
>>                 }
>>
>>                 // Check for extensions.
>>                 if ( glVersion >= 0x0120 ||
>>                         isOpenGLExtensionPresent( openGLExtensions,
>> "GL_EXT_separate_specular_color" ) )
>>                 {
>>                         featureFlags->separateSpecularColor = kQ3True;
>>                 }
>>
>>                 if ( glVersion >= 0x0120 ||
>>                         isOpenGLExtensionPresent( openGLExtensions,
>> "GL_EXT_texture_edge_clamp" ) ||
>>                         isOpenGLExtensionPresent( openGLExtensions,
>> "GL_SGIS_texture_edge_clamp" ) )
>>                 {
>>                         featureFlags->clampToEdge = kQ3True;
>>                 }
>>         }
>> }
>> ------
>>
>> Note: I added the GL_SGIS_texture_edge_clamp check as well. I've
>> updated my patch archive with these changes, but for some reason I'm
>> not convinced GL_VERSION is always correct (though Apple seems to
>> depend on it). What OS are you running that returns OpenGL 1.15?
>>
>> Thanks,
>> Frank.
>>
>> On 29-Sep-04, at 12:42 PM, Daniele Cavallini wrote:
>>
>>> I am using  OpenGL 1.15. The value is obtained from glGetString(
>>> GL_VERSION ).
>>> When exit from  GLUtils_CheckExtensions featureFlags->clampToEdge is
>>> set to kQ3True;
>>> I obtain:
>>> majorVers =  1
>>> minorVers = 15
>>> after the step
>>> int             numScanned = sscanf( openGLVersion, "%d.%d",
>>> &majorVers, &minorVers );
>>> It is Correct?
>>> Daniele
>>>
>>> At 18.06 29/09/04, you wrote:
>>>> No, that'll break it...
>>>>
>>>> The value will be false to start (the struct is zeroed in the
>>>> function) and is set to true if using OpenGL 1.2+. The extension may
>>>> not exist in an OpenGL 1.2+ implementation though, so you'll be
>>>> setting it back to false even though it can be handled just fine at
>>>> that point. The extension check is strictly for older OpenGL 
>>>> versions
>>>> before the ARB ratified the function.
>>>>
>>>> Frank.
>>>>
>>>> On 29-Sep-04, at 10:59 AM, Daniele Cavallini wrote:
>>>>
>>>>> Question:
>>>>> Is It better add this "else" in function "GLUtils_CheckExtensions"?
>>>>>
>>>>>  if (isOpenGLExtensionPresent( openGLExtensions,
>>>>> GL_EXT_texture_edge_clamp" ))
>>>>>         {
>>>>>                 featureFlags->clampToEdge = kQ3True;
>>>>>         }
>>>>>         else
>>>>>                 featureFlags->clampToEdge = kQ3False;
>>>>> Daniele
>>>>>
>>>>> At 01.50 29/09/04, you wrote:
>>>>>> Here: <http://chaoticbox.com/quesa901422.zip> is a small patch 
>>>>>> that
>>>>>> checks for CLAMP_TO_EDGE and uses it when available for texture
>>>>>> shaders
>>>>>> that have a kQ3ShaderUVBoundaryClamp setting. The original report 
>>>>>> is
>>>>>> here:
>>>>>> <http://sourceforge.net/tracker/index.php?  >>>> 
>>>>>> func=detail&aid=901422&group_id=45158&atid=442052>
>>>>>>
>>>>>> On a similar note; Is there a better way to submit patches? Do you
>>>>>> guys
>>>>>> prefer some sort of diff tool output? If so, please let me know...

Re: [OT] QD3D not returning a Renderer Object

[Tom S. <to...@as...>]

> Q3Renderer_NewFromType(kQ3RendererTypeInteractive) always returns 0 if the app was run from the Shortcut in the start bar, (as
> installed from .msi file). Obviously this causes the app not to work.
>
> However, all works fine if the app icon was double-clicked.

One more clue I have just found - the problem only occurs when QD3D.dll and related files are in their default location
(WINDOWS\SYSTEM), but works fine if these files are placed in the application directory.

Tom

[OT] QD3D not returning a Renderer Object

[Tom S. <to...@as...>]

Hi,

Apologies that this is not a Quesa question, but relating to QD3D.DLL running under Windows 98. I hope this is OK, I thought people
on this list might know.

The problem is a strange one:

Q3Renderer_NewFromType(kQ3RendererTypeInteractive) always returns 0 if the app was run from the Shortcut in the start bar, (as
installed from .msi file). Obviously this causes the app not to work.

However, all works fine if the app icon was double-clicked.

Running the app with Quesa returns the Renderer Object correctly in all cases, but due to other unresolved problems this particular
app has with Quesa on Win98. I am currently having to explore this route.

The same app works no problem on WinXP (Quesa or QD3D), MacOS 9 and X. It just seems to dislike Win98 for some reason.

Any ideas would be much appreciated.

Tom

Re: Patch for bug #901422 (CLAMP_TO_EDGE)

[Daniele C. <dca...@in...>]

I try function with Window 98 and Windows Xp
In Window 98 I obtain:
openGLVersion = "1.15"
majorVers=1
minorVers=15

In Window Xp
openGLVersion = "1.3.3966 winXP Release"
majorVers=1
minorVers=3

Daniele


At 20.26 29/09/04, you wrote:
>Hmmm, GLUtils_CheckExtensions looks like it has some problems...
>
>First, the version check is flawed:
>
>         if ( (majorVers >= 1) && (minorVers >= 2) )
>
>would make more sense as:
>
>         if ( (majorVers > 1) || ((majorVers == 1) && (minorVers >= 2)) )
>
>Or else a version like "2.0" will get bypassed. The minor version can
>easily be two digits though, and "15" shouldn't be greater than "2" in
>this case, so it's broken anyway...
>
>Apple's glCheck code converts the GL_VERSION string into a BCD for
>comparisons
><http://developer.apple.com/samplecode/Carbon_AGL_Full_Screen/ 
>listing2.html> Quesa should probably do the same, something like this:
>
>------
>void
>GLUtils_CheckExtensions( TQ3GLExtensions* featureFlags )
>{
>         const char*     openGLVersion = (const char*)glGetString( 
> GL_VERSION );
>         const char*     openGLExtensions = (const char*)glGetString( 
> GL_EXTENSIONS
>);
>
>         short j = 0;
>         short shiftVal = 8;
>         unsigned short glVersion = 0;
>
>         // Initialize to default value, all off.
>         memset( featureFlags, 0, sizeof(TQ3GLExtensions) );
>
>         if (openGLVersion != NULL)
>         {
>                 // Get BCD version.
>                 while (((openGLVersion[j] <= '9') && (openGLVersion[j] >= 
> '0')) ||
>(openGLVersion[j] == '.'))
>                 {
>                         if ((openGLVersion[j] <= '9') && 
> (openGLVersion[j] >= '0'))
>                         {
>                                 glVersion += (openGLVersion[j] - '0') << 
> shiftVal;
>                                 shiftVal -= 4;
>                         }
>                         j++;
>                 }
>
>                 // Check for extensions.
>                 if ( glVersion >= 0x0120 ||
>                         isOpenGLExtensionPresent( openGLExtensions,
>"GL_EXT_separate_specular_color" ) )
>                 {
>                         featureFlags->separateSpecularColor = kQ3True;
>                 }
>
>                 if ( glVersion >= 0x0120 ||
>                         isOpenGLExtensionPresent( openGLExtensions,
>"GL_EXT_texture_edge_clamp" ) ||
>                         isOpenGLExtensionPresent( openGLExtensions,
>"GL_SGIS_texture_edge_clamp" ) )
>                 {
>                         featureFlags->clampToEdge = kQ3True;
>                 }
>         }
>}
>------
>
>Note: I added the GL_SGIS_texture_edge_clamp check as well. I've
>updated my patch archive with these changes, but for some reason I'm
>not convinced GL_VERSION is always correct (though Apple seems to
>depend on it). What OS are you running that returns OpenGL 1.15?
>
>Thanks,
>Frank.
>
>On 29-Sep-04, at 12:42 PM, Daniele Cavallini wrote:
>
>>I am using  OpenGL 1.15. The value is obtained from glGetString(
>>GL_VERSION ).
>>When exit from  GLUtils_CheckExtensions featureFlags->clampToEdge is
>>set to kQ3True;
>>I obtain:
>>majorVers =  1
>>minorVers = 15
>>after the step
>>int             numScanned = sscanf( openGLVersion, "%d.%d",
>>&majorVers, &minorVers );
>>It is Correct?
>>Daniele
>>
>>At 18.06 29/09/04, you wrote:
>>>No, that'll break it...
>>>
>>>The value will be false to start (the struct is zeroed in the
>>>function) and is set to true if using OpenGL 1.2+. The extension may
>>>not exist in an OpenGL 1.2+ implementation though, so you'll be
>>>setting it back to false even though it can be handled just fine at
>>>that point. The extension check is strictly for older OpenGL versions
>>>before the ARB ratified the function.
>>>
>>>Frank.
>>>
>>>On 29-Sep-04, at 10:59 AM, Daniele Cavallini wrote:
>>>
>>>>Question:
>>>>Is It better add this "else" in function "GLUtils_CheckExtensions"?
>>>>
>>>>  if (isOpenGLExtensionPresent( openGLExtensions,
>>>>GL_EXT_texture_edge_clamp" ))
>>>>         {
>>>>                 featureFlags->clampToEdge = kQ3True;
>>>>         }
>>>>         else
>>>>                 featureFlags->clampToEdge = kQ3False;
>>>>Daniele
>>>>
>>>>At 01.50 29/09/04, you wrote:
>>>>>Here: <http://chaoticbox.com/quesa901422.zip> is a small patch that
>>>>>checks for CLAMP_TO_EDGE and uses it when available for texture
>>>>>shaders
>>>>>that have a kQ3ShaderUVBoundaryClamp setting. The original report is
>>>>>here:
>>>>><http://sourceforge.net/tracker/index.php?  >>>> 
>>>>>func=detail&aid=901422&group_id=45158&atid=442052>
>>>>>
>>>>>On a similar note; Is there a better way to submit patches? Do you
>>>>>guys
>>>>>prefer some sort of diff tool output? If so, please let me know...
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
>Use IT products in your business? Tell us what you think of them. Give us
>Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
>http://productguide.itmanagersjournal.com/guidepromo.tmpl
>_______________________________________________
>Quesa-develop mailing list
>Que...@li...
>https://lists.sourceforge.net/lists/listinfo/quesa-develop
>

[ quesa-Bugs-967773 ] Lighting state isn't respected on transparent objects

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

Bugs item #967773, was opened at 2004-06-06 17:09
Message generated for change (Comment added) made by pox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=967773&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Frank Condello (pox)
Assigned to: Nobody/Anonymous (nobody)
Summary: Lighting state isn't respected on transparent objects

Initial Comment:
The lighting state isn't restored when rendering transparent 
primitives.

There may already be enough information saved in the 
TQ3TransparentPrim struct to get proper lighting (in the 
"illumination" member)

Fixing this could be as simple as adding the following to 
ir_geom_transparent_render:

	if (thePrim->illumination == kQ3IlluminationTypeNULL)
		{
		glDisable(GL_LIGHTING);
		glDisable(GL_COLOR_MATERIAL);
		}
	else
		{
		glEnable(GL_LIGHTING);
		glEnable(GL_COLOR_MATERIAL);
		}
	}

...but the state should be saved between primitives and only 
changed when needed since they will likely be drawn in large 
groups that are either lit, or unlit.

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

>Comment By: Frank Condello (pox)
Date: 2004-09-29 12:22

Message:
Logged In: YES 
user_id=171509

Note: If using the workaround above, be sure to enable the GL_LIGHTING 
state for the specular pass, and before IRTransBuffer_Draw returns.

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

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

Re: Patch for bug #901422 (CLAMP_TO_EDGE)

[Frank C. <dev...@ch...>]

Hmmm, GLUtils_CheckExtensions looks like it has some problems...

First, the version check is flawed:

	if ( (majorVers >= 1) && (minorVers >= 2) )

would make more sense as:

	if ( (majorVers > 1) || ((majorVers == 1) && (minorVers >= 2)) )

Or else a version like "2.0" will get bypassed. The minor version can  
easily be two digits though, and "15" shouldn't be greater than "2" in  
this case, so it's broken anyway...

Apple's glCheck code converts the GL_VERSION string into a BCD for  
comparisons  
<http://developer.apple.com/samplecode/Carbon_AGL_Full_Screen/ 
listing2.html> Quesa should probably do the same, something like this:

------
void
GLUtils_CheckExtensions( TQ3GLExtensions* featureFlags )
{
	const char*	openGLVersion = (const char*)glGetString( GL_VERSION );
	const char*	openGLExtensions = (const char*)glGetString( GL_EXTENSIONS  
);
	
	short j = 0;
	short shiftVal = 8;
	unsigned short glVersion = 0;
	
	// Initialize to default value, all off.
	memset( featureFlags, 0, sizeof(TQ3GLExtensions) );
	
	if (openGLVersion != NULL)
	{
		// Get BCD version.
		while (((openGLVersion[j] <= '9') && (openGLVersion[j] >= '0')) ||  
(openGLVersion[j] == '.'))
		{
			if ((openGLVersion[j] <= '9') && (openGLVersion[j] >= '0'))
			{
				glVersion += (openGLVersion[j] - '0') << shiftVal;
				shiftVal -= 4;
			}
			j++;
		}

		// Check for extensions.
		if ( glVersion >= 0x0120 ||
			 isOpenGLExtensionPresent( openGLExtensions,  
"GL_EXT_separate_specular_color" ) )
		{
			featureFlags->separateSpecularColor = kQ3True;
		}
			
		if ( glVersion >= 0x0120 ||
			 isOpenGLExtensionPresent( openGLExtensions,  
"GL_EXT_texture_edge_clamp" ) ||
			 isOpenGLExtensionPresent( openGLExtensions,  
"GL_SGIS_texture_edge_clamp" ) )
		{
			featureFlags->clampToEdge = kQ3True;
		}
	}
}
------

Note: I added the GL_SGIS_texture_edge_clamp check as well. I've  
updated my patch archive with these changes, but for some reason I'm  
not convinced GL_VERSION is always correct (though Apple seems to  
depend on it). What OS are you running that returns OpenGL 1.15?

Thanks,
Frank.

On 29-Sep-04, at 12:42 PM, Daniele Cavallini wrote:

> I am using  OpenGL 1.15. The value is obtained from glGetString(  
> GL_VERSION ).
> When exit from  GLUtils_CheckExtensions featureFlags->clampToEdge is  
> set to kQ3True;
> I obtain:
> majorVers =  1
> minorVers = 15
> after the step
> int             numScanned = sscanf( openGLVersion, "%d.%d",  
> &majorVers, &minorVers );
> It is Correct?
> Daniele
>
> At 18.06 29/09/04, you wrote:
>> No, that'll break it...
>>
>> The value will be false to start (the struct is zeroed in the  
>> function) and is set to true if using OpenGL 1.2+. The extension may  
>> not exist in an OpenGL 1.2+ implementation though, so you'll be  
>> setting it back to false even though it can be handled just fine at  
>> that point. The extension check is strictly for older OpenGL versions  
>> before the ARB ratified the function.
>>
>> Frank.
>>
>> On 29-Sep-04, at 10:59 AM, Daniele Cavallini wrote:
>>
>>> Question:
>>> Is It better add this "else" in function "GLUtils_CheckExtensions"?
>>>
>>>  if (isOpenGLExtensionPresent( openGLExtensions,  
>>> GL_EXT_texture_edge_clamp" ))
>>>         {
>>>                 featureFlags->clampToEdge = kQ3True;
>>>         }
>>>         else
>>>                 featureFlags->clampToEdge = kQ3False;
>>> Daniele
>>>
>>> At 01.50 29/09/04, you wrote:
>>>> Here: <http://chaoticbox.com/quesa901422.zip> is a small patch that
>>>> checks for CLAMP_TO_EDGE and uses it when available for texture  
>>>> shaders
>>>> that have a kQ3ShaderUVBoundaryClamp setting. The original report is
>>>> here:
>>>> <http://sourceforge.net/tracker/index.php?  
>>>> func=detail&aid=901422&group_id=45158&atid=442052>
>>>>
>>>> On a similar note; Is there a better way to submit patches? Do you  
>>>> guys
>>>> prefer some sort of diff tool output? If so, please let me know...

Re: Patch for bug #901422 (CLAMP_TO_EDGE)

[Daniele C. <dca...@in...>]

I am using  OpenGL 1.15. The value is obtained from glGetString( GL_VERSION ).
When exit from  GLUtils_CheckExtensions featureFlags->clampToEdge is set to 
kQ3True;
I obtain:
majorVers =  1
minorVers = 15
after the step
int             numScanned = sscanf( openGLVersion, "%d.%d", &majorVers, 
&minorVers );
It is Correct?
Daniele



At 18.06 29/09/04, you wrote:
>No, that'll break it...
>
>The value will be false to start (the struct is zeroed in the function) 
>and is set to true if using OpenGL 1.2+. The extension may not exist in an 
>OpenGL 1.2+ implementation though, so you'll be setting it back to false 
>even though it can be handled just fine at that point. The extension check 
>is strictly for older OpenGL versions before the ARB ratified the function.
>
>Frank.
>
>On 29-Sep-04, at 10:59 AM, Daniele Cavallini wrote:
>
>>Question:
>>Is It better add this "else" in function "GLUtils_CheckExtensions"?
>>
>>  if (isOpenGLExtensionPresent( openGLExtensions, 
>> GL_EXT_texture_edge_clamp" ))
>>         {
>>                 featureFlags->clampToEdge = kQ3True;
>>         }
>>         else
>>                 featureFlags->clampToEdge = kQ3False;
>>Daniele
>>
>>At 01.50 29/09/04, you wrote:
>>>Here: <http://chaoticbox.com/quesa901422.zip> is a small patch that
>>>checks for CLAMP_TO_EDGE and uses it when available for texture shaders
>>>that have a kQ3ShaderUVBoundaryClamp setting. The original report is
>>>here:
>>><http://sourceforge.net/tracker/index.php? 
>>>func=detail&aid=901422&group_id=45158&atid=442052>
>>>
>>>On a similar note; Is there a better way to submit patches? Do you guys
>>>prefer some sort of diff tool output? If so, please let me know...
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
>Use IT products in your business? Tell us what you think of them. Give us
>Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
>http://productguide.itmanagersjournal.com/guidepromo.tmpl
>_______________________________________________
>Quesa-develop mailing list
>Que...@li...
>https://lists.sourceforge.net/lists/listinfo/quesa-develop
>

Re: Question on transparent camera transformed objects.

[Frank C. <dev...@ch...>]

On 29-Sep-04, at 12:05 PM, Frank Condello wrote:

> On 29-Sep-04, at 6:17 AM, Peter Michelsen wrote:
>
>>> That's correct-  the illumination of the last solid object is 
>>> errantly maintained for the entire transparent pass. The bug report 
>>> linked above includes a bit of a workaround if your're using the CVS 
>>> source.
>>
>> I have test this solution as list in the bug report ( 96773 ).
>>
>> Yes it fixes the problem but effects all the other transparent 
>> objects, they become white. So not a solution.
>
> Sorry - I didn't do exhaustive testing with that (it was just off the 
> top of my head). You'll need enable lighting for the specular pass, or 
> else it'll draw solid. i.e. put:
>
> 	 	glEnable(GL_LIGHTING);
> 	 	glEnable(GL_COLOR_MATERIAL);
>
> Before the "// Second pass to add specular highlights" bit in 
> IRTransBuffer_Draw. That should do it - I think...

Actually, that's a little excessive... Just put 
"glEnable(GL_LIGHTING);" above the "glBlendFunc( GL_ONE, GL_ONE );" in 
the "if (instanceData->transNeedSpecular)" statement. You may need to 
re-enable lighting at the bottom as well, but the next solid pass 
should get that anyway.

I'll add these notes to the bug report, but there are several GL states 
(including lighting) that can be cached between triangles to speed up 
the transparent renderer by quite a bit.

Frank.

Re: Patch for bug #901422 (CLAMP_TO_EDGE)

[Frank C. <dev...@ch...>]

No, that'll break it...

The value will be false to start (the struct is zeroed in the function) 
and is set to true if using OpenGL 1.2+. The extension may not exist in 
an OpenGL 1.2+ implementation though, so you'll be setting it back to 
false even though it can be handled just fine at that point. The 
extension check is strictly for older OpenGL versions before the ARB 
ratified the function.

Frank.

On 29-Sep-04, at 10:59 AM, Daniele Cavallini wrote:

> Question:
> Is It better add this "else" in function "GLUtils_CheckExtensions"?
>
>  if (isOpenGLExtensionPresent( openGLExtensions, 
> GL_EXT_texture_edge_clamp" ))
>         {
>                 featureFlags->clampToEdge = kQ3True;
>         }
>         else
>                 featureFlags->clampToEdge = kQ3False;
> Daniele
>
> At 01.50 29/09/04, you wrote:
>> Here: <http://chaoticbox.com/quesa901422.zip> is a small patch that
>> checks for CLAMP_TO_EDGE and uses it when available for texture 
>> shaders
>> that have a kQ3ShaderUVBoundaryClamp setting. The original report is
>> here:
>> <http://sourceforge.net/tracker/index.php? 
>> func=detail&aid=901422&group_id=45158&atid=442052>
>>
>> On a similar note; Is there a better way to submit patches? Do you 
>> guys
>> prefer some sort of diff tool output? If so, please let me know...

Re: Question on transparent camera transformed objects.

[Frank C. <dev...@ch...>]

On 29-Sep-04, at 6:17 AM, Peter Michelsen wrote:

>> That's correct-  the illumination of the last solid object is 
>> errantly maintained for the entire transparent pass. The bug report 
>> linked above includes a bit of a workaround if your're using the CVS 
>> source.
>
> I have test this solution as list in the bug report ( 96773 ).
>
> Yes it fixes the problem but effects all the other transparent 
> objects, they become white. So not a solution.

Sorry - I didn't do exhaustive testing with that (it was just off the 
top of my head). You'll need enable lighting for the specular pass, or 
else it'll draw solid. i.e. put:

	 	glEnable(GL_LIGHTING);
	 	glEnable(GL_COLOR_MATERIAL);

Before the "// Second pass to add specular highlights" bit in 
IRTransBuffer_Draw. That should do it - I think...

> Is the problem with openGL and transparent objects?

There's no real problem, they're just a pain in the arse ;)

Frank.

Re: Patch for bug #901422 (CLAMP_TO_EDGE)

[Daniele C. <dca...@in...>]

Question:
Is It better add this "else" in function "GLUtils_CheckExtensions"?

  if (isOpenGLExtensionPresent( openGLExtensions, GL_EXT_texture_edge_clamp" ))
         {
                 featureFlags->clampToEdge = kQ3True;
         }
         else
                 featureFlags->clampToEdge = kQ3False;
Daniele

At 01.50 29/09/04, you wrote:
>Here: <http://chaoticbox.com/quesa901422.zip> is a small patch that
>checks for CLAMP_TO_EDGE and uses it when available for texture shaders
>that have a kQ3ShaderUVBoundaryClamp setting. The original report is
>here:
><http://sourceforge.net/tracker/index.php? 
>func=detail&aid=901422&group_id=45158&atid=442052>
>
>On a similar note; Is there a better way to submit patches? Do you guys
>prefer some sort of diff tool output? If so, please let me know...
>
>Thanks,
>Frank.
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
>Use IT products in your business? Tell us what you think of them. Give us
>Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
>http://productguide.itmanagersjournal.com/guidepromo.tmpl
>_______________________________________________
>Quesa-develop mailing list
>Que...@li...
>https://lists.sourceforge.net/lists/listinfo/quesa-develop
>

Re: Question on transparent camera transformed objects.

[Peter M. <Pet...@mi...>]

On 28 Sep 2004, at 18:52, James W. Walker wrote:

> Peter Michelsen <Pet...@mi...> wrote:
>
>> I tried this but it had no effect as the objects are
>> transparent..... and I guess ( from testing ) use the last style
>> illumination style set in the submit loop. ( does this sound right
>> or am I way of base? ).
>
> That seems right.  Quesa saves the illumination style with each 
> transparent primitive, but only uses it to decide whether to use 
> specular highlights.  That is, it distinguishes Phong and Lambert 
> illumination from each other, but does not consider NULL illumination. 
>  This should probably be filed as a bug, if it hasn't been already.
>

Shall I write the bug report?

> What platform(s) are you targeting?  If all you need is Mac OS X, then 
> I would suggest not doing the selection stuff inside Quesa, but using 
> a transparent overlay window.  That way, the Quesa content does not 
> need to be re-rendered as the selection rectangle changes.
> -- 

This is the way we used to draw the rectangle but by using Quesa 
directly  we are able to get about 10 - 25 times more speed depending 
on the video card.

Peter.


>   James W. Walker, ScriptPerfection Enterprises, Inc.
>   <http://www.write-brain.com/>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on 
> ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give 
> us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out 
> more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>

Re: Question on transparent camera transformed objects.

[Peter M. <Pet...@mi...>]

>
> That's correct-  the illumination of the last solid object is errantly 
> maintained for the entire transparent pass. The bug report linked 
> above includes a bit of a workaround if your're using the CVS source.
>
> Frank.
>

I have test this solution as list in the bug report ( 96773 ).

Yes it fixes the problem but effects all the other transparent objects, 
they become white. So not a solution.

I tried just a special case for the objects in question but as soon as 
the function "glDisable(GL_LIGHTING);" is hit ( order not important 
)all transparent objects lose their colour ( I have also test without 
the glDisable(GL_COLOR_MATERIAL) function.)

Is the problem with openGL and transparent objects?
Are there any other solutions I can try.

Thanks for the ideas,

Peter.