quesa-develop — Mailing list for Quesa development

Re: Question on GeomTest.

[Tom S. <to...@as...>]

Just a guess really, but try adding 0.5 to each pixel coordinate to ensure the point is at the centre of that pixel, eg. (50.5,50.5)
etc.

Tom

----- Original Message ----- 
From: "Peter Michelsen" <Pet...@mi...>
To: <que...@li...>
Sent: Wednesday, September 22, 2004 11:14 AM
Subject: Re: Question on GeomTest.


> Thanks for the answer.
>
> The rasterized objects are coming along but now and then points are a
> little under or a little over the float value I was expecting onscreen
> in pixels. Should I assume that the float value I give to Quesa in
> Rasterize Transforms to be equal to the pixel value on screen ?
>
> If they should I re-check my maths. Otherwise can I compensate in any
> way?
> (At the moment I am adding extra 1.0f to short lines, not ideal but is
> working.)
>
> Thanks in Advance,
> Peter.
>
>
>
> On 21 Sep 2004, at 16:50, James W. Walker wrote:
>
> >
> > On Sep 21, 2004, at 3:41 AM, Peter Michelsen wrote:
> >
> >> We have started to implement some of the new camera rastise transform
> >> style objects.
> >> I was reading the code in GeomTest for "createTestRasterize" and
> >> would like to know why you create UV's for the object even thou you
> >> are likely never to add a texture. In other words should I be
> >> creating UVs to camera rastise objects that I know will never have
> >> textures on them? Or have I miss the point of why the SurfaceUV
> >> attribute has been added.
> >
> > It's probably just because of the "Toggle Texture" command in Geom
> > Test.  For your own use, I do not think you need UVs on an object that
> > will not be textured.
> > --
> > <http://www.jwwalker.com/>
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> > Project Admins to receive an Apple iPod Mini FREE for your judgement on
> > who ports your project to Linux PPC the best. Sponsored by IBM.
> > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> > _______________________________________________
> > Quesa-develop mailing list
> > Que...@li...
> > https://lists.sourceforge.net/lists/listinfo/quesa-develop
> >
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop

Caching of Textures in file format

[Peter M. <Pet...@mi...>]

Hello all,

In QuickDraw3D 1.6 I have been informed there used to be a bug with 
caching of textures on saving and loading. We have some code to 
overcome this bug, but after some testing it seems that this bug does 
not exist in Quesa making this code redundant. Is this correct?

Cheers,
Peter

Re: Question on GeomTest.

[Peter M. <Pet...@mi...>]

Thanks for the answer.

The rasterized objects are coming along but now and then points are a 
little under or a little over the float value I was expecting onscreen 
in pixels. Should I assume that the float value I give to Quesa in 
Rasterize Transforms to be equal to the pixel value on screen ?

If they should I re-check my maths. Otherwise can I compensate in any 
way?
(At the moment I am adding extra 1.0f to short lines, not ideal but is 
working.)

Thanks in Advance,
Peter.



On 21 Sep 2004, at 16:50, James W. Walker wrote:

>
> On Sep 21, 2004, at 3:41 AM, Peter Michelsen wrote:
>
>> We have started to implement some of the new camera rastise transform 
>> style objects.
>> I was reading the code in GeomTest for "createTestRasterize" and 
>> would like to know why you create UV's for the object even thou you 
>> are likely never to add a texture. In other words should I be 
>> creating UVs to camera rastise objects that I know will never have 
>> textures on them? Or have I miss the point of why the SurfaceUV 
>> attribute has been added.
>
> It's probably just because of the "Toggle Texture" command in Geom 
> Test.  For your own use, I do not think you need UVs on an object that 
> will not be textured.
> --
> <http://www.jwwalker.com/>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>

Re: Question on GeomTest.

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

On Sep 21, 2004, at 3:41 AM, Peter Michelsen wrote:

> We have started to implement some of the new camera rastise transform 
> style objects.
> I was reading the code in GeomTest for "createTestRasterize" and would 
> like to know why you create UV's for the object even thou you are 
> likely never to add a texture. In other words should I be creating UVs 
> to camera rastise objects that I know will never have textures on 
> them? Or have I miss the point of why the SurfaceUV attribute has been 
> added.

It's probably just because of the "Toggle Texture" command in Geom 
Test.  For your own use, I do not think you need UVs on an object that 
will not be textured.
--
<http://www.jwwalker.com/>

Re: Question on GeomTest.

[Peter M. <Pet...@mi...>]

Hello All,

Another question on camera rasterize transforms, would you say that the 
vertPoints used in floats in GeomTest, should be equal to pixels on 
screen?

I am drawing a 50.0f by 50.0f box and one corner is missing

Question on GeomTest.

[Peter M. <pet...@mi...>]

Hello all,

We have started to implement some of the new camera 
rastise transform style objects. 

I was reading the code in GeomTest for 
"createTestRasterize" and would like to know why you 
create UV's for the object even thou you are likely never 
to add a texture. In other words should I be creating UVs 
to camera rastise objects that I know will never have 
textures on them? Or have I miss the point of why the 
SurfaceUV attribute has been added.

Thanks in advance,

Peter.

Re: RasteriseCameraTransform

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

On Thursday, September 16, 2004, at 04:22  pm, Dair Grant wrote:

> Roger Holmes wrote:
>
>> In the Quesa inheritance structure, does TQ3RasteriseCameraTransform
>> inherit from TQ3Transform as its name implies?
>
> Yep - the camera transform and the rasterise camera transform both
> derive from the transform object.
>
>
>> If it does, shouldn't Q3Transform_GetMatrix work on it? At present it
>> gives an assertion error.
>
> It should work (i.e., not fail), although it won't return anything
> sensible. It should call down to e3transform_camera_rasterize_matrix,
> which will return an identity matrix for want of anything else.
>
> Where do you get the assert from?
>

It asserts that the object is of type transform, but this fails.

Re: RasteriseCameraTransform

[Dair G. <da...@re...>]

Roger Holmes wrote:

>In the Quesa inheritance structure, does TQ3RasteriseCameraTransform
>inherit from TQ3Transform as its name implies?

Yep - the camera transform and the rasterise camera transform both
derive from the transform object.


>If it does, shouldn't Q3Transform_GetMatrix work on it? At present it
>gives an assertion error.

It should work (i.e., not fail), although it won't return anything
sensible. It should call down to e3transform_camera_rasterize_matrix,
which will return an identity matrix for want of anything else.

Where do you get the assert from?


-dair
___________________________________________________
mailto:dair+refnum.com       http://www.refnum.com/

RasteriseCameraTransform

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

In the Quesa inheritance structure, does TQ3RasteriseCameraTransform 
inherit
from TQ3Transform as its name implies?

If it does, shouldn't Q3Transform_GetMatrix work on it? At present it 
gives an
assertion error.

Roger.

Re: Textures with transparency and glBlendFunc

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

Dair Grant <da...@re...> wrote:

>Should it go on the renderer, on as a new style? I guess if it's a short
>term thing the renderer would be simpler, but on the other hand if this
>is something you would want preserved forevermore then we should
>introduce it in a way we can keep working.

A new style would be a lot more work, and I'm not feeling quite that 
energetic. :-)  If a style were introduced later, the renderer blend 
setting could still be used as a default, i.e., if there is no active 
blend style, use the renderer's blend style (and of course, if 
neither exist, fall back to the QD3D-compatible defaults.)
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: Textures with transparency and glBlendFunc

[Frank C. <dev...@ch...>]

On 14-Sep-04, at 5:39 PM, Dair Grant wrote:

> James W. Walker wrote:
>
>> In the near term, would anyone object if I added a global option for
>> blending function, such as an object property on the renderer?
>
> Should it go on the renderer, on as a new style? I guess if it's a 
> short
> term thing the renderer would be simpler, but on the other hand if this
> is something you would want preserved forevermore then we should
> introduce it in a way we can keep working.

I have to agree - It would be much more useful if it could be applied 
per-object.

On a similar note, would it be reasonable to modify the Get/SetProperty 
API to work per object? That would be _much_ more useful than how it 
currently works, but I'm not sure how difficult the implementation 
would be. On the other hand, replacing that API with new style objects 
may be a better way to go about it. There are very few things that 
should have a strictly global effect IMHO. The global texture filtering 
settings are a constant annoyance for example, and although the depth 
buffer manipulation via the Get/SetProperty API is welcomed, it would 
be much easier to work with if the settings could be applied 
per-object.

Frank.

Re: Textures with transparency and glBlendFunc

[Dair G. <da...@re...>]

James W. Walker wrote:

>In the near term, would anyone object if I added a global option for=20
>blending function, such as an object property on the renderer?=20

Should it go on the renderer, on as a new style? I guess if it's a short
term thing the renderer would be simpler, but on the other hand if this
is something you would want preserved forevermore then we should
introduce it in a way we can keep working.


-dair
___________________________________________________
mailto:dair+refnum.com       http://www.refnum.com/

Re: Textures with transparency and glBlendFunc

[Dair G. <da...@re...>]

=46rank Condello wrote:

>That would be my #1 request, as long as it's generic (i.e. you can do=20
>light maps and bump maps, but aren't limited to light maps and bump=20
>maps). It should use true hardware multitexturing when possible, but=20
>also break down into multiple passes to keep it robust.

Yes, it would be the normal set of texture units and operators.


>>   - Hosting geometry data on the card
>
>Again, would be nice but not typically needed unless you're dealing=20
>with insane in-view polycounts (it also requires a decent AGP pipe to=20
>be worth the effort IIRC).

Assuming you have your gross culling sorted out, minimising the amount
of time you spent blocking waiting for GL to take your geometry data is
they key to getting good performance.

Rather than purely just having static data on the card, I was thinking
more along the lines of going straight to VBOs and skipping the interim
ideas in this area (fences and the like).


>Even object/group based frustum culling would be a good a start.

Yes, the IR should respond to that selector and cull any groups that
aren't visible.


>If it makes more sense, perhaps this stuff should be done in a new=20
>plugin renderer? It could just duplicate the IR renderer to start, and=20
>be built up from there to keep the default QD3D behaviour in tact=20
>without worrying about breaking it every time something is=20
>added/changed.

Hmm, I'd say a better way to spend time would be to set up a test
harness to ensure you can tell when something breaks. Otherwise you have
the same problem when NewIR needs to be rewritten for some future
thing... :-)


-dair
___________________________________________________
mailto:dair+refnum.com       http://www.refnum.com/

Re: Textures with transparency and glBlendFunc

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

Frank Condello <dev...@ch...> wrote:

>This blendfunc is used to mimic QD3D's blending. To get a
>transparent pixel you need to have an alpha of zero as well as RGB
>values that add up to zero (premultiplied alpha). The idea is that
>you can get additive blending and normal alpha blending by changing
>the art, rather than doing it in code. This is one legacy I'd rather
>do without to be honest...
>
>This is the source of many problems, including what you observed
>above (i.e. you can't fade out an ARGB texture reasonably in code).
>It also causes the problems with ARGB textures in fog - not that fog
>works on _any_ transparent triangles at the moment ;)

OK, thanks for the explanation.

>IMHO, Quesa really needs an API that allows you to either explicitly
>set the blend function for the underling 3D API, or have blend
>function "aliases" that are translated for each API - kinda moot at
>this point since OpenGL is the only API involved. Either that, or a
>new type of Shader that does something similar - I'd love to see a
>"MultipassShader" object that can reference one or more texture
>shaders and apply them in layers with different blend functions and
>UV transformations - that would at least allow Quesa to compete with
>other scene graphs on the rendering side of things. The
>one-texture-per-triangle limitation grows stale real fast...

In the near term, would anyone object if I added a global option for 
blending function, such as an object property on the renderer?  If it 
is OK, should the property specify 4 values, namely the source and 
destination blend factors for textures and for vertex colors, or just 
a single boolean flag indicating whether texture alpha is 
premultiplied?
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: Textures with transparency and glBlendFunc

[Frank C. <dev...@ch...>]

On 14-Sep-04, at 3:32 PM, Dair Grant wrote:

> Frank Condello wrote:
>
>> not that fog works on _any_ transparent triangles at the moment ;)
>
> It seems to be working OK for the cone in Geom test - do you have a 
> test
> case?

Sorry you're right - it does work (kinda) but there are problems:

Fog isn't explicitly checked for and set during the transparent pass, 
so it just uses the last fog state - which isn't necessarily the 
correct fog state. While we're at it, it's the same deal for 
illumination...

Phong shading on transparent triangles also breaks when fogged, since 
you get an additive effect over the entire polygon (I'm not sure if 
this can be fixed using the built-in specular extensions and fog). This 
is similar to the problem with ARGB textures in fog, but that can be 
worked around if you could explicitly assign blend modes.

>> I'd love to see a "MultipassShader" object that can reference one or
>> more texture shaders and apply them in layers with different blend
>> functions and UV transformations
>
> Yes, we really need to bring the shading API up to date with what's
> currently possible on average hardware. The current feature set is
> basically what was around a couple of years ago, so you're missing out
> on:
>
>   - Multitexturing (light maps, bump maps, etc)

That would be my #1 request, as long as it's generic (i.e. you can do 
light maps and bump maps, but aren't limited to light maps and bump 
maps). It should use true hardware multitexturing when possible, but 
also break down into multiple passes to keep it robust.

>   - Vertex programs
>   - Fragment programs

Would be nice, but to be honest I can do without these for a long while 
still...

>   - Hosting geometry data on the card

Again, would be nice but not typically needed unless you're dealing 
with insane in-view polycounts (it also requires a decent AGP pipe to 
be worth the effort IIRC). I think some built-in geometry partitioning 
and culling would be far more beneficial at this point. Even 
object/group based frustum culling would be a good a start.

> What we really need is a QD3D-style API for expressing this, which can
> then be implemented by a renderer using their particular feature set.

Yes, one or more new shader objects that can be applied in place of 
TextureShaders would be very cool. It appears Apple had the intent of 
supporting all sorts of shader objects but QD3D was dropped before they 
implemented them.

If it makes more sense, perhaps this stuff should be done in a new 
plugin renderer? It could just duplicate the IR renderer to start, and 
be built up from there to keep the default QD3D behaviour in tact 
without worrying about breaking it every time something is 
added/changed.

Frank.

Re: Textures with transparency and glBlendFunc

[Dair G. <da...@re...>]

=46rank Condello wrote:

>not that fog works on _any_ transparent triangles at the moment ;)

It seems to be working OK for the cone in Geom test - do you have a test
case?


>I'd love to see a "MultipassShader" object that can reference one or
>more texture shaders and apply them in layers with different blend
>functions and UV transformations

Yes, we really need to bring the shading API up to date with what's
currently possible on average hardware. The current feature set is
basically what was around a couple of years ago, so you're missing out
on:

  - Multitexturing (light maps, bump maps, etc)
  - Vertex programs
  - Fragment programs
  - Hosting geometry data on the card

The two big changes since QD3D came out have been in texture combining
(output =3D=3D chain of textures connected with some blend operators) and
programmability (animation and lighting controlled via little programs
that run on the GPU).

What we really need is a QD3D-style API for expressing this, which can
then be implemented by a renderer using their particular feature set.=20

D3D would actually be a better thing to look at for designing such a
thing, as it's (IMO) a lot saner than GL in some areas (you have one
description of how the API works, rather than N extensions with M
interactions between them).


-dair
___________________________________________________
mailto:dair+refnum.com       http://www.refnum.com/

Re: Textures with transparency and glBlendFunc

[Frank C. <dev...@ch...>]

On 14-Sep-04, at 2:32 PM, James W. Walker wrote:

> I was puzzled to observe that an object with an ARGB texture did not 
> become invisible, except for specular highlights, when the alpha 
> channel was zero.  Apparently this is because Quesa uses 
> glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA) for transparent textures. 
> Is there some good reason for this?

This blendfunc is used to mimic QD3D's blending. To get a transparent 
pixel you need to have an alpha of zero as well as RGB values that add 
up to zero (premultiplied alpha). The idea is that you can get additive 
blending and normal alpha blending by changing the art, rather than 
doing it in code. This is one legacy I'd rather do without to be 
honest...

This is the source of many problems, including what you observed above 
(i.e. you can't fade out an ARGB texture reasonably in code). It also 
causes the problems with ARGB textures in fog - not that fog works on 
_any_ transparent triangles at the moment ;)

IMHO, Quesa really needs an API that allows you to either explicitly 
set the blend function for the underling 3D API, or have blend function 
"aliases" that are translated for each API - kinda moot at this point 
since OpenGL is the only API involved. Either that, or a new type of 
Shader that does something similar - I'd love to see a 
"MultipassShader" object that can reference one or more texture shaders 
and apply them in layers with different blend functions and UV 
transformations - that would at least allow Quesa to compete with other 
scene graphs on the rendering side of things. The 
one-texture-per-triangle limitation grows stale real fast...

Sorry for the rant :)
Frank.

Re: Textures with transparency and glBlendFunc

[Dair G. <da...@re...>]

James W. Walker wrote:

>glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA) for transparent textures.=20
>Is there some good reason for this?

None comes to mind - I suspect I just grabbed it out of the FAQ:

  <http://www.opengl.org/resources/faq/technical/transparency.htm>


-dair
___________________________________________________
mailto:dair+refnum.com       http://www.refnum.com/

Textures with transparency and glBlendFunc

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

I was puzzled to observe that an object with an ARGB texture did not 
become invisible, except for specular highlights, when the alpha 
channel was zero.  Apparently this is because Quesa uses 
glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA) for transparent textures. 
Is there some good reason for this?
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: [ quesa-Bugs-1027387 ] Quesa in CVS not compatible with Nanosaur

[Lane R. <la...@if...>]

on Mon, Sep 13, 2004 Dair Grant may have said:

>SourceForge.net wrote:
>
>>Bugs item #1027387, was opened at 2004-09-13 12:41 Message generated
>>for change (Tracker Item Submitted) made by Item Submitter You can
>>respond by visiting:
>>https://sourceforge.net/tracker/?func=detail&atid=442052&aid=1027387&
>>group_id=45158
>
>Could you log individual bugs for the specific issues you see?
>
>It's not going to be possible to do anything with this bug - "doesn't
>work" doesn't really help pin it down. :-)

OK; if I get time I will do this... but I have to get Bugdom and Nanosaur
working again (the latest Windows updates have broken quesa, and I've got
tons of customers very upset).

Lane Roathe
President          Ideas From the Deep        <http://www.ifd.com>
___________________________________________________________________
Since the Internet has no walls or fences, who needs Windows or Gates?

Re: [ quesa-Bugs-1027387 ] Quesa in CVS not compatible with Nanosaur

[Dair G. <da...@re...>]

SourceForge.net wrote:

>Bugs item #1027387, was opened at 2004-09-13 12:41 Message generated
>for change (Tracker Item Submitted) made by Item Submitter You can
>respond by visiting:
>https://sourceforge.net/tracker/?func=3Ddetail&atid=3D442052&aid=3D1027387=
&
>group_id=3D45158

Could you log individual bugs for the specific issues you see?

It's not going to be possible to do anything with this bug - "doesn't
work" doesn't really help pin it down. :-)


-dair
___________________________________________________
mailto:dair+refnum.com       http://www.refnum.com/

[ quesa-Bugs-1027387 ] Quesa in CVS not compatible with Nanosaur

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

Bugs item #1027387, was opened at 2004-09-13 12:41
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=1027387&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Lane Roathe (raving)
Assigned to: Nobody/Anonymous (nobody)
Summary: Quesa in CVS not compatible with Nanosaur

Initial Comment:
The version of Quesa for Windows that is in CVS does
not work with Nanosaur for Windows.

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

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

[ quesa-Bugs-1027379 ] Windows CW project has incorrect access paths

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

Bugs item #1027379, was opened at 2004-09-13 12:27
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=1027379&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Lane Roathe (raving)
Assigned to: Nobody/Anonymous (nobody)
Summary: Windows CW project has incorrect access paths

Initial Comment:
The CW project for Quesa Windows has incorrect access
paths;

{Compiler}Win32-x86 Support/Includes
{Compiler}Win32-x86 Support/Libraries
{Compiler}Win32-x86 Support/Libraries/Win32SDK

This should be:

{Compiler}Win32-x86 Support

as everyone's support folder can differ (greatly). For
example, if you update the DirectX SDK you will no
longer have ddraw.h in the includes folder, instead it
will be in DXSDK/Includes.


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

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

SetPixelFormat failing

[Lane R. <la...@if...>]

Recently I found that a SetPixelFormat call in Quesa was failing;
specifically the line

    if (!SetPixelFormat(theContext->theDC, pixelFormat, &pixelFormatDesc))

in "./Renderers/Common/GLDrawContext.c"


Nothing had changed, except I updated my video drivers. This has probably
been the cause of almost all of my non-solvable OpenGL issues with Bugdom
and Nanosaur with a lot of customers who purchased one of these games
(ie, lots of refunds).

Anyone have any ideas on why this would fail? It's when it's creating a
new GL context, and the pixel format's "cColorBits" are zero (meaning, I
would assume, the default).

Anyway, the fix I found was to remove the error checking on this line;
when removed everything works just fine.

Thoughts on a "proper" solution welcome.


PS: Also, as I lost the source to the version of Quesa for Nanosaur,
anyone willing to help look at getting the CVS version of Quesa working
with Nanosaur (and/or Bugdom for that matter) would have my eternal thanks :)


Lane Roathe
President          Ideas From the Deep        <http://www.ifd.com>
___________________________________________________________________
When we drive on parkways, park in driveways, and never obey the speed
limit, is it any wonder our children have trouble with right and wrong?

Re: Drag & Drop?

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

James and all,

Yes it is up to the application developers.

The standard flavour '3DMF' is both produced and accepted by
all Microspot's 3D products (Interiors, Modeller and one day
I hope the whole of 3D World will make it to OS-X too)

Demo and N.F.R. copies available to developers if you want to
test compatibility, or maybe a product swap?

Roger.


On Tuesday, August 31, 2004, at 03:44  pm, James Dessart wrote:

> On Mac OS X, do any Quesa views support drag & drop? Or is this left 
> to application developers? In any case, is there a standard flavour 
> for 3DMF drags?
>
> Thanks,
> James
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>