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-02-20 22:55:09
|
Bugs item #901442, was opened at 2004-02-20 22: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=901442&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dair Grant (grantd) Assigned to: Nobody/Anonymous (nobody) Summary: Finish mesh geometry Initial Comment: A first-pass on the mesh geometry has been checked in, however it is not yet complete. This implementation was written before the tessellator API was added, so it may be possible to simplify the current code now that the tessellator is available (e.g., a Mesh could be represented as a group of general polygons, where each polygon contained each face and its associated contours). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=901442&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-02-20 22:54:20
|
Bugs item #901440, was opened at 2004-02-20 22: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=901440&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dair Grant (grantd) Assigned to: Nobody/Anonymous (nobody) Summary: Wireframe renderer does not support hilighting Initial Comment: The Wireframe OpenGL renderer does not currently support the hilight style. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=901440&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-02-20 22:53:37
|
Bugs item #901439, was opened at 2004-02-20 22: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=901439&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dair Grant (grantd) Assigned to: Nobody/Anonymous (nobody) Summary: Hilight state does not match QD3D results Initial Comment: Fred Mandrea has an example demonstrating the way in which Quesa renders an object with a hilight style different to Quesa. Note that this happens with either the QD3D or the Quesa renderer, so the bug must be in the Quesa library rather than in the OpenGL code. Fred's example was at http://homepage.mac.com/genfred/ quesa3.html (no longer online). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=901439&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-02-20 22:52:30
|
Bugs item #901437, was opened at 2004-02-20 22:44 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=901437&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dair Grant (grantd) Assigned to: Nobody/Anonymous (nobody) Summary: Support alternative texture formats Initial Comment: Add support for 4444 and 8-bit grayscale texture map formats. Would need some new constants and support in Quesa, and support in the Interactive renderer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=901437&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-02-20 22:49:34
|
Bugs item #901432, was opened at 2004-02-20 22:41 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=901432&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dair Grant (grantd) Assigned to: Nobody/Anonymous (nobody) Summary: Textures should use client storage extension Initial Comment: Textures should use the client-storage extension on Mac OS X - would allow us to use the QD3D texture data directly rather than having to have OpenGL make a second copy. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=901432&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-02-20 22:48:46
|
Bugs item #901431, was opened at 2004-02-20 22:40 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=901431&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dair Grant (grantd) Assigned to: Nobody/Anonymous (nobody) Summary: Textures should use packed pixel extension Initial Comment: We currently convert all incoming textures to 32bpp RGBA for passing to OpenGL - most OpenGL implementations will now support the packed pixel extension, so we should be able to pass on 16 or 24 bit pixel data directly rather than copying it. This could also simplify the texture swapping code in IRUpdate.c, which is quite complex and a bit misleading (e.g., 16bpp texture data is not really swapped, it's permuted, and yet the variable is called 'swap'). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=901431&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-02-20 22:47:01
|
Bugs item #901427, was opened at 2004-02-20 22:39 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=901427&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dair Grant (grantd) Assigned to: Dair Grant (grantd) Summary: Implement visibility culling Initial Comment: Implement the kQ3XMethodTypeRendererIsBoundingBoxVisible method for OpenGL renderers, and make use of this when submitting groups with bounding boxes. Was discussed on the mailing list, and a proposal was: -------------------------------- > Do you see this general-purpose test in QuesaMath.h as something > we would expose to users, or something only for internal use? I think it's similar to the Q3Ray3D_IntersectXXX routines: these were written internally for the picking code (E3Utils.c is a good place for these to live temporarily until you firm up the interface), but they're really general purpose 3D utilities. A general visibility test routine would be useful in other circumstances (perhaps you have your own data structure for organising the world: if you can derive a bounding box from it, you could use this routine to do your own culling), and it would also be useful to have a bounding-sphere version as well. These are quicker, if less accurate, so perhaps what we need is: typedef enum TQ3Visibility { kQ3VisibleIsNot = 0, // kQ3False kQ3VisibleCompletely = 1, // kQ3True kQ3VisiblePartially = 2, } TQ3Visibility; TQ3Visibility Q3BoundingBox_IsVisible(box, TQ3View-or-camera- spec) TQ3Visibility Q3BoundingSphere_IsVisible(sphere, TQ3View-or- camera-spec) Currently the IsBoundingBox renderer method returns a TQ3Boolean. It would be useful to change this to return one of these visibility enums, so we could do this in a binary compatible manner by having the first two enum values correspond to the values for kQ3False/kQ3True. It wouldn't be source compatible, but a)it's a simple cast to fix and b)the only code I know of that uses this method is the code in QD3D that queries the QD3D IR. The reason for changing the return type is it'd be useful to add an IsBoundingSphere method to renderers as well. Both box and sphere methods would be implemented just by calling on to the Q3BoundingXXX_IsVisible methods for our IR, but this would mean Quesa could be a bit smarter. >> 2. When submitting a display group with a bounding box, call the >> method to decide if the group really needs to be submitted. I.e., this test (or any bounding box test) could now be: - Call the IsBoundingSphere method. This gives you a fast test, and if it returns kQ3VisibleIsNot or kQ3VisibleCompletely then you're done. - If it returns kQ3VisiblePartially, call the IsBoundingBox method. This takes longer, but gives you a better decision for some edge cases. I suppose you could implement the above simply by sticking to bools and having the Q3BoundingBox_IsVisible do an internal test on a bounding sphere first and then on the box, but having both methods available would be more flexible. Flexible in that there's an OpenGL extension where you can hint that the geometry is entirely visible on the screen (rather than partially clipped) for a slight performance boost. If we were able to pass back an enum rather than a bool then we'd be able to identify this case in the future and use the extension if it's present. -------------------------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=901427&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-02-20 22:44:49
|
Bugs item #901424, was opened at 2004-02-20 22:36 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=901424&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dair Grant (grantd) Assigned to: Nobody/Anonymous (nobody) Summary: Add error testing to OpenGL renderers Initial Comment: It would be useful to have some glError calls in debug builds of the OpenGL renderers, to catch any failures during rendering. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=901424&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-02-20 22:43:53
|
Bugs item #901422, was opened at 2004-02-20 22: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=901422&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dair Grant (grantd) Assigned to: Nobody/Anonymous (nobody) Summary: ImprokQ3ShaderUVBoundaryClamp handling Initial Comment: If GL_CLAMP_TO_EDGE is available, the Interactive Renderer should implement kQ3ShaderUVBoundaryClamp with this extension in preference to GL_EDGE. This helps avoid seams between otherwise adjacent textures. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=901422&group_id=45158 |
|
From: Dair G. <da...@re...> - 2004-02-20 22:33:25
|
Tom Sanham wrote: >Yes. The problem always occured (colours swapping back and forth >between the faces) at angles where a face was in a plane perpendicular >to the screen. Other angles (eg. an 'isometric view') were much more >stable. Hmm, that is curious. I can't think of an obvious explanation unfortunately... :-) >Ok, would you still like the bug to be logged in light of the >two work-arounds suggested above? Yes please, if you could log it at: <https://sourceforge.net/tracker/?group_id=3D45158&atid=3D442052> If you have a model file or screenshots that demonstrate the problem, please attach them to the bug as well. -dair ___________________________________________________ mailto:dair+refnum.com http://www.refnum.com/ |
|
From: SourceForge.net <no...@so...> - 2004-02-20 22:31:51
|
Bugs item #901410, was opened at 2004-02-20 22:22 Message generated for change (Settings changed) made by grantd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=901410&group_id=45158 Category: None Group: None >Status: Deleted Resolution: None Priority: 5 Submitted By: Dair Grant (grantd) Assigned to: Nobody/Anonymous (nobody) Summary: Add kQ3ViewerStateCanPaste state Initial Comment: There's currently a kQ3ViewerStateHasModel bit which indicates if the viewer contains a model which can be copied. A useful feature would be to add a kQ3ViewerStateCanPaste bit to indicate if the current clipboard contents could be pasted into the viewer. The clipboard would be tested by Q3Viewer_GetState, so that apps could use the presence of the bit to decide how to enable their Edit menu. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=901410&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-02-20 22:30:46
|
Bugs item #901410, was opened at 2004-02-20 22:22 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=901410&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dair Grant (grantd) Assigned to: Nobody/Anonymous (nobody) Summary: Add kQ3ViewerStateCanPaste state Initial Comment: There's currently a kQ3ViewerStateHasModel bit which indicates if the viewer contains a model which can be copied. A useful feature would be to add a kQ3ViewerStateCanPaste bit to indicate if the current clipboard contents could be pasted into the viewer. The clipboard would be tested by Q3Viewer_GetState, so that apps could use the presence of the bit to decide how to enable their Edit menu. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=901410&group_id=45158 |
|
From: Edward K. C. <ek...@lg...> - 2004-02-20 19:58:39
|
Take a close look at the debug code in each of the Q3Triangle
vertex-related accessor functions. I think "if(index >= 3)" might work
out a tad better. :-)
(By the way, is there a proper place to submit bug reports or should I
keep posting them here?)
-Ted
__________________________________________________
// Debug build checks
#if Q3_DEBUG
if (0) // Further checks on triangle
return(kQ3Failure);
// Further checks on index
if (index >= 2)
{
E3ErrorManager_PostError(kQ3ErrorParameterOutOfRange, kQ3False);
return(kQ3Failure);
}
if (0) // Further checks on point
return(kQ3Failure);
#endif
|
|
From: Tom S. <to...@as...> - 2004-02-20 12:58:04
|
Quick question: In Quesa, can a TriMesh have a different texture applied to each face of the shape? (QD3D seems to have no problem with this) In Quesa (WinXP) I have so far succeeded in doing this with colours fine, but textures applied as triangle attributes just appear pure white for me. Tom ps. thanks for the invaluable help I have found on this list so far. |
|
From: Tom S. <to...@as...> - 2004-02-20 12:48:58
|
>When the view orientation is such that some faces of a cube lie in a >plane exactly perpendicular to the window plane, Quesa seems to have >trouble matching the correct colour specified to the face. >Hmm, does the problem vary depending on the viewing angle? I.e., if you >rotate the cube it appears to work at some angles but not others? Yes. The problem always occured (colours swapping back and forth between the faces) at angles where a face was in a plane perpendicular to the screen. Other angles (eg. an 'isometric view') were much more stable. I have done more experimenting and have found 2 workarounds: 1) Turning Backface Culling off 2) Use a triMesh cube with 24 vertices, four per face I had been using 8 vertices for (I had assumed) max. efficiency. In testing I found that using the 24-vertex trimeshes made no difference whatsoever to the frame rate over using 8-vertex trimeshes, so for my purposes, this workaround is perfect. >Could you extract the cube into a 3DMF model that can be loaded up into >Geom Test? That would be of great help in debugging it, as we can then >look at just the geometry independently of anything else that's been >submitted. >If you could log a bug with these details, it can go on the todo list to >look at. Ok, would you still like the bug to be logged in light of the two work-arounds suggested above? Tom |
|
From: SourceForge.net <no...@so...> - 2004-02-20 12:15:38
|
Bugs item #901065, was opened at 2004-02-20 12:08 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=901065&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dair Grant (grantd) Assigned to: Nobody/Anonymous (nobody) Summary: Add kQ3ViewerStateCanPaste state Initial Comment: There's currently a kQ3ViewerStateHasModel bit which indicates if the viewer contains a model which can be copied. A useful feature would be to add a kQ3ViewerStateCanPaste bit to indicate if the current clipboard contents could be pasted into the viewer. The clipboard would be tested by Q3Viewer_GetState, so that apps could use the presence of the bit to decide how to enable their Edit menu. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=901065&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-02-20 12:10:51
|
Bugs item #901059, was opened at 2004-02-20 12:03 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=901059&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dair Grant (grantd) Assigned to: Nobody/Anonymous (nobody) Summary: Finish unified viewer Initial Comment: The viewer was once a distinct library, and available with two APIs for Mac Windows. For Quesa we have a single unified viewer API, which is exported by the main Quesa library. This process needs to be completed, so that the unified viewer is finished off and all of the previous Mac/Win APIs forward on to the unified viewer APIs. In adittion, the older viewer _GetVersion calls should be redirected to call Q3GetVersion/Q3GetReleaseVersion so that we lock the viewer version number to the main library. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=901059&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-02-20 12:01:44
|
Bugs item #901053, was opened at 2004-02-20 11: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=901053&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dair Grant (grantd) Assigned to: Nobody/Anonymous (nobody) Summary: Support viewer within static builds Initial Comment: For static builds, the viewer still needs to access its resources. These will need to be included in the app resource fork, or obtained some other way. Logging this just so we know the current approach doesn't work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=901053&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-02-19 22:10:50
|
Bugs item #900694, was opened at 2004-02-19 22:03 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=900694&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dair Grant (grantd) Assigned to: Nobody/Anonymous (nobody) Summary: Add image import support to Unix/Windows Qut Initial Comment: Add support for image import to Qut will let us test textures on these platforms more easily. Need to fill in Qut_SelectPictureFile, and rework QutText.c so that it doesn't assume QuickTime. In the short term, possibly just hard-code a fixed texture into the source for GeomTest so that textures can be tested more easily. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=900694&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-02-19 22:09:02
|
Bugs item #900692, was opened at 2004-02-19 22:01 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=900692&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 4 Submitted By: Dair Grant (grantd) Assigned to: Nobody/Anonymous (nobody) Summary: Glue .lib file would be useful on Windows Initial Comment: When running on Windows, it would be useful to have a QuickTime- style .lib file that could produce the effect you can get on the Mac with weak-linking (i.e., be able to run even if the DLL is missing). This would be a static library that loaded each symbol from the DLL manually (rather than using linker-generated references), which could then return an error at runtime if the Quesa DLL could not be found. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=900692&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-02-19 21:55:43
|
Bugs item #900675, was opened at 2004-02-19 21: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=900675&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dair Grant (grantd) Assigned to: Nobody/Anonymous (nobody) Summary: Add FSRef based storage object Initial Comment: We should add Mac OS TQ3StorageObjects based on FSRefs rather than FSSpecs, to support both types of file specifiers. The API should mirror the Q3FSSpecStorage_xxx calls, and Q3MacintoshStorage_GetType should be extended to return a kQ3MacintoshStorageTypeFSRef constant. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=900675&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-02-19 21:53:19
|
Bugs item #900672, was opened at 2004-02-19 21: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=900672&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dair Grant (grantd) Assigned to: Nobody/Anonymous (nobody) Summary: Scan CFMSupport for plug-ins Initial Comment: E3MacSystem_LoadPlugins should scan these two folders for CFM plug-ins when running on Mac OS X: /Library/CFMSupport ~Library/CFMSupport ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=900672&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-02-19 20:52:08
|
Bugs item #895117, was opened at 2004-02-11 20:13 Message generated for change (Comment added) made by grantd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=895117&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Frank Condello (pox) >Assigned to: Dair Grant (grantd) >Summary: Transparent surfaces not sorted well Initial Comment: The transparent surface renderer broke when the new view transform API was added. Vertices outside the frustum can become undefined, leading to infinite point errors and jumbled geometry. This may also adversely affect the sorting algorithm. Some other issues that may or may not be related involve an errant lighting state. Transparent objects may inherit the illumination style of other objects in the scene rather than use their own, and faceted geometry (interpolation style none) always appears with null shading. ---------------------------------------------------------------------- >Comment By: Dair Grant (grantd) Date: 2004-02-19 20:45 Message: Logged In: YES user_id=439944 It looks like this isn't related to the transform changes: as far as I can see, things are sorted as well in frustum space as they were in world coordinates (i.e., attached model also renders with flicker under 1.6d18). It looks like the problem is in the sorting choices made when triangles overlap in z: that overlap can be in world coordinates or frustum coordinates, but removing the current selection choice gives us a much more stable selection (for this case, but that won't be a fix). I can't see any problems with sorting in frustum coordinates when the vertices are outside the frustum - those vertices will be clipped later on, but being outside the frustum won't affect the sort. The lighting flicker appears to be due to the triangle order jumping around from frame to frame - if you still see any illumination problems when this bug is closed, can you log them as separate bugs? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=895117&group_id=45158 |
|
From: Dair G. <da...@re...> - 2004-02-17 22:49:45
|
Tom Sanham wrote: >When the view orientation is such that some faces of a cube lie in a >plane exactly perpendicular to the window plane, Quesa seems to have >trouble matching the correct colour specified to the face. Hmm, does the problem vary depending on the viewing angle? I.e., if you rotate the cube it appears to work at some angles but not others? That does seem odd, as any bug like that should just be either always-working or always-broken. Could you extract the cube into a 3DMF model that can be loaded up into Geom Test? That would be of great help in debugging it, as we can then look at just the geometry independently of anything else that's been submitted. If you could log a bug with these details, it can go on the todo list to look at. The bug database is now at: <http://sourceforge.net/tracker/?group_id=3D45158&atid=3D442052> =20 -dair ___________________________________________________ mailto:dair+refnum.com http://www.refnum.com/ |
|
From: Dair G. <da...@re...> - 2004-02-17 22:49:42
|
Dair Grant wrote: > 1. Reply-to-send, so when you hit reply to a list message the reply > will go to the list by default rather than to the individual. =2E.. > 2. Lose the "[Quesa-develop]" and "[Quesa-cvs]" prefix from the > subject lines OK, these are both in place: if it works, this message shouldn't have the prefix (and hitting reply should go back to the list). -dair ___________________________________________________ mailto:dair+refnum.com http://www.refnum.com/ |
1 message has been excluded from this view by a project administrator.