Menu
▾
▴
quesa-develop
|
From: James W. W. <os...@jw...> - 2008-08-28 05:18:20
|
I've just checked in changes to 19 files, based on Sean McBride's patch and a few tweaks of my own, to make Quesa compile in 64 bit mode on the Mac. Most of the changes involve a new macro QUESA_SUPPORT_HITOOLBOX, which Quesa defines by default to be 0 in Mac 64 bit and 1 in Mac 32 bit. You could choose to define it to be 0 in 32 bit mode too. When QUESA_SUPPORT_HITOOLBOX is 0, you cannot create Mac draw contexts, hence if you want to draw anything on the screen you must use Cocoa. You also cannot use FSSpec storage objects. A side effect of disabling Mac draw contexts is that currently pixmap draw contexts will not work on the Mac when QUESA_SUPPORT_HITOOLBOX is 0. If anyone cares, I'd guess it wouldn't be too hard to reimplement pixmap draw contexts using Cocoa or CGL. |
|
From: Sean M. <se...@ro...> - 2008-09-02 17:08:54
|
James, Thanks for your review and commit of our patch! I've attached one minor followup patch. Basically, it wraps the .m files in #if QUESA_OS_COCOA. The reason is that we'd like to be able to compile Quesa with absolutely no Obj-C code. Why? Well, our application uses garbage collection and so any libraries we link with need to also support GC. Since Quesa has not been tested with GC, the best thing is to just not build any of the Cocoa stuff (which is unneeded in our case). (A quick look at Quesa's Obj-C code suggests that some changes are needed to support GC, we can discuss that too if anyone is interested...) Cheers, -- ____________________________________________________________ Sean McBride, B. Eng se...@ro... Rogue Research www.rogue-research.com Mac Software Developer Montréal, Québec, Canada |
|
From: Sean M. <se...@ro...> - 2008-09-04 16:32:50
|
On 8/27/08 10:18 PM, James W. Walker said: >I've just checked in changes to 19 files, based on Sean McBride's >patch and a few tweaks of my own, to make Quesa compile in 64 bit mode >on the Mac. > >Most of the changes involve a new macro QUESA_SUPPORT_HITOOLBOX, which >Quesa defines by default to be 0 in Mac 64 bit and 1 in Mac 32 bit. >You could choose to define it to be 0 in 32 bit mode too. > >When QUESA_SUPPORT_HITOOLBOX is 0, you cannot create Mac draw >contexts, hence if you want to draw anything on the screen you must >use Cocoa. You also cannot use FSSpec storage objects. > >A side effect of disabling Mac draw contexts is that currently pixmap >draw contexts will not work on the Mac when QUESA_SUPPORT_HITOOLBOX is >0. If anyone cares, I'd guess it wouldn't be too hard to reimplement >pixmap draw contexts using Cocoa or CGL. James, Attached is another small simple patch that fixes a compiler warning. Also, I notice Quesa uses a mix of xcconfig files and directly setting options in the project/target. Would you accept a patch that moves all settings into xcconfig files? This would be useful to us since we are constantly having the change the project to customise build options. Cheers, -- ____________________________________________________________ Sean McBride, B. Eng se...@ro... Rogue Research www.rogue-research.com Mac Software Developer Montréal, Québec, Canada |
|
From: James W. <ja...@fr...> - 2008-09-04 17:16:52
|
Sean McBride wrote: > Also, I notice Quesa uses a mix of xcconfig files and directly setting > options in the project/target. Would you accept a patch that moves all > settings into xcconfig files? This would be useful to us since we are > constantly having the change the project to customise build options. Yes, that sounds reasonable. -- James W. Walker, Innoventive Software LLC <http://www.frameforge3d.com/> |
|
From: Sean M. <se...@ro...> - 2008-09-04 17:52:33
|
On 9/4/08 10:16 AM, James Walker said: >> Also, I notice Quesa uses a mix of xcconfig files and directly setting >> options in the project/target. Would you accept a patch that moves all >> settings into xcconfig files? This would be useful to us since we are >> constantly having the change the project to customise build options. > >Yes, that sounds reasonable. OK, so before I start, a few followup questions. What is the oldest version of Xcode to support? Can I remove the duplicate targets for gcc3.3? (Instead, compiler choice can be made in the xcconfig file). -- ____________________________________________________________ Sean McBride, B. Eng se...@ro... Rogue Research www.rogue-research.com Mac Software Developer Montréal, Québec, Canada |
|
From: James W. <ja...@fr...> - 2008-09-04 18:36:10
|
Sean McBride wrote: > On 9/4/08 10:16 AM, James Walker said: > >>> Also, I notice Quesa uses a mix of xcconfig files and directly setting >>> options in the project/target. Would you accept a patch that moves all >>> settings into xcconfig files? This would be useful to us since we are >>> constantly having the change the project to customise build options. >> Yes, that sounds reasonable. > > OK, so before I start, a few followup questions. What is the oldest > version of Xcode to support? I'd say 2.5. > Can I remove the duplicate targets for > gcc3.3? (Instead, compiler choice can be made in the xcconfig file). That's OK with me. (Using gcc .3.3 is only necessary when targeting OS versions earlier than 10.3.9, which I never do.) -- James W. Walker, Innoventive Software LLC <http://www.frameforge3d.com/> |
|
From: Pascal A. <pa...@ro...> - 2008-09-09 13:55:40
|
Hi,
Having experienced some problems with Q3Initialize() and Q3Exit(), I
decided to create this simple test app:
int main(int argc, char *argv[])
{
TQ3Status quesaStatus = Q3Initialize();
quesaStatus = Q3Exit();
quesaStatus = Q3Initialize();
quesaStatus = Q3Exit();
return NSApplicationMain(argc, (const char **) argv);
}
The app crashes on the second Q3Initialize() with a EXC_BAD_ACCESS
error message. Here is the backtrace:
0x000d80ce in E3ClassInfo::GetMethod at E3ClassTree.c:1426
0x00024792 in E3XObjectClass_GetMethod at E3Extension.c:223
0x0009a9c3 in Q3XObjectClass_GetMethod at QD3DExtension.c:202
0x000dc951 in GetParentRendererMethod at CartoonRenderer.cpp:957
0x000dc9f7 in ca_cartoon_metahandler at CartoonRenderer.cpp:1199
0x000d9204 in E3ClassTree::RegisterClass at E3ClassTree.c:518
0x000d94e9 in E3ClassTree::RegisterExternalClass at E3ClassTree.c:480
0x0004c7d0 in EiObjectHierarchy_RegisterClassByType at
E3Compatibility.c:436
0x000b1a4c in E3System_LoadPlugins at E3System.c:160
0x000bc441 in E3Initialize at E3Main.c:679
0x0005d574 in Q3Initialize at QD3DMain.c:101
0x00002913 in main at main.mm:24
Thanks
Pascal
|
|
From: James W. <ja...@fr...> - 2008-09-09 17:27:31
|
Pascal Augustin wrote:
> Having experienced some problems with Q3Initialize() and Q3Exit(), I
> decided to create this simple test app:
>
> int main(int argc, char *argv[])
> {
> TQ3Status quesaStatus = Q3Initialize();
> quesaStatus = Q3Exit();
> quesaStatus = Q3Initialize();
> quesaStatus = Q3Exit();
>
>
>
> return NSApplicationMain(argc, (const char **) argv);
> }
>
> The app crashes on the second Q3Initialize() with a EXC_BAD_ACCESS error
> message . Here is the backtrace:
I have checked in changes to CartoonRenderer.cpp and HiddenLine.cpp that
should fix this problem.
I suppose that the most common usage is to call Q3Initialize once at
startup and call Q3Exit at shutdown, so this bug would not be encountered.
--
James W. Walker, Innoventive Software LLC
<http://www.frameforge3d.com/>
|
|
From: Joe S. <jo...@st...> - 2008-09-09 17:31:50
|
On Sep 9, 2008, at 11:27 AM, James Walker wrote: > I have checked in changes to CartoonRenderer.cpp and HiddenLine.cpp > that > should fix this problem. > > I suppose that the most common usage is to call Q3Initialize once at > startup and call Q3Exit at shutdown, so this bug would not be > encountered. But, just to put in my $0.02, REALbasic apps generally initialize and exit Quesa repeatedly (that's just sort of the way the architecture works out -- the graphics code doesn't have a good way to know when the app is starting up or shutting down, so it just reference-counts the users and inits and exits when that count switches between 0 and 1). I've probably never run into this only because I haven't used the Cartoon Renderer yet. Thanks, - Joe -- Joe Strout jo...@st... Obama answers the top 14 science questions facing America: http://www.sciencedebate2008.com/www/index.php?id=40 |
|
From: Roger H. <rog...@mi...> - 2008-09-16 07:31:31
|
I have had a problem with a corrupt 3DMF file which draws OK and seems fine until I do some complicated manipulations on it where my code gets everything which is not already a TriMesh into a TriMesh (or Triangle) and calls Q3TriMesh_GetData on all the objects. Part of what this gives me is an edge list which contains pairs of triangle indices. The problem came when I got a triangle index of 86 and there were only 11 triangles in the triangle list. This caused my program to crash. I am now filtering the data I get back from Q3TriMesh_GetData and every index which is invalid gets set to 0xFFFFFFFF which means the edge has no triangle on that side. So others don't have to spend two days debugging, would it be worth adding this extra processing to Q3TriMesh_GetData itself, or where we read the trimeshes in from the 3DMF? Roger Holmes. |
|
From: James W. <ja...@fr...> - 2008-09-16 10:24:14
|
Roger Holmes wrote: > I have had a problem with a corrupt 3DMF file which draws OK and seems > fine until I do some complicated manipulations on it where my code > gets everything which is not already a TriMesh into a TriMesh (or > Triangle) and calls Q3TriMesh_GetData on all the objects. Part of what > this gives me is an edge list which contains pairs of triangle > indices. The problem came when I got a triangle index of 86 and there > were only 11 triangles in the triangle list. This caused my program to > crash. > > I am now filtering the data I get back from Q3TriMesh_GetData and > every index which is invalid gets set to 0xFFFFFFFF which means the > edge has no triangle on that side. > > So others don't have to spend two days debugging, would it be worth > adding this extra processing to Q3TriMesh_GetData itself, or where we > read the trimeshes in from the 3DMF? What about doing the sanity check in e3geom_trimesh_new, so it would cover TriMeshes created by means other than reading 3DMF? -- James W. Walker, Innoventive Software LLC <http://www.frameforge3d.com/> |
|
From: Roger H. <rog...@mi...> - 2008-09-16 10:49:33
|
On 16 Sep, 2008, at 18:23, James Walker wrote: > Roger Holmes wrote: >> I have had a problem with a corrupt 3DMF file which draws OK and >> seems >> fine until I do some complicated manipulations on it where my code >> gets everything which is not already a TriMesh into a TriMesh (or >> Triangle) and calls Q3TriMesh_GetData on all the objects. Part of >> what >> this gives me is an edge list which contains pairs of triangle >> indices. The problem came when I got a triangle index of 86 and there >> were only 11 triangles in the triangle list. This caused my program >> to >> crash. >> >> I am now filtering the data I get back from Q3TriMesh_GetData and >> every index which is invalid gets set to 0xFFFFFFFF which means the >> edge has no triangle on that side. >> >> So others don't have to spend two days debugging, would it be worth >> adding this extra processing to Q3TriMesh_GetData itself, or where we >> read the trimeshes in from the 3DMF? > > What about doing the sanity check in e3geom_trimesh_new, so it would > cover TriMeshes created by means other than reading 3DMF? > -- > James W. Walker, Innoventive Software LLC > <http://www.frameforge3d.com/> Yes that would be better. Am I right in thinking there is no way for an application to change a TriMesh after e3geom_trimesh_new creates it, other than recreating it totally. I know the main attribute set might be shared with other things but that is all that can get changed "when you're not looking" I think. Roger Holmes. |
|
From: James W. <ja...@fr...> - 2008-09-16 11:43:16
|
Roger Holmes wrote: > On 16 Sep, 2008, at 18:23, James Walker wrote: > >> What about doing the sanity check in e3geom_trimesh_new, so it would >> cover TriMeshes created by means other than reading 3DMF? > > Yes that would be better. Am I right in thinking there is no way for > an application to change a TriMesh after e3geom_trimesh_new creates > it, other than recreating it totally. I know the main attribute set > might be shared with other things but that is all that can get changed > "when you're not looking" I think. It is also possible for the application to change the TriMesh using Q3TriMesh_SetData or Q3TriMesh_LockData. The function e3geom_trimesh_optimize is called in 3 places: e3geom_trimesh_new, E3TriMesh_SetData, and E3TriMesh_UnlockData (in the read-write case), so that might be a reasonable place to fix bogus edges. Or else have a separate validation function that is called just before e3geom_trimesh_optimize in each place. While we're at it, it might make sense to sanity-check the point indices of faces and edges, but in those cases there is not a reasonable way to fix a problem, so the validation function should probably be able to cause a kQ3Failure result. -- James W. Walker, Innoventive Software LLC <http://www.frameforge3d.com/> |
|
From: Roger H. <rog...@mi...> - 2008-09-18 02:14:05
|
On 16 Sep, 2008, at 19:43, James Walker wrote: > Roger Holmes wrote: >> On 16 Sep, 2008, at 18:23, James Walker wrote: >> >>> What about doing the sanity check in e3geom_trimesh_new, so it would >>> cover TriMeshes created by means other than reading 3DMF? >> >> Yes that would be better. Am I right in thinking there is no way for >> an application to change a TriMesh after e3geom_trimesh_new creates >> it, other than recreating it totally. I know the main attribute set >> might be shared with other things but that is all that can get >> changed >> "when you're not looking" I think. > > It is also possible for the application to change the TriMesh using > Q3TriMesh_SetData or Q3TriMesh_LockData. OK > > > The function e3geom_trimesh_optimize is called in 3 places: > e3geom_trimesh_new, E3TriMesh_SetData, and E3TriMesh_UnlockData (in > the > read-write case), so that might be a reasonable place to fix bogus > edges. Or else have a separate validation function that is called > just > before e3geom_trimesh_optimize in each place. Yes that sounds better, we might want to call either routine separately one day and it keeps the names more meaningful. > > > While we're at it, it might make sense to sanity-check the point > indices > of faces and edges, but in those cases there is not a reasonable way > to > fix a problem, so the validation function should probably be able to > cause a kQ3Failure result. > I suggest we return kQ3Failure and also set the faulty indexes to zero. I know that will give strange looking data, but I think that is better than crashing. Anyway, an application should see the kQ3Failure and deal with it some other way, it is only apps which plough on regardless which will actually display the faulty data. In a way it is a shame there is not a third alternative to kQ3Failure and kQ3Success, something like a warning which we could return in the case of an edge which we have made safe. Roger Holmes. |
|
From: James W. W. <os...@jw...> - 2008-09-18 09:42:47
Attachments:
smime.p7s
|
On Sep 18, 2008, at 2:13 AM, Roger Holmes wrote: > I suggest we return kQ3Failure and also set the faulty indexes to > zero. I know that will give strange looking data, but I think that is > better than crashing. Anyway, an application should see the kQ3Failure > and deal with it some other way, it is only apps which plough on > regardless which will actually display the faulty data. > > In a way it is a shame there is not a third alternative to kQ3Failure > and kQ3Success, something like a warning which we could return in the > case of an edge which we have made safe. The validation function could post a warning (via the error manager) in the case of face indices of edges, and post an error in the case of point indices of edges and faces. |
|
From: Roger H. <rog...@mi...> - 2008-09-18 10:32:09
|
On 18 Sep, 2008, at 17:42, James W. Walker wrote: > > On Sep 18, 2008, at 2:13 AM, Roger Holmes wrote: > >> I suggest we return kQ3Failure and also set the faulty indexes to >> zero. I know that will give strange looking data, but I think that is >> better than crashing. Anyway, an application should see the >> kQ3Failure >> and deal with it some other way, it is only apps which plough on >> regardless which will actually display the faulty data. >> >> In a way it is a shame there is not a third alternative to kQ3Failure >> and kQ3Success, something like a warning which we could return in the >> case of an edge which we have made safe. > > The validation function could post a warning (via the error manager) > in the case of face indices of edges, and post an error in the case > of point indices of edges and faces. > Good idea. Roger. |
|
From: James W. <ja...@fr...> - 2008-09-23 18:15:23
|
I've checked in the validation code we discussed. -- James W. Walker, Innoventive Software LLC <http://www.frameforge3d.com/> |
|
From: Roger H. <rog...@mi...> - 2008-09-24 10:31:52
|
On 23 Sep, 2008, at 18:54, James Walker wrote: > I've checked in the validation code we discussed. > Excellent, thank you. Roger. |
|
From: James W. W. <os...@jw...> - 2008-09-24 19:20:48
Attachments:
smime.p7s
|
On Sep 24, 2008, at 1:50 AM, Roger Holmes wrote: > > On 23 Sep, 2008, at 18:54, James Walker wrote: > >> I've checked in the validation code we discussed. >> > Excellent, thank you. You're welcome. SourceForge is currently having problems with some mailing lists, so my changes have not shown up in the quesa-cvs list. The relevant changes were to QuesaErrors.h and E3GeometryTriMesh.c. I also made an unrelated documentation change in Quesa.h. |