quesa-develop — Mailing list for Quesa development

Re: texture alpha: premultiplied or not?

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

On 11 May, 2007, at 00:08, James Walker wrote:

> Back in 2004, there was some discussion here about the fact that the
> Interactive Renderer essentially assumes that ARGB textures use
> premultiplied alpha, and questioning whether it ought to be an option.
> Yesterday I changed the OpenGL renderer to assume non-premultiplied
> alpha, but now I'm wondering if that was too rash.
>
> The QD3D manual doesn't seem to give any hint whether alpha should be
> premultiplied or not.  I believe there was a claim in 2004 that
> QuickDraw 3D did use premultiplied alpha, but I can't confirm that
> today.  When I loaded an ARGB texture test in Classic Geom Test, the
> result doesn't agree with either of our renderers.

You mean the interactive renderers in Quesa and QuckDraw3D are  
different?
>
> If you'd like to check it yourself, my test model is here:
> <ftp://ftp.frameforge3d.com/misc/texture-argbT.3dmf.zip>.  It  
> contains 2
> flat TriMeshes.  One is opaque and gray, another has an ARGB texture
> whose background has alpha = 0, color = white, intended for use as
> non-premultiplied.  The opaque TriMesh looks transparent in Classic,
> which I don't understand at all.

Er, maybe I'm being thick (as usual), but alpha==0 means transparent,  
alpha ==1.0 (or 0xFF) means opaque. What's to not understand?

>
> Anyway, in the previous discussion, it was suggested that the
> premultipled flag could be set with an object property on the  
> renderer,
> or a new style object.  It occurs to me now that it might make  
> sense to
> set it at the level of individual textures... maybe a new pixel type
> constant like kQ3PixelTypeARGB32Premultiplied, maybe an object  
> property
> or custom element.

Sounds like a good idea to me, data can be imported into my programs  
so if you are going to support two types of alpha data, then the type  
needs to be bound to the data, how else could I render an image with  
a mixture of pre-multiplied and non pre-multiplied textures on many  
objects, pixmap markers, foreground and background images.

When was the concept of pre-multiplied alpha invented? After  
QuickDraw3D?

We should try to make existing data files to appear the same by  
default whenever possible.

Roger.

Re: texture alpha: premultiplied or not?

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

jo...@st... wrote:
> On May 10, 2007, at 23:08 UTC, James Walker wrote:
> 
>> Back in 2004, there was some discussion here about the fact that the 
>> Interactive Renderer essentially assumes that ARGB textures use 
>> premultiplied alpha, and questioning whether it ought to be an
>> option.  Yesterday I changed the OpenGL renderer to assume non
>> -premultiplied  alpha, but now I'm wondering if that was too rash.
> 
> I'd say so.  :)  First, you don't want to break existing software; and
> second, premultiplied alpha can be very useful in making (for example)
> "glow" effects.
> 
>> The QD3D manual doesn't seem to give any hint whether alpha should be
>> premultiplied or not.  I believe there was a claim in 2004 that 
>> QuickDraw 3D did use premultiplied alpha, but I can't confirm that 
>> today.  When I loaded an ARGB texture test in Classic Geom Test, the 
>> result doesn't agree with either of our renderers.
> 
> Hmm.  That's surprising.  It's been a while, of course, but I was sure
> that textures have worked the same way in Quesa as in QD3D from the
> beginning.  Certainly neither I nor my artist partner (Jeff Quan) have
> ever noticed the difference -- and he's even written a tutorial on the
> proper use of premultiplied alpha.  That was for Meshwork users, and
> was years ago, so I'd think he/we would have tested it under QD3D.

OK...

>> Anyway, in the previous discussion, it was suggested that the 
>> premultipled flag could be set with an object property on the
>> renderer,  or a new style object.  It occurs to me now that it might
>> make sense to  set it at the level of individual textures... maybe a
>> new pixel type  constant like kQ3PixelTypeARGB32Premultiplied, maybe
>> an object property  or custom element.
> 
> That'd be OK, but for the sort of thing I've done, it would be
> overkill.  An object property on the renderer would be fine, and a
> style object would be even finer.  I don't see a need to be more
> granular than that.  Most objects either need to glow, or they don't --
> and it's certainly not hard to premultiply some of the textures if
> needed.

Maybe even that's overkill.  Maybe I should just document that 
premultiplied alpha is expected, say next to kQ3PixelTypeARGB32 in the 
header docs.  As for the OpenGL renderer, I didn't like the switching 
back and forth between glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA) 
and glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA), but I could go the 
other way: use premultiplied alpha even for vertex colors, and always 
use glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA).

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

Re: texture alpha: premultiplied or not?

[<jo...@st...>]

On May 10, 2007, at 23:08 UTC, James Walker wrote:

> Back in 2004, there was some discussion here about the fact that the 
> Interactive Renderer essentially assumes that ARGB textures use 
> premultiplied alpha, and questioning whether it ought to be an
> option.  Yesterday I changed the OpenGL renderer to assume non
> -premultiplied  alpha, but now I'm wondering if that was too rash.

I'd say so.  :)  First, you don't want to break existing software; and
second, premultiplied alpha can be very useful in making (for example)
"glow" effects.

> The QD3D manual doesn't seem to give any hint whether alpha should be
> premultiplied or not.  I believe there was a claim in 2004 that 
> QuickDraw 3D did use premultiplied alpha, but I can't confirm that 
> today.  When I loaded an ARGB texture test in Classic Geom Test, the 
> result doesn't agree with either of our renderers.

Hmm.  That's surprising.  It's been a while, of course, but I was sure
that textures have worked the same way in Quesa as in QD3D from the
beginning.  Certainly neither I nor my artist partner (Jeff Quan) have
ever noticed the difference -- and he's even written a tutorial on the
proper use of premultiplied alpha.  That was for Meshwork users, and
was years ago, so I'd think he/we would have tested it under QD3D.

> Anyway, in the previous discussion, it was suggested that the 
> premultipled flag could be set with an object property on the
> renderer,  or a new style object.  It occurs to me now that it might
> make sense to  set it at the level of individual textures... maybe a
> new pixel type  constant like kQ3PixelTypeARGB32Premultiplied, maybe
> an object property  or custom element.

That'd be OK, but for the sort of thing I've done, it would be
overkill.  An object property on the renderer would be fine, and a
style object would be even finer.  I don't see a need to be more
granular than that.  Most objects either need to glow, or they don't --
and it's certainly not hard to premultiply some of the textures if
needed.

Best,
- Joe

--
Joe Strout -- jo...@st...
Strout Custom Solutions

texture alpha: premultiplied or not?

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

Back in 2004, there was some discussion here about the fact that the 
Interactive Renderer essentially assumes that ARGB textures use 
premultiplied alpha, and questioning whether it ought to be an option. 
Yesterday I changed the OpenGL renderer to assume non-premultiplied 
alpha, but now I'm wondering if that was too rash.

The QD3D manual doesn't seem to give any hint whether alpha should be 
premultiplied or not.  I believe there was a claim in 2004 that 
QuickDraw 3D did use premultiplied alpha, but I can't confirm that 
today.  When I loaded an ARGB texture test in Classic Geom Test, the 
result doesn't agree with either of our renderers.

If you'd like to check it yourself, my test model is here: 
<ftp://ftp.frameforge3d.com/misc/texture-argbT.3dmf.zip>.  It contains 2 
flat TriMeshes.  One is opaque and gray, another has an ARGB texture 
whose background has alpha = 0, color = white, intended for use as 
non-premultiplied.  The opaque TriMesh looks transparent in Classic, 
which I don't understand at all.

Anyway, in the previous discussion, it was suggested that the 
premultipled flag could be set with an object property on the renderer, 
or a new style object.  It occurs to me now that it might make sense to 
set it at the level of individual textures... maybe a new pixel type 
constant like kQ3PixelTypeARGB32Premultiplied, maybe an object property 
or custom element.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: Multi-pass rendering

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

Il giorno 08/mag/07, alle ore 02:33, James Walker ha scritto:

> I ran into a problem with transparency when using multiple passes for
> lighting.  I started a thread at OpenGL.org:
>
> <http://www.opengl.org/discussion_boards/ubb/ultimatebb.php?=20
> ubb=3Dget_topic;f=3D3;t=3D015193>
>
> Anyone who has anything to add, please comment there or here.


unfortunately, I'm not using this feature at the moment.

Pax et Bonum

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

Multi-pass rendering

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

I ran into a problem with transparency when using multiple passes for 
lighting.  I started a thread at OpenGL.org:

<http://www.opengl.org/discussion_boards/ubb/ultimatebb.php?ubb=get_topic;f=3;t=015193>

Anyone who has anything to add, please comment there or here.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

HiddenLine Renderer

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

I've added a draft for a hidden line removal renderer.

It's a multipass OpenGL renderer, and in its current state is more a  
proof of concept than anything.

It registers two renderers, one technical, and another more  
cartoonish, none of them will remain in Quesa in the current state,  
since it's still a work in progress.

We hope they will lite some bulb over your head, and after some more  
drafts and development, we decide which one (or ones) remain as  
renderer in Quesa

with the modifications made to the OpenGL renderer, it's fairly  
simple make fancy things with renderers,

in fact the hiddenline.cpp file is just administrative stuff  
(metahandlers and friends) and almost all the dancing is done inside  
the StartPass methods.

Re: RayShade Camera Orthographic

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

I understand the problem.
I thought to do this but shadow aren't always correct.
Thank's.

Jose' Cruanyes ha scritto:
> Il giorno 03/mag/07, alle ore 11:09, Daniele Cavallini ha scritto:
>
>   
>> With RayShade render is it possible to use correctly
>> Q3OrthographicCamera_New?
>> I tried it but seem don't work.
>>     
>
> the current implementation of the ray tracer assumes a point of view  
> from where cast rays...
>
> you can try to put it in the infinite (32 bit float point values  
> speaking), with a little focal aperture... it is not orthographic but  
> you can go fairly close
>
>
> Pax et Bonum
>
> # Dott. José Cruanyes Aguilar  -  C.E. Soft srl
> #  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
> #   02,3923101                0372,460602
>
>
>
> -------------------------------------------------------------------------
> 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
>
>   

Faking a view plane camera

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

Not sure if this would be of use to anyone, but I came across a  
function I wrote awhile back to get a view angle aspect camera to  
behave more like a view plane camera.  I guess I wrote it because at  
the time, Quesa hadn't implemented the latter.  If view plane cameras  
are now supported, well then, never mind...

It's sort of a half-implementation, in that it only converts from  
TQ3ViewPlaneCameraData to TQ3ViewAngleAspectCameraData and not the  
other way around, but that's all I needed in my case.  Also, I had to  
strip out some C++ class code to generalize it better, so hopefully  
that didn't break anything.

-Ted

Re: RayShade Camera Orthographic

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

Il giorno 03/mag/07, alle ore 11:09, Daniele Cavallini ha scritto:

> With RayShade render is it possible to use correctly
> Q3OrthographicCamera_New?
> I tried it but seem don't work.

the current implementation of the ray tracer assumes a point of view =20
from where cast rays...

you can try to put it in the infinite (32 bit float point values =20
speaking), with a little focal aperture... it is not orthographic but =20=

you can go fairly close


Pax et Bonum

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

RayShade Camera Orthographic

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

With RayShade render is it possible to use correctly 
Q3OrthographicCamera_New?
I tried it but seem don't work.

Re: 3DS Writer

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

Il giorno 01/mag/07, alle ore 02:02, James Walker ha scritto:

> Jose' Cruanyes wrote:
>
>> 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 :-)
>
> What about 3DS reading?  Do you plan to make it handle materials?

in the previous mail I've hit the "send" button too soon...

the materials (and uv params, and normals, etc) are already parsed =20
out of the file and stored in structures
it's just matter of add them to the trimesh when it gets created...


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 01/mag/07, alle ore 02:02, James Walker ha scritto:

> Jose' Cruanyes wrote:
>
>> 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 :-)
>
> What about 3DS reading?  Do you plan to make it handle materials?


Not at the moment, our priorities are other now

-hidden-line openGL rendering
-make Rayshade correctly handle materials in case of nested groups

our software is more a producer than a consumer of 3D models, so our =20
priorities are to export more that import...

we're evaluating support for .wrl (a much better format than .3ds) =20
but no promises...


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

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

Jose' Cruanyes wrote:

> 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 :-)

What about 3DS reading?  Do you plan to make it handle materials?

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

Re: Refection in the RayShade renderer

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

I see now.

Perhaps it might be better for me to change my program to refer to =20
roughness and smoothness rather than matt and gloss.

Thank you very much for the lesson, please disregard my earlier =20
ramblings.


On 28 Apr, 2007, at 11:48, Jose' Cruanyes wrote:

>
> Il giorno 28/apr/07, alle ore 12:15, Roger Holmes ha scritto:
>
>> Are you saying the more reflective one on the left is matt and the
>> less reflective one on the right is glossy?
>> If so our program has had its controls labelled back to front for
>> many years. Interesting!
>
>
> keep aside the fact that my english is limited, so certain details of
> the adjectives can be misunderstanding...
>
> #define "wheat flour" matte
> #define "car paint" glossy
>
> with these definitions the right torus is glossy and the left one is
> matte
>
> another aspect is which one cast more light in the direction of the
> observer
> in this case a matte object is more "brilliant" because it's rough
> surface reflect light in every direction, while a glossy object
> reflects the light in just one
>
> in a limit case, a perfect mirror in a black space is invisible
> except in the direction where the light is reflected
>
>
> so in my opinion one thing is the amount of light reflected, and
> another is how mirror-like is an object
>
> so the "sugar coated donut" in the left, can't reflect the objects
> around it, even if it is more bright, while I expect to see the
> objects around the right torus reflected on it
>
> you can see a discussion at:
>
> <http://www.artifice.com/support/user_guide/documents/tips/
> specularity.html>
>
>
>
> 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

Re: Refection in the RayShade renderer

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

Il giorno 28/apr/07, alle ore 12:15, Roger Holmes ha scritto:

> Are you saying the more reflective one on the left is matt and the =20
> less reflective one on the right is glossy?
> If so our program has had its controls labelled back to front for =20
> many years. Interesting!


keep aside the fact that my english is limited, so certain details of =20=

the adjectives can be misunderstanding...

#define "wheat flour" matte
#define "car paint" glossy

with these definitions the right torus is glossy and the left one is =20
matte

another aspect is which one cast more light in the direction of the =20
observer
in this case a matte object is more "brilliant" because it's rough =20
surface reflect light in every direction, while a glossy object =20
reflects the light in just one

in a limit case, a perfect mirror in a black space is invisible =20
except in the direction where the light is reflected


so in my opinion one thing is the amount of light reflected, and =20
another is how mirror-like is an object

so the "sugar coated donut" in the left, can't reflect the objects =20
around it, even if it is more bright, while I expect to see the =20
objects around the right torus reflected on it

you can see a discussion at:

<http://www.artifice.com/support/user_guide/documents/tips/=20
specularity.html>



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...>]

Here is a screen dump of the Quesa Interactive renderer.

On the left is a 50% grey torus with Quesa's SpecularControl set to 0.2.
On the right is an identical torus but with Quesa's SpecularControl  
set to about 219.
There is an ambient light and a a directional light.

Are you saying the more reflective one on the left is matt and the  
less reflective one on the right is glossy?
If so our program has had its controls labelled back to front for  
many years. Interesting!

Re: Refection in the RayShade renderer

[Sauro A. <int...@in...>]

>Il giorno 27/apr/07, alle ore 23:15, Jose' Cruanyes 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 
>>  reflecting...
>>
>>  anyway I'd like to be as compatible as possible...
>
>how are the parameters in the microspot renderer?
>
>and while at that, how do you pass the materials to the renderer? a 
>custom attribute?
>why don't make it a standard in Quesa,
>We're planning to support bump mappings, procedural shaders and other 
>features already present in RayShade
>

The internal code of RayShade supports a complete=20
ray tracing renderer, we could have all these=20
features in Quesa passing in some way the=20
necessary parameters, but the most part of these=20
parameters aren't actually present in Quesa.

It makes sense for me to go on with this simple=20
and fast implementation of reflection, because it=20
doesn't request any modification to the=20
applications that  actually support Quesa and all=20
of us can try and experiment this solution.

But there aren't simple solutions like this for=20
other RayShade functions, like procedural=20
shaders, bump mapping and others.

We could implement these parameters in Quesa or=20
pass them to RayShade and other renderers as=20
custom attributes.

I prefer the first solution, because it is more=20
general and the same parameters can be shared by=20
all the renderers. The second solution has the=20
advantage of not requesting any modification of=20
the Quesa code, it could be done modifying=20
Rayshade only, anyway a standardization of the=20
attributes is necessary.

Sauro


>
>
>Pax et Bonum
>
># Dott. Jos=E9 Cruanyes Aguilar  -  C.E. Soft srl
>#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
>#   02,3923101                0372,460602
>
>
>
>-------------------------------------------------------------------------
>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


-- 
----------------------------------------------------------------------------=
-
  _ ___
|_| __|  Interstudio S.r.l.      Tel + 39 0573 99291   Fax   + 39 0573=
 992930 
| |__ |  Piazza Monteoliveto 6a                    http://www.interstudio.ne=
t
|_____|  I-51100 Pistoia Italy             mailto:int...@in...=
t
----------------------------------------------------------------------------=
-

Re: 3DS Writer

[Kevin M. <mat...@ar...>]

Great news, thanks for highlighting it!

- K


On Fri, 27 Apr 2007 11:29:28 +0200, Jose' Cruanyes wrote:
>=20
> Il giorno 14/apr/07, alle ore 19:35, Jose' Cruanyes ha scritto:
>=20
>> Well, It's here
>> the first Quesa plug-in writer has arrived...
>>=20
>> Currently only on Mac, and currently only the geometry... but it's a
>> start :-)
>>=20
>> To try it, install it and uncomment line 2474 of GeomTest.c ...
>>=20
>> 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...)
>>=20
>=20
> For those not following the CVS activity list
>=20
> 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)
>=20
> It has been ported to Windows too...
>=20
> To try it, install it and uncomment line 2474 of GeomTest.c ...
>=20
>=20
> Pax et Bonum
>=20
> # Dott. Jos=E9 Cruanyes Aguilar  -  C.E. Soft srl
> #  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
> #   02,3923101                0372,460602
>=20
>=20
>=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

Re: Refection in the RayShade renderer

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

Jose' Cruanyes wrote:
> Il giorno 27/apr/07, alle ore 22:45, James Walker ha scritto:
> 
>> 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.
> 
> I've think about it, to make the reflection value based in the  
> luminance of the specular color, but at last I've opted for the  
> reasoning in the previous mail, to have a parameter easier to set by  
> the user
> 
> I'm open to suggestions

There is no perfect way to map two degrees of freedom to one.  But 
perhaps you could use some function of the product of specular control 
and specular luminance.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: Refection in the RayShade renderer

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

and those with an specular control of 1000

the Quesa logo is not the best geometry to see the effect, but  
overall the lighting effect is pretty much the same

Re: Refection in the RayShade renderer

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

These are with an specular control of 100
put side by side with the other, made with delault (4) specular control

Re: Refection in the RayShade renderer

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

Il giorno 27/apr/07, alle ore 23:15, Jose' Cruanyes 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...

how are the parameters in the microspot renderer?

and while at that, how do you pass the materials to the renderer? a =20
custom attribute?
why don't make it a standard in Quesa,
We're planning to support bump mappings, procedural shaders and other =20=

features already present in RayShade




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...>]

Il giorno 27/apr/07, alle ore 22:45, James Walker ha scritto:

> 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 =20
>>> 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 =20
> accurate
> to say that you get a non-reflecting surface by setting the specular
> color to black, never mind the value of GL_SHININESS.

I've think about it, to make the reflection value based in the =20
luminance of the specular color, but at last I've opted for the =20
reasoning in the previous mail, to have a parameter easier to set by =20
the user

I'm open to suggestions


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...>]

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

>
> 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?
>

which is which?
hint: look the shadows