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. <os...@jw...> - 2008-04-28 02:10:33
|
Quesa's wiki has a new page describing several advanced rendering techniques: Shadows, per-pixel lighting, and full-screen antialiasing. This is just to collect some information that previously appeared in list posts and release notes. See: <http://quesa.wiki.sourceforge.net/OpenGL+Rendering+Effects> |
|
From: James W. W. <os...@jw...> - 2008-04-08 03:00:26
|
On Apr 7, 2008, at 1:36 PM, Stefan Huber wrote: > Some renderer properties depend on OpenGL features that have to be > available. A function to check if e.g kQ3RendererPropertyShadows > will work with the OpenGL renderer would be a nice feature (something > like Q3Object_IsPropertySupported). So an application can check the > properties at startup and enable/disable GUI elements. There are some difficulties with that idea. It is not possible to check renderer capabilities until after an OpenGL context has been created, which normally Quesa does not do until you render. Also, it is possible for a machine to have multiple monitors supported by multiple video cards, in which case a feature might be supported on one monitor but not another. |
|
From: Stefan H. <st...@to...> - 2008-04-07 20:36:54
|
Some renderer properties depend on OpenGL features that have to be available. A function to check if e.g kQ3RendererPropertyShadows will work with the OpenGL renderer would be a nice feature (something like Q3Object_IsPropertySupported). So an application can check the properties at startup and enable/disable GUI elements. Stefan http://www.topoi.ch |
|
From: Daniele C. <dca...@in...> - 2008-03-19 14:10:26
|
Spot light don't work fine, and I remember it is not never worked well with rayshade. www.interstudio.net/quesa/spot.jpg Direction is wrong because it never change. Point light seem work fine www.interstudio.net/quesa/point.jpg Roger Holmes ha scritto: > On 18 Mar, 2008, at 17:11, Daniele Cavallini wrote: > > >> I wrote: >> case kQ3PixelTypeRGB32: >> case kQ3PixelTypeARGB32: >> { >> unsigned int pixel; >> >> pixel = ( correct ( rgbaPixels[i][3] ) << >> 24) | >> // Alpha >> ( correct ( rgbaPixels[i][0] ) << >> 16) | >> ( correct ( rgbaPixels[i][1] ) << >> 8) | >> ( correct ( rgbaPixels[i][2] ) << >> 0 ) ; >> *((unsigned int *)rowAddr) = pixel; >> } >> break; >> For all the configuration same code. >> >> For mac osx powerPC.............OK >> For mac osx Intel.....................OK >> For Windows XP.....................OK >> For Windows Vista..................OK >> It is not so clear but the result are correct. >> > > > Well that is the main thing. Well done. > > Have you seen any problems with spot lights? In the RayShade renderer > they behave identically to point lights. Maybe my source is not right > up to date but I have not noticed any relevant bug fixes being > checked in since I checked out my copy. > > Roger > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Quesa-develop mailing list > Que...@li... > https://lists.sourceforge.net/lists/listinfo/quesa-develop > > |
|
From: Roger H. <rog...@mi...> - 2008-03-18 19:57:57
|
On 18 Mar, 2008, at 17:11, Daniele Cavallini wrote:
> I wrote:
> case kQ3PixelTypeRGB32:
> case kQ3PixelTypeARGB32:
> {
> unsigned int pixel;
>
> pixel = ( correct ( rgbaPixels[i][3] ) <<
> 24) |
> // Alpha
> ( correct ( rgbaPixels[i][0] ) <<
> 16) |
> ( correct ( rgbaPixels[i][1] ) <<
> 8) |
> ( correct ( rgbaPixels[i][2] ) <<
> 0 ) ;
> *((unsigned int *)rowAddr) = pixel;
> }
> break;
> For all the configuration same code.
>
> For mac osx powerPC.............OK
> For mac osx Intel.....................OK
> For Windows XP.....................OK
> For Windows Vista..................OK
> It is not so clear but the result are correct.
Well that is the main thing. Well done.
Have you seen any problems with spot lights? In the RayShade renderer
they behave identically to point lights. Maybe my source is not right
up to date but I have not noticed any relevant bug fixes being
checked in since I checked out my copy.
Roger
|
|
From: Daniele C. <dca...@in...> - 2008-03-18 17:12:05
|
I wrote:
case kQ3PixelTypeRGB32:
case kQ3PixelTypeARGB32:
{
unsigned int pixel;
pixel = ( correct ( rgbaPixels[i][3] ) << 24) |
// Alpha
( correct ( rgbaPixels[i][0] ) << 16) |
( correct ( rgbaPixels[i][1] ) << 8) |
( correct ( rgbaPixels[i][2] ) << 0 ) ;
*((unsigned int *)rowAddr) = pixel;
}
break;
For all the configuration same code.
For mac osx powerPC.............OK
For mac osx Intel.....................OK
For Windows XP.....................OK
For Windows Vista..................OK
It is not so clear but the result are correct.
Roger Holmes ha scritto:
> It looks like Red has gone to Alpha, green has gone to Red, Blue has
> gone to green and Alpha has gone to Blue.
>
>
> Try this:
>
> pixel. fourChars [ 3 ] = correct ( rgbaPixels [ i ] [ 3 ] ) ;
> pixel. fourChars [ 0 ] = correct ( rgbaPixels [ i ] [ 2 ] ) ;
> pixel. fourChars [ 1 ] = correct ( rgbaPixels [ i ] [ 1 ] ) ;
> pixel. fourChars [ 2 ] = correct ( rgbaPixels [ i ] [0 ] ) ;
>
> and if that doesn't work it must be:
>
>
> pixel. fourChars [ 1 ] = correct ( rgbaPixels [ i ] [ 3 ] ) ;
> pixel. fourChars [ 2 ] = correct ( rgbaPixels [ i ] [ 2 ] ) ;
> pixel. fourChars [ 3 ] = correct ( rgbaPixels [ i ] [ 1 ] ) ;
> pixel. fourChars [ 0 ] = correct ( rgbaPixels [ i ] [0 ] ) ;
>
> Roger.
>
>
> On 14 Mar, 2008, at 11:26, Daniele Cavallini wrote:
>
>
>> I tried to implement this solution but it don't work well.
>> (I set anUnsignedInt like TQ3Uns32 )
>> The create colors aren't correct.
>> You can see
>> As it would have to be
>> http://www.interstudio.net/quesa/init.jpg
>> as it is
>> http://www.interstudio.net/quesa/res.jpg
>> I use imac intel.
>>
>> I don't know why doesn't work.
>> It isn't a good solution to use #define /QUESA_HOST_IS_BIG_ENDIAN
>> /because there are mac with intel and powerpc processor.
>> How I know in runtime if computer have an intel or powerpc processor?
>>
>>
>> Have you Some ideas?
>> //
>> Roger Holmes ha scritto:
>>
>>> On the other hand, if we define
>>>
>>> union longAndFourChars
>>> {
>>> char fourChars [ 4 ] ;
>>> unsigned long int anUnsignedInt ;
>>> }
>>>
>>> longAndFourChars pixel ;
>>>
>>> then
>>>
>>> pixel. fourChars [ 0 ] = correct ( rgbaPixels [ i ] [ 3 ] ) ;// Alpha
>>> pixel. fourChars [ 1 ] = correct ( rgbaPixels [ i ] [ 2 ] ) ;
>>> pixel. fourChars [ 2 ] = correct ( rgbaPixels [ i ] [ 1 ] ) ;
>>> pixel. fourChars [ 3 ] = correct ( rgbaPixels [ i ] [0 ] ) ;
>>>
>>> * ( ( unsigned int* ) rowAddr ) = pixel. anUnsignedInt ;
>>>
>>>
>>>
>>> Then won't that work on either endian machine?
>>>
>>> Roger.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> ----
>>> This SF.net email is sponsored by: Microsoft
>>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>> _______________________________________________
>>> Quesa-develop mailing list
>>> Que...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>>>
>>>
>>>
>> ----------------------------------------------------------------------
>> ---
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Quesa-develop mailing list
>> Que...@li...
>> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>
>
|
|
From: Roger H. <rog...@mi...> - 2008-03-14 19:42:48
|
It looks like Red has gone to Alpha, green has gone to Red, Blue has gone to green and Alpha has gone to Blue. Try this: pixel. fourChars [ 3 ] = correct ( rgbaPixels [ i ] [ 3 ] ) ; pixel. fourChars [ 0 ] = correct ( rgbaPixels [ i ] [ 2 ] ) ; pixel. fourChars [ 1 ] = correct ( rgbaPixels [ i ] [ 1 ] ) ; pixel. fourChars [ 2 ] = correct ( rgbaPixels [ i ] [0 ] ) ; and if that doesn't work it must be: pixel. fourChars [ 1 ] = correct ( rgbaPixels [ i ] [ 3 ] ) ; pixel. fourChars [ 2 ] = correct ( rgbaPixels [ i ] [ 2 ] ) ; pixel. fourChars [ 3 ] = correct ( rgbaPixels [ i ] [ 1 ] ) ; pixel. fourChars [ 0 ] = correct ( rgbaPixels [ i ] [0 ] ) ; Roger. On 14 Mar, 2008, at 11:26, Daniele Cavallini wrote: > I tried to implement this solution but it don't work well. > (I set anUnsignedInt like TQ3Uns32 ) > The create colors aren't correct. > You can see > As it would have to be > http://www.interstudio.net/quesa/init.jpg > as it is > http://www.interstudio.net/quesa/res.jpg > I use imac intel. > > I don't know why doesn't work. > It isn't a good solution to use #define /QUESA_HOST_IS_BIG_ENDIAN > /because there are mac with intel and powerpc processor. > How I know in runtime if computer have an intel or powerpc processor? > > > Have you Some ideas? > // > Roger Holmes ha scritto: >> On the other hand, if we define >> >> union longAndFourChars >> { >> char fourChars [ 4 ] ; >> unsigned long int anUnsignedInt ; >> } >> >> longAndFourChars pixel ; >> >> then >> >> pixel. fourChars [ 0 ] = correct ( rgbaPixels [ i ] [ 3 ] ) ;// Alpha >> pixel. fourChars [ 1 ] = correct ( rgbaPixels [ i ] [ 2 ] ) ; >> pixel. fourChars [ 2 ] = correct ( rgbaPixels [ i ] [ 1 ] ) ; >> pixel. fourChars [ 3 ] = correct ( rgbaPixels [ i ] [0 ] ) ; >> >> * ( ( unsigned int* ) rowAddr ) = pixel. anUnsignedInt ; >> >> >> >> Then won't that work on either endian machine? >> >> Roger. >> >> >> --------------------------------------------------------------------- >> ---- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2005. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Quesa-develop mailing list >> Que...@li... >> https://lists.sourceforge.net/lists/listinfo/quesa-develop >> >> > > ---------------------------------------------------------------------- > --- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Quesa-develop mailing list > Que...@li... > https://lists.sourceforge.net/lists/listinfo/quesa-develop |
|
From: Daniele C. <dca...@in...> - 2008-03-14 11:27:04
|
I tried to implement this solution but it don't work well. (I set anUnsignedInt like TQ3Uns32 ) The create colors aren't correct. You can see As it would have to be http://www.interstudio.net/quesa/init.jpg as it is http://www.interstudio.net/quesa/res.jpg I use imac intel. I don't know why doesn't work. It isn't a good solution to use #define /QUESA_HOST_IS_BIG_ENDIAN /because there are mac with intel and powerpc processor. How I know in runtime if computer have an intel or powerpc processor? Have you Some ideas? // Roger Holmes ha scritto: > On the other hand, if we define > > union longAndFourChars > { > char fourChars [ 4 ] ; > unsigned long int anUnsignedInt ; > } > > longAndFourChars pixel ; > > then > > pixel. fourChars [ 0 ] = correct ( rgbaPixels [ i ] [ 3 ] ) ;// Alpha > pixel. fourChars [ 1 ] = correct ( rgbaPixels [ i ] [ 2 ] ) ; > pixel. fourChars [ 2 ] = correct ( rgbaPixels [ i ] [ 1 ] ) ; > pixel. fourChars [ 3 ] = correct ( rgbaPixels [ i ] [0 ] ) ; > > * ( ( unsigned int* ) rowAddr ) = pixel. anUnsignedInt ; > > > > Then won't that work on either endian machine? > > Roger. > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Quesa-develop mailing list > Que...@li... > https://lists.sourceforge.net/lists/listinfo/quesa-develop > > |
|
From: Roger H. <rog...@mi...> - 2008-02-12 14:24:54
|
Thanks James, and also thanks for the changes to E3GeometryTriMeshOptimize.cpp. Roger On 11 Feb, 2008, at 19:47, James Walker wrote: > > Done. I also added some file extension mappings to the Mac CVS Pro > document. |
|
From: James W. <ja...@fr...> - 2008-02-11 22:19:28
|
Jeff Szuhay wrote: > does it make sense to make Quesa available via MacPorts or Fink? > > I use MacPorts and would volunteer to be the maintainer for that port. > > Is this a good idea or am I barking at the moon? > I don't know much about MacPorts (never used it) but I'm not sure I see the point. After all, Quesa doesn't need to be ported, as its support for Mac OS X is more up to date and complete than its support for any other platform. -- James W. Walker, Innoventive Software LLC <http://www.frameforge3d.com/> |
|
From: Jeff S. <jef...@ma...> - 2008-02-11 20:00:09
|
does it make sense to make Quesa available via MacPorts or Fink? I use MacPorts and would volunteer to be the maintainer for that port. Is this a good idea or am I barking at the moon? Jeff |
|
From: James W. <ja...@fr...> - 2008-02-11 19:47:55
|
Roger Holmes wrote: > On the quesa web site, at http://www.quesa.org/developer/cvs.html > there is a link to a pre-configured CVS session for Mac OS clients. > This has not been updated for the changes made by SourceForge on 12 > May 2007. i.e. : > > > Summary of changes, effective 2006-05-12: > > > 1. Hostname for CVS service > > Old: cvs.sourceforge.net > > New: PROJECT_UNIX_NAME.cvs.sourceforge.net > > > > I think this means changing cvs.sourceforge.net to quesa. > cvs.sourceforge.net in the session setting. > > > Please, could this be changed to allow visitors to download Quesa. Done. I also added some file extension mappings to the Mac CVS Pro document. -- James W. Walker, Innoventive Software LLC <http://www.frameforge3d.com/> |
|
From: Roger H. <rog...@mi...> - 2008-02-11 15:50:07
|
On the quesa web site, at http://www.quesa.org/developer/cvs.html there is a link to a pre-configured CVS session for Mac OS clients. This has not been updated for the changes made by SourceForge on 12 May 2007. i.e. : Summary of changes, effective 2006-05-12: 1. Hostname for CVS service Old: cvs.sourceforge.net New: PROJECT_UNIX_NAME.cvs.sourceforge.net I think this means changing cvs.sourceforge.net to quesa. cvs.sourceforge.net in the session setting. Please, could this be changed to allow visitors to download Quesa. Roger. |
|
From: Roger H. <rog...@mi...> - 2008-02-07 17:28:39
|
On 6 Feb, 2008, at 19:55, James Walker wrote: > > The unusual thing about this TriMesh is that some edges involve points > that are not in any of the faces. I see, I don't know why it applies to my data, but I can see that if anyone wanted different vertex attributes for the lines and triangles (like blended colours on one and not the other), then that could be useful. So its worth fixing in Quesa. > > It looks like E3TriMesh_OptimizeData will also do the wrong thing with > respect to point-fill style, since points that do not belong to any > faces go away. OK > > I'll try to fix it this weekend if not sooner. That would be great. As ever, thanks for all your help. |
|
From: James W. <ja...@fr...> - 2008-02-06 19:55:19
|
Roger Holmes wrote: > Hi James, > > Here is the file: > > > It no longer shows the problem of the end of the line zipping about > randomly because it now gets cached and so the bad line is in just one > position (which is random, but usually the origin, though I have seen it > elsewhere. This data is normally added by the user interface code to > show the user where they can click their mouse to select a vertex of a > solid object which is also drawn, but not in highlight colour (red). My > program removes the highlight state when it displays data from the file, > so I don't see it in red but you may do. > > I have not compressed it as its only 3.2k and hopefully you are using a > Mac. Thunderbird munged the file, but Mail received it OK. The unusual thing about this TriMesh is that some edges involve points that are not in any of the faces. It looks like E3TriMesh_OptimizeData will also do the wrong thing with respect to point-fill style, since points that do not belong to any faces go away. I'll try to fix it this weekend if not sooner. -- James W. Walker, Innoventive Software LLC <http://www.frameforge3d.com/> |
|
From: Roger H. <rog...@mi...> - 2008-02-05 13:59:39
|
Hi James, Here is the file: |
|
From: James W. <ja...@fr...> - 2008-02-04 20:47:05
|
Roger Holmes wrote: Can you send me (or post somewhere) a 3DMF file that illustrates the problem? -- James W. Walker, Innoventive Software LLC <http://www.frameforge3d.com/> |
|
From: Roger H. <rog...@mi...> - 2008-02-04 20:24:19
|
In E3GeometryTrimeshOptimize is a routine called E3TriMesh_OptimizeData. If I disable it by commenting out the line: outDidChange = optimizer.Optimize(); then my problem goes away. This looks a slick routine and I suspect there is very little wrong with it, and I do not want to make a mess of it so if the author is able to look at the problem, that would probably be far better than a stranger, particularly as it is so critical and hence errors will show up all over the place if I make it worse. I only see the problem when in a group with an edge rendering style attached. The TriMesh going into the routine has a valid edge list with all the point indices valid. The TriMesh coming out of the routine has at least one point index set to 0xffffffff. The trimesh has only three triangles and nine edges. It is a bit strange in that it comes from a TriGRID which originally creates some null triangles which I optimise out. I do not optimise out some of the extra points, hence there are 14 points in the TriMesh. I don't understand why they should cause a problem, but it is the only strange thing I can see about the TriMesh. Anyway I think it is valid to have points in the list which are not used, but maybe its worth a mention. Maybe it just that we rarely draw TriMeshes in edge mode so very little testing of this aspect has been done. Because of the 0xffffffff index, the interactive renderer generates a random line, often to the origin, which is very annoying, resize the window or drag an item about and the free end zips about all over the place. Roger Holmes. |
|
From: James W. W. <os...@jw...> - 2008-01-26 23:21:30
|
I have posted the 2.0 release at SourceForge. |
|
From: Sean M. <se...@ro...> - 2008-01-23 19:16:05
|
On 1/21/08 7:36 PM, James W. Walker said: >Having heard no votes for 1.9, I'm calling the next release 2.0. I've >put together drafts of Mac and Windows archives, temporarily available >at these URLs: I gave it a quick whirl. It builds fine on 10.5. -- =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Sean McBride, B. Eng se...@ro... Rogue Research www.rogue-research.com Mac Software Developer Montr=E9al, Qu=E9bec, Canada |
|
From: James W. W. <os...@jw...> - 2008-01-22 03:36:40
|
Having heard no votes for 1.9, I'm calling the next release 2.0. I've put together drafts of Mac and Windows archives, temporarily available at these URLs: <ftp://ftp.frameforge3d.com/misc/quesa_2.0_sdk_mac.zip> <ftp://ftp.frameforge3d.com/misc/quesa_2.0_sdk_win32.zip> <ftp://ftp.frameforge3d.com/misc/quesa_2.0_source_mac.zip> <ftp://ftp.frameforge3d.com/misc/quesa_2.0_source_win32.zip> The Mac and Windows source archives are basically the same except for the line breaks. In the Mac SDK, I judged that Mac OS X has been out long enough to omit the CFM binaries. I hope to make the release by the end of the week. |
|
From: Daniele C. <dca...@in...> - 2008-01-08 14:46:16
|
You are right. The problem is my old compiler VS 6. With VS 2005 I compile without problem Thank's a lot. James W. Walker ha scritto: > On Jan 7, 2008, at 3:13 AM, Daniele Cavallini wrote: > > >> This is the compile's list error I found with Visual Studio: >> >> lowerattributestogeometries.cpp(193) : error C2065: 'not' : undeclared >> identifier >> if (not geomAtts.isvalid()) -> if (!geomAtts.isvalid()) FIXED >> ............ >> > > > I have checked in that change (though the original was legal C++). > > > >> mergetrimeshlist.cpp(137) : error C2059: syntax error : '*' >> const TQ3TriMeshData& tmData( *tmPeek ); >> ............ >> mergetrimeshlist.cpp(150) : error C2061: syntax error : identifier >> 'mergedFaces' >> TQ3TriMeshTriangleData& theFace( mergedFaces[j] ); >> ............ >> mergetrimeshlist.cpp(159) : error C2061: syntax error : identifier >> 'mergedEdges' >> TQ3TriMeshEdgeData& theEdge( mergedEdges[j] ); >> > > > I don't understand what it's complaining about. There are similar > expressions in the main Quesa code. > > > >> >> James Walker ha scritto: >> >>> James W. Walker wrote: >>> >>> >>> >>>> You mean there is a compile error? If you tell me what the error is >>>> and what line of code produces it, I could probably tell you how to >>>> fix it. >>>> >>>> >>> P.S. I just committed a couple of changes that may help. >>> >>> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2005. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Quesa-develop mailing list >> Que...@li... >> https://lists.sourceforge.net/lists/listinfo/quesa-develop >> > > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > Quesa-develop mailing list > Que...@li... > https://lists.sourceforge.net/lists/listinfo/quesa-develop > > |
|
From: James W. W. <os...@jw...> - 2008-01-07 17:26:46
|
On Jan 7, 2008, at 3:13 AM, Daniele Cavallini wrote: > This is the compile's list error I found with Visual Studio: > > lowerattributestogeometries.cpp(193) : error C2065: 'not' : undeclared > identifier > if (not geomAtts.isvalid()) -> if (!geomAtts.isvalid()) FIXED > ............ I have checked in that change (though the original was legal C++). > mergetrimeshlist.cpp(137) : error C2059: syntax error : '*' > const TQ3TriMeshData& tmData( *tmPeek ); > ............ > mergetrimeshlist.cpp(150) : error C2061: syntax error : identifier > 'mergedFaces' > TQ3TriMeshTriangleData& theFace( mergedFaces[j] ); > ............ > mergetrimeshlist.cpp(159) : error C2061: syntax error : identifier > 'mergedEdges' > TQ3TriMeshEdgeData& theEdge( mergedEdges[j] ); I don't understand what it's complaining about. There are similar expressions in the main Quesa code. > > > > James Walker ha scritto: >> James W. Walker wrote: >> >> >>> You mean there is a compile error? If you tell me what the error is >>> and what line of code produces it, I could probably tell you how to >>> fix it. >>> >> >> P.S. I just committed a couple of changes that may help. >> > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Quesa-develop mailing list > Que...@li... > https://lists.sourceforge.net/lists/listinfo/quesa-develop |
|
From: Daniele C. <dca...@in...> - 2008-01-07 11:13:51
|
This is the compile's list error I found with Visual Studio: lowerattributestogeometries.cpp(193) : error C2065: 'not' : undeclared identifier if (not geomAtts.isvalid()) -> if (!geomAtts.isvalid()) FIXED ............ mergetrimeshlist.cpp(137) : error C2059: syntax error : '*' const TQ3TriMeshData& tmData( *tmPeek ); ............ mergetrimeshlist.cpp(150) : error C2061: syntax error : identifier 'mergedFaces' TQ3TriMeshTriangleData& theFace( mergedFaces[j] ); ............ mergetrimeshlist.cpp(159) : error C2061: syntax error : identifier 'mergedEdges' TQ3TriMeshEdgeData& theEdge( mergedEdges[j] ); James Walker ha scritto: > James W. Walker wrote: > > >> You mean there is a compile error? If you tell me what the error is >> and what line of code produces it, I could probably tell you how to >> fix it. >> > > P.S. I just committed a couple of changes that may help. > |
|
From: Kevin M. <mat...@ar...> - 2008-01-04 21:09:47
|
On Fri, 4 Jan 2008 21:47:35 +0100, Jose' Cruanyes wrote: > waiting the domain returns free (little hope I think) As soon as the update propagates through the DNS server system (variable up to three days), quesa.org should be functional again, just as before. (No thanks to the major domain registrar, who we are dumping, who failed to list it among our domains with them, even though it was and is.) Apologies for the temporary complication! - Kevin http://www.Artifice.com ecological media + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+ Artifice, Inc. ...the way of architecture http://www.greatbuildings.com http://www.designcommunity.com http://www.architectureweek.com 541.345.7421 vox . 541.345.7438 fax . 800.203.8324 US toll free + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+ Artifice. "1534. [a. F., ad. L. artificium] 1. The action of an artificer, construction, workmanship. 2. The product of art. 3. Mode or style of workmanship. 4. Constructive skill. 5. Human skill. 6. Skill in expedients. 7. An ingenious expedient." -- The Oxford Universal Dictionary, Third Edition |
1 message has been excluded from this view by a project administrator.