quesa-develop — Mailing list for Quesa development

Re: Refection in the RayShade renderer

[Jose' C. <cru...@ce...>]

Il giorno 27/apr/07, alle ore 22:14, Roger Holmes ha scritto:

>>>
>>
>> mmm which other renderers?
>
> The Quesa Interactive renderer, the QuickDraw3D Interactive renderer
> and the Microspot renderer.

don't know about microspot renderer, but the others does't support =20
reflecting...

anyway I'd like to be as compatible as possible...

>
>
>> I'm taking those values going back and forth from the values passed
>> in the open GL renderer in GL_SHININESS (it's not the same, I know,
>> but is clese anough)
>
> So if you have a matt object and a glossy object and switch between
> the interactive render and RayShade, do they look (about) the same?
>

you can test it by yourself in geom test

the quesa logo in Geom test is almost the same (so much that I've =20
even got the feel that nothing was changed, till I saw the shadow)

a glossy object is MUCH more "Brilliant" in the 'wow' sense of the =20
term, but seems quite right (edit GeomTest to make the Quesa logo =20
glossy)

every thing is perfectible anyway

>>

Pax et Bonum

# Dott. Jos=E9 Cruanyes Aguilar  -  C.E. Soft srl
#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
#   02,3923101                0372,460602

Re: contributors.html

[Jose' C. <cru...@ce...>]

Il giorno 27/apr/07, alle ore 19:34, James Walker ha scritto:

> The updated contributors list references "images/mobilia.png".  But =20=

> when
> I try to check out the images directory, Mac CVS Pro says:
>
> Could not map memory to RCS archive
> /cvsroot/quesa/quesa/Documentation/other/images/Mobilia.png,v: No such
> file or directory
>
> What does that mean?

means that a system failure happened while comitting, the sourceforge =20=

server ran out of file descriptors (!)

seems taht the index was created but the real file don't, I've =20
already opened a support ticket with them, in the meantime we have =20
the CVS system broken :-(


>
> Also, I see I've been elected to the steering committee... when did =20=

> that
> happen? :-)

what's fair, is fair...


Pax et Bonum

# Dott. Jos=E9 Cruanyes Aguilar  -  C.E. Soft srl
#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
#   02,3923101                0372,460602

Re: Refection in the RayShade renderer

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

Roger Holmes wrote:
> On 27 Apr, 2007, at 13:45, Jose' Cruanyes wrote:

>> this parameter controls how big is the reflection light spot on the
>> figure.
>>
>> in GL it goes from
>>
>> 0 (no spot (because too big) and hence rough and hence not reflecting)
>> to
>> 128 (pointy spot, hence polish hence reflecting)
> 
> Is it the other way round perhaps?

No, it is not the other way around, but it is a bit more complicated, 
because specular color is also involved.  In OpenGL it is more accurate 
to say that you get a non-reflecting surface by setting the specular 
color to black, never mind the value of GL_SHININESS.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: Refection in the RayShade renderer

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

On 27 Apr, 2007, at 13:45, Jose' Cruanyes wrote:

>
> Il giorno 27/apr/07, alle ore 12:30, Roger Holmes ha scritto:
>
>>
>> Well done! But please can you explain.
>>
>> With other renderers a specular control of 200 is matt, and a
>> specular control of 0.2 is gloss.
>>
>> Not only are the values bigger, they are also inverted.
>>
>> Can't we make these compatible with other renderers?
>>
>
> mmm which other renderers?

The Quesa Interactive renderer, the QuickDraw3D Interactive renderer =20
and the Microspot renderer.


> I'm taking those values going back and forth from the values passed
> in the open GL renderer in GL_SHININESS (it's not the same, I know,
> but is clese anough)

So if you have a matt object and a glossy object and switch between =20
the interactive render and RayShade, do they look (about) the same?

>
> I want the parameters in the geometry were used untouched by every
> renderer, but I can be wrong - (not tested too much indeed)

I don't quite get your meaning.

>
> this parameter controls how big is the reflection light spot on the
> figure.
>
> in GL it goes from
>
> 0 (no spot (because too big) and hence rough and hence not reflecting)
> to
> 128 (pointy spot, hence polish hence reflecting)

Is it the other way round perhaps?

>
> in Rayshade it goes from
> 0 no reflecting
> to
> 100 perfect mirror
>
> seems obvious to map rayshade =3D GL_SHININESS / 1.28
>
> now lets map this to Quesa specular control values (that BTW defaults
> to 4)
>
> the mapping between Quesa-OGl is done in GLUtils.c 419:441
>
> --8<------8<------8<------8<------8<------8<------8<------8<------8<--=20=

> --
> --8<------8<------8<----
>
> //
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
> =3D=3D
> =3D=3D=3D=3D=3D
> //      GLUtils_SpecularControlToGLShininess :
> //					Map Quesa specular control to =
OpenGL shininess.
> //--------------------------------------------------------------------=20=

> --
> -------
> //		This function was arrived at heuristically, but notice =
several
> properties:
> //		1. as long as specularControl >=3D 0, shininess >=3D 0.
> //		2. as specularControl increases, shininess increases.
> //		3. as specularControl tends to infinity, shininess =
approaches 128
> (the maximum
> //		allowed by OpenGL).
> GLfloat		GLUtils_SpecularControlToGLShininess( float =
inSpecControl )
> {
> 	GLfloat		shininess;
> =09
> 	if (inSpecControl < 0.0f)
> 		inSpecControl =3D 0.0f;
>
>
> 	shininess =3D 128.0f - (20.0f * 128.0f)/(inSpecControl + 20.0f);
> =09
> 	return shininess;
> }
>
> --8<------8<------8<------8<------8<------8<------8<------8<------8<--=20=

> --
> --8<------8<-----
>
> the default 4 value of specularControl, maps to 21 of shininess
> but 17 is too reflecting for a default value, so instead of do a
> linear interpolation, I've adjusted the curve of translation to
>
>      result->reflect =3D (128.0f - (100.0f * 128.0f)/(data-
>> specularControl + 100.0f))*0.008;
>
> of course all this reasoning is genuine out of my a**, so it can be
> discussed
>
>
> Pax et Bonum
>
> # Dott. Jos=E9 Cruanyes Aguilar  -  C.E. Soft srl
> #  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
> #   02,3923101                0372,460602
>
>
>
> ----------------------------------------------------------------------=20=

> ---
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop

contributors.html

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

The updated contributors list references "images/mobilia.png".  But when 
I try to check out the images directory, Mac CVS Pro says:

Could not map memory to RCS archive 
/cvsroot/quesa/quesa/Documentation/other/images/Mobilia.png,v: No such 
file or directory

What does that mean?


Also, I see I've been elected to the steering committee... when did that 
happen? :-)
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: Refection in the RayShade renderer

[Jose' C. <cru...@ce...>]

Il giorno 27/apr/07, alle ore 12:30, Roger Holmes ha scritto:

>
> Well done! But please can you explain.
>
> With other renderers a specular control of 200 is matt, and a
> specular control of 0.2 is gloss.
>
> Not only are the values bigger, they are also inverted.
>
> Can't we make these compatible with other renderers?
>

mmm which other renderers?
I'm taking those values going back and forth from the values passed =20
in the open GL renderer in GL_SHININESS (it's not the same, I know, =20
but is clese anough)

I want the parameters in the geometry were used untouched by every =20
renderer, but I can be wrong - (not tested too much indeed)

this parameter controls how big is the reflection light spot on the =20
figure.

in GL it goes from

0 (no spot (because too big) and hence rough and hence not reflecting)
to
128 (pointy spot, hence polish hence reflecting)

in Rayshade it goes from
0 no reflecting
to
100 perfect mirror

seems obvious to map rayshade =3D GL_SHININESS / 1.28

now lets map this to Quesa specular control values (that BTW defaults =20=

to 4)

the mapping between Quesa-OGl is done in GLUtils.c 419:441

--8<------8<------8<------8<------8<------8<------8<------8<------8<----=20=

--8<------8<------8<----

//=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
=3D=3D=3D=3D=3D
//      GLUtils_SpecularControlToGLShininess :
//					Map Quesa specular control to =
OpenGL shininess.
//----------------------------------------------------------------------=20=

-------
//		This function was arrived at heuristically, but notice =
several =20
properties:
//		1. as long as specularControl >=3D 0, shininess >=3D 0.
//		2. as specularControl increases, shininess increases.
//		3. as specularControl tends to infinity, shininess =
approaches 128 =20
(the maximum
//		allowed by OpenGL).
GLfloat		GLUtils_SpecularControlToGLShininess( float =
inSpecControl )
{
	GLfloat		shininess;
=09
	if (inSpecControl < 0.0f)
		inSpecControl =3D 0.0f;


	shininess =3D 128.0f - (20.0f * 128.0f)/(inSpecControl + 20.0f);
=09
	return shininess;
}

--8<------8<------8<------8<------8<------8<------8<------8<------8<----=20=

--8<------8<-----

the default 4 value of specularControl, maps to 21 of shininess
but 17 is too reflecting for a default value, so instead of do a =20
linear interpolation, I've adjusted the curve of translation to

     result->reflect =3D (128.0f - (100.0f * 128.0f)/(data-=20
 >specularControl + 100.0f))*0.008;

of course all this reasoning is genuine out of my a**, so it can be =20
discussed


Pax et Bonum

# Dott. Jos=E9 Cruanyes Aguilar  -  C.E. Soft srl
#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
#   02,3923101                0372,460602

Re: Refection in the RayShade renderer

[Jose' C. <cru...@ce...>]

oops error...


a matte surface has a specular control less than 5 (five)
a glossy surface is somewhere around 100 (hundred)
a mirror is something above 1000 (thousand)


Il giorno 27/apr/07, alle ore 11:49, Jose' Cruanyes ha scritto:

> a matte surface has a specular control less than 5
> a glossy surface is some where arround 1000
> a mirror is someting above 1000

Pax et Bonum

# Dott. Jos=E9 Cruanyes Aguilar  -  C.E. Soft srl
#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
#   02,3923101                0372,460602

Re: Refection in the RayShade renderer

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

On 27 Apr, 2007, at 10:49, Jose' Cruanyes wrote:

> We're working to update the rayshade renderer
>
> we'we added support to reflection,
>
> controlled by the standard SpecularControl attribute,
> the effect is pseudo logaritmic,
> a matte surface has a specular control less than 5
> a glossy surface is some where arround 1000
> a mirror is someting above 1000
>
> it works with textures too!!
>
> fire your CVSs
>


Well done! But please can you explain.

With other renderers a specular control of 200 is matt, and a  
specular control of 0.2 is gloss.

Not only are the values bigger, they are also inverted.

Can't we make these compatible with other renderers?


Thanks to you both.

Roger.

Refection in the RayShade renderer

[Jose' C. <cru...@ce...>]

We're working to update the rayshade renderer

we'we added support to reflection,

controlled by the standard SpecularControl attribute,
the effect is pseudo logaritmic,
a matte surface has a specular control less than 5
a glossy surface is some where arround 1000
a mirror is someting above 1000

it works with textures too!!

fire your CVSs


Pax et Bonum

# Dott. Jos=E9 Cruanyes Aguilar  -  C.E. Soft srl
#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
#   02,3923101                0372,460602

Universal Xcode project for RayShade renderer

[Jose' C. <cru...@ce...>]

Thanks to Sauro Agostini of interstudio <http://www.interstudio.net>

We have now a Universal version of RayShade renderer

in a CVS near you...


Pax et Bonum

# Dott. Jos=E9 Cruanyes Aguilar  -  C.E. Soft srl
#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
#   02,3923101                0372,460602

Re: 3DS Writer

[Jose' C. <cru...@ce...>]

Il giorno 14/apr/07, alle ore 19:35, Jose' Cruanyes ha scritto:

> Well, It's here
> the first Quesa plug-in writer has arrived...
>
> Currently only on Mac, and currently only the geometry... but it's a
> start :-)
>
> To try it, install it and uncomment line 2474 of GeomTest.c ...
>
> we have to think a clean way to put the PutFile Dialog using the
> plugged in writers...
> I will try something next week while porting the plug-in to Win32
> (the Mac versions of Qut_SelectMetafilexxxx need a deep refresh
> anyway...)
>

For those not following the CVS activity list

The 3DS project has been updated, to support materials in output =20
(great to export models to the outside world, that ignores completely =20=

our loved 3DMF)

It has been ported to Windows too...

To try it, install it and uncomment line 2474 of GeomTest.c ...


Pax et Bonum

# Dott. Jos=E9 Cruanyes Aguilar  -  C.E. Soft srl
#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
#   02,3923101                0372,460602

Re: More wireframe renderer

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

Stefan Huber wrote:

> You have right. Partly (sorry for not testing the issue thoroughly). 
> For most geometries Wireframe backface culling works. But at least 
> not for Cube, Mesh, Trimesh, and Polyhedron. With these geometries 
> the Interactive renderer does his own culling (probably in 
> IRGeometry_Generate_Triangle_Flags).

I think I finally understand what you're talking about.  If a TriMesh 
does not specify explicit edges (like the TriMeshes in the Quesa logo) 
then backfaces can be culled.  But if a TriMesh does specify explicit 
edges, then the Wireframe and OpenGL renderers simply draw each edge as 
a line, with no culling.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: More wireframe renderer

[Stefan H. <st...@to...>]

You have right. Partly (sorry for not testing the issue thoroughly). 
For most geometries Wireframe backface culling works. But at least 
not for Cube, Mesh, Trimesh, and Polyhedron. With these geometries 
the Interactive renderer does his own culling (probably in 
IRGeometry_Generate_Triangle_Flags).

   Stefan
   http://www.topoi.ch


>On Apr 19, 2007, at 10:05 PM, Stefan Huber wrote:
>
>>  The behaviour between renderers and (fill) styles is not consistent.
>>
>>  Quesa Interactive renderer supports TQ3FillStyle:: kQ3FillStyleEdges
>>  in combination with TQ3BackfacingStyle:: kQ3BackfacingStyleRemove.
>>  That is what you have probably seen in Geom Test.
>
>No, I specifically looked at the wireframe renderer.
>
>  > Quesa Wireframe renderer does not support the above combination.
>
>Yes it does....
>
>>  Actually Quesa Wireframe should ignore TQ3FillStyle (at least
>>  kQ3FillStyleFilled). Quesa Wireframe + kQ3BackfacingStyleRemove
>>  (ignoring kQ3FillStyleFilled ) should have (more or less) the same
>>  (redundant) effect as Quesa Interactive + kQ3FillStyleEdges +
>>  kQ3BackfacingStyleRemove.
>
>And it does.
>
>>  Under QD3D there was a slight difference. QD3D Interactive +
>>  kQ3FillStyleEdges + kQ3BackfacingStyleRemove showed triangle edges
>>  (exception: high level geometries like cube). QD3D Wireframe showed
>>  surface edges.
>
>I don't know what you mean by surface edges.
not decomposed into triangles
>
>>  By the way, Quesa OpenGL renderer does not support kQ3FillStyleEdges
>>  in combination with kQ3BackfacingStyleRemove.
>
>Sorry to keep contradicting you, but yes, it does, I just tried 
>that.  In fact, if you use the OpenGL renderer, kQ3FillStyleEdges, 
>kQ3BackfacingStyleRemove, and kQ3IlluminationTypeNULL, it looks the
>same as the wireframe renderer with kQ3BackfacingStyleRemove.

Re: More wireframe renderer

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

On Apr 19, 2007, at 10:05 PM, Stefan Huber wrote:

> The behaviour between renderers and (fill) styles is not consistent.
>
> Quesa Interactive renderer supports TQ3FillStyle:: kQ3FillStyleEdges
> in combination with TQ3BackfacingStyle:: kQ3BackfacingStyleRemove.
> That is what you have probably seen in Geom Test.

No, I specifically looked at the wireframe renderer.

> Quesa Wireframe renderer does not support the above combination.

Yes it does....

> Actually Quesa Wireframe should ignore TQ3FillStyle (at least
> kQ3FillStyleFilled). Quesa Wireframe + kQ3BackfacingStyleRemove
> (ignoring kQ3FillStyleFilled ) should have (more or less) the same
> (redundant) effect as Quesa Interactive + kQ3FillStyleEdges +
> kQ3BackfacingStyleRemove.

And it does.

> Under QD3D there was a slight difference. QD3D Interactive +
> kQ3FillStyleEdges + kQ3BackfacingStyleRemove showed triangle edges
> (exception: high level geometries like cube). QD3D Wireframe showed
> surface edges.

I don't know what you mean by surface edges.

> By the way, Quesa OpenGL renderer does not support kQ3FillStyleEdges
> in combination with kQ3BackfacingStyleRemove.

Sorry to keep contradicting you, but yes, it does, I just tried  
that.  In fact, if you use the OpenGL renderer, kQ3FillStyleEdges,  
kQ3BackfacingStyleRemove, and kQ3IlluminationTypeNULL, it looks the  
same as the wireframe renderer with kQ3BackfacingStyleRemove.

Re: More wireframe renderer

[Stefan H. <st...@to...>]

The behaviour between renderers and (fill) styles is not consistent.

Quesa Interactive renderer supports TQ3FillStyle:: kQ3FillStyleEdges 
in combination with TQ3BackfacingStyle:: kQ3BackfacingStyleRemove. 
That is what you have probably seen in Geom Test.

Quesa Wireframe renderer does not support the above combination. 
Actually Quesa Wireframe should ignore TQ3FillStyle (at least 
kQ3FillStyleFilled). Quesa Wireframe + kQ3BackfacingStyleRemove 
(ignoring kQ3FillStyleFilled ) should have (more or less) the same 
(redundant) effect as Quesa Interactive + kQ3FillStyleEdges + 
kQ3BackfacingStyleRemove.

Under QD3D there was a slight difference. QD3D Interactive + 
kQ3FillStyleEdges + kQ3BackfacingStyleRemove showed triangle edges 
(exception: high level geometries like cube). QD3D Wireframe showed 
surface edges.

By the way, Quesa OpenGL renderer does not support kQ3FillStyleEdges 
in combination with kQ3BackfacingStyleRemove.

   Stefan
   http://www.topoi.ch


>Stefan Huber wrote:
>>  There are (at least for me) two missing wireframe renderer features:
>>
>>  1. Backfacing hide
>
>Why do you think this is missing?  I definitely see the difference when
>I select Backfacing Style Remove in wireframe mode in Geom Test.
>--
>    James W. Walker, Innoventive Software LLC
>    <http://www.frameforge3d.com/>

Re: More wireframe renderer

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

Stefan Huber wrote:
> There are (at least for me) two missing wireframe renderer features:
> 
> 1. Backfacing hide

Why do you think this is missing?  I definitely see the difference when 
I select Backfacing Style Remove in wireframe mode in Geom Test.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: Bug caused by emissive colour?

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

Roger Holmes wrote:

>> On Apr 14, 2007, at 4:11 PM, James W. Walker wrote:
>> Another thought: when you print, I suppose you are using a bitmap
>> draw context, yes?
> 
> Yes, though the draw contexts are a bit different on Cocoa, but I think
> the bitmap ones are the same as the Carbon ones, its only the on
> screen one that are different.

Let me know when you figure it out, because I don't understand how it 
can work on Cocoa.  When QUESA_OS_COCOA is true, GLDrawContext_New calls 
gldrawcontext_cocoa_new instead of gldrawcontext_mac_new.  But 
gldrawcontext_cocoa_new only handles kQ3DrawContextTypeCocoa, not 
kQ3DrawContextTypePixmap.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: Bug caused by emissive colour?

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

Roger Holmes wrote:
> On 15 Apr, 2007, at 00:11, James W. Walker wrote:
>> What exactly does "will not print" mean?  Did it crash, or spit out a
>> blank piece of paper, or what?
> 
> It prints a blank piece of paper, or a blank preview.

Have you tried it under OpenGL Profiler with "Break on Error" checked?
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: Bug caused by emissive colour?

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

On 15 Apr, 2007, at 00:31, James W. Walker wrote:

>
> On Apr 14, 2007, at 4:11 PM, James W. Walker wrote:
>
>> What exactly does "will not print" mean?  Did it crash, or spit out a
>> blank piece of paper, or what?
>
> Another thought: when you print, I suppose you are using a bitmap
> draw context, yes?

Yes, though the draw contexts are a bit different on Cocoa, but I think
the bitmap ones are the same as the Carbon ones, its only the on
screen one that are different. I will look into this, I need to look  
at it
anyway before I ask you to check in the Microspot changes for it,
and I had better be sure I don't give you some rubbish code to
check in.

>   Apple's OpenGL software renderer is a newer
> version on Intel than on PowerPC, not just a recompiled version of
> the same thing, so it's conceivable that you ran into a bug in the
> Apple software renderer.

Could be.

Re: Bug caused by emissive colour?

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

On 15 Apr, 2007, at 00:11, James W. Walker wrote:

>
> On Apr 12, 2007, at 10:51 AM, Roger Holmes wrote:
>
>>> I have spent the last three days tracing a problem with our
>>> application, that it will not print on PowerPC, even though it works
>>> fine on Intel.
>>> ...
>
>>> For now I will remove the offending item (and everything which
>>> references it) from my latest code and see if that cures everything
>>> for me.
>>>
>>> I'll let the list know how I get on.
>>
>> It fixes the problem for me.
>>
>> One minor bug and it  will probably be ready for issuing.
>
> I looked through all the code that involves emissive color, and I
> can't find anything suspicious.

Thank you.


>   I also tried making Geom Test draw
> something with emissive color, and running it under Guard Malloc, on
> a PowerPC machine, and no problems showed up.

Its not using emissive colour thats the problem, its something to do  
with
having the emissive colour field in the TQ3ViewStackItem record.


>
> What exactly does "will not print" mean?  Did it crash, or spit out a
> blank piece of paper, or what?

It prints a blank piece of paper, or a blank preview.

Re: C++ language features

[Jose' C. <cru...@ce...>]

Il giorno 15/apr/07, alle ore 21:42, James W. Walker ha scritto:

> Jos=E9, I thought you said you wouldn't have to do that any more after
> dropping support for VC++ 6.0?

well, unfortunately VS 2005 (the last incarnation of the beast) still =20=

has some problems with the C99 standard

the verbose boolean operators (and, or, not) are not supported (I'm =20
wondering if we can simulate it with a define -- I'll try tomorrow)

some standard functions are not defined in the std namespace or are =20
missing completely, other that some string related C99 standard =20
functions had been deprecated (!!!) and replaced with MS specific =20
"secured" versions

>
> And what happened to E3IO.c?  The commit message seems to be saying
> that the whole thing changed, but when I checked out the two versions
> and compared in BBEdit, it says nothing changed.

I managed to check-in it with the wrong end-line... (VS doesn't =20
compile...) now corrected




Pax et Bonum

# Dott. Jos=E9 Cruanyes Aguilar  -  C.E. Soft srl
#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
#   02,3923101                0372,460602

C++ language features

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

Re: "Removed C++ language features to compile with VisualStudio"

Jos=E9, I thought you said you wouldn't have to do that any more after =20=

dropping support for VC++ 6.0?

And what happened to E3IO.c?  The commit message seems to be saying =20
that the whole thing changed, but when I checked out the two versions =20=

and compared in BBEdit, it says nothing changed.=

Re: Bug caused by emissive colour?

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

On Apr 14, 2007, at 4:11 PM, James W. Walker wrote:

> What exactly does "will not print" mean?  Did it crash, or spit out a
> blank piece of paper, or what?

Another thought: when you print, I suppose you are using a bitmap  
draw context, yes?  Apple's OpenGL software renderer is a newer  
version on Intel than on PowerPC, not just a recompiled version of  
the same thing, so it's conceivable that you ran into a bug in the  
Apple software renderer.

Re: Bug caused by emissive colour?

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

On Apr 12, 2007, at 10:51 AM, Roger Holmes wrote:

>> I have spent the last three days tracing a problem with our
>> application, that it will not print on PowerPC, even though it works
>> fine on Intel.
>> ...

>> For now I will remove the offending item (and everything which
>> references it) from my latest code and see if that cures everything
>> for me.
>>
>> I'll let the list know how I get on.
>
> It fixes the problem for me.
>
> One minor bug and it  will probably be ready for issuing.

I looked through all the code that involves emissive color, and I  
can't find anything suspicious.  I also tried making Geom Test draw  
something with emissive color, and running it under Guard Malloc, on  
a PowerPC machine, and no problems showed up.

What exactly does "will not print" mean?  Did it crash, or spit out a  
blank piece of paper, or what?

3DS Writer

[Jose' C. <cru...@ce...>]

Well, It's here
the first Quesa plug-in writer has arrived...

Currently only on Mac, and currently only the geometry... but it's a =20
start :-)

To try it, install it and uncomment line 2474 of GeomTest.c ...

we have to think a clean way to put the PutFile Dialog using the =20
plugged in writers...
I will try something next week while porting the plug-in to Win32 =20
(the Mac versions of Qut_SelectMetafilexxxx need a deep refresh =20
anyway...)


Pax et Bonum

# Dott. Jos=E9 Cruanyes Aguilar  -  C.E. Soft srl
#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
#   02,3923101                0372,460602