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: James W. W. <ja...@wr...> - 2004-10-28 19:07:34
|
Sorry, lost the quoting on that post, let's try again: Peter Michelsen <Pet...@mi...> wrote: > Yes you are right the function call is... >ResolveAliasFile(&theFSSpec, true, &targetIsFolder, &wasAliased); I >had copied the wrong call. But, what exactly goes wrong with this call? Does it show an alert requesting that a volume be mounted, or what? >But luckily this did force me to look in developer.apple.com for >this function. They have list the call as Not recommended I think that's just because it uses an FSSpec. I would not be opposed to switching to FSRefs, but I don't think we've made an official decision to drop support for Mac OS 8. > I also noticed that there is a call the FSResolveAliasFilewithMountFlags. If what you need to do is avoid UI, there is an FSSpec-compatible function ResolveAliasFileWithMountFlags. As I look at this code, I think I see another problem: If the file was an alias, we should get the file type and creator of the actual file, not the alias. The type and creator are probably correct for a normal alias, but not for a symbolic link. As long as we're discussing plugin loading, does anyone know whether the current system works when Quesa is built as a Mach-o framework, or do we need to add some sort of Mach-O-CFM glue? -- James W. Walker, ScriptPerfection Enterprises, Inc. <http://www.write-brain.com/> |
|
From: Jose' C. <cru...@ce...> - 2004-10-28 18:59:39
|
On 28/ott/04, at 20:39, James W. Walker wrote: > As long as we're discussing plugin loading, does anyone know whether > the current system works when Quesa is built as a Mach-o framework, or > do we need to add some sort of Mach-O-CFM glue? I seem to remember that it does't work, but by now I'm stuck with CFM (system 9 compatibility) Pax et Bonum # dott. Jose' Cruanyes Aguilar - C.E. Soft srl # Pzza. Firenze,4 MILANO - XX Settembre 10, CREMONA # 02,33603122 0372,460602 |
|
From: James W. W. <ja...@wr...> - 2004-10-28 18:39:56
|
<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: Issues with plug-in loading within
Quesa.</title></head><body>
<div>Peter Michelsen <Pet...@mi...>
wrote:</div>
<div><br></div>
<div>Yes you are right the function call is...
ResolveAliasFile(&theFSSpec, true, &targetIsFolder,
&wasAliased); I had copied the wrong call.</div>
<div><br></div>
<div>But, what exactly goes wrong with this call? Does it show
an alert requesting that a volume be mounted, or what?</div>
<div><br></div>
<div>But luckily this did force me to look in developer.apple.com for
this function. They have list the call as<font face="Lucida Grande">
</font><i>Not
recommended</i></div>
<div><br></div>
<div>I think that's just because it uses an FSSpec. I would not
be opposed to switching to FSRefs, but I don't think we've made an
official decision to drop support for Mac OS 8.</div>
<div><br></div>
<div>I also noticed that there is a call the
FSResolveAliasFilewithMountFlags.</div>
<div><br></div>
<div>If what you need to do is avoid UI, there is an FSSpec-compatible
function ResolveAliasFileWithMountFlags.</div>
<div><br></div>
<div>As I look at this code, I think I see another problem: If
the file was an alias, we should get the file type and creator of the
actual file, not the alias. The type and creator are probably
correct for a normal alias, but not for a symbolic link.</div>
<div><br></div>
<div>As long as we're discussing plugin loading, does anyone know
whether the current system works when Quesa is built as a Mach-o
framework, or do we need to add some sort of Mach-O-CFM glue?</div>
<x-sigsep><pre>--
</pre></x-sigsep>
<div> James W. Walker, ScriptPerfection Enterprises, Inc.<br>
<http://www.write-brain.com/></div>
</body>
</html>
|
|
From: Peter M. <Pet...@mi...> - 2004-10-28 17:49:29
|
Thats better.
Peter
static void
e3mac_load_plugins(const FSSpec *fileInDirToScan)
{ Boolean targetIsFolder;
Boolean wasAliased;
FSSpec theFSSpec;
FSRef theFSRef;
TQ3Int16 theIndex;
OSErr theErr;
CInfoPBRec thePB;
// Iterate through the directory, looking for plug-ins
theIndex = 1;
do
{
// Get the next file
thePB.dirInfo.ioFDirIndex = theIndex;
thePB.dirInfo.ioVRefNum = fileInDirToScan->vRefNum;
thePB.dirInfo.ioDrDirID = fileInDirToScan->parID;
thePB.dirInfo.ioNamePtr = theFSSpec.name;
theErr = PBGetCatInfoSync(&thePB);
if (theErr == noErr)
{
// Grab the file
theErr = FSMakeFSSpec(fileInDirToScan->vRefNum,
fileInDirToScan->parID, theFSSpec.name, &theFSSpec);
if (theErr == noErr)
{
// Grab the file's FSRef
theErr = FSpMakeFSRef(&theFSSpec, &theFSRef);
if (theErr == noErr)
{
// Resolve any aliases
targetIsFolder = true;
theErr = FSResolveAliasFileWithMountFlags ( &theFSRef, true,
&targetIsFolder, &wasAliased, kResolveAliasFileNoUI ) ;
if (theErr == noErr)
{
// If this isn't a directory, check the type
if (!targetIsFolder)
{
// If this is a plug-in, load it
if (thePB.hFileInfo.ioFlFndrInfo.fdType ==
kQ3XExtensionMacFileType &&
thePB.hFileInfo.ioFlFndrInfo.fdCreator ==
kQ3XExtensionMacCreatorType)
e3mac_load_plugin(&theFSSpec);
}
}
}
}
// Clear any error - don't stop if we hit an error at this point
theErr = noErr;
}
theIndex++;
}
while (theErr == noErr);
}
|
|
From: Peter M. <Pet...@mi...> - 2004-10-28 17:34:52
|
Hi James, Yes you are right the function call is... ResolveAliasFile(&theFSSpec,=20= true, &targetIsFolder, &wasAliased); I had copied the wrong call. But luckily this did force me to look in developer.apple.com for this=20 function. They have list the call as =A0=A0=A0=A0=A0=A0=A0Not = recommended I also noticed that there is a call the=20 FSResolveAliasFilewithMountFlags. Now I do not really know what is best but should we change the call to=20= be more like this; static void e3mac_load_plugins(const FSSpec *fileInDirToScan) { Boolean targetIsFolder; Boolean wasAliased; FSSpec theFSSpec; FSRef theFSRef; TQ3Int16 theIndex; OSErr theErr; CInfoPBRec thePB; // Iterate through the directory, looking for plug-ins theIndex =3D 1; do { // Get the next file thePB.dirInfo.ioFDirIndex =3D theIndex; thePB.dirInfo.ioVRefNum =3D fileInDirToScan->vRefNum; thePB.dirInfo.ioDrDirID =3D fileInDirToScan->parID; thePB.dirInfo.ioNamePtr =3D theFSSpec.name; =09 theErr =3D PBGetCatInfoSync(&thePB); if (theErr =3D=3D noErr) { // Grab the file theErr =3D = FSMakeFSSpec(fileInDirToScan->vRefNum,=20 fileInDirToScan->parID, theFSSpec.name, &theFSSpec); if (theErr =3D=3D noErr) { // Grab the file's FSRef theErr =3D FSpMakeFSRef(&theFSSpec, = &theFSRef); if (theErr =3D=3D noErr) { // Resolve any aliases targetIsFolder =3D true; theErr =3D = FSResolveAliasFileWithMountFlags ( &theFSRef, = true, = &targetIsFolder, = &wasAliased, = kResolveAliasFileNoUI ) = ; =09 // If this isn't a directory, = check the type if (!targetIsFolder) { if (theErr =3D=3D noErr) { // If this is a = plug-in, load it if = (thePB.hFileInfo.ioFlFndrInfo.fdType =3D=3D=20 kQ3XExtensionMacFileType && = thePB.hFileInfo.ioFlFndrInfo.fdCreator =3D=3D=20 kQ3XExtensionMacCreatorType) = e3mac_load_plugin(&theFSSpec); } } } } // Clear any error - don't stop if we hit an = error at this point theErr =3D noErr; } =09 theIndex++; } while (theErr =3D=3D noErr); } I will have to test this tomorrow as my tester has gone home for the=20 day but it seems to run on my machine. Peter Michelsen On 28 Oct 2004, at 17:11, James W. Walker wrote: > > On Oct 28, 2004, at 8:04 AM, Peter Michelsen wrote: > >> >>>> theErr =3D GetProcessBundleLocation( &thePSN, &bundleFSRef ); >> >> This line above returns a link to where the application is stored=20 >> e.g. " /private/Network/Servers/jupiter/Users/jbatt/Desktop/3D\=20 >> World.d.app " Later the function " e3mac_load_plugins( &fileSpec[i]=20= >> ); " is called which calls " theErr =3D ResolveAlias(NULL, gQuesaLib,=20= >> &fileSpec[ dirCount ], &wasChanged); " This fails causing Quesa to=20 >> assert. > > The only ResolveAlias call in E3MacSystem.c is in=20 > E3MacSystem_LoadPlugins. I think you must mean the ResolveAliasFile=20= > call in e3mac_load_plugins. But we don't even check for an error code=20= > from that, so I don't see how it can cause Quesa to assert. > -- > <http://www.jwwalker.com/> > > > > ------------------------------------------------------- > This Newsletter Sponsored by: Macrovision For reliable Linux=20 > application installations, use the industry's leading > setup authoring tool, InstallShield X. Learn more and evaluate today.=20= > http://clk.atdmt.com/MSI/go/ins0030000001msi/direct/01/ > _______________________________________________ > Quesa-develop mailing list > Que...@li... > https://lists.sourceforge.net/lists/listinfo/quesa-develop > |
|
From: James W. W. <os...@jw...> - 2004-10-28 16:11:41
|
On Oct 28, 2004, at 8:04 AM, Peter Michelsen wrote: > >>> theErr = GetProcessBundleLocation( &thePSN, &bundleFSRef ); > > This line above returns a link to where the application is stored e.g. > " /private/Network/Servers/jupiter/Users/jbatt/Desktop/3D\ World.d.app > " Later the function " e3mac_load_plugins( &fileSpec[i] ); " is > called which calls " theErr = ResolveAlias(NULL, gQuesaLib, &fileSpec[ > dirCount ], &wasChanged); " This fails causing Quesa to assert. The only ResolveAlias call in E3MacSystem.c is in E3MacSystem_LoadPlugins. I think you must mean the ResolveAliasFile call in e3mac_load_plugins. But we don't even check for an error code from that, so I don't see how it can cause Quesa to assert. -- <http://www.jwwalker.com/> |
|
From: Peter M. <Pet...@mi...> - 2004-10-28 15:04:59
|
Sorry, I will try to make it a bit more clear. > What is a specific example of a case where a plugin does not get > loaded when it should? The problem is not with loading a plug-in but in the way in which it is looking for plug-ins to load. >> theErr = GetProcessBundleLocation( &thePSN, &bundleFSRef ); This line above returns a link to where the application is stored e.g. " /private/Network/Servers/jupiter/Users/jbatt/Desktop/3D\ World.d.app " Later the function " e3mac_load_plugins( &fileSpec[i] ); " is called which calls " theErr = ResolveAlias(NULL, gQuesaLib, &fileSpec[ dirCount ], &wasChanged); " This fails causing Quesa to assert. The problem >> While Quesa is loading it tries to look for plug-ins (GOOD), while it >> is looking for plug-ins Quesa tries to resolve any alias (FINE most >> of the time), but should Quesa really be doing this at application >> bundle level on OSX. Now the solution to the problem is either, that Quesa should not search outside of the application bundle it is in, for plug-ins. Or that "ResolveAlias" should have checking code before it is called. What checking code I do not know? Peter Michelsen |
|
From: James W. W. <os...@jw...> - 2004-10-28 13:17:51
|
On Oct 28, 2004, at 5:46 AM, Peter Michelsen wrote:
> We have have come across a problem in Quesa while testing. The problem
> involves having an application ( using Quesa ) running from an AFP(OSX
> 10.3) users desktop with an alias to a SMB share.
>
> While Quesa is loading it tries to look for plug-ins (GOOD), while it
> is looking for plug-ins Quesa tries to resolve any alias (FINE most
> of the time), but should it really be doing this a application bundle
> level on OSX.
Doing what at the bundle level? What is a specific example of a case
where a plugin does not get loaded when it should?
> I have listed the code section I feel should be changed or removed
> below.
Unclear. It looks like you listed the same piece of code twice, but
haven't said what the problem is.
> The other option is to have better alias resolve code.
>
> File:
> E3MacSystem.cp
>
> Function:
> void
> E3MacSystem_LoadPlugins(void)
>
> Code Section:
> // Find the application file
> if (isOnOSX)
> {
> theErr = GetProcessBundleLocation( &thePSN, &bundleFSRef );
>
> if (theErr == noErr)
> {
> theErr = FSGetCatalogInfo( &bundleFSRef, 0, NULL, NULL, &fileSpec[
> dirCount ], NULL );
> }
> }
> else
> {
> processInfo.processInfoLength = sizeof(ProcessInfoRec);
> processInfo.processName = NULL;
> processInfo.processAppSpec = &fileSpec[ dirCount ];
>
> theErr = GetProcessInformation(&thePSN, &processInfo);
> }
>
> if (theErr == noErr)
> ++dirCount;
>
> Code Line problem:
> if (isOnOSX)
> {
> theErr = GetProcessBundleLocation( &thePSN, &bundleFSRef );
>
> if (theErr == noErr)
> {
> theErr = FSGetCatalogInfo( &bundleFSRef, 0, NULL, NULL, &fileSpec[
> dirCount ], NULL );
> }
> }
--
<http://www.jwwalker.com/>
|
|
From: Peter M. <Pet...@mi...> - 2004-10-28 12:46:14
|
Hi Quesa list,
We have have come across a problem in Quesa while testing. The problem
involves having an application ( using Quesa ) running from an AFP(OSX
10.3) users desktop with an alias to a SMB share.
While Quesa is loading it tries to look for plug-ins (GOOD), while it
is looking for plug-ins Quesa tries to resolve any alias (FINE most of
the time), but should it really be doing this a application bundle
level on OSX.
I have listed the code section I feel should be changed or removed
below. The other option is to have better alias resolve code.
File:
E3MacSystem.cp
Function:
void
E3MacSystem_LoadPlugins(void)
Code Section:
// Find the application file
if (isOnOSX)
{
theErr = GetProcessBundleLocation( &thePSN, &bundleFSRef );
if (theErr == noErr)
{
theErr = FSGetCatalogInfo( &bundleFSRef, 0, NULL, NULL, &fileSpec[
dirCount ], NULL );
}
}
else
{
processInfo.processInfoLength = sizeof(ProcessInfoRec);
processInfo.processName = NULL;
processInfo.processAppSpec = &fileSpec[ dirCount ];
theErr = GetProcessInformation(&thePSN, &processInfo);
}
if (theErr == noErr)
++dirCount;
Code Line problem:
if (isOnOSX)
{
theErr = GetProcessBundleLocation( &thePSN, &bundleFSRef );
if (theErr == noErr)
{
theErr = FSGetCatalogInfo( &bundleFSRef, 0, NULL, NULL, &fileSpec[
dirCount ], NULL );
}
}
What would other people suggest.
Peter Michelsen |
|
From: James W. W. <os...@jw...> - 2004-10-23 18:38:41
|
On Oct 23, 2004, at 1:30 AM, Jose' Cruanyes wrote: > try using the Q3RawData_Write procedure to allocate the buffer and > then get it > > or just allocate the buffer and pass it to Q3MemoryStorage_New The former way requires the use of a file object, and the latter copies the buffer, neither of which is necessary in Quesa. But I suppose I will do the latter to make Qut work with QD3D. -- <http://www.jwwalker.com/> |
|
From: Jose' C. <cru...@ce...> - 2004-10-23 08:30:44
|
On 23/ott/04, at 01:25, James W. Walker wrote: > I was trying to run Geom Test in Classic, and found that it crashed in > QutTexture_CreateTextureObjectFromTGAFile. What seems to be happening > is that Q3MemoryStorage_New returns a storage object, but > Q3MemoryStorage_GetBuffer returns a NULL buffer. Similar things > happen with Handle storage objects. It's beginning to look as if QD3D > does not allow one to write to an internally-allocated memory storage > except using Q3Storage_SetData. Is that true? If so, it's really a > pain. > never used Memory storage that way, but I've used this for ages storageObj = ::Q3MemoryStorage_New(NULL,0); ::Q3File_SetStorage(fileObj, storageObj); ::Q3File_OpenWrite( fileObj, fileMode ); ::Q3View_StartWriting(dummyView, fileObj); ::Q3DisplayGroup_Submit(groupObj, dummyView); ::Q3View_EndWriting(dummyView); ::Q3File_Close(fileObj); ::Q3MemoryStorage_GetBuffer(storageObj, &buffer, &size, &count); metafile = operator new(size); memcpy(metafile,buffer,size); so probably QD3D has a lazy allocation, try using the Q3RawData_Write procedure to allocate the buffer and then get it or just allocate the buffer and pass it to Q3MemoryStorage_New Pax et Bonum # dott. Jose' Cruanyes Aguilar - C.E. Soft srl # Pzza. Firenze,4 MILANO - XX Settembre 10, CREMONA # 02,33603122 0372,460602 |
|
From: James W. W. <ja...@wr...> - 2004-10-22 23:25:23
|
I was trying to run Geom Test in Classic, and found that it crashed in QutTexture_CreateTextureObjectFromTGAFile. What seems to be happening is that Q3MemoryStorage_New returns a storage object, but Q3MemoryStorage_GetBuffer returns a NULL buffer. Similar things happen with Handle storage objects. It's beginning to look as if QD3D does not allow one to write to an internally-allocated memory storage except using Q3Storage_SetData. Is that true? If so, it's really a pain. -- James W. Walker, ScriptPerfection Enterprises, Inc. <http://www.write-brain.com/> |
|
From: Jose' C. <cru...@ce...> - 2004-10-22 21:53:43
|
On 22/ott/04, at 16:15, Daniele Cavallini wrote: > In rayshade there is a problem when one or more texture are present. > The texture in shadow are completely black when a light are present . > I try to modify the code and it seems work fine. > > you can see the different at this link: > > Render with quesa: > =A0=A0=A0=A0=A0=A0=A0=A0http://www.interstudio.net/quesa/quesa.JPG > Render with old rayshade > =A0=A0=A0=A0=A0=A0=A0=A0http://www.interstudio.net/quesa/rayshadeold.JPG= > Render with my modify rayshade > =A0=A0=A0=A0=A0=A0=A0=A0http://www.interstudio.net/quesa/rayshadenew.JPG= > > It's another step forward... in my to-do list (buried among another bilion things) were to solve the=20= problem of rayShade being too dark and the incorrect use of textures=20 (are applied also to non involved geometries) I've checked it in Pax et Bonum # dott. Jose' Cruanyes Aguilar - C.E. Soft srl # Pzza. Firenze,4 MILANO - XX Settembre 10, CREMONA # 02,33603122 0372,460602 |
|
From: Daniele C. <dca...@in...> - 2004-10-22 14:15:33
|
In rayshade there is a problem when one or more texture are present.
The texture in shadow are completely black when a light are present .
I try to modify the code and it seems work fine.
I modify the function:
void CImageTexture::Apply(
Geom *prim,
Ray * /*ray*/,
Vector *pos,
Vector *norm,
Vector *gnorm,
Surface *surf)
.. ... ...
switch (tComponent) {
case kImageTextureType_QD3D:
tmpsurf.diff.r = outval[rchan];
tmpsurf.diff.g = outval[gchan];
tmpsurf.diff.b = outval[bchan];
//my modify
tmpsurf.amb.r = outval[rchan];
tmpsurf.amb.g = outval[gchan];
tmpsurf.amb.b = outval[bchan];
// old code
/*
tmpsurf.amb.r = 0;
tmpsurf.amb.g = 0;
tmpsurf.amb.b = 0;
*/
break;
.... ...... ....
you can see the different at this link:
Render with quesa:
http://www.interstudio.net/quesa/quesa.JPG
Render with old rayshade
http://www.interstudio.net/quesa/rayshadeold.JPG
Render with my modify rayshade
http://www.interstudio.net/quesa/rayshadenew.JPG
What do you think about this? |
|
From: James W. W. <ja...@wr...> - 2004-10-08 22:09:18
|
Dair Grant <da...@re...> wrote: >can you open a bug on SourceForge and attach >the problem model? Note, attaching the model will not work if the problem model is more than 256K. In that case, include a link to the file. -- James W. Walker, ScriptPerfection Enterprises, Inc. <http://www.write-brain.com/> |
|
From: Dair G. <da...@re...> - 2004-10-08 21:40:16
|
Roger Holmes wrote: >In both cases, Peter was using the CVS version. Actually he did try >it with the Microspot version and strangely, he said that worked OK. OK. Peter, if you don't have any luck finding where the instance data goes from non-NULL to NULL, can you open a bug on SourceForge and attach the problem model? -dair ___________________________________________________ mailto:dair+refnum.com http://www.refnum.com/ |
|
From: Roger H. <rog...@mi...> - 2004-10-08 19:56:42
|
In both cases, Peter was using the CVS version. Actually he did try it with the Microspot version and strangely, he said that worked OK. On Friday, October 8, 2004, at 06:59 pm, Dair Grant wrote: > > Was GeomTest using the same version of Quesa (the Microspot flavour, > which did have some instance data changes) or the CVS version? |
|
From: Dair G. <da...@re...> - 2004-10-08 17:59:26
|
Peter Michelsen wrote: >The question is should we have this kind of checks elsewhere when =20 >creating instanceData? That shader object should always have a valid (i.e., non-NULL) instance data pointer; if it doesn't then it's not a valid object. >Or is there a problem in my code that allows this problem in the first =20 >place? I would look at the shader object in question, see if you can track its instance data from when it's created until you hit this point. When E3Shader_RegisterClass registers the texture shader class it asks for sizeof(TQ3TextureObject) bytes of instance data. When E3TextureShader_New allocates the object it should either get that instance data or fail - so either it's failing at that point, or someone tramples it later on. >If you would like a copy of the file I can place it on ftp.( it is a =20 >sample 3DMF file from apple called "57 Chevy" ). I did not have any =20 >problems opening the file in geomtest. Was GeomTest using the same version of Quesa (the Microspot flavour, which did have some instance data changes) or the CVS version? -dair ___________________________________________________ mailto:dair+refnum.com http://www.refnum.com/ |
|
From: James W. W. <ja...@wr...> - 2004-10-08 17:44:07
|
Peter Michelsen <Pet...@mi...> wrote: >After testing I have found a crashing bug that we did not have >before. It looks to be with files that claim to have textures but do >not actual have any texture data when asked to supply them. > >I have a fix, in E3Shader.c but it is not pretty. > >The question is should we have this kind of checks elsewhere when >creating instanceData? > >Or is there a problem in my code that allows this problem in the first place? > >If you would like a copy of the file I can place it on ftp.( it is a >sample 3DMF file from apple called "57 Chevy" ). I did not have any >problems opening the file in geomtest. If the file opens in Geom Test, then I'd say we need something more, perhaps some of your code. I, at least, would not be comfortable checking in a fix for a problem that I don't know how to reproduce. -- James W. Walker, ScriptPerfection Enterprises, Inc. <http://www.write-brain.com/> |
|
From: Peter M. <Pet...@mi...> - 2004-10-08 17:11:23
|
Hi All,
After testing I have found a crashing bug that we did not have before.
It looks to be with files that claim to have textures but do not actual
have any texture data when asked to supply them.
I have a fix, in E3Shader.c but it is not pretty.
The question is should we have this kind of checks elsewhere when
creating instanceData?
Or is there a problem in my code that allows this problem in the first
place?
If you would like a copy of the file I can place it on ftp.( it is a
sample 3DMF file from apple called "57 Chevy" ). I did not have any
problems opening the file in geomtest.
Thanks for any pointer on this issus,
Peter.
Fix.....
//
========================================================================
=====
// E3TextureShader_GetTexture : Get the texture shader's texture
object.
/
/-----------------------------------------------------------------------
------
TQ3Status
E3TextureShader_GetTexture(TQ3ShaderObject shader, TQ3TextureObject
*texture)
{ TQ3TextureObject *instanceData = (TQ3TextureObject *)
E3ClassTree_FindInstanceData(shader, kQ3SurfaceShaderTypeTexture);
if ( instanceData )
{ // Create a new reference to our renderer
E3Shared_Acquire(texture, *instanceData);
return(kQ3Success);
}
return(kQ3Failure);
}
//
========================================================================
=====
// E3TextureShader_SetTexture : Set a texture shader's texture.
/
/-----------------------------------------------------------------------
------
TQ3Status
E3TextureShader_SetTexture(TQ3ShaderObject shader, TQ3TextureObject
texture)
{ TQ3TextureObject *instanceData = (TQ3TextureObject *)
E3ClassTree_FindInstanceData(shader, kQ3SurfaceShaderTypeTexture);
if ( instanceData )
{ // Replace the existing texture reference
E3Shared_Replace(instanceData, texture);
Q3Shared_Edited(shader);
return(kQ3Success);
}
return(kQ3Failure);
}
|
|
From: Roger H. <rog...@mi...> - 2004-10-06 13:22:31
|
Hi Dair,
A bit of a mystery, but it works properly now.
We did have some problems with CodeWarrior (we still use 8.3 for this
project)
Sorry for wasting your time.
Roger.
On Tuesday, October 5, 2004, at 11:40 pm, Dair Grant wrote:
> Roger Holmes wrote:
>
>>>> If it does, shouldn't Q3Transform_GetMatrix work on it? At present
>>>> it gives an assertion error.
>>>
>>> It should work (i.e., not fail), although it won't return anything
>>> sensible. It should call down to e3transform_camera_rasterize_matrix,
>>> which will return an identity matrix for want of anything else.
>>>
>>> Where do you get the assert from?
>>
>> It asserts that the object is of type transform, but this fails.
>
> I.e., the assert that's firing is the first one inside
> Q3Transform_GetMatrix in QD3DTransform.c?
>
> I don't see that fire here (current cvs) - I'm using the following as a
> test:
>
> { TQ3TransformObject theTransform;
> TQ3Matrix4x4 theMatrix;
>
> theTransform = Q3RasterizeCameraTransform_New();
> Q3Transform_GetMatrix(theTransform, &theMatrix);
> }
>
> If I step into that assertion, the transform object has type 'rast' and
> its immediate parent is 'xfrm' which is what the assert verifies.
>
>
> -dair
> ___________________________________________________
> mailto:dair+refnum.com http://www.refnum.com/
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on
> ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give
> us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out
> more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>
|
|
From: Frank C. <dev...@ch...> - 2004-10-06 06:35:35
|
On 5-Oct-04, at 7:09 PM, Dair Grant wrote:
> Frank Condello wrote:
>
>> This would be a temporary fix at best, but if someone with CVS access
>> wants to check it in that's fine with me.
>
> So in all the back and forth on this thread, I'm not sure what the
> final
> patch was; can you forward that to me or point me at the bug with it
> attached?
I added some notes to bug #967773 - basically the workaround is to set
the illumination state in ir_geom_transparent_render before drawing:
if (thePrim->illumination == kQ3IlluminationTypeNULL)
{
glDisable(GL_LIGHTING);
glDisable(GL_COLOR_MATERIAL);
}
else
{
glEnable(GL_LIGHTING);
glEnable(GL_COLOR_MATERIAL);
}
Then add a glEnable(GL_LIGHTING); call before the specular pass in
IRTransBuffer_Draw. Kinda brute force but it works...
I have an even nastier workaround for bug #967958
<http://sf.net/tracker/index.php?
func=detail&aid=967958&group_id=45158&atid=442052>. In
IRGeometryTriMesh.c, ir_geom_trimesh_build_transparent, in the last
"Check for transparent vertices" loop, replace these two lines:
m = vertexArray->vertexParents[n];
E3Bit_Set(vertexArray->triFlags[m], kQ3TriFlagTransparent);
With this:
for (m = 0; m < vertexArray->geomData->numTriangles; m++)
{
if (vertexArray->triFlags[m] & kQ3TriFlagTransparent)
continue;
theIndices = vertexArray->geomData->triangles[n].pointIndices;
if ( (theIndices[0] == n) || (theIndices[1] == n) || (theIndices[2]
== n) )
E3Bit_Set(vertexArray->triFlags[m], kQ3TriFlagTransparent);
}
This is pretty ugly and slow but it illustrates the underlying problem
detailed in the bug report.
Frank.
|
|
From: Dair G. <da...@re...> - 2004-10-06 00:44:55
|
James W. Walker wrote: >>I know you're keen to get a new sorting algorithm in place, but the >>problem is the proposed change (a centroid sort) fixes your case but >>makes others worse. In which case we're just swapping one problem for >>another, and we'll be having this conversation again in 6 months. :-) > >Oops. You must not be paying attention to the CVS list. Sorry, my mail has been getting out of control recently. :-) >I checked in that change on Saturday. It's true that this is a >tradeoff, but I would argue that the bad cases of the centroid sort >are neither as bad nor as likely as the bad cases of the old >algorithm, and the centroid sort is also much simpler. OK, lets go with that approach for now then - the other transparency issues will still stand (the state stuff), so I suspect this code will need more work along the way. -dair ___________________________________________________ mailto:dair+refnum.com http://www.refnum.com/ |
|
From: James W. W. <ja...@wr...> - 2004-10-06 00:27:52
|
Dair Grant <da...@re...> wrote: >I know you're keen to get a new sorting algorithm in place, but the >problem is the proposed change (a centroid sort) fixes your case but >makes others worse. In which case we're just swapping one problem for >another, and we'll be having this conversation again in 6 months. :-) Oops. You must not be paying attention to the CVS list. I checked in that change on Saturday. It's true that this is a tradeoff, but I would argue that the bad cases of the centroid sort are neither as bad nor as likely as the bad cases of the old algorithm, and the centroid sort is also much simpler. -- James W. Walker, ScriptPerfection Enterprises, Inc. <http://www.write-brain.com/> |
|
From: Dair G. <da...@re...> - 2004-10-05 23:09:37
|
=46rank Condello wrote: >On a similar note; Is there a better way to submit patches? Do you guys = =20 >prefer some sort of diff tool output? If so, please let me know... Missed this one as it was passing by, but I find the most useful thing to be the patch applied to the latest CVS source. I can then diff the old+new files with BBEdit, and push over the bits that need to change. -dair ___________________________________________________ mailto:dair+refnum.com http://www.refnum.com/ |
1 message has been excluded from this view by a project administrator.
