quesa-develop — Mailing list for Quesa development

[ quesa-Bugs-907855 ] TriMesh shading wrong when no vertex UVs are present

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

Bugs item #907855, was opened at 2004-03-01 21:21
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=907855&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dair Grant (grantd)
Assigned to: Nobody/Anonymous (nobody)
Summary: TriMesh shading wrong when no vertex UVs are present

Initial Comment:
(note, this issue could also be solved by bug 907849, as any 
triangles that shared vertex attributes would push us onto the 
break-down-and-push-into-tribuffer path)


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

When rendering a TriMesh with no vertex UVs in Quesa 1.6d16, the 
shading is interpolated across each triangle, as if we had vertex 
normals.  The correct appearance would be for each triangle to 
have a uniform shading, for a faceted appearance.  See attached 
sample 3DMF and picture showing the result in QD3D and Quesa.

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

OK, had a quick look at this. The problem is that the triangles in 
the TriMesh share vertices, and we don't correctly handle the case 
where a shared vertex inherits different values from the triangles 
which reference it.

The model was of a box, so if you consider two of the top/face 
triangles like:

        /|         |
     V_______
     |
  /  |
  ---|
  \  |

I.e., on triangle on the top of the box whose normal points up, and 
one triangle on the side of the face whose normal points out.

What happens at the moment is that when we're looking for the 
normal for V, we check to see if V specifies it. It doesn't, so we 
pick the first triangle which references V and use its normal. This 
then means that when the second triangle is rendered, it also 
references V and so ends up with the wrong normal (which 
produces the smoothed off effect).

The general way to handle this is to introduce new vertices into the 
TriMesh when we see that shared vertices have different parents - 
it looks like this is what QD3D was doing, as the same problem 
occurs with colours (e.g., if the top triangle was red and the side 
one was blue, you would get an all-red and all-blue triangle in 
QD3D: but we'll do a red-to-blue fade over the two triangles).


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

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

[ quesa-Bugs-907852 ] Custom elements always written to 3DMF

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

Bugs item #907852, was opened at 2004-03-01 21:17
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=907852&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dair Grant (grantd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Custom elements always written to 3DMF

Initial Comment:
While writing a 3DMF file, all the custom elements registered in the 
system are writen to the file.

We should only write those elements referenced by the saving 
model, so will need to perform an initial pass to identify the 
referenced elements or write the custom elements out after all the 
data has been submitted.

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

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

[ quesa-Bugs-907849 ] Split TriMesh into simple and complex cases

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

Bugs item #907849, was opened at 2004-03-01 21:16
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=907849&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dair Grant (grantd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Split TriMesh into simple and complex cases

Initial Comment:
From an older bug:

-----------------------
To correctly render complex meshes, the IR TriMesh code should 
handle TriMeshes with per-texture triangles (rather than only 
supporting per-TriMesh textures).

It won't be possible to submit them as a vertex array, so the best 
solution is probably to detect a "this is too complex to render as a 
TriMesh" which breaks the TriMesh up into individual triangles.

The "this is too complex" tests should be modelled on the fast-path 
tests, so we can add more tests in the future - for now, checking 
for kQ3AttributeTypeSurfaceShader in the triangle attribute list 
would sufice to detect this case.
-----------------------

As well as handling the above case, splitting the TriMesh code into 
"simple case, passed directly to GL/D3D" and "complex case, 
broken up and pushed into triangle buffer" will also help reduce the 
amount of data the CPU needs to touch for the fast case.

This bug was originally intended to track per-texture triangles, but 
the performance benefits from separating out the two cases would 
make it worthwhile regardless.

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

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

[ quesa-Bugs-907847 ] Architecture-specific optimisations

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

Bugs item #907847, was opened at 2004-03-01 21:13
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=907847&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dair Grant (grantd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Architecture-specific optimisations

Initial Comment:
Add AltiVec/SIMD specific implementations of some routines, to get 
platform-specific performance improvements.

Initial candidates would be the math _Array functions (vector 
optimisations typically need a large block of data to work with to 
make their setup cost worthwhile), or fast sqrt approximations 
(_frsqrte on G4s, HW sqrt on G5s, etc).

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

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

Re: Thread safety

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

Edward K. Chew wrote:

>but would you really want to lock every last Submit call or accessor
>function

Yep, if you want to be thread safe then any shared data must be
protected by a lock. Million to one chances (two people writing to the
same variable at the same time) happen all the time as soon as threads
are involved... :-)

The only functions which can avoid locks are those which don't access
shared state, i.e., the only data they manipulate is referenced by their
parameters.

E.g., a C library could easily provide a toupper() that didn't need a
lock, since all the state it needs is on the thread's own stack and
registers.

But something like malloc() will always need a lock, since two threads
could easily call malloc at the same time.


>My allocmem method was simply calling malloc under CodeWarrior, which=20
>was in turn calling NewPtr through a low-level function called=20
>__sys_alloc.  After setting the _MSL_THREADSAFE flag so it would call=20
>MPAllocateAligned instead, I have never experienced another=20
>crash...well, not in THAT part of the code, anyway.  :-)  But if you=20
>have read that NewPtr is safe, let me know and I will submit a bug=20
>report.

If you were calling the MSL malloc from a thread without rebuilding MSL
with _MSL_THREADSAFE, that's the behaviour I would expect (i.e., a
crash).

MSL implements its own memory manager on top of the system API, and so
if you've got multiple threads that memory manager needs to protect its
own data structures.

If you search for __begin_critical_region/__end_critical_region in MSL
you'll see where it applies the lock: these do nothing in default
builds, and acquire a mutex (either pthread or MP API) in thread-safe
builds.


There are several of them, applied in different places: one for memory
management APIs, one for file management APIs, etc.

They could have had one giant MSL lock to protect everything, but
multiple locks gives them better concurrency (but is more complex to
keep straight) since it allows one thread to be inside MSL's fopen while
another is inside malloc.


They use MPAllocateAligned as their underlying allocator because NewPtr
is only thread safe on X - since you could build MSL as thread-safe and
use it with MP tasks on 9, for the _MSL_THREADSAFE builds they need a
low-level allocator that is thread-safe on both platforms.

So I think the reason you're not crashing is not that you're going
through MPAllocateAligned, but that critical_regions.macos.h is
providing real locks rather than no-ops to protect the internals of MSL.

The end result is the same (no crash), but NewPtr is innocent here. ;-)


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

[ quesa-Bugs-905678 ] Texture filtering needs improvements

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

Bugs item #905678, was opened at 2004-02-27 03:16
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=905678&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Frank Condello (pox)
Assigned to: Nobody/Anonymous (nobody)
Summary: Texture filtering needs improvements

Initial Comment:
Here are the common filtering options in OpenGL.

// Nearest (Quesa's "kQATextureFilter_Fast" setting)
glTexParameteri(GL_TEXTURE_2D,  GL_TEXTURE_MAG_FILTER, 
GL_NEAREST);
glTexParameteri(GL_TEXTURE_2D,  GL_TEXTURE_MIN_FILTER, 
GL_NEAREST);

// Linear (Quesa's "kQATextureFilter_Best/Mid" setting)
glTexParameteri(GL_TEXTURE_2D,  GL_TEXTURE_MAG_FILTER, 
GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D,  GL_TEXTURE_MIN_FILTER, 
GL_LINEAR);

// Bilinear (Not supported in Quesa)
glTexParameteri(GL_TEXTURE_2D,  GL_TEXTURE_MAG_FILTER, 
GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D,  GL_TEXTURE_MIN_FILTER, 
GL_LINEAR_MIPMAP_NEAREST);

// Trilinear (Not supported in Quesa)
glTexParameteri(GL_TEXTURE_2D,  GL_TEXTURE_MAG_FILTER, 
GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D,  GL_TEXTURE_MIN_FILTER, 
GL_LINEAR_MIPMAP_LINEAR);

Bilinear and Trilinear are commonly the only options most scene 
graphs/games support, yet neither is supported in Quesa.

Fixing this requires a few changes:

1). The "qualityFilter" member in the "TQ3CachedTexture" struct 
can't be defined as a single GLuint. It either needs min/max 
values, or should possibly be a "TQ3TextureFilter" name instead, 
that can be used as a hint when uploading the texture (but that 
means changing how and where the TQ3TextureFilter is translated 
into something OpenGL can use).

2). Mipmaps should be generated when not present in a texture 
shader for filter modes that require them. This will more closely 
match the QD3D behaviour. but also allow mips to be easily 
excluded by using a Fast/Mid filter setting.

3). Quesa needs additional TQ3TextureFilter names, and the 
meaning of existing names should be altered. I'd recommend 
something like this to maintain compatibility:
kQATextureFilter_Fast = Nearest
kQATextureFilter_Mid = Linear
kQATextureFilter_Best = Bilinear
kQATextureFilter_Trilinear = Trilinear


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

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

Re: Thread safety

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

On Feb 26, 2004, at 04:59, Dair Grant wrote:

> Edward K. Chew wrote:
>
>> My approach so far has been to do geometry manipulations in the thread
>> and then signal the main process to handle the rendering.  Being
>> paranoid, I defined a single global critical region across the entire
>> application to wrap around every set of calls to Quesa functions.
>
> That is what you'd need to do: provided you have a single lock that
> protects any Quesa API call, you should be fine.
>
> Making the library thread safe would really be a two-step process:
>
> 1. Make there be a single lock inside Quesa that every glue method
> acquires/releases.

Hmm...I would be in favour of this up to a point, as long as all this 
locking and unlocking doesn't add significant overhead.  Sure, it makes 
sense to keep someone from directly manipulating the view that's 
currently rendering, but would you really want to lock every last 
Submit call or accessor function under the assumption that some idiot 
is going to call a Get function from one thread at the same time as a 
Set from another?

I think for any API you are likely to use a hundred times in a loop, it 
would be better to expose the locking and unlocking functions and let 
people call them themselves.  I guess rendering loops and their ilk are 
already encapsulated by library calls, so you could just build the 
locking logic into them.

> 2. Make there be multiple locks inside Quesa, so that multiple threads
> can be inside the library at the same time.
>
>
> The first one would let us declare the API to be thread-safe, so you
> could use it from a thread and let your app code run in parallel with
> itself (which will be where your 30% is coming from).
>
> The second one is obviously the tricky case, but you could probably
> introduce a lock per "module" (effectively source file, sinec most of
> our types are opaque even internally) fairly easily.

FWIW, I would like to see geometry and display group manipulation off 
in its own module.  I think the retained mode is just made for 
multithreading!  What could be simpler than creating a display group in 
a thread, playing around with it liberally as much as you want, and 
only worrying about locking at very the last instant when you are 
assigning it to a view?

> I believe NewPtr is (and always has been) thread safe on X, as it's 
> just
> a wrapper around malloc (with some extra book-keeping).

Then how do you explain this?  :-)

> Host Name:      yinyang.local
> Date/Time:      2004-02-16 18:47:30 -0500
> OS Version:     10.3.2 (Build 7D24)
> Report Version: 2
>
> Command: MultiLoop III.carbon
> Path:    /Users/ted/Public/cvstree/mlp3/release/MultiLoop III.carbon
> Version: ??? (???)
> PID:     1772
> Thread:  1
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000007
>
> Thread 0 Crashed:
> 0   MultiLoop III.carbon           	0x0053bcd8 0x405000 + 0x136cd8
> 1   MultiLoop III.carbon           	0x0053ba74 0x405000 + 0x136a74
> 2   MultiLoop III.carbon           	0x0053bfd8 0x405000 + 0x136fd8
> 3   MultiLoop III.carbon           	0x0053c6b4 0x405000 + 0x1376b4
> 4   MultiLoop III.carbon           	0x0053c750 0x405000 + 0x137750
> 5   MultiLoop III.carbon           	0x0051e458 
> allocmem__11xpmultitaskFUlRUc + 0x18
> 6   MultiLoop III.carbon           	0x004fce2c stdalloc__7xparrayFlRi 
> + 0x1c

[snip]

> Thread 1 Crashed:
> 0   MultiLoop III.carbon           	0x0053bcd8 0x405000 + 0x136cd8
> 1   MultiLoop III.carbon           	0x0053ba74 0x405000 + 0x136a74
> 2   MultiLoop III.carbon           	0x0053bfd8 0x405000 + 0x136fd8
> 3   MultiLoop III.carbon           	0x0053c6b4 0x405000 + 0x1376b4
> 4   MultiLoop III.carbon           	0x0053c750 0x405000 + 0x137750
> 5   MultiLoop III.carbon           	0x0051e458 
> allocmem__11xpmultitaskFUlRUc + 0x18
> 6   MultiLoop III.carbon           	0x004fce2c stdalloc__7xparrayFlRi 
> + 0x1c

My allocmem method was simply calling malloc under CodeWarrior, which 
was in turn calling NewPtr through a low-level function called 
__sys_alloc.  After setting the _MSL_THREADSAFE flag so it would call 
MPAllocateAligned instead, I have never experienced another 
crash...well, not in THAT part of the code, anyway.  :-)  But if you 
have read that NewPtr is safe, let me know and I will submit a bug 
report.

-Ted

Re: Thread safety

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

Edward K. Chew wrote:

>I am currently Carbonizing an old Quickdraw 3D app which did a lot of=20
>iterative updating out of the main event loop.  I want to move most of=20
>this logic into an MPTask, but am worried about the thread safety of=20
>the Quesa APIs.

At the moment, they're not:

<http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D902992&
group_id=3D45158&atid=3D442052>


>My approach so far has been to do geometry manipulations in the thread=20
>and then signal the main process to handle the rendering.  Being=20
>paranoid, I defined a single global critical region across the entire=20
>application to wrap around every set of calls to Quesa functions. =20

That is what you'd need to do: provided you have a single lock that
protects any Quesa API call, you should be fine.

Making the library thread safe would really be a two-step process:

1. Make there be a single lock inside Quesa that every glue method
acquires/releases.

2. Make there be multiple locks inside Quesa, so that multiple threads
can be inside the library at the same time.


The first one would let us declare the API to be thread-safe, so you
could use it from a thread and let your app code run in parallel with
itself (which will be where your 30% is coming from).

The second one is obviously the tricky case, but you could probably
introduce a lock per "module" (effectively source file, sinec most of
our types are opaque even internally) fairly easily.


>One concern I have is over memory allocation.  Does Quesa use NewPtr()=20
>to allocate retained-mode objects?

Quesa uses malloc, which will be thread safe if you're doing a Mach-O
build and normally not thread safe if you're using CFM (i.e., an MSL
which hasn't been rebuilt to be thread safe).

I believe NewPtr is (and always has been) thread safe on X, as it's just
a wrapper around malloc (with some extra book-keeping).


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

Thread safety

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

I am currently Carbonizing an old Quickdraw 3D app which did a lot of 
iterative updating out of the main event loop.  I want to move most of 
this logic into an MPTask, but am worried about the thread safety of 
the Quesa APIs.

My approach so far has been to do geometry manipulations in the thread 
and then signal the main process to handle the rendering.  Being 
paranoid, I defined a single global critical region across the entire 
application to wrap around every set of calls to Quesa functions.  
Depending on the locality of data in the library, I might have been 
able to get away with separate regions for each document (which has its 
own unique 3D view, thread, and geometries), but I didn't want to take 
any chances unless this is deemed safe.  Nevertheless, I have seen some 
impressive results already.  Activity Monitor says my app running on a 
dual processor G4 is sometimes using as much as 130% CPU, which 
suggests that it is rendering and calculating for the next iteration at 
the same time.  Whatever the case, it is running much faster than it 
used to.

One concern I have is over memory allocation.  Does Quesa use NewPtr() 
to allocate retained-mode objects?  That could be a problem, because I 
suspect it is not safe even in Panther.  malloc() is something of a 
mixed bag.  Apparently, it is safe in the gcc libraries, but under 
CodeWarrior, it calls NewPtr() by default (as of CW8.3).  :-(  You need 
to set the _MSL_THREADSAFE flag in ansi_prefix.mac.h and rebuild all 
the libraries to get it to use MPAllocateAligned() instead.

-Ted

Re: Joining Quesa project (was Minor bug in QD3DGeometry.c)

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

On Feb 24, 2004, at 10:49, Dair Grant wrote:

> Edward K. Chew wrote:
>
>> I take it you need to be a member of the Quesa project to submit a bug
>> report yourself?  How would I go about joining?
>
> You'll need to have a SF account to submit new bugs, but those are 
> free:
> follow the "New User via SSL" link on the left coumn.

Okay, thanks.  I see the "Submit New" option up at the top of the Bugs 
page now.

>> 1.  Write AltiVec versions of some of the math functions.  Some
>> functions like E3BoundingBox_SetFromPoints3D() are just begging to be
>> vectorized, since AltiVec can find minima and maxima very quickly
>> without any branching penalties.
>
> Yes, there are some fairly plausible vectorisations we could make in
> E3Math.c. We'd need to preserve the scalar approach for non-PowerPC
> platforms, and really ensure it's done in a way that can support SSE as
> well as AltiVec.
>
> The best approach for that is probably just calling through a function
> pointer, with some default callbacks that point to the scalar routines
> and which individual platforms can redirect to their own
> implementations.

Even if you tune the function for AltiVec or what have you, you will 
probably still need the default scalar version around, since the 
vectorized version may fall back on it if the input data has poor 
alignment or is otherwise difficult to work with.

Anyway, for now, maybe I will try writing a few functions external to 
the Quesa library and test them in my own app to make sure they work as 
advertised.  Then we can worry about how to incorporate them into the 
library?

>> 2.  Come up with some way to overlay 2D graphics (like Quickdraw or
>> Quartz) over a 3D view.  I have a real need for this in my app and I
>> doubt I am alone.
>
> You should  be able to do this now, however you will need to "draw"
> using Quesa objects (or OpenGL calls, you can make them within a
> rendering loop).
>
> There's now a camera transform object that will let you adjust the 
> three
> camera transforms directly, and a rasterize variant of that which sets
> things up for 2D drawing.
>
> I.e., the x and y components of a vertex will correspond to pixel
> locations, while the z component controls depth in the scene. See the
> comments for Q3RasterizeCameraTransform_New in QuesaTransform.h, or the
> example usage in GeomTest.c.
>
> The bitmap/pixmap markers now use this system to draw themselves as
> textured squares, which gives us much better performance than the
> previous approach.

Cool!  I will definitely look into that.

-Ted

Nanosaur shows bugs in new quesa

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

(first, apologies if you have already seen this; I sent it twice to the
old list as part of trying to send it to this list, which I thought I had
already joined ... but must not have ... senility sucks!)

Anyway, on with the message:

I just tried the latest CVS of quesa for Windows with Nanosaur. It works
pretty well (water now animates, and all terrain textures are much
improved, yea!), but there are a few problems with rendering (pretty
severe actually).

Anyone with indepth knowledge of Quesa's rendering pipeline interested in
taking a look at it? You can download Nanosaur from the IFD site and just
drop in new quesa DLL's as built. If you feel it will help, I can provide
the source under NDA.

(The same goes for Bugdom, which I still am trying to get working with
the latest builds instead of the custom build that Burger put
together...his seems to have a few fixes for loading files that I'm
having trouble syncing into the new Quesa project.)


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Lane Roathe, President                          Ideas From the Deep
<mailto:la...@if...>                          <http://www.ifd.com>
___________________________________________________________________
I am Pentium of Borg. Precision is futile. You will be approximated.

Fwd: About quesa bugs.

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

Peter Michelsen wrote:

> I see by the emails I have received you are making a new bug database,
> would you like other people to add to this database, or would you still
> like the bugs posted on the development list first.

Hi Peter,

Yes, please go ahead and add new bugs directly to the SourceForge
tracker. I have about another 30 bugs from the old Bugzilla database
which still need to be moved across, but if you have a new bug just log
it directly in SF.

The page to enter them is:

   <https://sourceforge.net/tracker/?group_id=45158&atid=442052>

Select the "Submit New" link, fill in the form (with any attached test
case), then hit the submit button at the bottom.

The SF bug tracker is hooked up to the mailing list, such that any new
bugs or changes to bugs will get copied to quesa-develop automatically.


> I am not sure but I believe this will also cure the problem we get with
> adding textures and then removing them. This gives a massive
> performance hit with the only method of refreshing the programs
> performance is to use the Microspot renderer then go back to the
> Interactive renderer.

Yes, that probably would help - the other thing that would be useful
would be the ability to use smaller texture formats.

Right now everything is converted to 32-bp 8888, but we could really use
a 16-bit (4444, 1555, or 565) format in some cases.


> One last question, does Quesa have a Final Renderer included in the cvs
> version? I did not think it has but I have been told that there is some
> software in the past for it. Is this the Generic Renderer?

The generic renderer is a QD3D concept, where it's a no-op renderer that
does nothing: you can use it if you want to submit data to a renderer
and have nothing happen (no, I'm not sure what use it is either :-).

There is a raytracer plug-in, called rayshade, within the CVS data:
however I don't know how up to date it is - I have seen some images out
of it, but I believe there are a couple of bugs in the set still to move
over.


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

Re: Joining Quesa project (was Minor bug in QD3DGeometry.c)

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

Edward K. Chew wrote:

>I take it you need to be a member of the Quesa project to submit a bug=20
>report yourself?  How would I go about joining?

You'll need to have a SF account to submit new bugs, but those are free:
follow the "New User via SSL" link on the left coumn.


>1.  Write AltiVec versions of some of the math functions.  Some=20
>functions like E3BoundingBox_SetFromPoints3D() are just begging to be=20
>vectorized, since AltiVec can find minima and maxima very quickly=20
>without any branching penalties.

Yes, there are some fairly plausible vectorisations we could make in
E3Math.c. We'd need to preserve the scalar approach for non-PowerPC
platforms, and really ensure it's done in a way that can support SSE as
well as AltiVec.

The best approach for that is probably just calling through a function
pointer, with some default callbacks that point to the scalar routines
and which individual platforms can redirect to their own
implementations.


>2.  Come up with some way to overlay 2D graphics (like Quickdraw or=20
>Quartz) over a 3D view.  I have a real need for this in my app and I=20
>doubt I am alone.

You should  be able to do this now, however you will need to "draw"
using Quesa objects (or OpenGL calls, you can make them within a
rendering loop).

There's now a camera transform object that will let you adjust the three
camera transforms directly, and a rasterize variant of that which sets
things up for 2D drawing.

I.e., the x and y components of a vertex will correspond to pixel
locations, while the z component controls depth in the scene. See the
comments for Q3RasterizeCameraTransform_New in QuesaTransform.h, or the
example usage in GeomTest.c.=20

The bitmap/pixmap markers now use this system to draw themselves as
textured squares, which gives us much better performance than the
previous approach.


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

Re: Joining Quesa project (was Minor bug in QD3DGeometry.c)

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

On Feb 20, 2004, at 17:49, Dair Grant wrote:

> Edward K. Chew wrote:
>
> The bug tracker is at:
>
>   <https://sourceforge.net/tracker/?group_id=45158&atid=442052>
>
> It's probably best for us to get in the habit of submitting anything
> that needs a cvs change (or just a feature request, whatever) to the
> tracker, as that way we can make sure we have an ID to reference if it
> turns out not to be trivial.

I take it you need to be a member of the Quesa project to submit a bug 
report yourself?  How would I go about joining?

Maybe I could contribute some code for a few things.  On my To-Do list 
might be:

1.  Write AltiVec versions of some of the math functions.  Some 
functions like E3BoundingBox_SetFromPoints3D() are just begging to be 
vectorized, since AltiVec can find minima and maxima very quickly 
without any branching penalties.

2.  Come up with some way to overlay 2D graphics (like Quickdraw or 
Quartz) over a 3D view.  I have a real need for this in my app and I 
doubt I am alone.  Even dragging a selection rectangle around a group 
of 3D objects seems rather non-trivial, unless I am missing something.  
Anyway, if I can find a satisfactory solution to the problem (and 
that's a big IF), I would be happy to submit it.

-Ted

[ quesa-Bugs-902993 ] Box depends on order of axes

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

Bugs item #902993, was opened at 2004-02-23 21:13
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=902993&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dair Grant (grantd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Box depends on order of axes

Initial Comment:
If the orientation, majorAxis, and minorAxis vectors do not form a 
right-handed system, then the box will not look correct unless you 
use the backfacing-flip style.  QuickDraw 3D seems to do the same 
thing, but it should at least be documented.

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

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

[ quesa-Bugs-902992 ] Make API re-entrant for multithreading

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

Bugs item #902992, was opened at 2004-02-23 21:12
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=902992&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dair Grant (grantd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make API re-entrant for multithreading

Initial Comment:
Discussion on the list about making the API re-entrant - logging 
here as a feature 
request.

-dair

*****

James Dessart wrote:

Is there a list somewhere of what Quesa functions are, or are not,  
reentrant?  It'd be nice to be able to push some of the more  
compute-bound functions out into multi-processor threads on the 
Mac  OS, in our application.

*****

Dair Grant wrote:

At present nothing is officially re-entrant - there aren't any locks 
whatsoever. In practice you would probably find that the math 
routines are probably safe, although even they should really have 
some protection in their glue around the global error state (or 
make the error state thread specific).


Doing a first pass on thread safety (i.e., one global lock which was 
acquired/released by every entry point) would be fairly easy since 
it could be munged into the glue code.

Allowing multiple threads inside Quesa at once would be more 
complex, although you could probably get most of the way there 
by having per-object locks since most routines pass the object 
they're working on around.

There is only bit of global data, so protecting that+the objects the 
current thread is working on would probably be enough (assuming 
a thread safe C library/OpenGL).


I suppose it depends on what the performance gains of doing that 
wold be vs the complexity of the extra locks.

My guess is it'd only really be worth it for things like the math 
routines, where you might want to dump transforming an array of 
vertices off to another thread?

*****

James Dessart wrote:

It's pretty much just the math routines, and perhaps setting  
TriMesh data.  Essentially, playing around with coordinates and  
such, without any rendering.

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

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

[ quesa-Bugs-902990 ] View hints are not supported

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

Bugs item #902990, was opened at 2004-02-23 21:11
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=902990&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dair Grant (grantd)
Assigned to: Nobody/Anonymous (nobody)
Summary: View hints are not supported

Initial Comment:
View hints are discarded when reading from 3DMFs, we should 
read and respect the values used by QD3D (camera position, draw 
context colour, etc) and write them out again when writing to 
3DMFs.

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

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

[ quesa-Bugs-902989 ] Scrolling Exhibits Coordinate-Space Confusion

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

Bugs item #902989, was opened at 2004-02-23 21:11
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=902989&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dair Grant (grantd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Scrolling Exhibits Coordinate-Space Confusion

Initial Comment:
Build Macintosh Carbon Quesa shared libraries. Retrieve <a 
href="http://www.halcyon.com/www3/jesjones/Whisper/
Home.html">Whisper 2</a> from CVS to get Carbonized version. 
Also check out "Extras" module. Build Hypermandella in "Extras" 
folder. Place "Quesa" shared library in Hypermandella folder. 
Launch Hypermandella. Allow rendering of fractal to complete. 
Shrink window until scroll bars appear. Scroll around.

By appearances, Quesa is getting confused (still) as to what the 
origin of its drawing context is. If memory serves me correctly, 
this bug is long-standing and has been believed to have been fixed 
before.

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

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

[ quesa-Bugs-902988 ] Add view statistics API

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

Bugs item #902988, was opened at 2004-02-23 21:10
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=902988&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dair Grant (grantd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add view statistics API

Initial Comment:
It would be useful to have an API for gathering statistics about a 
view, so that Quesa could maintain statistics about current 
performance. Sort of info which could be gathered includes number 
of objects culled due to visibility, number of TriMeshes which hit 
the fast path (or slow path) through the renderer, number of 
objects submitted per frame, number of submit loops performed, 
min/max/average FPS, etc.

Interface would probably be something like:

TQ3Status Q3View_ResetStatistics(TQ3ViewObject theView);
TQ3Status Q3View_GetStatistics(TQ3ViewObject theView, 
TQ3ViewStatistics *theStatistics);

Note that there's no enable/disable API, as this information would 
be collected continually (it's really just a bunch of counters that get 
incremented, so no overhead), but an app could reset+get over 
whatever time period they wanted (once per frame, over 5 
minutes, over the lifetime of their app).

The TQ3ViewStatistics structure would need to be extensible for 
the future: either with a size/version tag as the first field, or with 
enough space for say 100 TQ3Uns32 counters (probably a mixture 
of both: include a version/size for the long term, and reserve say 
30 fields for easy expansion).

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

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

[ quesa-Bugs-902985 ] Support ATI TruForm

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

Bugs item #902985, was opened at 2004-02-23 21:09
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=902985&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dair Grant (grantd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Support ATI TruForm

Initial Comment:
We should have a global pref that lets apps turn on ATI's TruForm 
(or as a special subdivision style?).

Example code to enable this is at http://lists.apple.com/archives/
mac-opengl/2002/Mar/27.html with the username/password 
"archives".

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

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

[ quesa-Bugs-902984 ] Use GL_APPLE_client_storage for textures

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

Bugs item #902984, was opened at 2004-02-23 21:07
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=902984&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dair Grant (grantd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Use GL_APPLE_client_storage for textures

Initial Comment:
We should use the GL_APPLE_client_storage extension for texture 
objects, to let OpenGL use our copy of the texture data rather than 
have them take another copy themselves.

Since we always know when the app touches the texture data, we 
can keep OpenGL in sync automatically.

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

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

[ quesa-Bugs-902983 ] Support alternative fog models

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

Bugs item #902983, was opened at 2004-02-23 21:06
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=902983&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dair Grant (grantd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Support alternative fog models

Initial Comment:
We should support per-vertex and radial fog: fog_coord and 
nv_fog_distance.

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

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

[ quesa-Bugs-902982 ] Support FSAA through arb_multisample

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

Bugs item #902982, was opened at 2004-02-23 21:05
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=902982&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dair Grant (grantd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Support FSAA through arb_multisample

Initial Comment:
The kQ3AntiAliasModeMaskFullScreen style should be implemented 
with the arb_multisample extension where available (e.g., in 
Jaguar) rather than an ATI specific enum.

This will let us support FSAA on both ATI and nvidia cards (and will 
also be portable, unlike the ATI enum).

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

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

[ quesa-Bugs-902979 ] Add DebugText for debug output

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

Bugs item #902979, was opened at 2004-02-23 21:04
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=902979&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dair Grant (grantd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add DebugText for debug output

Initial Comment:
It would be good to have a generic DebugText() routine that could 
map to:

  - fprintf to stderr for Unix
  - OutputDebugString for Win32
  - DebugStr for Mac OS X
  - fprintf to "Quesa Debug" for Mac OS 9

It could take a '...' argument, so you could use it with printf style 
format lists. Would make it easier to implement bug 41 and bug 
49, and could be used for outputing performance statistics (e.g., if 
particularly inefficient form of TriMesh was submitted).

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

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

[ quesa-Bugs-902978 ] Unified viewer doesn't work on Windows

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

Bugs item #902978, was opened at 2004-02-23 21:03
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=902978&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dair Grant (grantd)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unified viewer doesn't work on Windows

Initial Comment:
The unified viewer doesn't work on Windows - the previous version 
did, so we should get back the existing functionality before the 
next release.

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

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