quesa-develop — Mailing list for Quesa development

Re: Buffer overrun in 64 bit build: problem found, solution lacking

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

On 16 Apr 2009, at 22:23, Sean McBride wrote:

> On 4/15/09 10:29 PM, Roger Holmes said:
>
>> We should probably add an extra field to E3ClassInfo. I suggest it be
>> called deltaInstanceSize.
>>
>> We should have a new parameter in E3ClassTree::RegisterClass. When
>> called from E3ClassTree::RegisterExternalClass, this will be passed
>> straight through. When called for a built in class which merely  
>> adds a
>> single object to its base class, it would pass in the sizeof () this
>> object. When called for a class which adds more than one object to  
>> its
>> base class it would have to be the sum of the sizeof ()s of those
>> objects, however I don't think this will matter as such a class would
>> probably not call GetInstanceSize.
>>
>> GetInstanceSize would need to be changed to return deltaInstanceSize
>> instead of the difference of the instanceSize class and its parent.
>>
>> OpaqueTQ3Object::FindLeafInstanceData would need to be changed to add
>> ( instanceSize - deltaInstanceSize ) to 'this' rather than the parent
>> class's instanceSize, which would then allow for the pad bytes moving
>> the data fields forward in the record.
>>
>> The same change would need to be made to
>> OpaqueTQ3Object::DeleteInstanceData and
>> OpaqueTQ3Object::DuplicateInstanceData.
>
> This sounds reasonable.  I don't know Quesa well enough to attempt
> this... Roger or James, do one of you have the time/inclination?  I  
> can
> certainly do a code review and testing.

I have forgotten how to use CVS (and never was very confident with it)  
and don't really want to re-learn it, sorry. I am interested in doing  
a 64 bit version of our application and and happy to advise. I guess  
its a lot of work to convert the project to SVN. I could modify my  
local files (some of which have now diverged quite a bit because I  
have none of James' recent changes, but I think this area should be  
safe) and give the changes but thats almost what I've done already. I  
can't really test on 64 bit until we do the rest of the application,  
and we are about a week away from release of a new version, so a bad  
time.

Roger.

Re: Buffer overrun in 64 bit build: problem found, solution lacking

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

Sean McBride wrote:


> This sounds reasonable.  I don't know Quesa well enough to attempt
> this... Roger or James, do one of you have the time/inclination?  I can
> certainly do a code review and testing.

I don't have time right now, maybe over the weekend.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: Buffer overrun in 64 bit build: problem found, solution lacking

[Sean M. <se...@ro...>]

On 4/15/09 10:29 PM, Roger Holmes said:

>We should probably add an extra field to E3ClassInfo. I suggest it be  
>called deltaInstanceSize.
>
>We should have a new parameter in E3ClassTree::RegisterClass. When  
>called from E3ClassTree::RegisterExternalClass, this will be passed  
>straight through. When called for a built in class which merely adds a  
>single object to its base class, it would pass in the sizeof () this  
>object. When called for a class which adds more than one object to its  
>base class it would have to be the sum of the sizeof ()s of those  
>objects, however I don't think this will matter as such a class would  
>probably not call GetInstanceSize.
>
>GetInstanceSize would need to be changed to return deltaInstanceSize  
>instead of the difference of the instanceSize class and its parent.
>
>OpaqueTQ3Object::FindLeafInstanceData would need to be changed to add  
>( instanceSize - deltaInstanceSize ) to 'this' rather than the parent  
>class's instanceSize, which would then allow for the pad bytes moving  
>the data fields forward in the record.
>
>The same change would need to be made to  
>OpaqueTQ3Object::DeleteInstanceData and  
>OpaqueTQ3Object::DuplicateInstanceData.

This sounds reasonable.  I don't know Quesa well enough to attempt
this... Roger or James, do one of you have the time/inclination?  I can
certainly do a code review and testing.

Cheers,

-- 
____________________________________________________________
Sean McBride, B. Eng                 se...@ro...
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montréal, Québec, Canada

Re: Buffer overrun in 64 bit build: problem found, solution lacking

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

We should probably add an extra field to E3ClassInfo. I suggest it be  
called deltaInstanceSize.

We should have a new parameter in E3ClassTree::RegisterClass. When  
called from E3ClassTree::RegisterExternalClass, this will be passed  
straight through. When called for a built in class which merely adds a  
single object to its base class, it would pass in the sizeof () this  
object. When called for a class which adds more than one object to its  
base class it would have to be the sum of the sizeof ()s of those  
objects, however I don't think this will matter as such a class would  
probably not call GetInstanceSize.

GetInstanceSize would need to be changed to return deltaInstanceSize  
instead of the difference of the instanceSize class and its parent.

OpaqueTQ3Object::FindLeafInstanceData would need to be changed to add  
( instanceSize - deltaInstanceSize ) to 'this' rather than the parent  
class's instanceSize, which would then allow for the pad bytes moving  
the data fields forward in the record.

The same change would need to be made to  
OpaqueTQ3Object::DeleteInstanceData and  
OpaqueTQ3Object::DuplicateInstanceData.

Roger.




On 15 Apr 2009, at 15:56, Sean McBride wrote:

> On 4/14/09 11:20 PM, James W. Walker said:
>
>> The code you're looking at is not in e3geom_trimesh_copydata, but in
>> e3geom_trimesh_copyattributes.
>
> Ack, yes, sorry about that.
>
>> I guess it's trying to get the size of
>> the data for any given attribute type, in a way that would be
>> compatible with custom attributes.
>
> That was my impression too.
>
>> It would definitely be a bad idea
>> to replace theClass->GetInstanceSize() by sizeof(TQ3Vector3D),  
>> because
>> it won't be right for other attributes than normal vectors, such as  
>> UV
>> coordinates.  If you only care about the built-in attribute types,  
>> you
>> could use an array lookup or switch statement to get the right size,
>> but it would be nice to figure out what's going wrong.
>
> Agreed.
>
>> The class in
>> question is E3NormalAttribute, a subclass of E3Attribute with one
>> additional member, a TQ3Vector3D.  It looks like GetInstanceSize
>> basically takes sizeof(E3NormalAttribute) - sizeof(E3Attribute).
>
> I don't think this kind of subtraction is ever correct/reliable,
> really.  The structure padding is not mandated by the C language,  
> and so
> the compiler is free to choose it.  Or am I missing something...?
>
>> Apparently, in the 64-bit case, 4 pad bytes were added between the
>> base class and the instance data of the subclass. What exactly are  
>> the
>> rules about when structures are padded in the 64-bit world?
>
> The Mac OS X ABI spells out the rules on OS X; other platforms have
> other rules of course.  For example, for ppc64:
>
> <http://developer.apple.com/documentation/DeveloperTools/Conceptual/
> LowLevelABI/110-64-bit_PowerPC_Function_Calling_Conventions/
> 64bitPowerPC.html#//apple_ref/doc/uid/TP40002471>
>
> I've just noticed Quesa.h has "#pragma options align=power".  Perhaps
> the code really depends on that type of alignment?
>
> -- 
> ____________________________________________________________
> Sean McBride, B. Eng                 se...@ro...
> Rogue Research                        www.rogue-research.com
> Mac Software Developer              Montréal, Québec, Canada
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop

Re: Buffer overrun in 64 bit build: problem found, solution lacking

[Sean M. <se...@ro...>]

On 4/14/09 11:20 PM, James W. Walker said:

>The code you're looking at is not in e3geom_trimesh_copydata, but in  
>e3geom_trimesh_copyattributes.

Ack, yes, sorry about that.

>I guess it's trying to get the size of  
>the data for any given attribute type, in a way that would be  
>compatible with custom attributes.

That was my impression too.

>It would definitely be a bad idea  
>to replace theClass->GetInstanceSize() by sizeof(TQ3Vector3D), because  
>it won't be right for other attributes than normal vectors, such as UV  
>coordinates.  If you only care about the built-in attribute types, you  
>could use an array lookup or switch statement to get the right size,  
>but it would be nice to figure out what's going wrong.

Agreed.

>The class in  
>question is E3NormalAttribute, a subclass of E3Attribute with one  
>additional member, a TQ3Vector3D.  It looks like GetInstanceSize  
>basically takes sizeof(E3NormalAttribute) - sizeof(E3Attribute).

I don't think this kind of subtraction is ever correct/reliable,
really.  The structure padding is not mandated by the C language, and so
the compiler is free to choose it.  Or am I missing something...?

>Apparently, in the 64-bit case, 4 pad bytes were added between the  
>base class and the instance data of the subclass. What exactly are the  
>rules about when structures are padded in the 64-bit world?

The Mac OS X ABI spells out the rules on OS X; other platforms have
other rules of course.  For example, for ppc64:

<http://developer.apple.com/documentation/DeveloperTools/Conceptual/
LowLevelABI/110-64-bit_PowerPC_Function_Calling_Conventions/
64bitPowerPC.html#//apple_ref/doc/uid/TP40002471>

I've just noticed Quesa.h has "#pragma options align=power".  Perhaps
the code really depends on that type of alignment?

-- 
____________________________________________________________
Sean McBride, B. Eng                 se...@ro...
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montréal, Québec, Canada

Re: Buffer overrun in 64 bit build: problem found, solution lacking

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

On Apr 14, 2009, at 3:50 PM, Sean McBride wrote:

> Hi all,
>
> So we've built Quesa as 64 bit on Mac OS X 10.5.6 and found a nasty  
> bug
> when loading 3dmf files.  I've found the cause, but I am not sure of  
> the
> proper solution.
>
> Superficially, the problem is that a buffer of x bytes is allocated  
> but
> then later it attempts to copy that buffer, but with a size greater  
> than x.
>
> The allocation is performed in e3fformat_3dmf_attributearray_read(),
> specifically:
>
> 		case kQ3AttributeTypeNormal:			// TQ3Vector3D
> 			theAttribute->data = Q3Memory_Allocate
>     (sizeof(TQ3Vector3D) * numElems);
>
> Based on my very limited understanding, this seems correct.  Also,  
> note
> that sizeof(TQ3Vector3D) is 12 bytes both in 32 and 64 bit.
>
> This buffer is later copied (I confirmed it's the same buffer) in
> e3geom_trimesh_copydata():
>
> 		TQ3Uns32 attrSize = theClass->GetInstanceSize () ;
> 		TQ3Uns32 bytes    = numElements * attrSize ;
> 		if ( bytes != 0 )
> 			qd3dStatus = e3geom_trimesh_clone(
>        srcAttributeTypes[i].data,
> 								&(*destAttributeTypes)[i].data,
> 								bytes);
>
> The error is this computation of 'attrSize'.  In 32 bit,
> GetInstanceSize() gives 12, but in 64 bit it gives 16.  That seems
> correct.  It seems to me merely luck that GetInstanceSize() ==
> sizeof(TQ3Vector3D) in 32 bit.  I don't understand why  
> GetInstanceSize()
> is used here, or for that matter, what that function is all about.
>
> If I change:
>
> 		TQ3Uns32 attrSize = theClass->GetInstanceSize () ;
>
> to:
>
> 		TQ3Uns32 attrSize = sizeof(TQ3Vector3D) ;
>
> My problem is 'solved'.  But I suspect this is not a general fix.
>
> I have a small test project that repros 100%, if someone (James? :))
> would care to take a look!




The code you're looking at is not in e3geom_trimesh_copydata, but in  
e3geom_trimesh_copyattributes.  I guess it's trying to get the size of  
the data for any given attribute type, in a way that would be  
compatible with custom attributes.  It would definitely be a bad idea  
to replace theClass->GetInstanceSize() by sizeof(TQ3Vector3D), because  
it won't be right for other attributes than normal vectors, such as UV  
coordinates.  If you only care about the built-in attribute types, you  
could use an array lookup or switch statement to get the right size,  
but it would be nice to figure out what's going wrong.  The class in  
question is E3NormalAttribute, a subclass of E3Attribute with one  
additional member, a TQ3Vector3D.  It looks like GetInstanceSize  
basically takes sizeof(E3NormalAttribute) - sizeof(E3Attribute).   
Apparently, in the 64-bit case, 4 pad bytes were added between the  
base class and the instance data of the subclass. What exactly are the  
rules about when structures are padded in the 64-bit world?

Buffer overrun in 64 bit build: problem found, solution lacking

[Sean M. <se...@ro...>]

Hi all,

So we've built Quesa as 64 bit on Mac OS X 10.5.6 and found a nasty bug
when loading 3dmf files.  I've found the cause, but I am not sure of the
proper solution.

Superficially, the problem is that a buffer of x bytes is allocated but
then later it attempts to copy that buffer, but with a size greater than x.

The allocation is performed in e3fformat_3dmf_attributearray_read(),
specifically:

		case kQ3AttributeTypeNormal:			// TQ3Vector3D
			theAttribute->data = Q3Memory_Allocate
     (sizeof(TQ3Vector3D) * numElems);

Based on my very limited understanding, this seems correct.  Also, note
that sizeof(TQ3Vector3D) is 12 bytes both in 32 and 64 bit.

This buffer is later copied (I confirmed it's the same buffer) in
e3geom_trimesh_copydata():

		TQ3Uns32 attrSize = theClass->GetInstanceSize () ;
		TQ3Uns32 bytes    = numElements * attrSize ;
		if ( bytes != 0 )
			qd3dStatus = e3geom_trimesh_clone(
        srcAttributeTypes[i].data,
								&(*destAttributeTypes)[i].data,
								bytes);

The error is this computation of 'attrSize'.  In 32 bit,
GetInstanceSize() gives 12, but in 64 bit it gives 16.  That seems
correct.  It seems to me merely luck that GetInstanceSize() ==
sizeof(TQ3Vector3D) in 32 bit.  I don't understand why GetInstanceSize()
is used here, or for that matter, what that function is all about.

If I change:

		TQ3Uns32 attrSize = theClass->GetInstanceSize () ;

to:

		TQ3Uns32 attrSize = sizeof(TQ3Vector3D) ;

My problem is 'solved'.  But I suspect this is not a general fix.

I have a small test project that repros 100%, if someone (James? :))
would care to take a look!

Thanks!

-- 
____________________________________________________________
Sean McBride, B. Eng                 se...@ro...
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montréal, Québec, Canada

Re: Q3Polygon_GetVertexAttributeSet

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

On 19 Mar 2009, at 22:10, James Walker wrote:

> Roger Holmes wrote:
>
>> For a polygon there is a useful routine  
>> Q3Polygon_GetVertexAttributeSet,
>> which takes the object, an index and an attribute set. Trouble is, I
>> can't find a simple routine which tells me the maximum index. Of  
>> course
>> I can get the TQ3PolygonData and read it from there, but not only is
>> that slow, if I get that I can read the vertex array directly so  
>> don't
>> need Q3Polygon_GetVertexAttributeSet. Am I missing something or is  
>> this
>> just silly design?
>
> It does seem like a silly design (and the same could be said about
> PolyLine and Polyhedron).  But it's not clear to me that
> Q3Polygon_GetData should be slower than calling
> Q3Polygon_GetVertexAttributeSet for every vertex.  Have you profiled  
> it?

No, it was just a gut feeling, and more to do with our wrapper classes  
than with Quesa itself. I will add routines in our wrappers to get the  
various count via GetData routine for each of the different geometries  
and probably all will then be OK.

Thanks.

Re: Q3Polygon_GetVertexAttributeSet

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

Roger Holmes wrote:

> For a polygon there is a useful routine Q3Polygon_GetVertexAttributeSet, 
> which takes the object, an index and an attribute set. Trouble is, I 
> can't find a simple routine which tells me the maximum index. Of course 
> I can get the TQ3PolygonData and read it from there, but not only is 
> that slow, if I get that I can read the vertex array directly so don't 
> need Q3Polygon_GetVertexAttributeSet. Am I missing something or is this 
> just silly design?

It does seem like a silly design (and the same could be said about 
PolyLine and Polyhedron).  But it's not clear to me that 
Q3Polygon_GetData should be slower than calling 
Q3Polygon_GetVertexAttributeSet for every vertex.  Have you profiled it?
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Q3Polygon_GetVertexAttributeSet

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

Firstly let me say I am using a one or two year old version of Quesa  
so its possible a suitable routine has been added since.

I want to quickly scan through all the vertices of an object to see if  
they ALL have a diffuse colour attribute, which means that setting the  
objects own diffuse colour will have no effect, so the user option  
should be greyed out.

I don't think there is any way of doing this on a geometry object so I  
have to split off each type of object.

For a polygon there is a useful routine  
Q3Polygon_GetVertexAttributeSet, which takes the object, an index and  
an attribute set. Trouble is, I can't find a simple routine which  
tells me the maximum index. Of course I can get the TQ3PolygonData and  
read it from there, but not only is that slow, if I get that I can  
read the vertex array directly so don't need  
Q3Polygon_GetVertexAttributeSet. Am I missing something or is this  
just silly design?

Roger Holmes

[ quesa-Bugs-907878 ] View plane cameras not implemented

[SourceForge.net <no...@so...>]

Bugs item #907878, was opened at 2004-03-01 13:39
Message generated for change (Comment added) made by jwwalker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=907878&group_id=45158

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Dair Grant (grantd)
>Assigned to: James W. Walker (jwwalker)
Summary: View plane cameras not implemented

Initial Comment:
The view-plane camera type is not currently implemented in 
Quesa.

To implement this we need to fill in the 
e3camera_viewplane_frustum_matrix method, found in 
E3Camera.c.

----------------------------------------------------------------------

>Comment By: James W. Walker (jwwalker)
Date: 2009-02-23 23:12

Message:
This was implemented in December 2008.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=907878&group_id=45158

Re: GLDrawContext Rosetta Bug

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

On Feb 15, 2009, at 6:13 PM, Stefan Huber wrote:

>>> In GLDrawContext.c, line 1209, there is a workaround for
>>> TARGET_RT_MAC_CFM. The same bug happens with CodeWarrior
>>> TARGET_RT_MAC_MACHO projects.
>>
>> What's the solution, to replace TARGET_RT_MAC_CFM with  
>> TARGET_CPU_PPC?
>
> I think so.  BTW the specified bug is related to pixmap draw context.

OK, I have checked in the fix, and added more information to the  
comment while I was at it.

Re: GLDrawContext Rosetta Bug

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

>>In GLDrawContext.c, line 1209, there is a workaround for
>>TARGET_RT_MAC_CFM. The same bug happens with CodeWarrior
>>TARGET_RT_MAC_MACHO projects.
>
>What's the solution, to replace TARGET_RT_MAC_CFM with TARGET_CPU_PPC?

I think so.  BTW the specified bug is related to pixmap draw context.

   Stefan

Re: GLDrawContext Rosetta Bug

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

On Feb 15, 2009, at 4:06 PM, Stefan Huber wrote:

> In GLDrawContext.c, line 1209, there is a workaround for
> TARGET_RT_MAC_CFM. The same bug happens with CodeWarrior
> TARGET_RT_MAC_MACHO projects.

What's the solution, to replace TARGET_RT_MAC_CFM with TARGET_CPU_PPC?

GLDrawContext Rosetta Bug

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

In GLDrawContext.c, line 1209, there is a workaround for 
TARGET_RT_MAC_CFM. The same bug happens with CodeWarrior 
TARGET_RT_MAC_MACHO projects.

   Stefan
   http://www.topoi.ch

Re: RayShade UV transform error

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

For the benefit of any lurkers who aren't subscribed to the cvs  
commits mailing list:  Roger's recent RayShade fixes have been  
committed.

RayShade UV transform error

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

Hi Sauro,


Could you also correct an error in the UV mapping.

In RS_Texture.cpp please change the line:

	rsPrivate->uvTransform.value[1][1] *= -1.0f;


to read:

	rsPrivate->uvTransform.value[0][1] *= -1.0f;
	rsPrivate->uvTransform.value[1][1] *= -1.0f;
	rsPrivate->uvTransform.value[2][1] *= -1.0f;

in other words, copy and paste twice and change the first index to be  
0,1 and 2 in the three cases.

This fixes a problem with texture rotation direction and V offset.

Roger.

Re: RayShade and spot light bug fix.

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

Hi,

To fix the problem with spot lights:


In LibLight/spot.h

replace the lines:


#define LightSpotCreate(c,f,t,p,i,o) LightCreate( \
			(LightRef)SpotCreate(f,t,p,i,o), SpotMethods(), c)
typedef struct {
	Vector pos, dir;
	Float coef, radius, falloff;
} Spotlight;

extern Spotlight *
SpotCreate(Vector *from,Vector *to,Float coef,Float in,Float out);


with:

#define LightSpotCreate(c,f,t,i,o,at,fo) LightCreate( \
			(LightRef)SpotCreate(f,t,i,o,at,fo), SpotMethods(), c)
typedef struct {
	Vector pos, dir;
	Float hotAngle ;
	Float outerAngle ;
	Float cosHotAngle ;
	Float cosOuterAngle ;
	int	attenuation ;
	int	fallOff ;
} Spotlight;

extern Spotlight *
SpotCreate ( Vector* from , Vector* dir , Float hotAngle , Float  
outerAngle , int attenuation , int fallOff ) ;



Then in LibLight/spot.cpp replace:


static Float rampup(Float left,Float right,Float at);

static Float SpotAtten(Spotlight *lp, Vector *dir);
Spotlight *
SpotCreate(
         Vector          *from,
         Vector          *to,
         Float           coef,
         Float           in,
         Float           out)
{
	Spotlight *spot;

	spot = (Spotlight *)share_malloc(sizeof(Spotlight));
	spot->pos = *from;
	VecSub(*to, *from, &spot->dir);
	if (VecNormalize(&spot->dir) == 0. || in > out) {
		RLerror(RL_ABORT,"Invalid spotlight specification.\n");
		return (Spotlight *)NULL;
	}
	spot->coef = coef;
	spot->radius = cos(deg2rad(in));
	spot->falloff = cos(deg2rad(out));

	return spot;
}




with:




static Float SpotAtten(Spotlight *lp, Vector *dir);
Spotlight *
SpotCreate(
         Vector          *from,
         Vector          *dir,
         Float           hotAngle,
         Float           outerAngle ,
		int				attenuation ,
		int				fallOff )
{
	Spotlight *spot;

	spot = (Spotlight *)share_malloc(sizeof(Spotlight));
	spot->pos = *from;
	spot->dir.x = dir->x ;
	spot->dir.y = dir->y ;
	spot->dir.z = dir->z ;
	if (VecNormalize(&spot->dir) == 0. || hotAngle > outerAngle ) {
		RLerror(RL_ABORT,"Invalid spotlight specification.\n");
		return (Spotlight *)NULL;
	}
	spot->hotAngle = hotAngle ;
	spot->outerAngle = outerAngle ;
	spot->cosHotAngle = cos ( hotAngle ) ;
	spot->cosOuterAngle = cos ( outerAngle ) ;
	spot->attenuation = attenuation ;
	spot->fallOff = fallOff ;

	return spot;
}




and further down the same file replace:



/*
  * Compute intensity of spotlight along 'dir'.
  */
static Float
SpotAtten(
         Spotlight       *lp,
         Vector          *dir)
{
	Float costheta, atten;

	costheta = -dotp(dir, &lp->dir);
	/*
	 * Behind spotlight.
	 */
	if (costheta <= 0.)
		return 0.;
	/*
	 * Intensity is the product of costheta raised to lp->coef and
	 * a function that smoothly interpolates from 0 at
	 * costheta=lp->falloff to 1 at costheta=lp->radius.
	 */
	atten = pow(costheta, lp->coef);
	if (lp->radius > 0.)
		atten *= rampup(lp->falloff, lp->radius, costheta);
	return atten;
}

/*
  * Cubic interpolation between 0 at left and 1 at right, sampled at  
'at'
  * It is assumed that right >= left.
  */
Float
rampup(Float left,Float right,Float at)
{
	if (at < left)
		return 0.;
	else if (at > right)
		return 1.;

	if (right == left)
		return 0.;

	at = (at - left) / (right - left);
	return (3 - 2*at)*at*at;
}



with:



#define kQ3PiOver2                              ((Float)  
(3.1415926535898 / 2.0))
static const float eMinus1 = exp ( 1.0f ) - 1.0f ;

/*
  * Compute intensity of spotlight along 'dir'.
  */
static Float
SpotAtten(
         Spotlight       *lp,
         Vector          *dir)
{
	Float costheta, atten;

	costheta = -dotp(dir, &lp->dir);
	/*
	 * Behind spotlight.
	 */
	if (costheta <= 0.)
		return 0.;

	if ( costheta < lp->cosOuterAngle )
		return 0.0 ;

	atten = costheta ;
	if (lp->cosHotAngle > 0.) // What is this all about ?
		{
		Float fallOffMultiplier = 1.0 ;
		if ( lp->fallOff == 1 /*kQ3FallOffTypeLinear*/ )
			{
			if ( costheta < lp->cosHotAngle )
				{
				Float angle = acos ( costheta ) ;
				fallOffMultiplier = ( lp->outerAngle - angle ) / ( lp->outerAngle  
- lp->hotAngle ) ;
				}
			}
		else
		if ( lp->fallOff == 2/*kQ3FallOffTypeExponential*/ )
			{
			if ( costheta < lp->cosHotAngle )
				{
				Float angle = acos ( costheta ) ;
				fallOffMultiplier = ( exp ( ( lp->outerAngle - angle ) / ( lp- 
 >outerAngle - lp->hotAngle ) ) - 1 ) / eMinus1 ;
				}
			}
		else
		if ( lp->fallOff == 3/*kQ3FallOffTypeCosine*/ )
			{
			if ( costheta < lp->cosHotAngle )
				{
				Float angle = acos ( costheta ) ;
				fallOffMultiplier = cos ( ( angle - lp->hotAngle ) * kQ3PiOver2 /  
( lp->outerAngle - lp->hotAngle ) ) ;
				}
			}

				
/*
		This may be required some time but presently neither the attenuation  
nor the world pixel position are available. Maybe it should go  
somewhere else in the calculations
		if ( lp->attenuation != kQ3AttenuationTypeNone )
			{
			switch ( lp->attenuation )
				{
	    		case kQ3AttenuationTypeInverseDistance :
	    			{
	    			fallOffMultiplier *= 1.0f / Distance ( pixelWorldPos - lp- 
 >pos ) ;
	    			break ;
	   				}
				case kQ3AttenuationTypeInverseDistanceSquared :
	    			{
	    			fallOffMultiplier *= 1.0f / DistanceSquared ( pixelWorldPos -  
lp->pos ) ;
	    			break ;
	   				}
				}
			}
*/		
		
		atten *= fallOffMultiplier ;
		}
	return atten;
}





Nearly there. In RT_Light.cpp, in subroutine RT_AddSpotLight  replace:


     theVector.x = -inDirection->x;
     theVector.y = -inDirection->y;
     theVector.z = -inDirection->z;

     switch(inFallOffType)
     {
         case kQ3FallOffTypeNone:
             theCoeff = 0.0f;
             break;
         case kQ3FallOffTypeLinear:
             theCoeff = 1.0f;
             break;
         case kQ3FallOffTypeExponential:
             theCoeff = 0.8f;
             break;
         case kQ3FallOffTypeCosine:
             theCoeff = 2.0f;
             break;
     }
     theLight = LightSpotCreate(&theColor,
                   &thePos,
                   &theVector,
                   theCoeff,
                   Q3Math_RadiansToDegrees(hotAngle),
                   Q3Math_RadiansToDegrees(outerAngle));



with:


     theVector.x = inDirection->x;
     theVector.y = inDirection->y;
     theVector.z = inDirection->z;

     theLight = LightSpotCreate(&theColor,
                   &thePos,
                   &theVector,
                   hotAngle ,
                   outerAngle ,
				  kQ3AttenuationTypeNone ,
				  inFallOffType ) ; // Use kQ3AttenuationTypeNone until we find we  
need thee proper value



Thats it.

I tried including the file which defines kQ3FallOffTypeExponential etc  
but had problems with multiply defined names, hence the slightly  
questionable way I've used constants 1,2 and 3 in SpotAtten.

Roger.

Re: RayShade and aspect ratio in non square windows.

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

Hi Sauro and all,

First the aspect ratio bug.

In file RT.cpp in RT_SetCamera,

at the end of the routine, change the whole if statement to:

     if ( aspectRatioXToY <= 1.0 )
	 {
     	Camera.hfov = Q3Math_RadiansToDegrees ( minfov ) ;
    	Camera.vfov = Q3Math_RadiansToDegrees ( atan ( tan ( minfov *  
0.5 ) / aspectRatioXToY ) * 2.0 ) ;
    	}
    else
    	{
    	Camera.vfov = Q3Math_RadiansToDegrees ( minfov ) ;
    	Camera.hfov = Q3Math_RadiansToDegrees ( atan ( tan ( minfov *  
0.5 ) * aspectRatioXToY ) * 2.0 ) ;
    	}



The code was very nearly right but Quesa's FieldOfView is the whole  
angle from one side to the other but the original calculation assumed  
it was the angle from the centre of the view to the outside. Basically  
I just halve the input angle and then double the output value and  
cleaned the code up a tiny bit.

I will send another email later about the spot lights.

Roger.





On 17 Dec, 2008, at 17:45, Sauro Agostini wrote:

> Well done Roger. Finally these 2 old RayShade bugs are fixxed, thank  
> you.
>
> I'll try the new version asap.
>
> Sauro
>
>> I have also fixed the problem with RayShade stretching images when
>> drawn into non square windows if anyone's interested.
>>
>> Roger.
>>
>>
>> ------------------------------------------------------------------------------
>> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas,  
>> Nevada.
>> The future of the web can't happen without you.  Join us at MIX09  
>> to help
>> pave the way to the Next Web now. Learn more and register at
>> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
>> _______________________________________________
>> 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.net
> |_____|  I-51100 Pistoia Italy             mailto:int...@in...
> -----------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas,  
> Nevada.
> The future of the web can't happen without you.  Join us at MIX09 to  
> help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop

Re: RayShade and aspect ratio in non square windows.

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

Well done Roger. Finally these 2 old RayShade bugs are fixxed, thank you.

I'll try the new version asap.

Sauro

>I have also fixed the problem with RayShade stretching images when 
>drawn into non square windows if anyone's interested.
>
>Roger.
>
>
>------------------------------------------------------------------------------
>SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
>The future of the web can't happen without you.  Join us at MIX09 to help
>pave the way to the Next Web now. Learn more and register at
>http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
>_______________________________________________
>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.net
|_____|  I-51100 Pistoia Italy             mailto:int...@in...
-----------------------------------------------------------------------------

Re: RayShade and aspect ratio in non square windows.

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

I have also fixed the problem with RayShade stretching images when  
drawn into non square windows if anyone's interested.

Roger.

RayShade and spot lights.

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

I have improved the spot light handling code in Quesa's RayShade  
renderer. Would anyone like to test and check in the changes? Before  
they did not seem to work so I lifted some code I wrote for the  
Microspot Renderer and it seems to work quite well now, though it may  
need optimisation some time.

Roger Holmes.

Re: Null triangles

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

On 28 Oct, 2008, at 18:32, James Walker wrote:

>> What do you all think on this. When certain tri-grids get turned into
>> tri-meshes, they sometimes generate null triangles because two of the
>> four corners of one of the grid quadrilateral are coincident. For
>> instance the original QuickDraw3D sample code generated a sphere  
>> and a
>> cone with Tri-grids and at the poles of the sphere and the point of
>> the cone, this happened. Would it be worthwhile to not generate these
>> null triangles, or should the tri-mesh constructor function filter
>> them out or should we continue to filter them out every time we  
>> render
>> or do processing of triangulated  data such as when doing CSG
>> calculations.
>
> I don't have a strong opinion, but it might be reasonable to filter  
> out
> empty triangles in e3geom_trigrid_cache_new.

Good, that's what I meant by "the tri-mesh constructor function".

I will look at that function when I get some spare time.

Re: Null triangles

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

Roger Holmes wrote:
> What do you all think on this. When certain tri-grids get turned into  
> tri-meshes, they sometimes generate null triangles because two of the  
> four corners of one of the grid quadrilateral are coincident. For  
> instance the original QuickDraw3D sample code generated a sphere and a  
> cone with Tri-grids and at the poles of the sphere and the point of  
> the cone, this happened. Would it be worthwhile to not generate these  
> null triangles, or should the tri-mesh constructor function filter  
> them out or should we continue to filter them out every time we render  
> or do processing of triangulated  data such as when doing CSG  
> calculations.

I don't have a strong opinion, but it might be reasonable to filter out 
empty triangles in e3geom_trigrid_cache_new.

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

Null triangles

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

What do you all think on this. When certain tri-grids get turned into  
tri-meshes, they sometimes generate null triangles because two of the  
four corners of one of the grid quadrilateral are coincident. For  
instance the original QuickDraw3D sample code generated a sphere and a  
cone with Tri-grids and at the poles of the sphere and the point of  
the cone, this happened. Would it be worthwhile to not generate these  
null triangles, or should the tri-mesh constructor function filter  
them out or should we continue to filter them out every time we render  
or do processing of triangulated  data such as when doing CSG  
calculations.

Roger Holmes.