quesa-develop — Mailing list for Quesa development

Re: Version

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

On Mar 28, 2005, at 12:46 AM, Stefan Huber wrote:

> In E3Version.h the version should be updated (currently 1.6d19).

True, it should be 1.6d20.  I don't know how we missed that.  I fixed 
it.

> PLIST_COMPILER (defined in Quesa.plc) seems to be useless because 
> kQ3PackedVersion will be used by E3Viewer_GetReleaseVersion and 
> E3GetReleaseVersion.

The reason for the PLIST_COMPILER flag is that otherwise the definition 
of kQ3PackedVersion causes an error when Quesa.plc is compiled.
--
<http://www.jwwalker.com/>

Version

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

In E3Version.h the version should be updated (currently 1.6d19).

PLIST_COMPILER (defined in Quesa.plc) seems to be useless because 
kQ3PackedVersion will be used by E3Viewer_GetReleaseVersion and 
E3GetReleaseVersion.

Stefan

Re: Problem with Image more large than 2048 pixel

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

On Mar 22, 2005, at 2:38 AM, Daniele Cavallini wrote:

> In both Windows and Macintosh I am creating an image in memory, not on 
> screen.
> Image is create correctly if I use Windows 98 or Windows XP.

I am sure that this is caused by the viewport limit of Apple's OpenGL 
software renderer.

It is possible to render a larger image by tiling it into smaller 
rectangles to be drawn separately, using Q3DrawContext_SetPane and 
Q3Camera_SetViewPort.  Another possible workaround would be to make a 
large window, with coordinates that put it off the screen, render to 
that window, and get the image using glReadPixels.

It is possible that a future release of Mac OS X will include a more 
capable software renderer.
--
<http://www.jwwalker.com/>

Re: Problem with Image more large than 2048 pixel

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

"S.O". is for Operative System. I used the Italian shortcut.

In both Windows and Macintosh I am creating an image in memory, not on screen.
Image is create correctly if I use Windows 98 or Windows XP.

The function RS_EndPass(...) is in the file RSRegister.cpp.


At 17.58 21/03/05, you wrote:
>On Mar 21, 2005, at 12:42 AM, Daniele Cavallini wrote:
>
>>There is a problem with image with  dimension more large than 2048 in 
>>RayShade plug in and in Quesa for MAC. Quesa for S.O. Windows work fine.
>
>In the Mac case, you may be seeing an OpenGL limitation, called the 
>maximum viewport size.  This limit depends on the video card.  For 
>instance, my PowerBook's video card has a maximum viewport size of 
>2656x2656, while the software renderer (used for rendering to an offscreen 
>context) has a maximum viewport size of 2048x2048.
>
>What does S.O. stand for?
>--
><http://www.jwwalker.com/>
>
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Quesa-develop mailing list
>Que...@li...
>https://lists.sourceforge.net/lists/listinfo/quesa-develop
>

Re: Problem with Image more large than 2048 pixel

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

On Mar 21, 2005, at 12:42 AM, Daniele Cavallini wrote:

> There is a problem with image with  dimension more large than 2048 in 
> RayShade plug in and in Quesa for MAC. Quesa for S.O. Windows work 
> fine.

In the Mac case, you may be seeing an OpenGL limitation, called the 
maximum viewport size.  This limit depends on the video card.  For 
instance, my PowerBook's video card has a maximum viewport size of 
2656x2656, while the software renderer (used for rendering to an 
offscreen context) has a maximum viewport size of 2048x2048.

What does S.O. stand for?
--
<http://www.jwwalker.com/>

Problem with Image more large than 2048 pixel

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

There is a problem with image with  dimension more large than 2048 in 
RayShade plug in and in Quesa for MAC. Quesa for S.O. Windows work fine.
In rayshade the problem is simple to resolve
In the function :

static
TQ3ViewStatus RS_EndPass(
	TQ3ViewObject			pView,
	TRSRendererPrivate		*rsPrivate)
{

there is:
TQ3Uns8 buf[2048][3]

I change
TQ3Uns8 buf[MAXSCREEN][3];
with
  #define MAXSCREEN 8000

It is 8000 a just value?I think is possible use dynamic allocation of 
memory and use malloc or calloc.
In quesa for MAC I don't know what is the problem.Just may be similar problem.

Daniele

  

Copyright out of date on Quesa license page

[Lars J. <lar...@rc...>]

Says "1999-2004" in a couple spots.

  http://quesa.org/reference/licence.html

lj

Default highlight style

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

The default highlight style in QD3D is red. Currently the default 
highlight style in Quesa is NULL.

Here's a small patch...

Stefan

_________________________________________________
File: E3View
Method: e3view_stack_initialise

TQ3ColorRGB defaultHighLightDiffuseColor;
TQ3ColorRGB defaultHighLightTransparencyColor;

...

// theItem->styleHighlight  = NULL; // to be commented

theItem->styleHighlight  = Q3AttributeSet_New();

if (theItem->styleHighlight != NULL)
   {
   Q3ColorRGB_Set(&defaultHighLightDiffuseColor, kQ3ViewDefaultHighlightColor);
   Q3AttributeSet_Add (theItem->styleHighlight, 
kQ3AttributeTypeDiffuseColor, &defaultHighLightDiffuseColor);
   Q3ColorRGB_Set(&defaultHighLightTransparencyColor, 
kQ3ViewDefaultTransparency);
   Q3AttributeSet_Add (theItem->styleHighlight, 
kQ3AttributeTypeTransparencyColor, 
&defaultHighLightTransparencyColor);
   }

Re: quaternion question

[Keith W. <kw...@cs...>]

Works beautifully.  Thanks.  I guess I should have been able to find that 
on my own.  Sorry, but thanks.

On Wed, 23 Feb 2005, James W. Walker wrote:

> On Feb 23, 2005, at 11:02 PM, Keith Wiley wrote:
>
>> I have an object that has not been rotated at all yet, so its starting 
>> quaternion Q is (1,0,0,0).  I have a vector V (x,y,z) that specifies a 3D 
>> pointing or facing direction.  I would like to take the object's facing 
>> direction, which starts out (0,0,1), straight down the z axis, and orient 
>> it such that it faces in the same direction as the vector V.  I realize 
>> this doesn't entirely specify an orientation since there is still the 
>> question of how the object is "rolled" around the facing vector, but I am 
>> not concerned with that right now.  For this specific application it 
>> doesn't even matter because the object in question is perfectly 
>> cylindrical around the z axis so rolling doesn't mean anything.  I just 
>> want to make it point in the direction of the vector V.
>> 
>> How do I do this?  Any ideas?
>
> How about using Q3Quaternion_SetRotateVectorToVector?
> --
> <http://www.jwwalker.com/>
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>

________________________________________________________________________
Keith Wiley         kw...@cs...         http://www.unm.edu/~keithw

"Yet mark his perfect self-contentment, and hence learn his lesson,
that to be self-contented is to be vile and ignorant, and that to
aspire is better than to be blindly and impotently happy."
                                            --  Edwin A. Abbott, Flatland
________________________________________________________________________

Re: quaternion question

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

On Feb 23, 2005, at 11:02 PM, Keith Wiley wrote:

> I have an object that has not been rotated at all yet, so its starting 
> quaternion Q is (1,0,0,0).  I have a vector V (x,y,z) that specifies a 
> 3D pointing or facing direction.  I would like to take the object's 
> facing direction, which starts out (0,0,1), straight down the z axis, 
> and orient it such that it faces in the same direction as the vector 
> V.  I realize this doesn't entirely specify an orientation since there 
> is still the question of how the object is "rolled" around the facing 
> vector, but I am not concerned with that right now.  For this specific 
> application it doesn't even matter because the object in question is 
> perfectly cylindrical around the z axis so rolling doesn't mean 
> anything.  I just want to make it point in the direction of the vector 
> V.
>
> How do I do this?  Any ideas?

How about using Q3Quaternion_SetRotateVectorToVector?
--
<http://www.jwwalker.com/>

quaternion question

[Keith W. <kw...@cs...>]

I have an object that has not been rotated at all yet, so its starting 
quaternion Q is (1,0,0,0).  I have a vector V (x,y,z) that specifies a 
3D pointing or facing direction.  I would like to take the object's 
facing direction, which starts out (0,0,1), straight down the z axis, 
and orient it such that it faces in the same direction as the vector V.  
I realize this doesn't entirely specify an orientation since there is 
still the question of how the object is "rolled" around the facing 
vector, but I am not concerned with that right now.  For this specific 
application it doesn't even matter because the object in question is 
perfectly cylindrical around the z axis so rolling doesn't mean 
anything.  I just want to make it point in the direction of the vector V.

How do I do this?  Any ideas?

Thanks, as always.


________________________________________________________________________
Keith Wiley         kw...@cs...         http://www.unm.edu/~keithw

"Yet mark his perfect self-contentment, and hence learn his lesson,
that to be self-contented is to be vile and ignorant, and that to
aspire is better than to be blindly and impotently happy."
                                           --  Edwin A. Abbott, Flatland
________________________________________________________________________

Re: draft release notes 1.6d20 to 1.7b1

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

On Feb 21, 2005, at 5:05 AM, Roger Holmes wrote:

> I have not done anything about
> reading View Hints from text files, for me this is almost zero 
> priority, and I would have to learn how to do it first.

If you're reading view hints as I suggested, using short-lived Quesa 
objects for things that the 3DMF specification calls objects, then text 
reading should be almost automatic.

> If my checking in of a partial implementation is undesirable at this 
> time I can delay it. I will until I hear from you anyway.

As long as it's likely to be useful to someone, it's fine with me.
--
<http://www.jwwalker.com/>

Version Numbers

[John W. A. <jo...@hy...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 21 Feb 2005, at 09:31, Jose' Cruanyes wrote:
> about version number
> IMHO the beta cycle means feature freeze, bugs hunting, but this will 
> never be the case in Quesa, so better use a different numbering like
> 1.7.0
> 1.7.1
> ...
I thought the idea was to release something that is considered stable 
as "x.y[.z]beta[number]", then allow people to thrash it for a while 
(while development continues on a later numbered version). Assuming no 
bugs turn up, it becomes "x.y[.z]" (i.e. 'released' version with the 
same version number) with no changes to anything. If bugs turn up, it's 
another story, of course -- sometimes it's clear how to pull back bug 
fixes from the next version, sometimes it's easier just to abandon that 
release and either rename the current development effort x.y.z or 
abandon x.y.z and increment the number. I rather liked this idea, as it 
gives users what they might expect -- a not-fully-tested beta version, 
plus a stable but older release version -- without freezing anything in 
the development side. Was this not the plan, and if not, what was the 
plan?

> anyway this is not really important what counts is release
Agreed. Preferably with changing version numbers so that users get an 
impression of change.

Keep up the good work, guys -- hopefully I'll have some time to help 
RSN!
- -- 
John Aldis, BF, MMath
"So this is what God feels like, eh?
  In truth I have little power beyond the ability to pull the plug."
   -- WardCunningham
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFCGgo5nxj37eSkoRMRAjyvAJ4koW8Snv6LtQuxKJTnXuORzXaSlwCdHR+z
AgrsGHE5fjHQZowYh5oYAcY=
=+Pw3
-----END PGP SIGNATURE-----

Re: draft release notes 1.6d20 to 1.7b1

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

On Monday, February 21, 2005, at 01:49 AM, James W. Walker wrote:

> I went through the CVS mailing list from Dec. 4 to now and made some 
> notes for the 1.7b1 change notes.
>
> Roger, do you expect to finish your view hints change before we do 
> 1.7b1?  If so, how would you describe it?

I expect to check in Peter's View Hint implementation and my reading 
code later today, maybe tomorrow.
This allows view hint to passed in memory (Interiors/Modeller use them 
on the clipboard for instance) and
also allows the reading of view hints from files generated by 
QuickDraw3D on OS7/8/9 or classic environment.
I hope to get Peter to write the view hint writing code in the next 
month or so. I have not done anything about
reading View Hints from text files, for me this is almost zero 
priority, and I would have to learn how to do it first.

If my checking in of a partial implementation is undesirable at this 
time I can delay it. I will until I hear from you anyway.


>
> * Quesa is now compiled as C++, although the public API is still C.
> * The code has been overhauled, taking advantage of C++ for better 
> speed.
> * memory storage objects can be duplicated.
> * texture objects are correctly duplicated.
> * when reading text 3DMF, references are handled correctly.
> * mipmap textures are handled more correctly.
> * The CodeWarrior project for the Geom Test sample has Windows targets.
> * Minor improvements in the RayShade renderer.
> * There is a new public API CENameElement_PeekData.
> * textures are cached differently, to allow using a texture object 
> with different texture shaders.
> * fixed a bug in draw context pane positions in "metal" Mac windows.

Looks good.


>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real 
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>

Re: draft release notes 1.6d20 to 1.7b1

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

Il giorno 21/feb/05, alle 02:49, James W. Walker ha scritto:

> I went through the CVS mailing list from Dec. 4 to now and made some 
> notes for the 1.7b1 change notes.

about version number
IMHO the beta cycle means feature freeze, bugs hunting, but this will 
never be the case in Quesa, so better use a different numbering like
1.7.0
1.7.1
...

anyway this is not really important what counts is release

Pax et Bonum

# dott. Jose' Cruanyes Aguilar  -  C.E. Soft srl
#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
#   02,33603122                0372,460602

draft release notes 1.6d20 to 1.7b1

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

I went through the CVS mailing list from Dec. 4 to now and made some 
notes for the 1.7b1 change notes.

Roger, do you expect to finish your view hints change before we do 
1.7b1?  If so, how would you describe it?

* Quesa is now compiled as C++, although the public API is still C.
* The code has been overhauled, taking advantage of C++ for better 
speed.
* memory storage objects can be duplicated.
* texture objects are correctly duplicated.
* when reading text 3DMF, references are handled correctly.
* mipmap textures are handled more correctly.
* The CodeWarrior project for the Geom Test sample has Windows targets.
* Minor improvements in the RayShade renderer.
* There is a new public API CENameElement_PeekData.
* textures are cached differently, to allow using a texture object with 
different texture shaders.
* fixed a bug in draw context pane positions in "metal" Mac windows.

Re: Even more on View Hints

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

Roger Holmes <rog...@mi...> wrote:

>  So we instead of four floats we have just 3 colour components but
>held in four bytes. This is quite likely to be 0..255 values (using
>Pascal syntax) but in the file would it be reasonable to assume
>rgba, or argb, or rgb<pad> or <pad>rgb?

I don't think the documentation can be trusted in this case.  If I 
were you, I'd either find a binary 3DMF file containing view hints 
with image clear color, or write a little Classic program to make 
one, and then see what's really there.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: Even more on View Hints (NEW INFO)

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

Il giorno 18/feb/05, alle 19:33, Roger Holmes ha scritto:

>>
>> Data Size
>>
>> 4
>
> But in my normal test file (from OS9) the object size is 16. Sounds 
> like it changed at some point.
>
> Is there a way of getting the object size into the _read method so I 
> can
> handle it in a different way depending on whether the length is 4 or 
> 16?
>

I was looking at this, I cant find a file with 4 bytes len data

they are in fact ARGB with four floats,

69 6D 63 63  	imcc
00 00 00 10 	16 (len)
00 00 00 00 	0		A
3F 80 00 00		1.0f	R
3F 80 00 00 	1.0f	G
3F 80 00 00 	1.0f	B

and converted to text (using anatas) are

ImageClearColor ( 0 1 1 1 )




Pax et Bonum

# dott. Jose' Cruanyes Aguilar  -  C.E. Soft srl
#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
#   02,33603122                0372,460602

Re: Even more on View Hints (NEW INFO)

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

>
> Data Size
>
> 4

But in my normal test file (from OS9) the object size is 16. Sounds 
like it changed at some point.

Is there a way of getting the object size into the _read method so I can
handle it in a different way depending on whether the length is 4 or 16?

Roger.

Re: Even more on View Hints

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

On Friday, February 18, 2005, at 02:33 PM, Jose' Cruanyes wrote:

> I think is anyway cleaner the first approach (patching=20
> e3fformat_3dmf_bin_readobject...)


I have now done it that way.

Any ideas on another quirk of QD3D?

Q3ViewHints_SetClearImageColor takes a parameter of TQ3ColorARGB*,
which has four float components, alpha, red, green and blue.

In the meta file specification we have:

ASCII
ImageClearColor
Binary
imcc ( =3D 0x696D6363 )



Data Format
ColorRGB=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0clearColor

clearColor
The RGB color to be given to the visible background of a model when an=20=

image is rendered from that model.



Data Size

4


Description

An image clear color object is used to assign color to the background=20
of a model in a rendered image when the model does not completely fill=20=

that image.

Example
Container (
=A0=A0=A0=A0ViewHints ( )
=A0=A0=A0=A0ImageDimensions ( ... )
=A0=A0=A0=A0ImageClearColor ( 1 1 1 )
=A0=A0=A0=A0.
=A0=A0=A0=A0.
=A0=A0=A0=A0.
)


So we instead of four floats we have just 3 colour components but held=20=

in four bytes. This is quite likely to be 0..255 values (using Pascal=20
syntax)
but in the file would it be reasonable to assume rgba, or argb, or=20
rgb<pad> or <pad>rgb?



What about in byte swapped files, should I read individual bytes, or=20
must I read them into an TQ3Uns32, letting the byte swapping code get
at them on the way, and then get the red byte by right shifting 24=20
places?



Roger

Re: Even more on View Hints

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

Il giorno 18/feb/05, alle 15:02, Roger Holmes ha scritto:

>
> On Thursday, February 17, 2005, at 09:58 PM, Jose' Cruanyes wrote:
>
>> Il giorno 17/feb/05, alle 21:15, James W. Walker ha scritto:
>>
>>> Here's a possibility:  In e3fformat_3dmf_bin_readobject, add a 
>>> special case, that checks whether the object type is 'lght' and 
>>> changes it to something else like 'lghd'.
>>>
>>
>> I support this idea (just made a comment blaming on Apple to make a 
>> such a bad coice)
>>
>> or perhaps add a metahandler for read/write the "Light Data" inside 
>> the kQ3ShapeTypeLight class
>
> With the last option, how would this work when reading text 3DMF? 
> Would it not check against the name of
> the class "Light" instead of "LightData" as required? Not that I have 
> any idea how text 3DMF I/O works in
> Quesa, but I assume the class names are there for some purpose. A neat 
> idea apart from that.
>
> Roger.

apart from this issue... I think is anyway cleaner the first approach 
(patching e3fformat_3dmf_bin_readobject...)

Pax et Bonum

# dott. Jose' Cruanyes Aguilar  -  C.E. Soft srl
#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
#   02,33603122                0372,460602

Re: Even more on View Hints

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

On Thursday, February 17, 2005, at 09:58 PM, Jose' Cruanyes wrote:

> Il giorno 17/feb/05, alle 21:15, James W. Walker ha scritto:
>
>> Here's a possibility:  In e3fformat_3dmf_bin_readobject, add a 
>> special case, that checks whether the object type is 'lght' and 
>> changes it to something else like 'lghd'.
>>
>
> I support this idea (just made a comment blaming on Apple to make a 
> such a bad coice)
>
> or perhaps add a metahandler for read/write the "Light Data" inside 
> the kQ3ShapeTypeLight class

With the last option, how would this work when reading text 3DMF? Would 
it not check against the name of
the class "Light" instead of "LightData" as required? Not that I have 
any idea how text 3DMF I/O works in
Quesa, but I assume the class names are there for some purpose. A neat 
idea apart from that.

Roger.

Re: Even more on View Hints

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

Il giorno 17/feb/05, alle 21:15, James W. Walker ha scritto:

> Here's a possibility:  In e3fformat_3dmf_bin_readobject, add a special 
> case, that checks whether the object type is 'lght' and changes it to 
> something else like 'lghd'.
>

I support this idea (just made a comment blaming on Apple to make a 
such a bad coice)

or perhaps add a metahandler for read/write the "Light Data" inside the 
kQ3ShapeTypeLight class

Pax et Bonum

# dott. Jose' Cruanyes Aguilar  -  C.E. Soft srl
#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
#   02,33603122                0372,460602

Re: Even more on View Hints

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

Kevin Matthews <mat...@ar...> wrote:

>Is this getting a bit whacky?  Isn't there a clean approach?

Short of having each class maintain two object types, one to be used 
only when reading binary 3DMF, I don't know what else to do.  But if 
you have another idea, we're listening.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: Even more on View Hints

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

On Thursday, February 17, 2005, at 08:15 PM, James W. Walker wrote:

> Roger Holmes <rog...@mi...> wrote:
>
>> As we never actually create any objects of class 'Light', only
>> ambient, directional, spot and point lights,
>> would it be OK to redefine kQ3ShapeTypeLight to be something like
>> 'lghT' with a capital T or 'Lght' ?
>
> I have some code that uses Q3Group_GetFirstPositionOfType and 
> Q3Group_GetNextPositionOfType with kQ3ShapeTypeLight, and that will 
> break if you redefine kQ3ShapeTypeLight.

Unless you recompiled with the revised headers but I accept that is not 
always convenient.

>
> Here's a possibility:  In e3fformat_3dmf_bin_readobject, add a special 
> case, that checks whether the object type is 'lght' and changes it to 
> something else like 'lghd'.

Yes that would work, not elegant but then Apple using the same ID for 
two different things is not elegant in the first place.

Thanks,

Roger.

> -- 
>   James W. Walker, ScriptPerfection Enterprises, Inc.
>   <http://www.write-brain.com/>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real 
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>