Menu
▾
▴
quesa-develop — Mailing list for Quesa development
This list is closed, nobody may subscribe to it.
| 2004 |
Jan
(7) |
Feb
(117) |
Mar
(37) |
Apr
(46) |
May
(14) |
Jun
(255) |
Jul
(100) |
Aug
(76) |
Sep
(65) |
Oct
(38) |
Nov
(49) |
Dec
(41) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(106) |
Feb
(70) |
Mar
(9) |
Apr
(4) |
May
(42) |
Jun
(29) |
Jul
(106) |
Aug
(38) |
Sep
(11) |
Oct
(31) |
Nov
(14) |
Dec
(14) |
| 2006 |
Jan
(2) |
Feb
(9) |
Mar
(15) |
Apr
(13) |
May
(16) |
Jun
(5) |
Jul
(11) |
Aug
(1) |
Sep
(7) |
Oct
|
Nov
(9) |
Dec
(1) |
| 2007 |
Jan
(13) |
Feb
(107) |
Mar
(43) |
Apr
(43) |
May
(38) |
Jun
(38) |
Jul
(63) |
Aug
|
Sep
(30) |
Oct
(52) |
Nov
(4) |
Dec
(10) |
| 2008 |
Jan
(12) |
Feb
(10) |
Mar
(5) |
Apr
(3) |
May
(15) |
Jun
(2) |
Jul
|
Aug
(10) |
Sep
(20) |
Oct
(6) |
Nov
|
Dec
(6) |
| 2009 |
Jan
(1) |
Feb
(5) |
Mar
(3) |
Apr
(51) |
May
|
Jun
|
Jul
|
Aug
(14) |
Sep
|
Oct
|
Nov
|
Dec
(4) |
| 2010 |
Jan
(9) |
Feb
|
Mar
(8) |
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
(1) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
(9) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
(7) |
Dec
(1) |
| 2012 |
Jan
|
Feb
(6) |
Mar
(3) |
Apr
|
May
(6) |
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2004-06-06 20:54:05
|
Bugs item #967765, was opened at 2004-06-06 16:54 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=967765&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Frank Condello (pox) Assigned to: Nobody/Anonymous (nobody) Summary: Bad view transformations for transparent objects Initial Comment: Transparent vertices warp and eventually shoot off into infinity when approaching the camera/hither plane. This is likely a problem with the transforms used in ir_geom_transparent_add. See attached CFM Mac OS X application for an example. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=967765&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-06-06 20:00:52
|
Bugs item #967746, was opened at 2004-06-06 13:00 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=967746&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: James W. Walker (jwwalker) Assigned to: Nobody/Anonymous (nobody) Summary: IR doesn't support ambient coefficient Initial Comment: This was bug 00051 in the ancient pre-Bugzilla bug list. As far as I know it is still true, but I don't know if anyone cares. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=967746&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-06-06 19:48:43
|
Bugs item #967741, was opened at 2004-06-06 12:46 Message generated for change (Comment added) made by jwwalker You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=967741&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 4 Submitted By: James W. Walker (jwwalker) Assigned to: Nobody/Anonymous (nobody) Summary: Polyline ignores segment attributes Initial Comment: This was bug 00007 in the ancient pre-Bugzilla bug list: Wireframe/ Interactive renderers don't support segment attributes for polylines. Note that e3geom_polyline_cache_new is never called when using these renderers, instead IRGeometry_Submit_PolyLine and WFGeometry_PolyLine handle the polyline. ---------------------------------------------------------------------- >Comment By: James W. Walker (jwwalker) Date: 2004-06-06 12:48 Message: Logged In: YES user_id=433183 Bug 00022 in the ancient bug list was also this bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=967741&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-06-06 19:46:33
|
Bugs item #967741, was opened at 2004-06-06 12:46 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=967741&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 4 Submitted By: James W. Walker (jwwalker) Assigned to: Nobody/Anonymous (nobody) Summary: Polyline ignores segment attributes Initial Comment: This was bug 00007 in the ancient pre-Bugzilla bug list: Wireframe/ Interactive renderers don't support segment attributes for polylines. Note that e3geom_polyline_cache_new is never called when using these renderers, instead IRGeometry_Submit_PolyLine and WFGeometry_PolyLine handle the polyline. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=967741&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-06-06 18:47:37
|
Bugs item #967715, was opened at 2004-06-06 11:47 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=967715&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 1 Submitted By: James W. Walker (jwwalker) Assigned to: Nobody/Anonymous (nobody) Summary: Possible additional math functions Initial Comment: Formerly on the web site: -------------------------------------- The following functions have been identified as missing from QD3D, and potential candidates for including in Quesa: TQ3RationalPoint3D * Q3Param2D_To3D( const TQ3Param2D *param2D, TQ3RationalPoint3D *result); TQ3Param2D * Q3RationalPoint3D_ToParam2D( const TQ3RationalPoint3D *rationalPoint3D, TQ3Param2D *result); TQ3RationalPoint3D * Q3RationalPoint3D_RRatio( const TQ3RationalPoint3D *p1, const TQ3RationalPoint3D *p2, float r1, float r2, TQ3RationalPoint4D *result); float * Q3Param2D_CrossProductTri( const TQ3Param2D *p1, const TQ3Param2D *p2, const TQ3Param2D *p3); TQ3Status Q3Vector2D_To3DTransformArray( const TQ3Vector2D *inVectors2D, const TQ3Matrix3x3 *matrix3x3, TQ3RationalPoint3D *outRationalPoints3D, TQ3Uns32 numVectors, TQ3Uns32 inStructSize, TQ3Uns32 outStructSize); TQ3Status Q3Vector3D_To4DTransformArray( const TQ3Vector3D *inVectors3D, const TQ3Matrix4x4 *matrix4x4, TQ3RationalPoint4D *outRationalPoints4D, TQ3Uns32 numVectors, TQ3Uns32 inStructSize, TQ3Uns32 outStructSize); TQ3PolarPoint * Q3Param2D_ToPolar( const TQ3Param2D *param2D, TQ3PolarPoint *result); TQ3Param2D * Q3PolarPoint_ToParam2D( const TQ3PolarPoint *polarPoint, TQ3Param2D *result); TQ3PolarPoint * Q3Vector2D_ToPolar( const TQ3Vector2D *vector2D, TQ3PolarPoint *result); TQ3Vector2D * Q3PolarPoint_ToVector2D( const TQ3PolarPoint *polarPoint, TQ3Vector2D *result); TQ3SphericalPoint * Q3Vector3D_ToSpherical( const TQ3Vector3D *vector3D, TQ3SphericalPoint *result); Q3Vector3D * Q3SphericalPoint_ToVector3D( const TQ3SphericalPoint *sphericalPoint, TQ3Vector3D *result); TQ3Matrix4x4 * Q3Matrix4x4_Adjoint( const TQ3Matrix4x4 *matrix4x4, TQ3Matrix4x4 *result); -------------------------------------- I am not personally endorsing them, just recording them for posterity before deleting them from the web site. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=967715&group_id=45158 |
|
From: Frank C <li...@si...> - 2004-06-06 17:12:06
|
Below is a message I attempted to send to the list but apparently the attachments were too big - the files can be downloaded here: <http://webhome.idirect.com/~frankco/IRTexture.zip> Original message follows... On 5-Jun-04, at 9:14 PM, Stefan Huber wrote: > In ir_texture_convert_rave_filter the GL filter values has been > changed a few days ago. I've found a message about incomplete mipmap > specifications: > http://lists.apple.com/archives/mac-opengl/2003/Oct/13/ > ilosttextureunit2.001.txt. It says that CMF apps handle these cases as > linear where Mach-0 apps handle these cases as failure. I've attached two patched files that should fix this issue. The patch adds a "useMipmapping" flag to cached textures that allows ir_texture_set_state to fall back to the mag filter for the minification setting when textures lack mipmaps. NOTE: This won't catch cases where a Mipmap texture contains a partial set, so you'll either have to guarantee a full set, or ensure that the Mipmap texture's useMipmapping flag is set to false. ir_texture_convert_mipmap expects the same, so this seemed reasonable (partial sets would certainly be a bad idea either way). Please let me know how it works out - hopefully someone with CVS access can review it as well. Thanks, Frank. |
|
From: SourceForge.net <no...@so...> - 2004-06-06 15:21:47
|
Bugs item #967641, was opened at 2004-06-06 10:21 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=967641&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Lane Roathe (raving) Assigned to: Nobody/Anonymous (nobody) Summary: Flickering objects (shading?) Initial Comment: Using the 6/1/4 cvs version of Quesa, there are flickering (triangles?) objects in Nanosaur for Windows; these look like they might be "shadows" or other shading objects being drawn incorrectly. The version of Quesa I am using from 2/1/3 does not have these artifacts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=967641&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-06-06 15:19:33
|
Bugs item #967639, was opened at 2004-06-06 10:19 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=967639&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Lane Roathe (raving) Assigned to: Nobody/Anonymous (nobody) Summary: Nanosaur Overview Map not transparent Initial Comment: With the latest version of Quesa from cvs (6/1/4) the overview map in Nanosaur (for Windows) is not transparent. Using the cvs version from 2/1/3 the map is correctly transparent. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=967639&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-06-06 15:11:34
|
Bugs item #967633, was opened at 2004-06-06 10:11 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=967633&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Lane Roathe (raving) Assigned to: Nobody/Anonymous (nobody) Summary: Fog does not work correctly Initial Comment: The current version of Quesa (cvs as of 6/1/4) does not render fog correctly in Nanosaur Extreme under Windows. The verison of Quesa from Bugdom renders fog correctly. (But I can't use it due to lighting and floor tiling issues). You can swap in the Bugdom Quesa.dll to see how for should work, and the source for the Bugdom Quesa is at: <ftp://ftp.ifd.com/pub/Quesa_Bugdom.zip> Note that this is not a new issue, all versions of Quesa from cvs that I have used have had this issue with Nanosaur. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=967633&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-06-06 08:09:21
|
Bugs item #967190, was opened at 2004-06-05 10:27 Message generated for change (Comment added) made by jwwalker You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=967190&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Lane Roathe (raving) Assigned to: Nobody/Anonymous (nobody) Summary: Quesa Fails loading objects Initial Comment: The version of Quesa that is in CVS fails to load objects in Bugdom. I am using an older (much older!) version of Quesa in Bugdom now that loads these files correctly. I'd really like to update to the latest Quesa due to the speed improvements, but have not been able to sort out why the files do not load. I've attached the items that fail to load before the project crashes to this report. My working copy of Quesa is here in case anyone needs it again: ftp://ftp.ifd.com/pub/Quesa_Bugdom.zip Here is the function used to load the files: /***************** READ 3DMF MODEL ************************/ // // Reads the 3DMF file and saves into new struct OpaqueTQ3Object*. // // INPUT: file = File Object containing reference to 3DMF file // // OUTPUT: model =object containing all the important data in the 3DMF file // // static TQ3Status MyRead3DMFModel(TQ3FileObject file, struct OpaqueTQ3Object* *model) { struct OpaqueTQ3Object* myGroup; struct OpaqueTQ3Object* myObject; /* INIT MODEL TO BE RETURNED */ *model = 0; // assume return nothing myGroup = myObject = 0; /* OPEN THE FILE OBJECT & EXIT GRACEFULLY IF UNSUCCESSFUL */ if (Q3File_OpenRead(file,0) != kQ3Success) // open the file DoFatalAlert("Reading 3DMF file failed!"); /**************************************/ /* READ ALL THE OBJECTS FROM THE FILE */ /**************************************/ do { /* READ A METAFILE OBJECT FROM THE FILE OBJECT */ myObject = Q3File_ReadObject(file); if (myObject == 0) { if (myGroup) Q3Object_Dispose(myGroup); DoAlert("MyRead3DMFModel: Q3File_ReadObject Failed!"); QD3D_ShowRecentError(); break; } /* ADD ANY DRAWABLE OBJECTS TO A GROUP */ if (Q3Object_IsDrawable(myObject)) // see if is a drawable object { if (myGroup) // if group exists Q3Group_AddObject(myGroup,myObject); // add object to group else if (*model == 0) // if no model data yet / this is first { *model = myObject; // set model to this object myObject = 0; // clear this object } else // this isn't the first & only object, so add to group { myGroup = Q3DisplayGroup_New(); // make new group if (myGroup == 0) DoFatalAlert("MyRead3DMFModel: Q3DisplayGroup_New failed!"); Q3Group_AddObject(myGroup,*model); // add existing model to group Q3Group_AddObject(myGroup,myObject); // add object to group Q3Object_Dispose(*model); // dispose extra ref *model = myGroup; // set return value to the new group } } if (myObject != 0) // dispose extra ref Q3Object_Dispose(myObject); } while(!Q3File_IsEndOfFile(file)); /* SEE IF ANYTHING WENT WRONG */ if (Q3Error_Get(0) != kQ3ErrorNone) { if (*model != 0) { Q3Object_Dispose(*model); *model = 0; } return(kQ3Failure); } return(kQ3Success); } ---------------------------------------------------------------------- >Comment By: James W. Walker (jwwalker) Date: 2004-06-06 01:09 Message: Logged In: YES user_id=433183 The difference between your code and that in Qut.c (Qut_ReadModel) is that you quit when Q3File_ReadObject returns NULL. You could argue that this is valid, since the documentation says that Q3File_ReadObject returning NULL indicates an error. However, the sample code on p. 1026 of the QD3D manual also continues if Q3File_ReadObject returns NULL. The specific reason that Q3File_ReadObject returns NULL is that e3fformat_3dmf_bin_readobject does not know what to do about a table of contents, which e3fformat_3dmf_bin_read_toc has already dealt with. ---------------------------------------------------------------------- Comment By: Lane Roathe (raving) Date: 2004-06-05 23:01 Message: Logged In: YES user_id=48487 For some reason SF will not accept my attachments; probably requires that I use IE on Windows XP or some ... Anyway, I put the archive of the files that Quesa fails on online: <ftp://ftp.ifd.com/pub/Bugdom_3dmfs.zip> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=967190&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-06-06 06:01:48
|
Bugs item #967190, was opened at 2004-06-05 12:27 Message generated for change (Comment added) made by raving You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=967190&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Lane Roathe (raving) Assigned to: Nobody/Anonymous (nobody) Summary: Quesa Fails loading objects Initial Comment: The version of Quesa that is in CVS fails to load objects in Bugdom. I am using an older (much older!) version of Quesa in Bugdom now that loads these files correctly. I'd really like to update to the latest Quesa due to the speed improvements, but have not been able to sort out why the files do not load. I've attached the items that fail to load before the project crashes to this report. My working copy of Quesa is here in case anyone needs it again: ftp://ftp.ifd.com/pub/Quesa_Bugdom.zip Here is the function used to load the files: /***************** READ 3DMF MODEL ************************/ // // Reads the 3DMF file and saves into new struct OpaqueTQ3Object*. // // INPUT: file = File Object containing reference to 3DMF file // // OUTPUT: model =object containing all the important data in the 3DMF file // // static TQ3Status MyRead3DMFModel(TQ3FileObject file, struct OpaqueTQ3Object* *model) { struct OpaqueTQ3Object* myGroup; struct OpaqueTQ3Object* myObject; /* INIT MODEL TO BE RETURNED */ *model = 0; // assume return nothing myGroup = myObject = 0; /* OPEN THE FILE OBJECT & EXIT GRACEFULLY IF UNSUCCESSFUL */ if (Q3File_OpenRead(file,0) != kQ3Success) // open the file DoFatalAlert("Reading 3DMF file failed!"); /**************************************/ /* READ ALL THE OBJECTS FROM THE FILE */ /**************************************/ do { /* READ A METAFILE OBJECT FROM THE FILE OBJECT */ myObject = Q3File_ReadObject(file); if (myObject == 0) { if (myGroup) Q3Object_Dispose(myGroup); DoAlert("MyRead3DMFModel: Q3File_ReadObject Failed!"); QD3D_ShowRecentError(); break; } /* ADD ANY DRAWABLE OBJECTS TO A GROUP */ if (Q3Object_IsDrawable(myObject)) // see if is a drawable object { if (myGroup) // if group exists Q3Group_AddObject(myGroup,myObject); // add object to group else if (*model == 0) // if no model data yet / this is first { *model = myObject; // set model to this object myObject = 0; // clear this object } else // this isn't the first & only object, so add to group { myGroup = Q3DisplayGroup_New(); // make new group if (myGroup == 0) DoFatalAlert("MyRead3DMFModel: Q3DisplayGroup_New failed!"); Q3Group_AddObject(myGroup,*model); // add existing model to group Q3Group_AddObject(myGroup,myObject); // add object to group Q3Object_Dispose(*model); // dispose extra ref *model = myGroup; // set return value to the new group } } if (myObject != 0) // dispose extra ref Q3Object_Dispose(myObject); } while(!Q3File_IsEndOfFile(file)); /* SEE IF ANYTHING WENT WRONG */ if (Q3Error_Get(0) != kQ3ErrorNone) { if (*model != 0) { Q3Object_Dispose(*model); *model = 0; } return(kQ3Failure); } return(kQ3Success); } ---------------------------------------------------------------------- >Comment By: Lane Roathe (raving) Date: 2004-06-06 01:01 Message: Logged In: YES user_id=48487 For some reason SF will not accept my attachments; probably requires that I use IE on Windows XP or some ... Anyway, I put the archive of the files that Quesa fails on online: <ftp://ftp.ifd.com/pub/Bugdom_3dmfs.zip> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=967190&group_id=45158 |
|
From: Frank C <li...@si...> - 2004-06-06 05:35:37
|
On 5-Jun-04, at 11:03 PM, Joseph J. Strout wrote: > At 7:23 PM -0700 6/5/04, James W. Walker wrote: > >> I haven't seen any problem with texturing. In particular, in Geom >> Test, the textured box and the TriMesh with toggled texture look OK. >> Have you tried to reproduce it in a simple setting? > > But when I load the same floor model used in the screen shots posted > earlier, the bug is clearly happening in Geom Test. You can try the > same model here: <http://www.strout.net/temp/Floor.3DMF> The texture is ARGB32... I've seen this, and it appears to be the same (or related) problem I mentioned earlier; Basically, the new transforms in ir_geom_transparent_add aren't working right. I'll try to log a bug with an example app in the next day or so. Frank. |
|
From: Frank C <li...@si...> - 2004-06-06 05:33:40
|
On 5-Jun-04, at 9:14 PM, Stefan Huber wrote: > It seems that it's a Mach-0 only bug. To my surprise the CFM version > of my app works fine. > > In ir_texture_convert_rave_filter the GL filter values has been > changed a few days ago. I've found a message about incomplete mipmap > specifications: > http://lists.apple.com/archives/mac-opengl/2003/Oct/13/ > ilosttextureunit2.001.txt. It says that CMF apps handle these cases as > linear where Mach-0 apps handle these cases as failure. That would explain it. This was one of my concerns when implementing the new filters, but when it worked in CFM I figured it was OK - live and learn I guess... We'll have to revert to a GL_LINEAR minification filter when a Mipmap texture uses an incomplete set - I should have some time to look into this over the next few days, but please feel free to do the same. Thanks, Frank. |
|
From: James W. W. <os...@jw...> - 2004-06-06 05:18:04
|
I've done some binary search testing, checking out to various dates, and have determined that the bug was introduced on Jan. 12, 2004, when Dair checked in changes having to do with camera matrices. This change involved many interdependent changes in a slew of files, so it's hard to narrow things down any more without actually understanding what these changes are supposed to be doing. -- <http://www.jwwalker.com/> |
|
From: James W. W. <os...@jw...> - 2004-06-06 03:57:31
|
On Jun 5, 2004, at 8:03 PM, Joseph J. Strout wrote: > But when I load the same floor model used in the screen shots posted > earlier, the bug is clearly happening in Geom Test. You can try the > same model here: <http://www.strout.net/temp/Floor.3DMF> > > It's not as obvious in Geom Test, because the view is small and the > object is tumbling, but it's clearly there. Can you see it with your > build? (I could post a screen shot if that would help.) Yes, I do see it. It became even more obvious when I edited your file to make the uv coordinates range between 0 and 1. -- <http://www.jwwalker.com/> |
|
From: Joseph J. S. <jo...@st...> - 2004-06-06 03:03:21
|
At 7:23 PM -0700 6/5/04, James W. Walker wrote: >I haven't seen any problem with texturing. In particular, in Geom >Test, the textured box and the TriMesh with toggled texture look OK. >Have you tried to reproduce it in a simple setting? I can't convince myself whether the textured TriMesh in Geom Test looks OK or not; it's not a flat plane to begin with, and it's rotating, and the texture is not regular like a grid, so the effect may be harder to see. But when I load the same floor model used in the screen shots posted earlier, the bug is clearly happening in Geom Test. You can try the same model here: <http://www.strout.net/temp/Floor.3DMF> It's not as obvious in Geom Test, because the view is small and the object is tumbling, but it's clearly there. Can you see it with your build? (I could post a screen shot if that would help.) Thanks, - Joe -- ,------------------------------------------------------------------. | Joseph J. Strout Check out the Mac Web Directory: | | jo...@st... http://www.macwebdir.com/ | `------------------------------------------------------------------' |
|
From: James W. W. <os...@jw...> - 2004-06-06 02:23:58
|
On Jun 5, 2004, at 6:56 PM, Joseph J. Strout wrote: > I've just noticed a serious bug in texture-mapping with a build of > Quesa I did from the CVS sources on June 1st. It shows up in a level > editor, where there is a floor textured with a grid. ... > Known issue, or unpleasant surprise? I searched the bug tracker and > didn't find anything, but then, I don't trust my searching skills > with that yet. I haven't seen any problem with texturing. In particular, in Geom Test, the textured box and the TriMesh with toggled texture look OK. Have you tried to reproduce it in a simple setting? -- <http://www.jwwalker.com/> |
|
From: Joseph J. S. <jo...@st...> - 2004-06-06 02:02:52
|
I've just noticed a serious bug in texture-mapping with a build of Quesa I did from the CVS sources on June 1st. It shows up in a level editor, where there is a floor textured with a grid. The floor is a TriMesh with two triangles, with a simple grid texture, and looks like this in 1.6d18 and before: <http://www.strout.net/temp/texmap-d18.png> (Please excuse the low contrast.) But under my June 1st build, it looks like this: <http://www.strout.net/temp/texmap-d19.png> When I move the camera so that the triangle normals are pointing directly out of the screen, the mapping is correct. It looks to me as if the UV interpolation is happening after the triangles are projected to the screen, rather than happening in world coordinates, so the perspective on the texture is all screwed up. Known issue, or unpleasant surprise? I searched the bug tracker and didn't find anything, but then, I don't trust my searching skills with that yet. (Jos=E9: I strongly recommend we *don't* pack up a 1.6d19 distribution for general consumption yet; we need to nail down any new bugs first, like this one and perhaps others, so that updating doesn't turn out to be a step backwards for end-users.) Thanks, - Joe -- ,------------------------------------------------------------------. | Joseph J. Strout Check out the Mac Web Directory: | | jo...@st... http://www.macwebdir.com/ | `------------------------------------------------------------------' |
|
From: Stefan H. <st...@to...> - 2004-06-06 01:15:15
|
It seems that it's a Mach-0 only bug. To my surprise the CFM version of my app works fine. In ir_texture_convert_rave_filter the GL filter values has been changed a few days ago. I've found a message about incomplete mipmap specifications: http://lists.apple.com/archives/mac-opengl/2003/Oct/13/ilosttextureunit2.001.txt. It says that CMF apps handle these cases as linear where Mach-0 apps handle these cases as failure. I've no idea if this is the problem. My test file contains the same mipmap type as yours (0 mipmap). Stefan >>The TQ3TextureFilter types kQATextureFilter_Mid and >>kQATextureFilter_Best don't work together with Mipmap textures. The >>Mipmap textures won't be rendered. This bug has been introduced >>during the last two or three weeks. > >The filters have recently been updated specifically to work with >mipmaps and to better match QD3D's output. Previously, only the 0 >mip was ever considered (in fact, this is still the case in >kQATextureFilter_Fast). This change may have revealed a problem with >how custom mip levels are uploaded in ir_texture_convert_mipmap, or >could point to a bug in your own source that wouldn't have >manifested itself prior to this change. > >Do you have a sample I can look at? I've tested the Mipmap texture >type using only the 0 mip (i.e. to avoid using mipmaps for certain >textures) but I haven't tried creating all the mip levels manually, >since the Pixmap type now does that automatically to match QD3D >1.6's behaviour. > >Frank. |
|
From: Frank C <li...@si...> - 2004-06-05 21:27:53
|
On 5-Jun-04, at 5:00 PM, Stefan Huber wrote: > The TQ3TextureFilter types kQATextureFilter_Mid and > kQATextureFilter_Best don't work together with Mipmap textures. The > Mipmap textures won't be rendered. This bug has been introduced during > the last two or three weeks. The filters have recently been updated specifically to work with mipmaps and to better match QD3D's output. Previously, only the 0 mip was ever considered (in fact, this is still the case in kQATextureFilter_Fast). This change may have revealed a problem with how custom mip levels are uploaded in ir_texture_convert_mipmap, or could point to a bug in your own source that wouldn't have manifested itself prior to this change. Do you have a sample I can look at? I've tested the Mipmap texture type using only the 0 mip (i.e. to avoid using mipmaps for certain textures) but I haven't tried creating all the mip levels manually, since the Pixmap type now does that automatically to match QD3D 1.6's behaviour. Frank. |
|
From: Stefan H. <st...@to...> - 2004-06-05 21:01:45
|
The TQ3TextureFilter types kQATextureFilter_Mid and kQATextureFilter_Best don't work together with Mipmap textures. The Mipmap textures won't be rendered. This bug has been introduced during the last two or three weeks. Stefan ___________________ http://www.topoi.ch |
|
From: SourceForge.net <no...@so...> - 2004-06-05 20:48:50
|
Bugs item #967272, was opened at 2004-06-05 13:48 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=967272&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: Leak stack crawls for other OS/runtime Initial Comment: The leak detection mechanism in Quesa currently only shows stack crawls for leaked allocations in the Mac/CFM case. It should be possible to add support for Mac/Mach using the MoreBackTrace code from Apple's MoreIsBetter sample code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=967272&group_id=45158 |
|
From: Frank C <li...@si...> - 2004-06-05 20:37:55
|
On 5-Jun-04, at 3:43 PM, Dair Grant wrote:
> Can you log some bugs demonstrating how?
I'll try to do this tomorrow.
>> The only thing I'm concerned about is how and when the light state is
>> updated - looking through the code it appears to happen once per
>> frame, but in practice it updates for every mesh - so I'm missing
>> something here...
>
> Where do you see it being updated on each mesh? The lights should be
> converted once per frame, by IRRenderer_Lights_StartPass.
That's why I'm confused - I'll try to explain what I'm seeing:
As part of the colour modulation fix posted yesterday, I'm checking
stateViewIllumination in ir_light_reset and disabling lighting if it's
kQ3IlluminationTypeNULL. This allows modulated texture blending on null
shaded objects, but still has them render at full brightness
(previously the blend state was set to replace and lighting was simply
left on).
If ir_light_reset is only called once per frame then this should break
scenes that mix lit and null shaded objects, but it's been working in
my test cases so far.
I've set up a test app that draws 12 cubes in a grid, with the state of
each cude is determined by it's position in the grid:
Phong Lambert Null
no texture opaque: X X X
no texture transparent: X X X
textured opaque: X X X
textured transparent: X X X
Attribute sets are shared across each row, but each cube is it's own
display group containing an appropriate illumination shader to try and
get the illumination state to change as often as possible. This renders
correctly with my changes (transparency bugs aside for the moment) but
looking at the source, it really shouldn't. I must be missing something
entirely in the IR source, or my test case is flawed.
Is there an explanation and/or diagram of Quesa's render pipeline
anywhere?
Frank.
|
|
From: Dair G. <da...@re...> - 2004-06-05 19:43:15
|
=46rank C wrote: >The transparent renderer is very broken in the current CVS source - I'd=20 >highly recommend waiting till it's fixed! Can you log some bugs demonstrating how? >Problems with the transparent renderer that I've seen so far: > >1). the new localToFrustum transforms in ir_geom_transparent_add aren't=20 >working right - I'm consistently seeing jumbled geometry (I'll make an=20 >example app that shows this if no one else sees it, but all you have to=20 >do is draw some transparent geometry that approaches or clips the=20 >frustum). I had a look at this with the bug you logged before: and wasn't able to reproduce any problems with geometry intersecting the frustum. The flicker in that particular case (three overlapping transparent boxes) was due to the sorting order: see the notes on that bug for more info. >2). No fog. This is almost better than the additive fog on transparent=20 >textures in previous releases, but it should be fixed with an=20 >additional pass. > >3). The lighting state is never taken into consideration, so stale=20 >states from the last solid objects are used - null shaders can come out=20 >lit and vice-versa (this is an old bug). > >4). Facet normals don't appear to be handled properly (i.e. "none"=20 >interpolation style) Can you log three bugs for these three issues, with appropriate sample models to reproduce them? =46og and lighting will probably be wrong ta the moment (since we're letting GL handle that for us, we will need to record the state that was active when a transparent triangle was seen and save it away: or do our own lighting). Either way will be quite expensive though. >5). Sorting is less than spectacular - it can't handle a rotating cube=20 >properly. If you have a particularly poor sorting case, please log a bug and attach a model. However bear in mind that some models just can't be sorted correctly: e.g., interpenetrating geometry can't be sorted without splitting it up and introducing new polygons. One solution to this might be to allow applications to provide a sorting callback: the technique we currently use is "good enough" for most cases, but if you have a particular problem case (and a solution) then a callback would let you sort whatever way was appropriate. >Points 2, 3, & 4 above all point to a similar problem; the state simply=20 >isn't managed well for transparent triangles. Yes, strictly speaking we need to capture every bit of state that will affect the final rasterisation when a transparent triangle is submitted. That obviously makes transparent triangles quite expensive, as you have to a)record a lot more state and b)switch state more often when processing them (since they a sort-by-depth ordering probably won't correspond to a sort-by-state ordering) >The only thing I'm concerned about is how and when the light state is >updated - looking through the code it appears to happen once per >frame, but in practice it updates for every mesh - so I'm missing >something here... Where do you see it being updated on each mesh? The lights should be converted once per frame, by IRRenderer_Lights_StartPass. -dair ___________________________________________________ mailto:dair+refnum.com http://www.refnum.com/ |
|
From: Dair G. <da...@re...> - 2004-06-05 19:28:23
|
James W. Walker wrote: >* Has the To Do page been updated lately? Nope - some of these were added to the old Bugzilla, but I don't think they all were. >* It would be good to get rid of the old bug list, after checking that=20 >each item is either fixed or in the SourceForge bug list. I believe none of the things on this page were entered into the old Bugzilla: although some of them may have been fixed since then (that page predates the old Bugzilla, so the ID numbers don't map to anything other than that page). The list of "missing functions" should be logged as bugs if we don't have them, and the documentation stuff should just probably go to an errata section within the Quesa book? >* The Building Quesa page needs an update, for instance it does not=20 >mention XCode. Yep. For these things, and in fact the "Most Wanted" list, they should all get logged in the bug tracker. I.e., if they're not logged, they don't exist (as far as knowing what problems are goes). -dair ___________________________________________________ mailto:dair+refnum.com http://www.refnum.com/ |
1 message has been excluded from this view by a project administrator.