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-23 21:12:48
|
Bugs item #902977, was opened at 2004-02-23 21:02 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=902977&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 text 3DMF writing Initial Comment: It would be good to support the text form of 3DMF writing. Currently, if you say Q3File_OpenWrite( theFile, kQ3FileModeText ), the file is actually written in binary form. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=902977&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-02-23 21:12:12
|
Bugs item #902976, was opened at 2004-02-23 21:02 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=902976&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dair Grant (grantd) Assigned to: Nobody/Anonymous (nobody) Summary: Custom elements not read from 3DMF files Initial Comment: Custom elements (such as names assigned with CENameElement_SetData) are not read from 3DMF files. ------- Additional Comments From James W. Walker 2002-05 -17 13:32 ------- Custom elemenst on display groups, trimeshes, and ellipsoids are now read. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=902976&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-02-23 21:11:32
|
Bugs item #902975, was opened at 2004-02-23 21: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=902975&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dair Grant (grantd) Assigned to: Nobody/Anonymous (nobody) Summary: Use shared texture namespace Initial Comment: The OpenGL renderer should create contexts with a shared texture namspace, to allow them to share texture objects. May need a bit of thought to make sure the are updated correctly when the texture objects are updated, but it might be a useful optimisation memory- wise. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=902975&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-02-23 20:39:53
|
Bugs item #902965, was opened at 2004-02-23 20:29 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=902965&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 Projects area to the web site Initial Comment: Add a Projects area to the web site, indicating what people are using Quesa in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=902965&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-02-23 20:39:09
|
Bugs item #902964, was opened at 2004-02-23 20:29 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=902964&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dair Grant (grantd) Assigned to: Nobody/Anonymous (nobody) Summary: Polyline should cache transparent state Initial Comment: The polyline geometry should cache if it contains transparent attributes or not, and invalidate its cache when its edit index changes. Would save interactive renderer from calculating this state each time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=902964&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-02-23 20:20:42
|
Bugs item #902950, was opened at 2004-02-23 20:10 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=902950&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dair Grant (grantd) Assigned to: Nobody/Anonymous (nobody) Summary: Improve view state stack performance Initial Comment: A performance bottleneck at present is that pushing/popping the view state stack is quite expensive. This could be improved by doing some kind of lazy-updating of the stack, where values would only be pushed if they were changed since the view state was 'pushed'. ------- Additional Comments From Dair Grant 2002-04-17 09:58 ------- Additional comments from Erik Olson: > Profiling under Quesa did reveal that about one third of cpu > time was spent copying and destructing attribute sets on > stack pops. An optimization would be to have lazy > construction of the stack frame's attribute set. > > I rely on the stack to unwind hierarchical matrix transforms > and infrequent color highlights, so most of the time the > attribute set is constant. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=902950&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-02-23 20:19:52
|
Bugs item #902948, was opened at 2004-02-23 20:09 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=902948&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dair Grant (grantd) Assigned to: Nobody/Anonymous (nobody) Summary: Implement kQ3XMethodTypeDrawContextGetDimensions Initial Comment: The Be, X11, and Win32 DD draw contexts do not implement the kQ3XMethodTypeDrawContextGetDimensions method. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=902948&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-02-23 20:18:55
|
Bugs item #902946, was opened at 2004-02-23 20: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=902946&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dair Grant (grantd) Assigned to: Nobody/Anonymous (nobody) Summary: Make more use of the Error Manager Initial Comment: We should review all of the errors/warnings/notices in QuesaErrors.h, and make sure they are all posted at least once (and ideally as often as possible). Presumably QD3D will post each constant in at least one situation, so we should try and identify when these errors could be generated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=902946&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-02-23 20:18:18
|
Bugs item #902944, was opened at 2004-02-23 20: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=902944&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 OBJ and 3DS importers Initial Comment: The OBJ and 3DS importers need to be finished off. The projects don't have Carbon targets, and they need more documentation on how to install them. Perhaps think about bundling them into Quesa itself, depending on how large they are? (above may be out of date, imported from Bugzilla) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=902944&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-02-23 19:57:01
|
Bugs item #902932, was opened at 2004-02-23 19: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=902932&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 global-preferences API Initial Comment: Add a global API for getting/setting "preferences" (for want of a better word), like aglSetInteger/aglGetInteger. Could be used to control FSAA, TruForm, etc, that are more "whole API"-level rather than renderer- specific. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=902932&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-02-23 19:56:10
|
Bugs item #902931, was opened at 2004-02-23 19: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=902931&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dair Grant (grantd) Assigned to: Nobody/Anonymous (nobody) Summary: Implement level-of-detail groups Initial Comment: I believe this was an Apple demo at one point, but it would be useful to have support for level-of-detail groups built in. These would contain a list of sub-groups, where submitting the parent group would submit one of the sub-groups based on the range to the camera. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=902931&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-02-23 19:55:15
|
Bugs item #902930, was opened at 2004-02-23 19: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=902930&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 simple one-shot file APIs Initial Comment: Would be useful to have Q3File_Submit (to read a file and submit it to a view), or Q3File_ReadAsGroup (to read a file and return it as a group). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=902930&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-02-23 19:54:34
|
Bugs item #902928, was opened at 2004-02-23 19: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=902928&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dair Grant (grantd) Assigned to: Nobody/Anonymous (nobody) Summary: API to support file metadata Initial Comment: Add API to return HFS file types/extensions/MIME-type for importer/exporters. Was discussed on the mailing list, and a proposal was: -------------------------------- Lets suppose we have a dozen readers and writers some of them are built in to Quesa (although I'd prefer make all of them plugins, but this is another question) and others are user plugged now I want to display a "get file" dialog that shows me the files that I understand, both filtered by type, extension or magic numbers, and do this in every of our supported platforms. on the other hand I want to display a "put file" dialog that shows me every avalaible format to choose from (let alone plug-ins, we have lots of possible 3DMF formats - binary,text, normal,Stream, database and combinations of them) so Quesa has to be able to ask the renderers for info about which formats they can handle and build a dialog accordingly (or let qut to do it) what info will be the most suitable and cross platform. mime types?, extensions, filetypes, all, others? what do you think? -------------------------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=902928&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-02-23 19:53:27
|
Bugs item #902926, was opened at 2004-02-23 19:43 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=902926&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 simple default error/warning/notice handlers Initial Comment: Would be useful to have default error/warning/notice handlers that would convert the error to a string (using the _ToString calls) and then print it to stderr or DebugStr. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=902926&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-02-23 19:52:17
|
Bugs item #902924, was opened at 2004-02-23 19:42 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=902924&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dair Grant (grantd) Assigned to: Nobody/Anonymous (nobody) Summary: Q3Object_Duplicate doesn't handle storage objects Initial Comment: See comments in E3Main.c - other object types can be duplicated correctly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=902924&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-02-23 19:51:36
|
Bugs item #902923, was opened at 2004-02-23 19: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=902923&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dair Grant (grantd) Assigned to: Nobody/Anonymous (nobody) Summary: Generic renderer should clear draw contexts Initial Comment: QD3D's generic renderer clears the draw context to the background colour, even though it's not really meant to be a drawing renderer. We don't currently do this, but perhaps we should. Could easily be implemented by the API in bug 902922. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=902923&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-02-23 19:50:54
|
Bugs item #902921, was opened at 2004-02-23 19:39 Message generated for change (Comment added) made by grantd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=902921&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dair Grant (grantd) Assigned to: Nobody/Anonymous (nobody) >Summary: Set kQ3AttributeTypeSurfaceTangent attribute Initial Comment: These geometries currently skip the kQ3AttributeTypeSurfaceTangent attribute, since it's never used by our wireframe or interactive renderers. They should pass this value on into the underlying TriMesh anyway, since custom renderers may want to use this value. ---------------------------------------------------------------------- >Comment By: Dair Grant (grantd) Date: 2004-02-23 19:40 Message: Logged In: YES user_id=439944 Renamed to shorten title, affected geometries are the TriMesh and Polyhedron. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=902921&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-02-23 19:49:47
|
Bugs item #902922, was opened at 2004-02-23 19: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=902922&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 draw-context independent drawing API Initial Comment: It would be useful to have a draw-context independent API for drawing, to act as a portable way to get/set pixels that would work with any kind of draw context object. Draw contexts could implement required get/set pixel methods, and optionally get/set scanline or drawrect methods (the root draw context object would provide default implementations of these methods, which would just work by calling the single-pixel method repeatedly). This would let applications draw directly to draw contexts, and would make it possible to write plug-in renderers (e.g., a RayTracer) without requiring that they hard-code support for each available draw context type in them (at present, every renderer must know how to draw to every type of draw context). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=902922&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-02-23 19:49:07
|
Bugs item #902921, was opened at 2004-02-23 19: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=902921&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dair Grant (grantd) Assigned to: Nobody/Anonymous (nobody) Summary: TriMesh/Polyhedron should use kQ3AttributeTypeSurfaceTangent Initial Comment: These geometries currently skip the kQ3AttributeTypeSurfaceTangent attribute, since it's never used by our wireframe or interactive renderers. They should pass this value on into the underlying TriMesh anyway, since custom renderers may want to use this value. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=902921&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-02-23 19:48:10
|
Bugs item #902920, was opened at 2004-02-23 19:38 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=902920&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dair Grant (grantd) Assigned to: Nobody/Anonymous (nobody) Summary: Set usage array for built-in attributes Initial Comment: The interactive renderer will honour the TriMesh use array for any attribute type, so the geometries which can generate partially- present attributes (e.g., TriMesh, Polyhderon, or the Tessellator) should also generate a usage array. At present they put some dummy values into the attribute value array, but this means that attributes won't be inherited correctly during rendering - the usage array would let the real values to be picked up from the enclosing group. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=902920&group_id=45158 |
|
From: Tom S. <to...@as...> - 2004-02-23 11:19:03
|
>Yes please, if you could log it at: > > <https://sourceforge.net/tracker/?group_id=45158&atid=442052> > >If you have a model file or screenshots that demonstrate the problem, >please attach them to the bug as well. Done. The submitted report describes slightly different symptoms to the description I gave in this thread, but is simpler and I beleive it's essentially the same bug. Tom |
|
From: SourceForge.net <no...@so...> - 2004-02-23 11:10:32
|
Bugs item #902592, was opened at 2004-02-23 11: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=902592&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tom Sanham (tomsanham) Assigned to: Nobody/Anonymous (nobody) Summary: TriMesh Colours go to the wrong faces Initial Comment: Quesa 1.6d18 OS used: Windows XP (not tested on Mac) This bug affects cube shaped TriMeshes with 8 vertices which specify a colour attribute per face. I believe that the described behaviour occurs because the model has >1 faces referencing the same vertex. Behaviour: The following strange behaviour was observed: Setting Attribute 0 controls faces 0,4,5 Setting Attribute 1 controls face 1 Setting Attribute 2 controls faces 2,6,7,8,9,10 Setting Attribute 3 controls faces 3,11 Setting Attributes 4..11 has no visual effect The same model renders correctly under QD3D - attribute n controls face n for 0<=n<12. Workaround: An effective workaround is to build the cube with duplicate vertices such that no vertex is shared by two faces. Example trimesh included as a 3DMF. Best viewed with kQ3InterpolationStyleNone .triMeshAttributeSet = 0 .numTriangles = 12 .*triangles = (4,6,2) , (4,2,0) , (1,3,7) , (1,7,5) , (5,7,6) , (5,6,4) , (0,2,3) , (0,3,1) , (2,6,3) , (3,6,7) , (4,0,1) , (4,1,5) .numTriangleAttributeTypes = 1 .triangleAttributeTypes = .attributeType = kQ3AttributeTypeDiffuseColor .data = (1,0,0), (1,1,1), (1,1,1), remaining 9 faces (1,1,1) .numEdges = 0 .edges = 0 .numEdgeAttributeTypes = 0 .*edgeAttributeTypes = 0 .numPoints = 8 .*points = (0,0,0), (1,0,0), (0,1,0), (1,1,0), (0,0,1), (1,0,1), (0,1,1), (1,1,1) .numVertexAttributeTypes = 0 .*vertexAttributeTypes = 0 .bBox = (0,0,0) , (10,10,10) , kQ3False ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=902592&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-02-21 07:57:07
|
Bugs item #895106, was opened at 2004-02-11 15:03 Message generated for change (Comment added) made by pox You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=895106&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Frank Condello (pox) Assigned to: Nobody/Anonymous (nobody) Summary: Colours have no effect on textured geometry Initial Comment: Diffuse/Transparency colours have no effect on textured geometry. The QuickDraw3D behaviour is to modulate colors on geometry using a null shader, otherwise it is ignored. Quesa should probably support this behaviour as the default, but allow Phong/Lambert lit geometry to modulate colours via an extended API. ---------------------------------------------------------------------- >Comment By: Frank Condello (pox) Date: 2004-02-21 02:49 Message: Logged In: YES user_id=171509 Some testing with the GeomTest app shows that TriGrid and Triangle geometries actually do respect vertex colours when textured. Although blending works on those geometries, the behaviour is backwards to that of QD3D (geometry lit Phong/Lambert blend colours, null shader does not). This seems to be intended looking at the ir_texture_set_state function however. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=895106&group_id=45158 |
|
From: Dair G. <da...@re...> - 2004-02-20 22:55:28
|
Edward K. Chew wrote: >Take a close look at the debug code in each of the Q3Triangle=20 >vertex-related accessor functions. I think "if(index >=3D 3)" might work= =20 >out a tad better. :-) Well spotted! I've checked in a fix. >(By the way, is there a proper place to submit bug reports or should I >keep posting them here?) The bug tracker is at: <https://sourceforge.net/tracker/?group_id=3D45158&atid=3D442052> It's probably best for us to get in the habit of submitting anything that needs a cvs change (or just a feature request, whatever) to the tracker, as that way we can make sure we have an ID to reference if it turns out not to be trivial. -dair ___________________________________________________ mailto:dair+refnum.com http://www.refnum.com/ |
|
From: Dair G. <da...@re...> - 2004-02-20 22:55:23
|
Tom Sanham wrote: >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.=20 In theory it should be fine, in practice I'm not sure if we will currently handle this correctly. This is another argument for splitting the TriMesh code into "pass data directly to GL" vs "break down into individual triangles". A texture on each triangle is never going to be fast, but if we pushed it down the second path it would at least render correctly. -dair ___________________________________________________ mailto:dair+refnum.com http://www.refnum.com/ |
1 message has been excluded from this view by a project administrator.