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-03-24 13:02:24
|
Bugs item #922421, was opened at 2004-03-24 13: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=922421&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tom Sanham (tomsanham) Assigned to: Nobody/Anonymous (nobody) Summary: Severe Memory Leak caused by Resizing View (x86 only) Initial Comment: Platform: Windows XP Quesa 1.6d18 To reproduce: - Load GeomTest.exe - Open 'Windows Task Manager' - Resize the GeomTest window repeatedly - 'Commit Charge' value in the Windows Task Manager window increases by a few MB with each resize. This lost memory is only reclaimed on quitting GeomTest ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=922421&group_id=45158 |
|
From: Dair G. <da...@re...> - 2004-03-20 18:27:26
|
Joseph J. Strout wrote: >I never saw an answer to this, and I'm curious about it. Anyone? It looks like your subscription wasn't in place when the discussion took place: I think there are archives for the list (not sure how frequently they're generated) on SF though which should have it. -dair ___________________________________________________ mailto:dair+refnum.com http://www.refnum.com/ |
|
From: Joseph J. S. <jo...@st...> - 2004-03-19 03:27:52
|
At 1:11 PM -0600 2/10/04, Chris Dillman did some profiling and wrote thusly: >1. Eliminate any calls to glFinish(); >Apple advise againts using this at all for any high speed GL application. >So is there a reason it is in Quesa? I never saw an answer to this, and I'm curious about it. Anyone? >2. Move to vertex array range in "shared" state if possible. >WC3 uses this to very good effect. > >3. How about a state flag of some sort so that Quesa knows which >objects have basically become static and have not changed from frame >to frame so that it does not need to keep building them as GL calls >everyframe? I'm curious about these too. My users are bugging me about alleged poor performance on Quesa, but I haven't yet found the time to do any profiling, so I'm riding on Chris's coat-tails. Thanks, - Joe -- ,------------------------------------------------------------------. | Joseph J. Strout Check out the Mac Web Directory: | | jo...@st... http://www.macwebdir.com/ | `------------------------------------------------------------------' |
|
From: SourceForge.net <no...@so...> - 2004-03-04 22:54:54
|
Bugs item #909213, was opened at 2004-03-03 17:56 Message generated for change (Comment added) made by grantd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=909213&group_id=45158 Category: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Tom Sanham (tomsanham) Assigned to: Nobody/Anonymous (nobody) Summary: SetRotateVectorToVector problem Initial Comment: Some input values for Q3Quaternion_SetRotateVectorToVector produce duff quaternions. Example: start vector: -0.2252647,-0.8941119,-182972.5 put through Q3Vector3D_Normalize gives -1.231140e-6,-4.886592e-6,-1 Now do Q3Quaternion_SetRotateVectorToVector with the following parameters: v1=-1.231140e-6,-4.886592e-6,-1 v2=0,0,1 the resulting quaternion is (0,-INF,INF,NAN) This problem occurs on Mac OS X Quesa, I am unable to reproduce it on Windows. To workaround this case, I just detect magnitudes <1e- 5 and set them to 0, and hence v1 becomes 0,0,-1, which then works correctly. ---------------------------------------------------------------------- >Comment By: Dair Grant (grantd) Date: 2004-03-04 22:40 Message: Logged In: YES user_id=439944 I've checked in a fix - the problem appears to be in the use of a macro which compares the vector length to a tolerance. When done as a macro, this routine operates entirely in registers (which are double-precision on PowerPC, although the inputs to this routine are floats). When implemented as a function, the inputs are passed through memory and truncated to single precision - which allows the existing tolerance test to pass. Strictly speaking the example inputs should be allowed to fail (since v1 is not normalised), and one way to address this would be to have Q3Vector3D_Normalise double-check its outputs. However this would make normalising a vector quite expensive (6 additional compares, 12 if it should also have a tolerance) and since we need to handle tolerance in RotateVToV anyway we might as well do it once. Would be interesting to know if the original code fails on x86 as well: I suspect it won't, even in macro form. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=909213&group_id=45158 |
|
From: Roger H. <rog...@mi...> - 2004-03-03 19:01:41
|
Maybe we should get Q3Vector3D_Normalize to check for 1 and -1 in its result, and if found, set the other components to zero. Roger. > Initial Comment: > Some input values for > Q3Quaternion_SetRotateVectorToVector produce duff > quaternions. > > Example: > > start vector: > -0.2252647,-0.8941119,-182972.5 > > put through Q3Vector3D_Normalize gives > -1.231140e-6,-4.886592e-6,-1 > > Now do Q3Quaternion_SetRotateVectorToVector with > the following parameters: > v1=-1.231140e-6,-4.886592e-6,-1 > v2=0,0,1 > > the resulting quaternion is (0,-INF,INF,NAN) > > This problem occurs on Mac OS X Quesa, I am unable to > reproduce it on Windows. > > To workaround this case, I just detect magnitudes <1e- > 5 and set them to 0, and hence v1 becomes 0,0,-1, > which then works correctly. > |
|
From: SourceForge.net <no...@so...> - 2004-03-03 18:09:33
|
Bugs item #909213, was opened at 2004-03-03 17:56 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=909213&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tom Sanham (tomsanham) Assigned to: Nobody/Anonymous (nobody) Summary: SetRotateVectorToVector problem Initial Comment: Some input values for Q3Quaternion_SetRotateVectorToVector produce duff quaternions. Example: start vector: -0.2252647,-0.8941119,-182972.5 put through Q3Vector3D_Normalize gives -1.231140e-6,-4.886592e-6,-1 Now do Q3Quaternion_SetRotateVectorToVector with the following parameters: v1=-1.231140e-6,-4.886592e-6,-1 v2=0,0,1 the resulting quaternion is (0,-INF,INF,NAN) This problem occurs on Mac OS X Quesa, I am unable to reproduce it on Windows. To workaround this case, I just detect magnitudes <1e- 5 and set them to 0, and hence v1 becomes 0,0,-1, which then works correctly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=909213&group_id=45158 |
|
From: Dair G. <da...@re...> - 2004-03-02 21:11:06
|
Tom Sanham wrote: >What are the obligations a distributor must fulfil to be allowed to >place the compiled release version macintosh Quesa library, or windows >Quesa.dll file on a CD alongside a commercial application which >requires Quesa as a shared library? Hi Tom, The only requirements are that if you have made any modifications to Quesa then the source for those modifications must be made available, and you should a copy of the LGPL (or a link to it) on the CD. Not related to this, but some news on the licence front is that we will shortly be switching to the BSD licence. This is less restrictive (for developers using Quesa), and will allow you to link statically as well as dynamically. -dair ___________________________________________________ mailto:dair+refnum.com http://www.refnum.com/ |
|
From: Tom S. <to...@as...> - 2004-03-02 14:41:15
|
Hi, What are the obligations a distributor must fulfil to be allowed to place the compiled release version macintosh Quesa library, or windows Quesa.dll file on a CD alongside a commercial application which requires Quesa as a shared library? I have checked the LPGL page on http://www.quesa.org/reference/lgpl.html but am still unsure of our exact obligation. I am checking with the list so as to be sure. Thanks, Tom |
|
From: SourceForge.net <no...@so...> - 2004-03-02 00:00:05
|
Bugs item #907863, was opened at 2004-03-01 15:27 Message generated for change (Comment added) made by raving You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=907863&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dair Grant (grantd) Assigned to: Nobody/Anonymous (nobody) Summary: Quesa Unix doesn't load plug-ins Initial Comment: Quesa Unix doesn't load plug-ins. Not sure if we can have a standard plug-in format for all Unix targets, but we can probably provide some shared library support for common platforms (Linux+*BSD say). ---------------------------------------------------------------------- Comment By: Lane Roathe (raving) Date: 2004-03-01 17:47 Message: Logged In: YES user_id=48487 You might look at the way OpenPlay handles this for it's modules (NetModules like TCPIP); the code is a bit messy because it has native MachO and *nix suppot in the same files (legacy issue where MachO is considered a *nix posix build). OpenPlay is on SF, www.sf.net/projects/openplay ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=907863&group_id=45158 |
|
From: Dair G. <da...@re...> - 2004-03-01 22:34:51
|
Hi, As you've seen, a bunch more bugs moved over to SF from Bugzilla tonight. There are about 20 left that I think may be fixed so I want to take another look at them before re-entering them, but everything else should be visible in the SF tracker now. -dair ___________________________________________________ mailto:dair+refnum.com http://www.refnum.com/ |
|
From: SourceForge.net <no...@so...> - 2004-03-01 21:54:23
|
Bugs item #907880, was opened at 2004-03-01 21: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=907880&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dair Grant (grantd) Assigned to: Nobody/Anonymous (nobody) Summary: Stale (cached?) data saved in 3DMF file Initial Comment: I have a TriGrid with a custom attribute attached to it. I draw it, that works fine. I change the value of the custom attribute and save the file. What gets saved is a TriMesh (fair enough) with the original version of the custom attribute rather than the new value. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=907880&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-03-01 21:53:38
|
Bugs item #907879, was opened at 2004-03-01 21: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=907879&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dair Grant (grantd) Assigned to: Nobody/Anonymous (nobody) Summary: Unable to load some text 3DMFs Initial Comment: Frank Cox wrote: Quesa is having problems loading 3DMFs with multiple trimeshes that use shader references. Here's a simplified example model: http://webhome.idirect.com/~frankco/ test_3dm.sit It's a simple cube, with each face saved as a separate trimesh, but all faces reference the first texture shader. QD3D handles these files just fine. A second issue that popped up with 1.6d18 involves specular highlighting. I'm getting specular highlights on trimeshes that shouldn't be receiving them (i.e. meshes using a null shader). This only happens when at least one object in the scene has specular highlighting enabled, which leads me to suspect that the GL state may be left dangling between vertex flushes. ----- James Walker wrote: The bug appears to be in reading text 3DMF files. After I converted the test file to binary form with Anatas, a Quesa app was able to read all 6 textured TriMeshes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=907879&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-03-01 21:51:56
|
Bugs item #907878, was opened at 2004-03-01 21: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=907878&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dair Grant (grantd) Assigned to: Nobody/Anonymous (nobody) Summary: View plane cameras not implemented Initial Comment: The view-plane camera type is not currently implemented in Quesa. To implement this we need to fill in the e3camera_viewplane_frustum_matrix method, found in E3Camera.c. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=907878&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-03-01 21:51:15
|
Bugs item #907877, was opened at 2004-03-01 21: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=907877&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 attributes sometimes inaccessible Initial Comment: When I read a QD3D file containing a custom attribute in a loose set in a group then it is put somewhere where I cannot access it either by using Q3Shape_GetSet, nor by iterating through the group. e3read_3dmf_merge_element_set puts a pointer to my set in the group's instanceData->set, but Q3Shape_GetSet expects an attribute set which has an element of type kQ3ElementTypeSet, but it does not have this, its got a set with my data in it instead, so it returns a failure. Thus : TQ3Status E3Shape_GetSet(TQ3ShapeObject theShape, TQ3SetObject *theSet) { *theSet = NULL; return E3Object_GetElement( theShape, kQ3ElementTypeSet, theSet ); } Does the fault lie in E3Shape_GetSet or in e3read_3dmf_merge_element_set ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=907877&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-03-01 21:50:01
|
Bugs item #907875, was opened at 2004-03-01 21:37 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=907875&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dair Grant (grantd) Assigned to: Nobody/Anonymous (nobody) Summary: Quesa Viewer project won't compile on Visual Studio.net Initial Comment: (not sure if viewer project should still be supported, it's part of the main project now) Quesa Viewer project won't compile on Visual Studio.net (but Quesa project compiles OK). Build output attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=907875&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-03-01 21:47:45
|
Bugs item #907874, was opened at 2004-03-01 21: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=907874&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dair Grant (grantd) Assigned to: Nobody/Anonymous (nobody) Summary: Picking on Windows does not match Mac Initial Comment: Joe Strout wrote: There's a bug with picking in Win32, where in order to get the correct result, you have to adjust the window coordinates passed in by a certain scale factor that varies from machine to machine. My guess is that this relates somehow to the resolution of the screen. Perhaps we're somewhere using pixels where we should be using points, or vice versa. We've found more information about the odd picking bug on Win32. In order to get the pick to work correctly, you have to apply a scaling factor that depends on both the screen size and the view size and position. In RB code, it looks like this: #If TargetWin32 x2 = x * Screen(0).width / Rb3DSpace1.width - Rb3DSpace1.left y2 = y * Screen(0).height / Rb3DSpace1.height - Rb3DSpace1.top #Else x2 = x // All works as expected on the Mac y2 = y #Endif // (and then pass x2, y2 to the picking function) So, for both X and Y, we have to multiply by the ratio of the screen size to view size, and then subtract off the top/left of the view (so that the coordinates are now relative to the view rather than the window). On the Mac none of that is necessary; we just pass in window coordinates and it works. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=907874&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-03-01 21:46:17
|
Bugs item #907873, was opened at 2004-03-01 21:33 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=907873&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dair Grant (grantd) Assigned to: Nobody/Anonymous (nobody) Summary: Wire frame renderer does not draw Polygon objects Initial Comment: Quesa's interactive renderer does not draw Polygon objects correctly in edge mode. QD3D draws the lines making up the boundary. The default cube objects in 3D World are composed of six polygons. They totally disappear when using Quesa. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=907873&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-03-01 21:44:21
|
Bugs item #907872, was opened at 2004-03-01 21:31 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=907872&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dair Grant (grantd) Assigned to: Nobody/Anonymous (nobody) Summary: Textured geometry without UVs rendered as white Initial Comment: Unlike QD3D, geometry which is submitted without UVs while a texture is active will be rendered as white. On QD3D, it will be rendered as if no texture was active. This was broken deliberately in 1.6d18 - we could optionally post a notice if we detect this case, as I have assumed it's not terribly common (and the QD3D behaviour is probably a side-effect rather than deliberate) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=907872&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-03-01 21:43:26
|
Bugs item #907870, was opened at 2004-03-01 21:31 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=907870&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 edit index objects in 3DMF Initial Comment: Certain 3DMF files contain objects of type 'edit' and 4 bytes of data. My guess is that this is the value of Q3Shared_GetEditIndex for the parent object. I don't see any QD3D documentation of this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=907870&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-03-01 21:42:02
|
Bugs item #907868, was opened at 2004-03-01 21: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=907868&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dair Grant (grantd) Assigned to: Nobody/Anonymous (nobody) Summary: Unknown objects are not written to 3DMF Initial Comment: Unknown objects are not currently written to 3DMF, they should be preserved. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=907868&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-03-01 21:41:28
|
Bugs item #907866, was opened at 2004-03-01 21: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=907866&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dair Grant (grantd) Assigned to: Nobody/Anonymous (nobody) Summary: DisplayGroupBBox object not handled Initial Comment: "We have to match the group bounding box handling with QD3D, both for IO an in implementation, culling ecc." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=907866&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-03-01 21:40:15
|
Bugs item #907863, was opened at 2004-03-01 21:27 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=907863&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dair Grant (grantd) Assigned to: Nobody/Anonymous (nobody) Summary: Quesa Unix doesn't load plug-ins Initial Comment: Quesa Unix doesn't load plug-ins. Not sure if we can have a standard plug-in format for all Unix targets, but we can probably provide some shared library support for common platforms (Linux+*BSD say). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=907863&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-03-01 21:38:58
|
Bugs item #907859, was opened at 2004-03-01 21:26 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=907859&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dair Grant (grantd) Assigned to: Nobody/Anonymous (nobody) Summary: Qut unix doesn't handle mouse move events Initial Comment: Qut unix doesn't handle mouse move events - Camera Test doesn't work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=907859&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-03-01 21:38:29
|
Bugs item #907858, was opened at 2004-03-01 21:26 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=907858&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dair Grant (grantd) Assigned to: Nobody/Anonymous (nobody) Summary: Trigrid decomposition creates triangles Initial Comment: (this is another case of bug 907849 - we currently create triangles to support some apps that need per-triangle textures, but really a TriMesh should be able to handle this) The decomposition of trigrid creates triangles even when it will be possible to create trimeshes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=907858&group_id=45158 |
|
From: SourceForge.net <no...@so...> - 2004-03-01 21:35:30
|
Bugs item #907857, was opened at 2004-03-01 21:23 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=907857&group_id=45158 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dair Grant (grantd) Assigned to: Nobody/Anonymous (nobody) Summary: RayShade misapplies textures Initial Comment: The RayShade renderer seems to be applying the whole texture to every triangle of a TriMesh model. Actually, with a model that contains several TriMeshes, the texture from one gets applied even to the other (untextured) models. Jose' comments: "the problem could be at: - the renderer doesn't honor the u,v parameters for the triangles - the decomposition routine doesn't set properly the u,v in the resulting triangles to test which one is you could comment out the entry in the IR renderer metahandler for trimeshes, and see if the problem is replicated in the IR" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=442052&aid=907857&group_id=45158 |
1 message has been excluded from this view by a project administrator.