quesa-develop — Mailing list for Quesa development

Re: Quesa patch for partial 64 bit support on Mac OS X

[James W. W. <os...@jw...>]

OK, I've done some testing with the 64-bit patch.  My first comment is  
that I'm not sure if I like the symbol QUESA_SUPPORT_QUICKDRAW, since  
a Carbon app using Quesa does not necessarily use QuickDraw to any  
significant degree.  Maybe QUESA_SUPPORT_HITOOLBOX or QUESA_SUPPORT_AGL.

When building for 64 bit, I removed the following sources from the  
target:

QD3DViewer.c
E3Viewer.c
E3ViewerOldAPIs.c
E3MacDrawContext.c
Quesa.rsrc (I think this is only needed for the viewer?)

In QD3DDrawContext.c, I placed the Q3MacDrawContext_ functions under  
the condition #if QUESA_OS_MACINTOSH & QUESA_SUPPORT_QUICKDRAW.

In E3Main.c, I added the QUESA_SUPPORT_QUICKDRAW condition to the  
E3Viewer_RegisterClass and E3Viewer_UnregisterClass calls.

In E3MacSystem.c, in E3MacSystem_Terminate, I surrounded the  
aglResetLibrary stuff by #if QUESA_SUPPORT_QUICKDRAW.

In E3DrawContext.c, I put QUESA_SUPPORT_QUICKDRAW conditions on the  
calls to E3MacDrawContext_RegisterClass,  
E3MacDrawContext_UnregisterClass, and E3MacDrawContext_NewWithWindow.

With these changes, and using the 10.5 SDK, the framework compiles and  
links as x86_64.  Then I built the Cocoa sample as 64 bit, and it  
runs!  Activity Monitor shows that it is indeed running as Intel 64 bit.

Re: Quesa patch for partial 64 bit support on Mac OS X

[James W. <ja...@fr...>]

Sean McBride wrote:


> So to clarify further... the patch file is just text, and was created like so:
> 
> cvs diff -u > patch.txt
> 
> and you can apply it to a fresh cvs checkout like so:
> 
> cd /path/to/quesa
> patch -p0 <patch.txt


OK, that helps.


> I look forward to you trying it, so we can discuss the remaining harder
> to fix problems. :)


Maybe I can do it on the weekend.  I can't really justify spending time 
on it at work, since we have no plans to leave the Carbon world.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: Quesa patch for partial 64 bit support on Mac OS X

[Sean M. <se...@ro...>]

On 8/15/08 2:04 PM, James Walker said:

>> Attached is a patch that fixes almost all compilation issues.  Could
>> someone review it?
>
>Pardon my ignorance, but what is a patch file, i.e., what programs use 
>.patch files?

So to clarify further... the patch file is just text, and was created like so:

cvs diff -u > patch.txt

and you can apply it to a fresh cvs checkout like so:

cd /path/to/quesa
patch -p0 <patch.txt

I look forward to you trying it, so we can discuss the remaining harder
to fix problems. :)

Cheers,

-- 
____________________________________________________________
Sean McBride, B. Eng                 se...@ro...
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montréal, Québec, Canada

Re: Quesa patch for partial 64 bit support on Mac OS X

[Sean M. <se...@ro...>]

On 8/16/08 10:07 AM, Roger Holmes said:

>> b) Added a QUESA_SUPPORT_QUICKDRAW that is analogous to
>> QUESA_SUPPORT_QUICKTIME.  It must be 0 in 64 bit since QuickDraw/
>> HIToolbox is gone.  Changed some QUESA_OS_MACINTOSH to
>> QUESA_SUPPORT_QUICKDRAW.
>
>Is all the QuickDraw usage in the viewer code? If so, I'm not  
>currently using it either.

Use of QUESA_SUPPORT_QUICKDRAW is in QD3DViewer.c, E3Viewer.c, and
GLDrawContext.c.

>> c) Removed FSSpec usage in 64 bit.
>
>Not replaced? Have you disabled file I/O temporarily?

There seem to already be FSRef versions, happily.

>Please explain how you get around the compiler errors in 64 bit mode.

The errors that remain after our patch we simply commented out. :) 
Luckily, none of the code was needed in our case.  It's just one file:
E3MacDrawContext.c.

-- 
____________________________________________________________
Sean McBride, B. Eng                 se...@ro...
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montréal, Québec, Canada

Re: Quesa patch for partial 64 bit support on Mac OS X

[Sean M. <se...@ro...>]

On 8/15/08 2:04 PM, James Walker said:

>> So we've just downloaded Quesa CVS and tried to build it as 64 bit.  Not
>> sure if we're the first to try... it doesn't compile.  :)
>> 
>> Attached is a patch that fixes almost all compilation issues.  Could
>> someone review it?
>
>Pardon my ignorance, but what is a patch file, i.e., what programs use 
>.patch files?

On Mac OS X type 'man patch' in Terminal...  If you'd prefer, I could
always send you my entire modified Quesa directory, but it would be too
big for the list, I'm sure.

-- 
____________________________________________________________
Sean McBride, B. Eng                 se...@ro...
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montréal, Québec, Canada

Re: Quesa patch for partial 64 bit support on Mac OS X

[Roger H. <rog...@mi...>]

On 15 Aug, 2008, at 21:04, Sean McBride wrote:

> Hi all,
>
> So we've just downloaded Quesa CVS and tried to build it as 64  
> bit.  Not
> sure if we're the first to try...

Yes I think you are. I have thought about it and concluded it was  
doable but I didn't have the time to do it then.

> it doesn't compile.  :)

You thought it would? :-)

>
> Attached is a patch that fixes almost all compilation issues.  Could
> someone review it?

I know our tech support guy generates patch files so that users can  
update our products with minimal download time. I'll ask him to see  
if we can use your file with out program.
>

> Most changes are pretty straightforward.  Some comments:
>
> a) QUESA_SUPPORT_QUICKTIME is forced to 0 in 64 bit.
>
> b) Added a QUESA_SUPPORT_QUICKDRAW that is analogous to
> QUESA_SUPPORT_QUICKTIME.  It must be 0 in 64 bit since QuickDraw/
> HIToolbox is gone.  Changed some QUESA_OS_MACINTOSH to
> QUESA_SUPPORT_QUICKDRAW.

Is all the QuickDraw usage in the viewer code? If so, I'm not  
currently using it either.

>
> c) Removed FSSpec usage in 64 bit.

Not replaced? Have you disabled file I/O temporarily?

>
> d) various casts, tweaks, etc.
>
> Note that I have only compiled this on Mac OS X, no other platforms.

Personally that's all I want anyway. It could be that with the other  
platforms, 64 bit is not such an issue.

>
> Note that even with this patch, there are still compiler errors in 64
> bit (but not in 32 bit).  The remaining errors I am not comfortable
> fixing because it requires a better knowledge of Quesa than I have.  I
> thought I'd start with this patch before discussing remaining  
> problems....

Oh, I see.

>
> Lastly, I realise that removing the QuickDraw/HIToolbox usage in Quesa
> means that it will be missing major functionality.

It's a fair chunk of code, but I think it was all platform dependant.  
Maybe we need a new platform in Quesa for Mac OS-X 64 bit. It could  
use Cocoa and Objective C++ for the user interface.

> In our case however,
> we only need a small subset of Quesa and are happy to report that that
> subset runs just fine in x86_64!

Please explain how you get around the compiler errors in 64 bit mode.

There is another future problem to be addressed one day. It fine  
having 64 bit code, but the Quesa file structure uses 32 bit offsets,  
in fact everything including booleans are 32 bits. I am very happy to  
stay with 32 bit floating point values internally but I wonder if we  
should define a new file type, maybe .Q64 or .3DMF64 is Windoze  
allows more than 3 characters now. In the new file type everything  
would be 64 bits, even the floating point values, which would get  
converted to 32 bit floats when the file was read, until such time as  
64 bit floating point gets (almost) as quick as 32 bit. I suppose  
someone is now going to tell me it is already, well I have not  
checked the specs, I'm just assuming and if I'm wrong then thats  
great and I can go and change the another product's source code.

Well done Sean for being the first of us to put his head above the  
64bit parapet.

Roger

>
> Cheers,
>
> --
> ____________________________________________________________
> Sean McBride, B. Eng                 se...@ro...
> Rogue Research                        www.rogue-research.com
> Mac Software Developer              Montréal, Québec,  
> Canada<quesa_64.patch>------------------------------------------------ 
> -------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/ 
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop

Re: Quesa patch for partial 64 bit support on Mac OS X

[James W. <ja...@fr...>]

Sean McBride wrote:

> So we've just downloaded Quesa CVS and tried to build it as 64 bit.  Not
> sure if we're the first to try... it doesn't compile.  :)
> 
> Attached is a patch that fixes almost all compilation issues.  Could
> someone review it?

Pardon my ignorance, but what is a patch file, i.e., what programs use 
.patch files?
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Quesa patch for partial 64 bit support on Mac OS X

[Sean M. <se...@ro...>]

Hi all,

So we've just downloaded Quesa CVS and tried to build it as 64 bit.  Not
sure if we're the first to try... it doesn't compile.  :)

Attached is a patch that fixes almost all compilation issues.  Could
someone review it?

Most changes are pretty straightforward.  Some comments:

a) QUESA_SUPPORT_QUICKTIME is forced to 0 in 64 bit.

b) Added a QUESA_SUPPORT_QUICKDRAW that is analogous to
QUESA_SUPPORT_QUICKTIME.  It must be 0 in 64 bit since QuickDraw/
HIToolbox is gone.  Changed some QUESA_OS_MACINTOSH to
QUESA_SUPPORT_QUICKDRAW.

c) Removed FSSpec usage in 64 bit.

d) various casts, tweaks, etc.

Note that I have only compiled this on Mac OS X, no other platforms.

Note that even with this patch, there are still compiler errors in 64
bit (but not in 32 bit).  The remaining errors I am not comfortable
fixing because it requires a better knowledge of Quesa than I have.  I
thought I'd start with this patch before discussing remaining problems....

Lastly, I realise that removing the QuickDraw/HIToolbox usage in Quesa
means that it will be missing major functionality.  In our case however,
we only need a small subset of Quesa and are happy to report that that
subset runs just fine in x86_64!

Cheers,

-- 
____________________________________________________________
Sean McBride, B. Eng                 se...@ro...
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montréal, Québec, Canada

Re: kQ3ErrorInfiniteRationalPoint

[James W. <ja...@fr...>]

Edward K. Chew wrote:
> I have been getting reports from users of a -28376 error  
> (kQ3ErrorInfiniteRationalPoint) appearing when they click in a view.   
> I have not been able to reproduce this so far, but I have been looking  
> closely at my picking code.  There doesn't seem to be anything amiss  
> with the coordinates going into the window point pick, so that  
> suggests a geometry object in one of the display groups is acting up.
> 
> Would I see that error if I were unlucky enough to click on a  
> polygonal element edge on, so that it is oriented exactly  
> perpendicular to the plane of view?  I'm just trying to narrow down  
> the possibilities here.  In the event of such an error, would the pick  
> simply not report any hits?  That would be good.  I could simply  
> ignore the error in that case.  :)

Assuming you are not explicitly using rational points, 
kQ3ErrorInfiniteRationalPoint is most likely to be caused by 
transforming a 3D point by a 4x4 matrix.  Furthermore, the matrix would 
need to be not a rigid motion -- for instance not a local-to-world 
matrix, but maybe window-to-world or world-to-frustum or some such.  I 
don't see anything like that in E3Ray3D_IntersectTriangle or 
E3Triangle_InterpolateHit, the key low-level routines used in picking.

You could change your program so that it crashes when it receives 
kQ3ErrorInfiniteRationalPoint, and then the users could send you crash 
logs. :-)
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

kQ3ErrorInfiniteRationalPoint

[Edward K. C. <ek...@lg...>]

I have been getting reports from users of a -28376 error  
(kQ3ErrorInfiniteRationalPoint) appearing when they click in a view.   
I have not been able to reproduce this so far, but I have been looking  
closely at my picking code.  There doesn't seem to be anything amiss  
with the coordinates going into the window point pick, so that  
suggests a geometry object in one of the display groups is acting up.

Would I see that error if I were unlucky enough to click on a  
polygonal element edge on, so that it is oriented exactly  
perpendicular to the plane of view?  I'm just trying to narrow down  
the possibilities here.  In the event of such an error, would the pick  
simply not report any hits?  That would be good.  I could simply  
ignore the error in that case.  :)

-Ted

Re: Texture shaders have scope problem?

[James W. W. <os...@jw...>]

On May 19, 2008, at 5:18 AM, Roger Holmes wrote:

>
> On 17 May, 2008, at 21:42, James W. Walker wrote:
>
>> It is just TriGrids.  In fact a textured TriGrid gets cached as a
>> group of triangles, not a TriMesh, and the problem was that it was an
>> inline group.  I've checked in a fix.
>
>
> I just realised something. Does this mean that if I have two triangle
> objects in an ordinary group, the first with a texture and the second
> without, that the same problem occurs? Maybe for a group generated
> from a TriGrid, the texture is loose in the group before the  
> triangles?

If I recall correctly, the texture shader is in an attribute set in  
the group before the triangles.

Re: Texture shaders have scope problem?

[Roger H. <rog...@mi...>]

On 17 May, 2008, at 21:42, James W. Walker wrote:

> It is just TriGrids.  In fact a textured TriGrid gets cached as a
> group of triangles, not a TriMesh, and the problem was that it was an
> inline group.  I've checked in a fix.


I just realised something. Does this mean that if I have two triangle  
objects in an ordinary group, the first with a texture and the second  
without, that the same problem occurs? Maybe for a group generated  
from a TriGrid, the texture is loose in the group before the triangles?
  

Re: Texture shaders have scope problem?

[Roger H. <rog...@mi...>]

>
>> It goes wrong with at least three renderers, so I think the problem
>> is in Quesa's handling of the graphics state outside the sending of
>> data to the renderer. I suspect it is not just Tri-grids, though it
>> could be when the Tri-grids get converted to Tri-meshes.
>
> It is just TriGrids.  In fact a textured TriGrid gets cached as a
> group of triangles, not a TriMesh, and the problem was that it was an
> inline group.  I've checked in a fix.

Wonderful. Thank you.

Roger.

Re: Texture shaders have scope problem?

[James W. W. <os...@jw...>]

On May 16, 2008, at 12:04 PM, Roger Holmes wrote:

> It goes wrong with at least three renderers, so I think the problem
> is in Quesa's handling of the graphics state outside the sending of
> data to the renderer. I suspect it is not just Tri-grids, though it
> could be when the Tri-grids get converted to Tri-meshes.

It is just TriGrids.  In fact a textured TriGrid gets cached as a  
group of triangles, not a TriMesh, and the problem was that it was an  
inline group.  I've checked in a fix.

Re: Apply Mutating Algorithms

[James W. W. <os...@jw...>]

I checked in another modification to MergeTriMeshList.cpp.  Let me  
know if you get any more errors.

Re: Texture shaders have scope problem?

[Roger H. <rog...@mi...>]

On 16 May, 2008, at 17:28, James W. Walker wrote:

>
> On May 16, 2008, at 8:09 AM, Roger Holmes wrote:
>
>> I have not checked out for about a year (and do not want to), so
>> maybe this has been fixed.
>>
>> I have two trigrids, one with a texture shader in is attribute set
>> and the second one without. If I put them in a group I get the
>> texture shader of the first displayed on the second one. If I put
>> them both in their own display group this does not happen. If I make
>> the groups 'inline' the problem comes back.
>>
>> Should Quesa save the graphic state, or at least the texture state,
>> around each object in a group? Is there some resetting code missing?
>> Am I just out of date?
>
> That does sound like a bug, but I don't know whether it may have been
> fixed.  I haven't seen it.  Does it matter which renderer you use?

It goes wrong with at least three renderers, so I think the problem  
is in Quesa's handling of the graphics state outside the sending of  
data to the renderer. I suspect it is not just Tri-grids, though it  
could be when the Tri-grids get converted to Tri-meshes.

Re: Texture shaders have scope problem?

[James W. W. <os...@jw...>]

On May 16, 2008, at 8:09 AM, Roger Holmes wrote:

> I have not checked out for about a year (and do not want to), so
> maybe this has been fixed.
>
> I have two trigrids, one with a texture shader in is attribute set
> and the second one without. If I put them in a group I get the
> texture shader of the first displayed on the second one. If I put
> them both in their own display group this does not happen. If I make
> the groups 'inline' the problem comes back.
>
> Should Quesa save the graphic state, or at least the texture state,
> around each object in a group? Is there some resetting code missing?
> Am I just out of date?

That does sound like a bug, but I don't know whether it may have been  
fixed.  I haven't seen it.  Does it matter which renderer you use?

Texture shaders have scope problem?

[Roger H. <rog...@mi...>]

I have not checked out for about a year (and do not want to), so  
maybe this has been fixed.

I have two trigrids, one with a texture shader in is attribute set  
and the second one without. If I put them in a group I get the  
texture shader of the first displayed on the second one. If I put  
them both in their own display group this does not happen. If I make  
the groups 'inline' the problem comes back.

Should Quesa save the graphic state, or at least the texture state,  
around each object in a group? Is there some resetting code missing?  
Am I just out of date?

Roger

Re: Apply Mutating Algorithms

[Daniele C. <dca...@in...>]

Error message is "vector subscript out of range" if  mergedEdges.size() 
is zero I write

TQ3TriMeshEdgeData    *pEdge=NULL;

pEdge=&mergedEdges[0]; <---------------- ERROR 


So I made the little modify. I don' t find other solution.





James Walker wrote:

> Daniele Cavallini wrote:
>
>   
>> I made a little modify  ad the function: MergeTriMeshList
>> I think it is necessary initialize mergedEdges to NULL but I don't found 
>> like do it.
>>     
>
> Did you get an error message about this?  I don't know what you mean by 
> "I don't found like do it".
>
>
>   
>>  
>> .....
>>
>> TQ3TriMeshEdgeData                                  *pEdge;
>>     int dimEdge=mergedEdges.size();
>>     if (dimEdge>0)
>>         pEdge=&mergedEdges[0];
>>     else
>>         pEdge=NULL;
>>
>>     TQ3TriMeshData    mergedData = {
>>         overallAtts.get(),
>>         mergedFaces.size(),
>>         &mergedFaces[0],
>>         (mergedFaceNormals.size() == mergedFaces.size()? 1 : 0),
>>         &faceAtt,
>>         mergedEdges.size(),
>>         pEdge,
>>         0,
>>         NULL,
>>         mergedPoints.size(),
>>         &mergedPoints[0],
>>         vertAtts.size(),
>>         &vertAtts[0],
>>         theBounds
>>     };
>>     
>
>
>   

Re: Apply Mutating Algorithms

[James W. <ja...@fr...>]

Daniele Cavallini wrote:

> I made a little modify  ad the function: MergeTriMeshList
> I think it is necessary initialize mergedEdges to NULL but I don't found 
> like do it.

Did you get an error message about this?  I don't know what you mean by 
"I don't found like do it".


>  
> .....
> 
> TQ3TriMeshEdgeData                                  *pEdge;
>     int dimEdge=mergedEdges.size();
>     if (dimEdge>0)
>         pEdge=&mergedEdges[0];
>     else
>         pEdge=NULL;
> 
>     TQ3TriMeshData    mergedData = {
>         overallAtts.get(),
>         mergedFaces.size(),
>         &mergedFaces[0],
>         (mergedFaceNormals.size() == mergedFaces.size()? 1 : 0),
>         &faceAtt,
>         mergedEdges.size(),
>         pEdge,
>         0,
>         NULL,
>         mergedPoints.size(),
>         &mergedPoints[0],
>         vertAtts.size(),
>         &vertAtts[0],
>         theBounds
>     };


-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: Apply Mutating Algorithms

[Daniele C. <dca...@in...>]

I made a little modify  ad the function: MergeTriMeshList
I think it is necessary initialize mergedEdges to NULL but I don't found 
like do it.
 
.....

TQ3TriMeshEdgeData                                  *pEdge;
    int dimEdge=mergedEdges.size();
    if (dimEdge>0)
        pEdge=&mergedEdges[0];
    else
        pEdge=NULL;

    TQ3TriMeshData    mergedData = {
        overallAtts.get(),
        mergedFaces.size(),
        &mergedFaces[0],
        (mergedFaceNormals.size() == mergedFaces.size()? 1 : 0),
        &faceAtt,
        mergedEdges.size(),
        pEdge,
        0,
        NULL,
        mergedPoints.size(),
        &mergedPoints[0],
        vertAtts.size(),
        &vertAtts[0],
        theBounds
    };



James Walker ha scritto:
> Daniele Cavallini wrote:
>
>   
>> The error prompt is:
>>  Expression: vector subscript out the range
>> The problem is when there is a trimesh and edges are not definite.
>> I modify function MergeTrimeshList , I add
>> if(tmData.edges>0)
>>     AppendArrayToVec(... ... ...)
>>
>> It seem work fine.
>>     
>
> Thanks.  I have committed a slightly different fix, which does the check 
> inside AppendArrayToVec.
>
>   

Re: Apply Mutating Algorithms

[James W. <ja...@fr...>]

Daniele Cavallini wrote:

> The error prompt is:
>  Expression: vector subscript out the range
> The problem is when there is a trimesh and edges are not definite.
> I modify function MergeTrimeshList , I add
> if(tmData.edges>0)
>     AppendArrayToVec(... ... ...)
> 
> It seem work fine.

Thanks.  I have committed a slightly different fix, which does the check 
inside AppendArrayToVec.

-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: Apply Mutating Algorithms

[Daniele C. <dca...@in...>]

The error prompt is:
 Expression: vector subscript out the range
The problem is when there is a trimesh and edges are not definite.
I modify function MergeTrimeshList , I add
if(tmData.edges>0)
    AppendArrayToVec(... ... ...)

It seem work fine.



James Walker ha scritto:
> Daniele Cavallini wrote:
>   
>> At last I installed Visual studio 8 into my Computer.
>> So I can utilize Mutating Algorithms. With mac I increase very much 
>> performance.
>> I use the function doLoadModel modified like below but I have an error 
>> when I call MergeTriMeshes function.
>> An example of file is at
>> www.interstudio.net/quesa/Roof.3DMF
>> Have you some idea?
>>     
>
> Please be more specific about the error.  What was the error message?
>
>   
>> //=============================================================================
>> //      doLoadModel : Loads a Model from File
>> //-----------------------------------------------------------------------------
>> static TQ3Object
>> doLoadModel(TQ3ViewObject theView)
>> {
>> TQ3StorageObject    storageObj;
>>     TQ3Object             notOptimizedModel,theModel;
>>     float                xBounds, yBounds, zBounds, scaleFactor;
>>     TQ3BoundingBox        theBounds;
>>     TQ3Vector3D            translateToOrigin = { 0.0f, 0.0f, 0.0f };
>>     TQ3Matrix4x4        translateMatrix;
>>     TQ3Matrix4x4        scaleMatrix;
>>     TextureImporterProcPtr    funcPtr = TextureImportCallback;
>>     TQ3BoundingBox dummyBounds;
>>     // Get the file
>>     storageObj = Qut_SelectMetafileToOpen();
>>     if( storageObj == NULL )
>>         return NULL;
>>     
>>
>>     // Attach texture import callback in case this is VRML.
>> #if !TARGET_API_MAC_OS8
>>     Q3Object_SetProperty( storageObj, kTextureImportCallbackPropertyType,
>>         sizeof(TextureImporterProcPtr), &funcPtr );
>> #endif
>>
>>
>>     // Read the file (note, this disposes of storageObj)
>>     notOptimizedModel = Qut_ReadModel(storageObj);
>>         
>>     
>>     // Adjust the scale and translation required for the model
>>     //
>>     // Qut positions the camera 5 units away from the origin, with a 
>> hither-yon
>>     // distance of ~10 units. By scaling the object to be 3.75f units 
>> across,
>>     // we obtain something which fits within the visible range of the 
>> camera.
>>     if(notOptimizedModel)
>>         {
>> //        theModel=optmizeModel(notOptimizedModel,theView);
>> TQ3Status            stato;
>> TQ3ViewStatus        viewStatus;
>> TQ3BoundingBox dummyBounds;
>>
>>     RemoveExtraReferences(notOptimizedModel);
>>
>>     stato=Q3View_StartBoundingBox( theView, kQ3ComputeBoundsApproximate );
>>     Qut_SubmitDefaultState(theView);
>>     DecomposeGeometries( notOptimizedModel, theView );
>>     
>>     viewStatus=Q3View_EndBoundingBox( theView, &dummyBounds );
>>
>> if(stato==kQ3Success)
>>                 do
>>                     {
>>                     
>>                     Q3Object_Submit(notOptimizedModel,theView);
>>                     
>>                     DecomposeGeometries( notOptimizedModel, theView );
>>                     viewStatus=Q3View_EndBoundingBox( theView, 
>> &dummyBounds);
>>                     }//do
>>                 while (viewStatus==kQ3ViewStatusRetraverse);
>>     
>>     
>>     
>>     LowerAttributesToGeometries( notOptimizedModel);
>> //TQ3GroupObject oldgroup=notOptimizedModel;
>>
>>     theModel=(TQ3GroupObject) FlattenHierarchy(notOptimizedModel,0 );
>> //Q3Object_Dispose(oldgroup);
>>
>>     OptimizeTriMeshes(theModel);
>>     MergeTriMeshes( theModel);
>>
>>         Qut_CalcBounds(theView, theModel, &theBounds);
>>         xBounds = (theBounds.max.x - theBounds.min.x);
>>         yBounds = (theBounds.max.y - theBounds.min.y);
>>         zBounds = (theBounds.max.z - theBounds.min.z);
>>
>>         scaleFactor = (xBounds > yBounds)     ? xBounds : yBounds;
>>         scaleFactor = (zBounds > scaleFactor) ? zBounds : scaleFactor;
>>         scaleFactor = 3.75f / scaleFactor;
>>
>>         translateToOrigin.x = -(theBounds.min.x + (xBounds * 0.5f));
>>         translateToOrigin.y = -(theBounds.min.y + (yBounds * 0.5f));
>>         translateToOrigin.z = -(theBounds.min.z + (zBounds * 0.5f));
>>
>>         
>> Q3Matrix4x4_SetTranslate(&translateMatrix,translateToOrigin.x,translateToOrigin.y,translateToOrigin.z);
>>         
>> Q3Matrix4x4_SetScale(&scaleMatrix,scaleFactor,scaleFactor,scaleFactor);
>>         
>>         Q3Matrix4x4_SetIdentity(&gMatrixCurrent);
>>         
>>        
>>  Q3Matrix4x4_Multiply(&gMatrixCurrent,&translateMatrix,&gMatrixCurrent);
>>         Q3Matrix4x4_Multiply(&gMatrixCurrent,&scaleMatrix,&gMatrixCurrent);
>>
>>         }
>>     return theModel;
>>
>>
>> }
>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
>> Don't miss this year's exciting event. There's still time to save $100. 
>> Use priority code J8TL2D2. 
>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>> _______________________________________________
>> Quesa-develop mailing list
>> Que...@li...
>> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>>
>>     
>
>
>   

Re: Apply Mutating Algorithms

[James W. <ja...@fr...>]

Daniele Cavallini wrote:
> At last I installed Visual studio 8 into my Computer.
> So I can utilize Mutating Algorithms. With mac I increase very much 
> performance.
> I use the function doLoadModel modified like below but I have an error 
> when I call MergeTriMeshes function.
> An example of file is at
> www.interstudio.net/quesa/Roof.3DMF
> Have you some idea?

Please be more specific about the error.  What was the error message?

> 
> //=============================================================================
> //      doLoadModel : Loads a Model from File
> //-----------------------------------------------------------------------------
> static TQ3Object
> doLoadModel(TQ3ViewObject theView)
> {
> TQ3StorageObject    storageObj;
>     TQ3Object             notOptimizedModel,theModel;
>     float                xBounds, yBounds, zBounds, scaleFactor;
>     TQ3BoundingBox        theBounds;
>     TQ3Vector3D            translateToOrigin = { 0.0f, 0.0f, 0.0f };
>     TQ3Matrix4x4        translateMatrix;
>     TQ3Matrix4x4        scaleMatrix;
>     TextureImporterProcPtr    funcPtr = TextureImportCallback;
>     TQ3BoundingBox dummyBounds;
>     // Get the file
>     storageObj = Qut_SelectMetafileToOpen();
>     if( storageObj == NULL )
>         return NULL;
>     
> 
>     // Attach texture import callback in case this is VRML.
> #if !TARGET_API_MAC_OS8
>     Q3Object_SetProperty( storageObj, kTextureImportCallbackPropertyType,
>         sizeof(TextureImporterProcPtr), &funcPtr );
> #endif
> 
> 
>     // Read the file (note, this disposes of storageObj)
>     notOptimizedModel = Qut_ReadModel(storageObj);
>         
>     
>     // Adjust the scale and translation required for the model
>     //
>     // Qut positions the camera 5 units away from the origin, with a 
> hither-yon
>     // distance of ~10 units. By scaling the object to be 3.75f units 
> across,
>     // we obtain something which fits within the visible range of the 
> camera.
>     if(notOptimizedModel)
>         {
> //        theModel=optmizeModel(notOptimizedModel,theView);
> TQ3Status            stato;
> TQ3ViewStatus        viewStatus;
> TQ3BoundingBox dummyBounds;
> 
>     RemoveExtraReferences(notOptimizedModel);
> 
>     stato=Q3View_StartBoundingBox( theView, kQ3ComputeBoundsApproximate );
>     Qut_SubmitDefaultState(theView);
>     DecomposeGeometries( notOptimizedModel, theView );
>     
>     viewStatus=Q3View_EndBoundingBox( theView, &dummyBounds );
> 
> if(stato==kQ3Success)
>                 do
>                     {
>                     
>                     Q3Object_Submit(notOptimizedModel,theView);
>                     
>                     DecomposeGeometries( notOptimizedModel, theView );
>                     viewStatus=Q3View_EndBoundingBox( theView, 
> &dummyBounds);
>                     }//do
>                 while (viewStatus==kQ3ViewStatusRetraverse);
>     
>     
>     
>     LowerAttributesToGeometries( notOptimizedModel);
> //TQ3GroupObject oldgroup=notOptimizedModel;
> 
>     theModel=(TQ3GroupObject) FlattenHierarchy(notOptimizedModel,0 );
> //Q3Object_Dispose(oldgroup);
> 
>     OptimizeTriMeshes(theModel);
>     MergeTriMeshes( theModel);
> 
>         Qut_CalcBounds(theView, theModel, &theBounds);
>         xBounds = (theBounds.max.x - theBounds.min.x);
>         yBounds = (theBounds.max.y - theBounds.min.y);
>         zBounds = (theBounds.max.z - theBounds.min.z);
> 
>         scaleFactor = (xBounds > yBounds)     ? xBounds : yBounds;
>         scaleFactor = (zBounds > scaleFactor) ? zBounds : scaleFactor;
>         scaleFactor = 3.75f / scaleFactor;
> 
>         translateToOrigin.x = -(theBounds.min.x + (xBounds * 0.5f));
>         translateToOrigin.y = -(theBounds.min.y + (yBounds * 0.5f));
>         translateToOrigin.z = -(theBounds.min.z + (zBounds * 0.5f));
> 
>         
> Q3Matrix4x4_SetTranslate(&translateMatrix,translateToOrigin.x,translateToOrigin.y,translateToOrigin.z);
>         
> Q3Matrix4x4_SetScale(&scaleMatrix,scaleFactor,scaleFactor,scaleFactor);
>         
>         Q3Matrix4x4_SetIdentity(&gMatrixCurrent);
>         
>        
>  Q3Matrix4x4_Multiply(&gMatrixCurrent,&translateMatrix,&gMatrixCurrent);
>         Q3Matrix4x4_Multiply(&gMatrixCurrent,&scaleMatrix,&gMatrixCurrent);
> 
>         }
>     return theModel;
> 
> 
> }
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save $100. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
> 


-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Apply Mutating Algorithms

[Daniele C. <dca...@in...>]

At last I installed Visual studio 8 into my Computer.
So I can utilize Mutating Algorithms. With mac I increase very much 
performance.
I use the function doLoadModel modified like below but I have an error 
when I call MergeTriMeshes function.
An example of file is at
www.interstudio.net/quesa/Roof.3DMF
Have you some idea?

//=============================================================================
//      doLoadModel : Loads a Model from File
//-----------------------------------------------------------------------------
static TQ3Object
doLoadModel(TQ3ViewObject theView)
{
TQ3StorageObject    storageObj;
    TQ3Object             notOptimizedModel,theModel;
    float                xBounds, yBounds, zBounds, scaleFactor;
    TQ3BoundingBox        theBounds;
    TQ3Vector3D            translateToOrigin = { 0.0f, 0.0f, 0.0f };
    TQ3Matrix4x4        translateMatrix;
    TQ3Matrix4x4        scaleMatrix;
    TextureImporterProcPtr    funcPtr = TextureImportCallback;
    TQ3BoundingBox dummyBounds;
    // Get the file
    storageObj = Qut_SelectMetafileToOpen();
    if( storageObj == NULL )
        return NULL;
    

    // Attach texture import callback in case this is VRML.
#if !TARGET_API_MAC_OS8
    Q3Object_SetProperty( storageObj, kTextureImportCallbackPropertyType,
        sizeof(TextureImporterProcPtr), &funcPtr );
#endif


    // Read the file (note, this disposes of storageObj)
    notOptimizedModel = Qut_ReadModel(storageObj);
        
    
    // Adjust the scale and translation required for the model
    //
    // Qut positions the camera 5 units away from the origin, with a 
hither-yon
    // distance of ~10 units. By scaling the object to be 3.75f units 
across,
    // we obtain something which fits within the visible range of the 
camera.
    if(notOptimizedModel)
        {
//        theModel=optmizeModel(notOptimizedModel,theView);
TQ3Status            stato;
TQ3ViewStatus        viewStatus;
TQ3BoundingBox dummyBounds;

    RemoveExtraReferences(notOptimizedModel);

    stato=Q3View_StartBoundingBox( theView, kQ3ComputeBoundsApproximate );
    Qut_SubmitDefaultState(theView);
    DecomposeGeometries( notOptimizedModel, theView );
    
    viewStatus=Q3View_EndBoundingBox( theView, &dummyBounds );

if(stato==kQ3Success)
                do
                    {
                    
                    Q3Object_Submit(notOptimizedModel,theView);
                    
                    DecomposeGeometries( notOptimizedModel, theView );
                    viewStatus=Q3View_EndBoundingBox( theView, 
&dummyBounds);
                    }//do
                while (viewStatus==kQ3ViewStatusRetraverse);
    
    
    
    LowerAttributesToGeometries( notOptimizedModel);
//TQ3GroupObject oldgroup=notOptimizedModel;

    theModel=(TQ3GroupObject) FlattenHierarchy(notOptimizedModel,0 );
//Q3Object_Dispose(oldgroup);

    OptimizeTriMeshes(theModel);
    MergeTriMeshes( theModel);

        Qut_CalcBounds(theView, theModel, &theBounds);
        xBounds = (theBounds.max.x - theBounds.min.x);
        yBounds = (theBounds.max.y - theBounds.min.y);
        zBounds = (theBounds.max.z - theBounds.min.z);

        scaleFactor = (xBounds > yBounds)     ? xBounds : yBounds;
        scaleFactor = (zBounds > scaleFactor) ? zBounds : scaleFactor;
        scaleFactor = 3.75f / scaleFactor;

        translateToOrigin.x = -(theBounds.min.x + (xBounds * 0.5f));
        translateToOrigin.y = -(theBounds.min.y + (yBounds * 0.5f));
        translateToOrigin.z = -(theBounds.min.z + (zBounds * 0.5f));

        
Q3Matrix4x4_SetTranslate(&translateMatrix,translateToOrigin.x,translateToOrigin.y,translateToOrigin.z);
        
Q3Matrix4x4_SetScale(&scaleMatrix,scaleFactor,scaleFactor,scaleFactor);
        
        Q3Matrix4x4_SetIdentity(&gMatrixCurrent);
        
       
 Q3Matrix4x4_Multiply(&gMatrixCurrent,&translateMatrix,&gMatrixCurrent);
        Q3Matrix4x4_Multiply(&gMatrixCurrent,&scaleMatrix,&gMatrixCurrent);

        }
    return theModel;


}