quesa-develop — Mailing list for Quesa development

Re: Alpha channel in RayShade

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

Il giorno 06/lug/07, alle ore 14:49, Roger Holmes ha scritto:

>
> On 5 Jul, 2007, at 20:40, Jose' Cruanyes wrote:
>
>>
>> I vote to maintain four floats till is converted to the native format
>>
>> the code to write the pixels to the destination bitmap is ugly to say
>> the least, specially on windows, so I think it has to be reworked.
>
>
> OK, will do.
>
>>
>> On the other hand, while experimenting with spherical lights, I've
>> noted problems with the antialiasing, but I've not gone much further
>> since,
>
> Is this the same problem we are seeing with spheres?
>
> We are doing an animation of a virtual pool table and we see
> horrendous random white speckles around the periphery of some of the
> balls and sometime a similar round pattern of white speckles on the
> cloth of the pool table.

No, this problem is another, it stops a recursion too early...
to solve it go to line 242 of file RTInterface/RT.cpp
and change

Options.maxdepth =3D MAXDEPTH;

to something bigger (MAXDEPTH is defined as 5) like 8

please note that for every unit added the render time is doubled

We're working on those files... expect the first batch of changes =20
this evening, so don't work too heavy on this...


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: Alpha channel in RayShade

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

On 5 Jul, 2007, at 20:40, Jose' Cruanyes wrote:

>
> I vote to maintain four floats till is converted to the native format
>
> the code to write the pixels to the destination bitmap is ugly to say
> the least, specially on windows, so I think it has to be reworked.


OK, will do.

>
> On the other hand, while experimenting with spherical lights, I've
> noted problems with the antialiasing, but I've not gone much further
> since,

Is this the same problem we are seeing with spheres?

We are doing an animation of a virtual pool table and we see  
horrendous random white speckles around the periphery of some of the  
balls and sometime a similar round pattern of white speckles on the  
cloth of the pool table.


>
> if we have to redo the antialiasing code (cubic and gaussian)
> probably is better to have the data as four floats, the size is not a
> problem, anyway we need just a tiny strip of data that will be copied
> to the destination buffer


OK.



Roger.

Re: Alpha channel in RayShade

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

Il giorno 05/lug/07, alle ore 20:57, Roger Holmes ha scritto:

> I need to change RayShade to support the alpha channel.
>
> Currently each pixel is encoded as four floats, r,g,b and alpha. This
> is then converted to three bytes when the alpha is thrown away. This
> is then converted back to the representation desired by the
> application and O.S. . I can do it three different ways, by making
> the internal buffer always four bytes, or always four floats, or by
> looking at the output representation and using either three or four
> bytes as appropriate. For simplicity, I favour the four byte
> approach, though at the cost of a larger buffer, but then RAM is now
> fairly cheap.
>
> Your thoughts please.
>
> Roger.


I vote to maintain four floats till is converted to the native format

the code to write the pixels to the destination bitmap is ugly to say =20=

the least, specially on windows, so I think it has to be reworked.

On the other hand, while experimenting with spherical lights, I've =20
noted problems with the antialiasing, but I've not gone much further =20
since,

if we have to redo the antialiasing code (cubic and gaussian) =20
probably is better to have the data as four floats, the size is not a =20=

problem, anyway we need just a tiny strip of data that will be copied =20=

to the destination buffer



Pax et Bonum

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

Alpha channel in RayShade

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

I need to change RayShade to support the alpha channel.

Currently each pixel is encoded as four floats, r,g,b and alpha. This  
is then converted to three bytes when the alpha is thrown away. This  
is then converted back to the representation desired by the  
application and O.S. . I can do it three different ways, by making  
the internal buffer always four bytes, or always four floats, or by  
looking at the output representation and using either three or four  
bytes as appropriate. For simplicity, I favour the four byte  
approach, though at the cost of a larger buffer, but then RAM is now  
fairly cheap.

Your thoughts please.

Roger.

Re: RayTrace bug is not in RayTrace but in Quesa, just nobody's noticed before.

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

On 3 Jul, 2007, at 01:02, Jose' Cruanyes wrote:

>
> Il giorno 03/lug/07, alle ore 00:45, Roger Holmes ha scritto:
>
>> It cannot be as simple as it seems. Other renderers DO display
>> different intensities when the matt/gloss/mirror slider in my app is
>> dragged about, so I do not understand why RayShade doesn't.
>>
>> Roger.
>
>
> probably has something to do the fact that RayShade uses triangles
> instead of trimeshes...
>
> if so, the culprit is to be searched in the decomposition trimesh ->
> triangles

I've spent too much time on this. As a quick and dirty fix I have  
changed my Apps to increment the object's edited count when I change  
its specular control. It fixes it for me, does no harm and nobody  
else is seeing the problem anyway.

Roger.

Re: RayTrace bug is not in RayTrace but in Quesa, just nobody's noticed before.

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

Il giorno 03/lug/07, alle ore 00:45, Roger Holmes ha scritto:

> It cannot be as simple as it seems. Other renderers DO display
> different intensities when the matt/gloss/mirror slider in my app is
> dragged about, so I do not understand why RayShade doesn't.
>
> Roger.


probably has something to do the fact that RayShade uses triangles =20
instead of trimeshes...

if so, the culprit is to be searched in the decomposition trimesh -> =20
triangles

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: RayTrace bug is not in RayTrace but in Quesa, just nobody's noticed before.

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

On 2 Jul, 2007, at 20:53, Roger Holmes wrote:

>
> Its not actually in RayTrace. If I put "return false ;" at the top
> of  e3geometry_cache_isvalid, then everything runs OK. So it seems
> there is a bug in Quesa's caching code which does not notice that the
> specular control has changed. Actually I can't see anything for
> things like the diffuse colour being changed either, so how do these
> work? Should Quesa check for the edit index of the geometry's
> attribute set? But then attributes can be in the group the geometry
> is in and in any group out from that. If someone can tell me how this
> works I can probably do the fix.


Sorry about replying to my own e-mails.

It cannot be as simple as it seems. Other renderers DO display  
different intensities when the matt/gloss/mirror slider in my app is  
dragged about, so I do not understand why RayShade doesn't.

Roger.

RayTrace bug is not in RayTrace but in Quesa, just nobody's noticed before.

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

On 2 Jul, 2007, at 15:27, Jose' Cruanyes wrote:

>
>>
>> Hate to curb your enthusiasm for new stuff, but any news on the
>> caching problem in RayShade?
>>
> I've no problem, but probably I'm using it very differently than you
>
> please trace RS_UpdateAttributes in the RS_Update.cpp file to see how
> the specular control value changes
>


Its not actually in RayTrace. If I put "return false ;" at the top  
of  e3geometry_cache_isvalid, then everything runs OK. So it seems  
there is a bug in Quesa's caching code which does not notice that the  
specular control has changed. Actually I can't see anything for  
things like the diffuse colour being changed either, so how do these  
work? Should Quesa check for the edit index of the geometry's  
attribute set? But then attributes can be in the group the geometry  
is in and in any group out from that. If someone can tell me how this  
works I can probably do the fix.

Roger.

Re: Spherical Light

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

On Jul 2, 2007, at 7:27 AM, Jose' Cruanyes wrote:

>
> Il giorno 02/lug/07, alle ore 15:42, Roger Holmes ha scritto:
>>

>> If it needs an extra data field, your spherical light should inherit
>> from point light. Can we make it so that renderers which do not
>> support them see the base class instead, and just give crisper
>> shadows.
>
> I've not still decided, but the better (IMHO) will be to extend the
> point light, call it spherical, and let access it fron the old API as
> point light, when the radius data will be ignored
>
> the problem will be the metafile I/O, in reading old files there's no
> problem, the problem is in reading new files with old code... the
> lights will be lost, since it will be saved as spherical, and the old
> code expects point lights, unless we don't save the lights with
> radius 0.0 as point lights...
>
> I'll update the Quesa renderers to use it as point light,
>
> for the Microspot, you can just add a case label and treat it as
> point light,

If a spherical light is a subclass of point light, then presumably  
Q3Light_GetType would return kQ3LightTypePoint for a spherical light,  
and the Interactive and OpenGL renderers would not need any update.

Re: Spherical Light

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

Il giorno 02/lug/07, alle ore 15:42, Roger Holmes ha scritto:

>
> On 2 Jul, 2007, at 12:23, Jose' Cruanyes wrote:
>
>> Since Rayshade supports spherical lights, it could be a good addition
>> to Quesa
>>
>> it's just a point lighi with a diameter, and it creates a blurred
>> shadow (really nice)
>>
>> I can derive it from point light (or the other way around, since the
>> point light is an especial case of spherical light)
>> or create a completely new type
>>
>> what is better?
>
>
> If it needs an extra data field, your spherical light should inherit
> from point light. Can we make it so that renderers which do not
> support them see the base class instead, and just give crisper =20
> shadows.

I've not still decided, but the better (IMHO) will be to extend the =20
point light, call it spherical, and let access it fron the old API as =20=

point light, when the radius data will be ignored

the problem will be the metafile I/O, in reading old files there's no =20=

problem, the problem is in reading new files with old code... the =20
lights will be lost, since it will be saved as spherical, and the old =20=

code expects point lights, unless we don't save the lights with =20
radius 0.0 as point lights...

I'll update the Quesa renderers to use it as point light,

for the Microspot, you can just add a case label and treat it as =20
point light,

>
> Hate to curb your enthusiasm for new stuff, but any news on the
> caching problem in RayShade?
>
I've no problem, but probably I'm using it very differently than you

please trace RS_UpdateAttributes in the RS_Update.cpp file to see how =20=

the specular control value changes



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: Spherical Light

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

On 2 Jul, 2007, at 12:23, Jose' Cruanyes wrote:

> Since Rayshade supports spherical lights, it could be a good addition
> to Quesa
>
> it's just a point lighi with a diameter, and it creates a blurred
> shadow (really nice)
>
> I can derive it from point light (or the other way around, since the
> point light is an especial case of spherical light)
> or create a completely new type
>
> what is better?


If it needs an extra data field, your spherical light should inherit  
from point light. Can we make it so that renderers which do not  
support them see the base class instead, and just give crisper shadows.

Hate to curb your enthusiasm for new stuff, but any news on the  
caching problem in RayShade?

Spherical Light

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

Since Rayshade supports spherical lights, it could be a good addition =20=

to Quesa

it's just a point lighi with a diameter, and it creates a blurred =20
shadow (really nice)

I can derive it from point light (or the other way around, since the =20
point light is an especial case of spherical light)
or create a completely new type

what is better?


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: OpenGL Renderers Reorganization

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

Il giorno 29/giu/07, alle ore 19:26, James Walker ha scritto:

> Jose' Cruanyes wrote:
>> We're ready to go on with the Hiddenline renderers, but I'm not sure
>> that poluting the Quesa space is the way to go, also because we want
>> to create several different renderers.
>>
>> so we want to detach the renderers from quesa.
>>
>> there are several options,
>> one Quick n dirty  that is use several #defines to turn on and off
>> the renderers at compile time,
>> and the other is to make all the renderers (minus one?) plug-ins.
>>
>> the problem with the second approach is that the Open GL renderers
>> (that forms the base class for all others) uses private View methods
>> and data, so we have to make them public.
>
> Private view *data*?  I don't remember any such case.  If I search the
> OpenGL renderer folder for "E3View", I only find the function calls:
>
> E3View_State_SetShaderSurface
> E3View_SubmitRetained

E3View_State_SetShaderSurface is not a public method... and in the =20
case we need to pubblish the whole set...
Anyway is not a problem now since I've decided for including =20
everything and control it with properties

>
> It seems to me that the bigger problem with separating renderers into
> plug-ins is the fact that subclasses of the OpenGL renderer use =20
> methods
> and members of the base class.

this is not a problem if you're willing to duplicate the code in =20
every plug-in



>
>> the third approach is to leave the OpenGL Hiddenline renderer (only
>> one) on by default,
>
> I'm not sure I understand what you mean here.  Make the hidden-line
> renderer, but not its base class, the only built-in renderer?

my problem is that I want to have several hidden-line renderers in my =20=

app (other than the 'classics' renderers Wireframe-interactive-OpenGL-=20=

Cartoon, that are not in discussion)

but in the current state I've to compile them inside the Quesa Lib... =20=

leading to too many renderers in the default installation..

So I'll made a single hidden-line, controlled by a bunch of properties,
Also with the rayshade I want to pubblish a number of properties =20
(gamma correction and antialias level, and antialias method are the =20
first three)


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: OpenGL Renderers Reorganization

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

On 29 Jun, 2007, at 18:26, James Walker wrote:

>
> Then you'd have an illumination shader that only works in the OpenGL
> renderer, unless you want to implement it multiple times.  I  
> suppose the
> advantage is that it would be easier to choose not to render certain
> objects in cartoon style.


Good point, but on the other hand, not all renderers support all  
illumination styles e.g. the wireframe renderer.

Re: RayShade change

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

On 29 Jun, 2007, at 18:31, James Walker wrote:

>
> Done.  I wonder if similar fixes are needed for 16-bit color?
>


Does any graphics generator on Intel support 16 bit colour? Probably  
not on PC but just maybe early Intel Macs. Not sure. Probably less  
likely a problem with every passing day.

Roger.

Re: RayShade change

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

Roger Holmes wrote:
> Could one of you please check in this change for me:
> 
> In RayShade, in RS_Rasterize.cpp, in RSRasterizer_Rasterize_RGB_Span_PM
> 
> Please change:
> 
> 			case kQ3PixelTypeRGB32:
> 			case kQ3PixelTypeARGB32:
> 				{
> 					unsigned int pixel;
> 					pixel = 	(0xFF << 24) |
> 								(rgbPixels[i][0] << 16) |
> 								(rgbPixels[i][1] << 8)  |
> 								(rgbPixels[i][2] << 0);
> 					*((unsigned int *)rowAddr) = pixel;
> 				}
> 				break;
> 
> 
> 
> 
> To:
> 
> 
> 
> 			case kQ3PixelTypeRGB32:
> 			case kQ3PixelTypeARGB32:
> 				{
> 					unsigned int pixel;
> #if QUESA_HOST_IS_BIG_ENDIAN
> 					pixel = 	(0xFF << 24) |
> 								(rgbPixels[i][0] << 16) |
> 								(rgbPixels[i][1] << 8)  |
> 								(rgbPixels[i][2] << 0);
> 					*((unsigned int *)rowAddr) = pixel;
> #else
> 					pixel = 	(0xFF << 0) |
> 								(rgbPixels[i][0] << 8)  |
> 								(rgbPixels[i][1] << 16) |
> 								(rgbPixels[i][2] << 24);
> 					*((unsigned int *)rowAddr) = pixel;
> #endif
> 				}
> 				break;
> 
> 
> 
> Many thanks.

Done.  I wonder if similar fixes are needed for 16-bit color?

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

Re: OpenGL Renderers Reorganization

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

Jose' Cruanyes wrote:
> We're ready to go on with the Hiddenline renderers, but I'm not sure  
> that poluting the Quesa space is the way to go, also because we want  
> to create several different renderers.
> 
> so we want to detach the renderers from quesa.
> 
> there are several options,
> one Quick n dirty  that is use several #defines to turn on and off  
> the renderers at compile time,
> and the other is to make all the renderers (minus one?) plug-ins.
> 
> the problem with the second approach is that the Open GL renderers  
> (that forms the base class for all others) uses private View methods  
> and data, so we have to make them public.

Private view *data*?  I don't remember any such case.  If I search the 
OpenGL renderer folder for "E3View", I only find the function calls:

E3View_State_SetShaderSurface
E3View_SubmitRetained

It seems to me that the bigger problem with separating renderers into 
plug-ins is the fact that subclasses of the OpenGL renderer use methods 
and members of the base class.

> the third approach is to leave the OpenGL Hiddenline renderer (only  
> one) on by default,

I'm not sure I understand what you mean here.  Make the hidden-line 
renderer, but not its base class, the only built-in renderer?

> Also, What about make the cartoon renderer a illumination style like  
> Phong or Lambert?

Then you'd have an illumination shader that only works in the OpenGL 
renderer, unless you want to implement it multiple times.  I suppose the 
advantage is that it would be easier to choose not to render certain 
objects in cartoon style.

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

RayShade change

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

Could one of you please check in this change for me:

In RayShade, in RS_Rasterize.cpp, in RSRasterizer_Rasterize_RGB_Span_PM

Please change:

			case kQ3PixelTypeRGB32:
			case kQ3PixelTypeARGB32:
				{
					unsigned int pixel;
					pixel = 	(0xFF << 24) |
								(rgbPixels[i][0] << 16) |
								(rgbPixels[i][1] << 8)  |
								(rgbPixels[i][2] << 0);
					*((unsigned int *)rowAddr) = pixel;
				}
				break;




To:



			case kQ3PixelTypeRGB32:
			case kQ3PixelTypeARGB32:
				{
					unsigned int pixel;
#if QUESA_HOST_IS_BIG_ENDIAN
					pixel = 	(0xFF << 24) |
								(rgbPixels[i][0] << 16) |
								(rgbPixels[i][1] << 8)  |
								(rgbPixels[i][2] << 0);
					*((unsigned int *)rowAddr) = pixel;
#else
					pixel = 	(0xFF << 0) |
								(rgbPixels[i][0] << 8)  |
								(rgbPixels[i][1] << 16) |
								(rgbPixels[i][2] << 24);
					*((unsigned int *)rowAddr) = pixel;
#endif
				}
				break;



Many thanks.


Roger.

Re: OpenGL Renderers Reorganization

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

On 28 Jun, 2007, at 22:39, Jose' Cruanyes wrote:

> We're ready to go on with the Hiddenline renderers, but I'm not sure
> that poluting the Quesa space is the way to go, also because we want
> to create several different renderers.
>
> so we want to detach the renderers from quesa.

Sounds good.

>
> there are several options,
> one Quick n dirty  that is use several #defines to turn on and off
> the renderers at compile time,
> and the other is to make all the renderers (minus one?) plug-ins.

If you are not talking about source separation, there's not much  
wrong with what I am doing now, which is to only allow the user to  
select the ones the application supports, either grey them out or  
what I do, not add them to the appropriate menu/pop-up menu.

Of course plug-in renderers give better modularity.


>
> the problem with the second approach is that the Open GL renderers
> (that forms the base class for all others) uses private View methods
> and data, so we have to make them public.

How many methods are we talking about?

Would they be of any use to other renderers?

Could they be implemented as a library which was hard linked?

>
> the third approach is to leave the OpenGL Hiddenline renderer (only
> one) on by default,


You mean the original 'Interactive' renderer is not going to be the  
default?

A traditional hidden line renderer would not be much good as a default.

>
> Also, What about make the cartoon renderer a illumination style like
> Phong or Lambert?

Nice lateral thinking. Yes I like it.


> What do you think?
>
> Pax et Bonum

OpenGL Renderers Reorganization

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

We're ready to go on with the Hiddenline renderers, but I'm not sure =20
that poluting the Quesa space is the way to go, also because we want =20
to create several different renderers.

so we want to detach the renderers from quesa.

there are several options,
one Quick n dirty  that is use several #defines to turn on and off =20
the renderers at compile time,
and the other is to make all the renderers (minus one?) plug-ins.

the problem with the second approach is that the Open GL renderers =20
(that forms the base class for all others) uses private View methods =20
and data, so we have to make them public.

the third approach is to leave the OpenGL Hiddenline renderer (only =20
one) on by default,

Also, What about make the cartoon renderer a illumination style like =20
Phong or Lambert?


What do you think?

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

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

I have now changed my app so that the user can change the Quesa  
Specular Control	between 0.2 and 1,262.1376216178. This works great  
for spheres, but for cuboids made up of six polygons, when I change  
it nothing happens until I save the file and re-open it. It looks  
like RayShade is caching the specular control value and not noticing  
that it has changed. Changing it works with other renderers. Any ideas?

Roger.

Re: Rayshade

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

On 26 Jun, 2007, at 18:13, Jose' Cruanyes wrote:

>
> one great addition to rayshade will be to made it threaded to use
> multiprocessor system


The main problem is sorting out the global variables, or at least it  
was with my renderer.

Some of the globals had to be per process, some shared, some  
initialised by the main thread and copies made for each process which  
then modified them.

I only applied multi-processing to the most time consuming part of  
the rendering.

Re: Rayshade

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

Il giorno 26/giu/07, alle ore 18:46, Roger Holmes ha scritto:

> I have finally built a version of RayShade which runs within my Macho/
> Cocoa application.

Great

>
> I am seeing a problem with the RGB and Alpha channels being mixed up.
> I get no green, mainly cyan and white with some blue and magenta.
> This is on Intel.

Im actually porting our app from CFM to Mach0 and intel, and I've =20
seen the endian problems too, but these are the least of our problems =20=

now..

>
>
> Am I right in thinking RayShade is non interactive (in the Quesa =20
> sense)?

yes, it declares itself as non interactive
>
> What does it put into the Alpha channel when rendering into an
> offscreen pixmap with an alpha channel? (The MicroSpot renderer sets
> all the background pixels to 100% transparent and normal objects
> pixels to 0% transparent and pixels which only have transparent
> objects, to their combined transparency)
>
> Does RayShade support the background and foreground planes which Dair
> introduced a few years back?

no, but I think it's not difficult to implement

>
> Apart from that it looks good, speed looks OK though I've not thrown
> anything really difficult at it yet.

one great addition to rayshade will be to made it threaded to use =20
multiprocessor system

>

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

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

I have finally built a version of RayShade which runs within my Macho/ 
Cocoa application.

I am seeing a problem with the RGB and Alpha channels being mixed up.  
I get no green, mainly cyan and white with some blue and magenta.  
This is on Intel.

Has anyone seen any similar problems with RayShade or is it my App?  
Though the app works with the interactive renderer and an other plug- 
in (non interactive) renderer.

Am I right in thinking RayShade is non interactive (in the Quesa sense)?

What does it put into the Alpha channel when rendering into an  
offscreen pixmap with an alpha channel? (The MicroSpot renderer sets  
all the background pixels to 100% transparent and normal objects  
pixels to 0% transparent and pixels which only have transparent  
objects, to their combined transparency)

Does RayShade support the background and foreground planes which Dair  
introduced a few years back?

Apart from that it looks good, speed looks OK though I've not thrown  
anything really difficult at it yet.


Roger.

Q3TriMesh_Submit bug (Quesa Interactive)

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

Q3TriMesh_Submit does not work with the Quesa Interactive rederer. In 
case of  "submit immediate" the argument theGeom of 
IRGeometry_Submit_TriMesh is NULL. Therefore the following lines lead 
to a crash:

     cachedGeom = CQ3ObjectRef( Q3TriMesh_Optimize( theGeom ) );
     SetCachedOptimizedTriMesh( theGeom, cachedGeom.get() );

   Stefan
   http://www.topoi.ch