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: Daniele C. <dca...@in...> - 2007-10-04 15:41:36
|
Is it possible to export a model in a 3D metafile mode text ? In Geom Test in function doSaveModel () there is : Q3File_OpenWrite(file,fileMode); for export in text mode I replace Q3File_OpenWrite(file,kQ3FileModeNormal | kQ3FileModeText); But obtain: Quesa Warning :Type has not been registered Any suggest? |
|
From: Sauro A. <sag...@in...> - 2007-10-04 14:10:07
|
> >When you say "last Quesa", does that include yesterday's changes? > No, it was compiled last week. With your last changes all is ok, with a little difference with the OpenGl renderer. The problem is resolved. Thank you. Sauro |
|
From: James W. <ja...@fr...> - 2007-10-03 19:34:10
|
Sauro Agostini wrote: > The FPS of the Farmhouse test were wrong. > > The right test is > > Previous 1.8 Quesa and Interactive renderer 8.1 - 8.4 FPS > > Last Quesa with Interactive or OpenGl renderer 2.9 - 3.2 FPS I tried the Farmhouse on my Mac Pro. Quesa 1.8, IR: 14.9 FPS current Quesa, OpenGL: 15.0 FPS current Quesa, IR: 15.7 FPS The main reason that the OpenGL renderer is a little slower than the IR seems to be the visibility culling in QORenderer::Renderer::SubmitTriMesh. Anyway, you need to improve your model. The farmhouse model has multiple references to various groups. Of course in some cases multiple references can make sense, for instance if the references are subject to different transformations, but in this case the multiple references are just siblings in a group. That is, you're rendering things multiple times for no apparent reason. When I removed the multiple references, the model rendered almost 10 times faster with no apparent change in appearance. -- James W. Walker, Innoventive Software LLC <http://www.frameforge3d.com/> |
|
From: James W. W. <os...@jw...> - 2007-10-03 16:27:15
|
On Oct 3, 2007, at 7:06 AM, Sauro Agostini wrote: > The FPS of the Farmhouse test were wrong. > > The right test is > > Previous 1.8 Quesa and Interactive renderer 8.1 - 8.4 FPS > > Last Quesa with Interactive or OpenGl renderer 2.9 - 3.2 FPS > > I'm sorry. When you say "last Quesa", does that include yesterday's changes? |
|
From: Sauro A. <sag...@in...> - 2007-10-03 14:06:45
|
The FPS of the Farmhouse test were wrong. The right test is Previous 1.8 Quesa and Interactive renderer 8.1 - 8.4 FPS Last Quesa with Interactive or OpenGl renderer 2.9 - 3.2 FPS I'm sorry. Sauro Agostini |
|
From: Sauro A. <sag...@in...> - 2007-10-03 11:14:03
|
I used multi-box because the results are similar to the models in our programs. We have mainly architectural models, with thousands of polygons and general polygons. I posted a 3DMF file of a small house at the following address http://www.interstudio.net/quesa/Farmhouse1.3DMF.zip Loading this model in Geom Text I have the following results (Dual 1.8 GHzG5): Previous 1.8 Quesa and Interactive renderer 2.9 - 3.2 FPS Last Quesa with Interactive or OpenGl renderer 8.1 - 8.4 FPS Other results with other models of Geom Test Test Quesa 1.8 Last Quesa Interactive OpenGl Box 2000 1500 MultiBox 25 8 Cone 60 280 General Polygon 2220 1900 Polygon 2200 1900 Trymesh 2200 2000 TriGrid 1500 1400 Torus 1400 1900 Quesa Logo 630 1200 Cone, Quesa Logo and Torus are better with the new version. Box and MultiBox are better with the old version. The others practically are the same. Sauro Agostini -- ----------------------------------------------------------------------------- _ ___ |_| __| Interstudio S.r.l. Tel + 39 0573 99291 Fax + 39 0573 992930 | |__ | Piazza Monteoliveto 6a http://www.interstudio.net |_____| I-51100 Pistoia Italy mailto:int...@in... ----------------------------------------------------------------------------- |
|
From: James W. <ja...@fr...> - 2007-10-02 21:36:43
|
I've committed a fix for the multi-box slowdown. It may still be a few percent slower than 1.8, and I'm not sure why, maybe virtual method dispatch. Bear in mind that the multi-box test is not a very realistic benchmark. It has 6000 TriMeshes, each of which has its own attribute set but only 2 triangles. This is an exceptionally high amount of overhead for the amount of geometry. -- James W. Walker, Innoventive Software LLC <http://www.frameforge3d.com/> |
|
From: Sean M. <se...@ro...> - 2007-10-02 19:50:22
|
On 10/2/07 5:33 PM, Roger Holmes said: >>> UInt32 would be better, since 'unsigned long int' is 64 bit when >>> building 64 bit, and 32 bit when building 32 bit. >> >> UInt32 isn't defined on platforms other than Mac, is it=3F > >Would 'unsigned int' be safest=3F Actually, seems like "TQ3Uns32" is ideal. :) -- =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: Roger H. <rog...@mi...> - 2007-10-02 17:23:56
|
I cannot make out if some of the changes are things I have done to my code or thing you guys have done to the master version. I thought I had kept a baseline version from which I had derived my version but I can't find it. Anyway, by far the most important change is this one: Inside surface.cpp Inside the routine SurfaceCreate After: stmp->reflect = stmp->transp = 0.; I inserted: stmp->translucency = 0.0 ; which fixes a bug with white speckling on second and subsequent renders, so particularly noticeable when generating QuickTime movies from animations. It seems the changes for the endian issue have already been incorporated. Roger. |
|
From: Sean M. <se...@ro...> - 2007-10-02 16:36:50
|
On 10/2/07 8:41 AM, James W. Walker said: >UInt32 isn't defined on platforms other than Mac, is it=3F Probably not. Popular choices are 1) C99's uint32=5Ft 2) typedef your own, based on platform/compiler. 3) assume 32 bit CPUs. -- =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: Roger H. <rog...@mi...> - 2007-10-02 16:33:58
|
On 2 Oct, 2007, at 16:41, James W. Walker wrote:
>
> On Oct 2, 2007, at 8:16 AM, Sean McBride wrote:
>
>> On 10/2/07 1:54 PM, Roger Holmes said:
>>
>>> On the other hand, if we define
>>>
>>> union longAndFourChars
>>> {
>>> char fourChars [ 4 ] ;
>>> unsigned long int anUnsignedInt ;
>>> }
>>
>> UInt32 would be better, since 'unsigned long int' is 64 bit when
>> building 64 bit, and 32 bit when building 32 bit.
>
> UInt32 isn't defined on platforms other than Mac, is it?
Would 'unsigned int' be safest?
|
|
From: James W. W. <os...@jw...> - 2007-10-02 15:42:08
|
On Oct 2, 2007, at 8:16 AM, Sean McBride wrote:
> On 10/2/07 1:54 PM, Roger Holmes said:
>
>> On the other hand, if we define
>>
>> union longAndFourChars
>> {
>> char fourChars [ 4 ] ;
>> unsigned long int anUnsignedInt ;
>> }
>
> UInt32 would be better, since 'unsigned long int' is 64 bit when
> building 64 bit, and 32 bit when building 32 bit.
UInt32 isn't defined on platforms other than Mac, is it?
|
|
From: Sean M. <se...@ro...> - 2007-10-02 15:17:28
|
On 10/2/07 1:54 PM, Roger Holmes said:
>On the other hand, if we define
>
>union longAndFourChars
>=09{
>=09char fourChars [ 4 ] ;
>=09unsigned long int anUnsignedInt ;
>=09}
UInt32 would be better, since 'unsigned long int' is 64 bit when
building 64 bit, and 32 bit when building 32 bit.
--
=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: Jose' C. <cru...@ce...> - 2007-10-02 13:35:05
|
Il giorno 02/ott/07, alle ore 15:05, Daniele Cavallini ha scritto: > My e-mail is dca...@in... pls email it to the list and I'll put it in CVS Pax et Bonum # Dott. Jos=E9 Cruanyes Aguilar - C.E. Soft srl # Pzza. Firenze,4 MILANO - XX Settembre 10, CREMONA # 02,3923101 0372,460602 |
|
From: Daniele C. <dca...@in...> - 2007-10-02 13:05:34
|
My e-mail is dca...@in... In rayshade I set a big #if but Your idea to use longAndFourChars seem good and elegant Roger Holmes ha scritto: > No but I can do a comparison and e-mail the changes. > > > > On 2 Oct, 2007, at 13:50, Daniele Cavallini wrote: > > >> Is your version downloadable from cvs? >> I can try it. >> Roger Holmes ha scritto: >> >>> Er, yes. I have a big #if for those two cases. I have some other >>> changes too if anyone would like to check them in for me. >>> >>> Most important one is that there is an unitialised field in one of >>> the records which causes speckling which I've fixed in my version. >>> >>> Roger. >>> >>> >>> >>> >>> On 2 Oct, 2007, at 11:58, Daniele Cavallini wrote: >>> >>> >>> >>>> There is a little problem with rayshade >>>> In function RSRasterizer_Rasterize_RGB_Span_PM when you compile for >>>> windows in >>>> case kQ3PixelTypeRGB32: >>>> case kQ3PixelTypeARGB32: >>>> >>>> is always >>>> 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; >>>> >>>> regardless of /QUESA_HOST_IS_BIG_ENDIAN/ . >>>> >>>> >>>> Same for kQ3PixelTypeRGB24 >>>> >>>> >>>> >>>> -------------------------------------------------------------------- >>>> -- >>>> --- >>>> 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 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 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 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...> - 2007-10-02 12:56:11
|
No but I can do a comparison and e-mail the changes. On 2 Oct, 2007, at 13:50, Daniele Cavallini wrote: > Is your version downloadable from cvs? > I can try it. > Roger Holmes ha scritto: >> Er, yes. I have a big #if for those two cases. I have some other >> changes too if anyone would like to check them in for me. >> >> Most important one is that there is an unitialised field in one of >> the records which causes speckling which I've fixed in my version. >> >> Roger. >> >> >> >> >> On 2 Oct, 2007, at 11:58, Daniele Cavallini wrote: >> >> >>> There is a little problem with rayshade >>> In function RSRasterizer_Rasterize_RGB_Span_PM when you compile for >>> windows in >>> case kQ3PixelTypeRGB32: >>> case kQ3PixelTypeARGB32: >>> >>> is always >>> 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; >>> >>> regardless of /QUESA_HOST_IS_BIG_ENDIAN/ . >>> >>> >>> Same for kQ3PixelTypeRGB24 >>> >>> >>> >>> -------------------------------------------------------------------- >>> -- >>> --- >>> 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 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 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...> - 2007-10-02 12:54:21
|
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.
|
|
From: Daniele C. <dca...@in...> - 2007-10-02 12:50:39
|
Is your version downloadable from cvs? I can try it. Roger Holmes ha scritto: > Er, yes. I have a big #if for those two cases. I have some other > changes too if anyone would like to check them in for me. > > Most important one is that there is an unitialised field in one of > the records which causes speckling which I've fixed in my version. > > Roger. > > > > > On 2 Oct, 2007, at 11:58, Daniele Cavallini wrote: > > >> There is a little problem with rayshade >> In function RSRasterizer_Rasterize_RGB_Span_PM when you compile for >> windows in >> case kQ3PixelTypeRGB32: >> case kQ3PixelTypeARGB32: >> >> is always >> 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; >> >> regardless of /QUESA_HOST_IS_BIG_ENDIAN/ . >> >> >> Same for kQ3PixelTypeRGB24 >> >> >> >> ---------------------------------------------------------------------- >> --- >> 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 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...> - 2007-10-02 12:43:45
|
Er, yes. I have a big #if for those two cases. I have some other changes too if anyone would like to check them in for me. Most important one is that there is an unitialised field in one of the records which causes speckling which I've fixed in my version. Roger. On 2 Oct, 2007, at 11:58, Daniele Cavallini wrote: > There is a little problem with rayshade > In function RSRasterizer_Rasterize_RGB_Span_PM when you compile for > windows in > case kQ3PixelTypeRGB32: > case kQ3PixelTypeARGB32: > > is always > 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; > > regardless of /QUESA_HOST_IS_BIG_ENDIAN/ . > > > Same for kQ3PixelTypeRGB24 > > > > ---------------------------------------------------------------------- > --- > 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...> - 2007-10-02 10:58:14
|
There is a little problem with rayshade
In function RSRasterizer_Rasterize_RGB_Span_PM when you compile for
windows in
case kQ3PixelTypeRGB32:
case kQ3PixelTypeARGB32:
is always
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;
regardless of /QUESA_HOST_IS_BIG_ENDIAN/ .
Same for kQ3PixelTypeRGB24
|
|
From: James W. W. <os...@jw...> - 2007-10-02 04:10:32
|
Progress report: I've identified a reason that the multi-box test got slower. It seems to be a result of calling glBindFrameBufferEXT on each call to GLDrawContext_SetCurrent. I have a fix, but I want to do a bit more testing before committing. |
|
From: Sauro A. <sag...@in...> - 2007-09-28 18:24:27
|
> > > >> Practically the latest version is faster using OpenGl and Quesa Logo, >> but it is very slow with the MultiBox model, independently of the >> kind of renderer, where last Quesa for Intel is slower than Quesa 1.8 >> emulated with Rosetta! >> >> Also with our programs we have similar results, with the latest >> version that is 3 times slower than Quesa 1.8 and previous versions >> (12 FPS versus 36 FPS). >> >> Any suggestions? > >Are you sure you're comparing builds made with the same compiler and >optimization options? I am a little skeptical, because outside the >OpenGL renderer, I think most recent changes have been intended to >improve performance. I compiled the release version just with the options of the downloaded project. Looking to the Quesa Logo FPS there is a big improvement, from 1500 to 2500, while multibox goes down from 36 to 12, so it doesn't seem depend on some optimization option, the difference is too big. > >Besides my previous suggestion to try Shark, you could use cvs to try to >narrow down the problem. That is, check out the sources as of various >dates between 1.8 and now, to try to discover when a slowdown happened. >-- I'll try to test with Shark. Sauro |
|
From: Sauro A. <int...@in...> - 2007-09-28 17:35:46
|
RayShade draws the image getting the aspect ratio of the screen instead of the Window. If you arrange the windows size with the same ratio of the screen the result should be correct. Probably it isn't difficult to correct this bug. Sauro >We draw all our perspective scenes using the View Angle Aspect camera. > >Comparing the RayShade renderer output for a non 1:1 aspect ratio >scene, with the output from the Interactive renderer ( and the >Microspot Renderer ), we get a slight stretching out with RayShade. > >Whilst it is not critical, it is a bit annoying at times when you >accurately clip (in the PhotoShop sense) the scene you want using the >interactive renderer and then wait for RayShade to do its thing, but >then find the clipping is wrong in the final output. > > > >------------------------------------------------------------------------- >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: James W. <ja...@fr...> - 2007-09-28 17:35:44
|
Sauro Agostini wrote: > Using the latest Quesa we found that it is very slow than the old 1.8 > version and previous versions, especially with polygons and general > polygons. > > The problems is evident with our programs, where using the latest > version of Quesa, navigating is very slow using any renderer. > > We tested different versions of Quesa on different computers using > Geom Test with the following results: > > > Test MultiBox > Quesa Logo MultiBox Quesa Logo > Interactive > Interactive OpenGl OpenGl > FPS > FPS FPS FPS > > Last Quesa on iMac Intel Core duo 1.83 GHz 12 > 1030 11 2500 > Last Quesa on G5 Dual 1.8 GHz 9 > 630 11 1500 > > Quesa 1.8 on iMac Intel Core duo 1.83 GHz 36 > 970 ----- ----- > Quesa 1.8 on G5 Dual 1.8 GHz 26 > 720 ----- ----- > > Old Geom Test 2003 on iMac and Rosetta 18 > 500 ----- ----- > Old Geom Test 2003 on G5 Dual 1.8 GHz 28 > 730 ----- ----- > > > Practically the latest version is faster using OpenGl and Quesa Logo, > but it is very slow with the MultiBox model, independently of the > kind of renderer, where last Quesa for Intel is slower than Quesa 1.8 > emulated with Rosetta! > > Also with our programs we have similar results, with the latest > version that is 3 times slower than Quesa 1.8 and previous versions > (12 FPS versus 36 FPS). > > Any suggestions? Are you sure you're comparing builds made with the same compiler and optimization options? I am a little skeptical, because outside the OpenGL renderer, I think most recent changes have been intended to improve performance. Besides my previous suggestion to try Shark, you could use cvs to try to narrow down the problem. That is, check out the sources as of various dates between 1.8 and now, to try to discover when a slowdown happened. -- James W. Walker, Innoventive Software LLC <http://www.frameforge3d.com/> |
|
From: Sauro A. <int...@in...> - 2007-09-28 16:58:06
|
Using the latest Quesa we found that it is very slow than the old 1.8
version and previous versions, especially with polygons and general
polygons.
The problems is evident with our programs, where using the latest
version of Quesa, navigating is very slow using any renderer.
We tested different versions of Quesa on different computers using
Geom Test with the following results:
Test MultiBox
Quesa Logo MultiBox Quesa Logo
Interactive
Interactive OpenGl OpenGl
FPS
FPS FPS FPS
Last Quesa on iMac Intel Core duo 1.83 GHz 12
1030 11 2500
Last Quesa on G5 Dual 1.8 GHz 9
630 11 1500
Quesa 1.8 on iMac Intel Core duo 1.83 GHz 36
970 ----- -----
Quesa 1.8 on G5 Dual 1.8 GHz 26
720 ----- -----
Old Geom Test 2003 on iMac and Rosetta 18
500 ----- -----
Old Geom Test 2003 on G5 Dual 1.8 GHz 28
730 ----- -----
Practically the latest version is faster using OpenGl and Quesa Logo,
but it is very slow with the MultiBox model, independently of the
kind of renderer, where last Quesa for Intel is slower than Quesa 1.8
emulated with Rosetta!
Also with our programs we have similar results, with the latest
version that is 3 times slower than Quesa 1.8 and previous versions
(12 FPS versus 36 FPS).
Any suggestions?
Sauro Agostini
|
1 message has been excluded from this view by a project administrator.
