quesa-develop — Mailing list for Quesa development

Re: 10.2

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

Hi Dair,

We support 10.2.6 onwards so no problem for Microspot.

Just don't forget about my modifications (at a low priority).

Roger.



On Thursday, August 19, 2004, at 10:04  pm, Dair Grant wrote:

>
> Hi,
>
> I've been working on some ideas for a lower-level-than-the-TriMesh
> geometry type, which would let geometry data live in VRAM and fix a
> couple of long-standing problems with the TriMesh (with vertices shared
> between triangles that inherit a different value for some attribute 
> from
> each parent).
>
> One of the other things this would be useful for is to start support 
> for
> vertex shaders, which allow vertices to be processed by the GPU rather
> than the CPU.
>
> Vertex shaders would require 10.2 (on the Mac), so before I get too far
> into this can I check if anyone still needs Quesa support for prior to
> that OS?
>
> If so it shouldn't be a problem (and the geometry change would run on
> anything), but it'd be useful to know if that was the majority 
> situation
> or the minority.
>
>
> -dair
> ___________________________________________________
> mailto:dair+refnum.com       http://www.refnum.com/
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>

Re: 10.2

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

James W. Walker wrote:

>Would your idea work with the Apple OpenGL software renderer?  It's=20
>still OpenGL 1.1, but supports a bunch of extensions.

Vertex shaders will be processed on the CPU with any renderer from 10.2
upwards - so even an HW accelerated card that doesn't support HW vertex
shaders will be able to use them.

They're not present in any form on older systems though, so we will need
to make this optional (which is fine, was thinking it through last night
and I think that route is probably best anyway as there are a couple of
different languages for specifying vertex shaders - so we should keep
things as generic as possible at the Quesa level).

The main idea is threefold:

1. There's some kind of buffer object that can hold structured data, and
provide lock/unlock access to it.

This lets you put geometry data (vertices and indices) onto the card,
since the app has to let the card know when it wants to read/write the
data.


2. There's some kind of primitive geometry that takes a description of
the thing you're rendering (points, lines, triangles, tristrip, fans,
etc) and where to find the data for that object.

This lets us host the TriMesh on top of this, and means renderers only
need to support one geometry to be able to support anything (as point
and line support can then be optional).


3. There's some processing of the vertices before they reach the
rasterisation point.

Today this is done for us by OpenGL by pushing the vertices through the
GL lighting pipeline. Vertex shaders just give you a way to customise
this section, so that you write a mini-program that gets invoked on each
vertex to figure out what its final appearance should be.



The tie-in between points 2 and 3 is that the way things are exposed in
2 has to be in a way that lets you do everything you want to do from 3
if vertex shaders were there.

So we might find that to start with 2 exposes some stuff that has to be
set to NULL, with the plan being that a primitive geometry can have a
shader progam attached to it as well.

I.e., so that as well as saying "this is the type of thing I'm drawing,
and this is where to find the vertices" it also says "and this is how to
process the vertices (or do the default pipeline if NULL)".

Am just looking through the GL vs D3D interfaces to see what the common
requirements are, and who has the simpler API.


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

Re: 10.2

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

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

>Vertex shaders would require 10.2 (on the Mac), so before I get too far
>into this can I check if anyone still needs Quesa support for prior to
>that OS?

Would your idea work with the Apple OpenGL software renderer?  It's 
still OpenGL 1.1, but supports a bunch of extensions.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: 10.2

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

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

>Vertex shaders would require 10.2 (on the Mac), so before I get too far
>into this can I check if anyone still needs Quesa support for prior to
>that OS?

I'm not quite ready to drop OS 9.  (I don't really care about 10.1.)
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Re: 10.2

[Joseph J. S. <jo...@st...>]

At 10:04 PM +0100 8/19/04, Dair Grant wrote:

>Vertex shaders would require 10.2 (on the Mac), so before I get too far
>into this can I check if anyone still needs Quesa support for prior to
>that OS?

REALbasic still supports 10.1, so if it's not a lot of extra trouble, 
we'd like to keep 10.1 support for Quesa for a while.  Otherwise we'd 
have to either ship a custom build of Quesa, or tell our users that 
their 3D apps run only on 10.2 or later and 9.x or earlier, even 
though their other REALbasic apps also run on 10.1.

Thanks,
- Joe

-- 
,------------------------------------------------------------------.
|    Joseph J. Strout         Check out the Mac Web Directory:     |
|    jo...@st...           http://www.macwebdir.com/            |
`------------------------------------------------------------------'

10.2

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

Hi,

I've been working on some ideas for a lower-level-than-the-TriMesh
geometry type, which would let geometry data live in VRAM and fix a
couple of long-standing problems with the TriMesh (with vertices shared
between triangles that inherit a different value for some attribute from
each parent).

One of the other things this would be useful for is to start support for
vertex shaders, which allow vertices to be processed by the GPU rather
than the CPU.

Vertex shaders would require 10.2 (on the Mac), so before I get too far
into this can I check if anyone still needs Quesa support for prior to
that OS?

If so it shouldn't be a problem (and the geometry change would run on
anything), but it'd be useful to know if that was the majority situation
or the minority.


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

Re: More thoughts on transparent depth sorting

[Frank C <li...@si...>]

On 9-Aug-04, at 3:01 PM, James W. Walker wrote:

> Frank C <li...@si...> wrote:
>
>> Meshes with intersecting bounds would have to have their triangles
>> lumped into the same list, but the fact that intersecting triangles
>> aren't split means this scenario will rarely work no matter what
>> sorting method is used.
>
> This isn't a big objection, but intersecting bounding boxes do not 
> imply intersecting triangles.  For instance consider nested boxes.

True, but my point was that intersecting meshes would have to be lumped 
together and sorted per triangle regardless if they contained 
intersecting triangles (that way it will work for cases like nested 
boxes).

>> 1. A "no sort" flag can be used on objects that require absolutely
>> no self-sorting; e.g. billboards, or meshes that use additive
>> blending.
>
> Meshes that use additive blending?  Such a thing does not currently 
> exist in Quesa, right?

It does, but it's not explicit. A transparent texture that isn't 
pre-multiplied with its alpha channel results in an additive blend. 
This means any texture may blend only partially additively, so 
unfortunately we don't have a way to automatically detect full additive 
blends.

Frank.

Re: More thoughts on transparent depth sorting

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

Frank C <li...@si...> wrote:

>Meshes with intersecting bounds would have to have their triangles
>lumped into the same list, but the fact that intersecting triangles
>aren't split means this scenario will rarely work no matter what
>sorting method is used.

This isn't a big objection, but intersecting bounding boxes do not 
imply intersecting triangles.  For instance consider nested boxes.

>1. A "no sort" flag can be used on objects that require absolutely
>no self-sorting; e.g. billboards, or meshes that use additive
>blending.

Meshes that use additive blending?  Such a thing does not currently 
exist in Quesa, right?
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

More thoughts on transparent depth sorting

[Frank C <li...@si...>]

Since James has recently put a lot of work into new sorting algorithms 
I thought this may be a good time to throw a around a few more ideas on 
the topic.

I think the current method of lumping all transparent triangles into a 
single list may not be the best way to go about it. I'm no sort 
algorithm expert but I believe it would be faster sort the triangles in 
each mesh separately, then sort and draw each mesh as a whole rather 
than sort all triangles in all meshes simultaneously. Meshes with 
intersecting bounds would have to have their triangles lumped into the 
same list, but the fact that intersecting triangles aren't split means 
this scenario will rarely work no matter what sorting method is used. I 
suppose which method is faster depends on wether sorting a big list of 
triangles is faster than detecting intersections.

When sorting by mesh, there should also be some of way of flagging 
meshes to allow fast self-sorting paths:

1. A "no sort" flag can be used on objects that require absolutely no 
self-sorting; e.g. billboards, or meshes that use additive blending.

2. A "convex" flag can be used for meshes with convex hulls so they can 
be drawn quickly with the draw-backs-draw-fronts method (Quesa's 
primitives will qualify for this more often than not - all the box 
self-sorting problems instantly disappear).

3. I almost hesitate to mention this third sorting method since it's 
rather specific, but meshes with mostly-solid textures can sometimes be 
sorted acceptably in two passes. The first passes uses an alpha test 
that clips to solid (or near-solid) with z writes enabled and colour 
turned off. The second pass draws the colour with blending enabled and 
z writes off. The result may/will show depth errors at texture fringes, 
but this is often an acceptable tradeoff for complicated structures 
like branches/leaves/grasses without resorting to using 1 bit alphas. 
This technique has no doubt been described more elegantly elsewhere but 
I usually call it a "texture based depth sort".

Basically it comes down to this:

Step 1: Sort transparent meshes back-to-front, lumping intersecting 
meshes into a single group/mesh.

Step 2: Draw each mesh in the sorted list using one of the 3 methods 
listed above, or if all else fails do a per-triangle sort.

Just some ideas - feel free o shoot'em down.
Frank.

Re: depth sorting (bug 989156)

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

On Aug 8, 2004, at 2:39 AM, Dair Grant wrote:

> See also bug 895117: that's the case that originally raised this issue.

I can't find that bug.  I've set SourceForge to browse bugs with 
Assignee, Status, Category, and Group all set to Any, but the bug 
numbers jump from 895106 to 900672.

> Is the centroid method just taking the center in z of the two triangles
> and comparing?

What we used to do was not exactly the centroid method.  We took the 
average of the maximum and minimum z values, which is not equal to the 
average of the 3 z values of the vertices.  However I wouldn't be 
surprised if the results were pretty much the same.

> If so that's actually what we used to do, but you changed
> it last year... :-)

I was hoping nobody would notice that. :-)  Clearly I didn't do enough 
testing back then.  If you look at the case of a single box in my test 
app, then arguably the current Quesa method is better than the centroid 
method.  But once you get to two boxes, it's a different story.

> Firstly, nice test app. :-)

Thanks.

> I think the problem does come down to a tradeoff: even more so than you
> describe here, as strictly speaking interpenetrating triangles need to
> be split into sub-triangles if they're to be sorted correctly.

True.

> Most interactive scene graphs don't bother going that far, and I think
> whatever choice we make is going to have to have some trade off. The
> centroid case definitely does improve these boxes, but assuming it's 
> the
> same as 1.9 then we would presumably make some other case worse.

Yep, such as a single box.

> If it's not the same as 1.9, can you post a snippet showing what it 
> does
> for the overlapping extents case?

I'm not sure what you mean by overlapping extents.

--
<http://www.jwwalker.com/>

Re: depth sorting (bug 989156)

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

James W. Walker wrote:

>I've been doing some experimentation on ways of doing depth sorting of=20
>transparent triangles.  The choice of algorithms comes down to one of=20
>those classic tradeoffs: do you want the job done right or do you want=20
>it done right now?  But it seems clear that we can do better than what=20
>we have now.

See also bug 895117: that's the case that originally raised this issue.


>1. current Quesa comparison method, qsort
>2. centroid comparison, qsort
>3. barycentric comparison, selection sort after centroid qsort

Is the centroid method just taking the center in z of the two triangles
and comparing? If so that's actually what we used to do, but you changed
it last year... :-)

If look go back to revs 1.9/1.10/1.11 of IRTransparent.c we have:

  1.9     "Centroid" (assuming above is true)
  1.10    ifdef'd plane equation test
  1.11    final plane equation test

Unfortunately I can't find the mail that started that change in motion,
but I can remember some discussion about how the centroid method wasn't
providing the best results and hence we added the more complex test for
triangles.

There are some more notes in a URL attached to 895117: I tried that
approach, but it didn't help with the box test unfortunately.


>Comments?

=46irstly, nice test app. :-)

I think the problem does come down to a tradeoff: even more so than you
describe here, as strictly speaking interpenetrating triangles need to
be split into sub-triangles if they're to be sorted correctly.

Most interactive scene graphs don't bother going that far, and I think
whatever choice we make is going to have to have some trade off. The
centroid case definitely does improve these boxes, but assuming it's the
same as 1.9 then we would presumably make some other case worse.

If it's not the same as 1.9, can you post a snippet showing what it does
for the overlapping extents case?


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

Re: depth sorting (bug 989156)

[Frank C <li...@si...>]

On 7-Aug-04, at 10:20 PM, James W. Walker wrote:

> I've been doing some experimentation on ways of doing depth sorting of 
> transparent triangles.  The choice of algorithms comes down to one of 
> those classic tradeoffs: do you want the job done right or do you want 
> it done right now?  But it seems clear that we can do better than what 
> we have now.
>
> ...
>
> 1. current Quesa comparison method, qsort
> 2. centroid comparison, qsort
> 3. barycentric comparison, selection sort after centroid qsort
>
> Method 1 (which Quesa currently uses) displays constant ugly flashing.
> Method 2 has much less flashing, though it is not hard to see sorting 
> errors much of the time.  This is of similar speed to method 1.
> Method 3 has only occasional errors, but is quite a bit slower.

Very nice!

#2 seems like an excellent quality/speed tradeoff. I did some tests 
with a more stressful mesh (approx 1600 triangles) and the occasional 
errors were totally acceptable with #2 while #1 was a massacre and 
about 5FPS slower. #3 ran at 0.1FPS, so I don't think it would be a 
good choice as the default setting, though it may make sense as an 
option for those who prefer accuracy over speed. Perhaps you can add a 
"sorting quality hint" via the Get/SetProperty API and use both #2 and 
#3?

I think #2 should work out well enough in real-world applications. 
Self-sorting a cube turns out to be a fairly difficult thing to do 
per-triangle.

Frank.

depth sorting (bug 989156)

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

I've been doing some experimentation on ways of doing depth sorting of 
transparent triangles.  The choice of algorithms comes down to one of 
those classic tradeoffs: do you want the job done right or do you want 
it done right now?  But it seems clear that we can do better than what 
we have now.

Those with access to Mac OS X can see some of my experiments in this 
program: <ftp://ftp.jwwalker.com/TransTest.dmg>.  This program offers 
choices of 3 comparison methods (the current Quesa method, and what I 
call the centroid and barycentric methods) and 3 sorting methods 
(qsort, selection sort, and qsort with centroid comparison followed by 
selection sort by the specified comparison).  Obviously that produces 9 
possible combinations, but I would like to direct your attention to 3 
of them:

1. current Quesa comparison method, qsort
2. centroid comparison, qsort
3. barycentric comparison, selection sort after centroid qsort

Method 1 (which Quesa currently uses) displays constant ugly flashing.
Method 2 has much less flashing, though it is not hard to see sorting 
errors much of the time.  This is of similar speed to method 1.
Method 3 has only occasional errors, but is quite a bit slower.

In case you wonder why one would want to use qsort for centroid 
comparison but not barycentric comparison:  The qsort algorithm is 
intended for sorting totally ordered data, and the centroid comparison 
comes close to providing a linear order on triangles (it orders them by 
z coordinate of the centroid).  The barycentric method, on the other 
hand, defines only a partial order on triangles, so qsort does not work 
well on it.  The problem of finding a linear order consistent with a 
partial order is called topological sorting, and my selection sort 
algorithm is a kind of topological sort.   There are other topological 
sorting algorithms that are probably faster than mine, but use 
additional storage as a quadratic function of the number of triangles.

Comments?
--
<http://www.jwwalker.com/>

Re: Resizing contexts

[Frank C <li...@si...>]

On 7-Aug-04, at 12:03 AM, Frank C wrote:

> On 6-Aug-04, at 10:41 PM, James W. Walker wrote:
>
>> On Aug 6, 2004, at 4:17 PM, Frank C wrote:
>>
>>> It appears Quesa rebuilds the GL context whenever it's resized,  
>>> which can take a good _long_ while if you have a lot of textures  
>>> loaded (pretty much rules out using live-resize windows on OS X).  
>>> Would it be reasonable to have a GLDrawContext_UpdateSize function  
>>> to avoid rebuilding textures for a resize event? I'm fairly certain  
>>> all you have to do is update the viewport and clipping rect -  
>>> trashing the context isn't needed or desirable.
>>>
>>> Comments?
>>
>> On the Mac, you would also need to call aglUpdateContext, i think.
>
> That would be part of updating the clipping rect. On Mac OS, you would  
> have to grab the context port dimensions, update AGL_BUFFER_RECT,  
> update glViewport, and finally call aglUpdateContext. The first two  
> steps can be ignored for offscreen contexts.
>
>> I do not see any analogous wgl call for Windows.  I don't know if  
>> that means that the wgl layer does not need to be informed of a  
>> window resize, or if it means that you must recreate the context.
>
> Ya, it looks like GLDrawContext_UpdateWindowClip does nothing on  
> platforms other than Mac OS so perhaps updates are automatic, but I  
> can't offer any more insight. glViewport would certainly need to be  
> updated in all cases however.
>
> I hacked in support for the Mac at this point and it's a whole lot  
> nicer when using freely resizable windows, but I ran into a bit of  
> roadblock in IRRenderer_StartFrame. It seems the context flags get  
> trashed before getting there when a resize is pending (forcing a  
> rebuild), but I can't see where that happens. I traced one such case  
> to e3drawcontext_mac_update but it still occurs after modifying that  
> function. I'll look at it some more over the weekend...

Scratch that e3drawcontext_mac_update remark - it's Qut's fault. I've  
submitted a bug with more details:  
<http://sourceforge.net/tracker/index.php? 
func=detail&aid=1005268&group_id=45158&atid=442052>

I can offer up some code that seems to work on Mac OS X, but I suspect  
someone with more intimate knowledge of Quesa should tackle this, as  
I'm not sure how best to handle offscreen contexts or other platforms.  
One thing I noticed is that AGL_BUFFER_RECT is always enabled from the  
get-go, but really doesn't need to be for full-window contexts. I doubt  
there's any sort of performance penalty, but it would make resizing  
easier for contexts attached to window ports if AGL_BUFFER_RECT simply  
wasn't enabled.

Frank.

[ quesa-Bugs-1005268 ] Resizing contexts should not force a rebuild

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

Bugs item #1005268, was opened at 2004-08-07 17: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=1005268&group_id=45158

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Frank Condello (pox)
Assigned to: Nobody/Anonymous (nobody)
Summary: Resizing contexts should not force a rebuild

Initial Comment:
Currently, Quesa will forcefully rebuild a GL context when it is 
resized. This leads to a UI hang while Quesa reloads all active 
textures, and can adversely affect application with freely sizable 
windows/panes even with just a few textures loaded.

The problem however is two-fold...

Quesa must first handle resizes within the library, by providing a 
GLDrawContext_UpdateSize function in GLDrawContext.c. All 
renderers must catch resize flags 
(kQ3XDrawContextValidationWindowSize and 
kQ3XDrawContextValidationPane) in their StartFrame function and 
call GLDrawContext_UpdateSize instead of forcing a context 
rebuild.

Once the library can handle context resizing, some applications 
may require modification to take advantage of this functionality. 
The Qut framework for example, creates a new context when a 
window is resized, but it should really let Quesa handle that 
internally.

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

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

Re: Resizing contexts

[Frank C <li...@si...>]

On 6-Aug-04, at 10:41 PM, James W. Walker wrote:

> On Aug 6, 2004, at 4:17 PM, Frank C wrote:
>
>> It appears Quesa rebuilds the GL context whenever it's resized, which 
>> can take a good _long_ while if you have a lot of textures loaded 
>> (pretty much rules out using live-resize windows on OS X). Would it 
>> be reasonable to have a GLDrawContext_UpdateSize function to avoid 
>> rebuilding textures for a resize event? I'm fairly certain all you 
>> have to do is update the viewport and clipping rect - trashing the 
>> context isn't needed or desirable.
>>
>> Comments?
>
> On the Mac, you would also need to call aglUpdateContext, i think.

That would be part of updating the clipping rect. On Mac OS, you would 
have to grab the context port dimensions, update AGL_BUFFER_RECT, 
update glViewport, and finally call aglUpdateContext. The first two 
steps can be ignored for offscreen contexts.

> I do not see any analogous wgl call for Windows.  I don't know if that 
> means that the wgl layer does not need to be informed of a window 
> resize, or if it means that you must recreate the context.

Ya, it looks like GLDrawContext_UpdateWindowClip does nothing on 
platforms other than Mac OS so perhaps updates are automatic, but I 
can't offer any more insight. glViewport would certainly need to be 
updated in all cases however.

I hacked in support for the Mac at this point and it's a whole lot 
nicer when using freely resizable windows, but I ran into a bit of 
roadblock in IRRenderer_StartFrame. It seems the context flags get 
trashed before getting there when a resize is pending (forcing a 
rebuild), but I can't see where that happens. I traced one such case to 
e3drawcontext_mac_update but it still occurs after modifying that 
function. I'll look at it some more over the weekend...

Thanks,
Frank.

Re: Resizing contexts

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

On Aug 6, 2004, at 4:17 PM, Frank C wrote:

> It appears Quesa rebuilds the GL context whenever it's resized, which 
> can take a good _long_ while if you have a lot of textures loaded 
> (pretty much rules out using live-resize windows on OS X). Would it be 
> reasonable to have a GLDrawContext_UpdateSize function to avoid 
> rebuilding textures for a resize event? I'm fairly certain all you 
> have to do is update the viewport and clipping rect - trashing the 
> context isn't needed or desirable.
>
> Comments?

On the Mac, you would also need to call aglUpdateContext, i think.  I 
do not see any analogous wgl call for Windows.  I don't know if that 
means that the wgl layer does not need to be informed of a window 
resize, or if it means that you must recreate the context.
--
<http://www.jwwalker.com/>

Resizing contexts

[Frank C <li...@si...>]

It appears Quesa rebuilds the GL context whenever it's resized, which 
can take a good _long_ while if you have a lot of textures loaded 
(pretty much rules out using live-resize windows on OS X). Would it be 
reasonable to have a GLDrawContext_UpdateSize function to avoid 
rebuilding textures for a resize event? I'm fairly certain all you have 
to do is update the viewport and clipping rect - trashing the context 
isn't needed or desirable.

Comments?

Thanks,
Frank.

Re: BUG in function "ir_texture_convert_rave_filter" ?

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

Daniele Cavallini <dca...@in...> wrote:

>If I use "TQ3PixmapDrawContextData" instead "TQ3DrawContextData" and
>I set "Q3InteractiveRenderer_SetRAVETextureFilter" with
>"kQATextureFilter_Fast" the render of texture is not correct.  If I
>use "kQATextureFilter_Mid" or "kQATextureFilter_Best "  render is ok.
>I thought the problem was "oglFilter.magFilter = GL_NEAREST" in
>"ir_texture_convert_rave_filter" function . You can see an examples
>with "oglFilter.magFilter = GL_NEAREST" at link
>http://www.interstudio.net/quesa/nearest.JPG
>and an examples with "oglFilter.magFilter = GL_LINEAR" at link
>http://www.interstudio.net/quesa/Linear.JPG
>I used  windows  I don't know if with mac os there is the same
>problem.May be the problem in other part of code?

My product FrameForge 3D Studio uses offscreen rendering on both Mac 
and Windows, and we do not have that problem.  Though I think maybe 
we once saw it on Windows.  What version of Quesa are you using?  We 
use the current CVS version.

Do your textures have an alpha channel?  There is at least one open 
bug involving textures with alpha.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

Bug in e3fformat_3dmf_bin_read_toc

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

I think I have traced the problem with my bio-degradable 3DMF.

if e3fformat_3dmf_bin_read_toc if gets the logical end of file from
the file manager. It gets the size of the table of contents from the
size recorded in the file. It the recalculates the size of the table
of contents (presumably it is a different size in its internal
representation or some such). It then subtracts the NEWLY
CALCULATED size of the T.O.C. from the logical end of
file. This means the value of 'end of file' is actually well before
the TOC, before the end of the useful data. Subsequently
the routines which read the objects from the file give up
prematurely because they think they are reading over the
end of the file!

I find it amazing that nobody (including me) has noticed this
before.

I propose to save the size of TOC read from the file in a
separate local variable and subtract this from the end of
file rather than the recalculated value.

Unless someone objects by Monday, I'll check in a fix.

Roger.

Re: BUG in function "ir_texture_convert_rave_filter" ?

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

If I use "TQ3PixmapDrawContextData" instead "TQ3DrawContextData" and I set 
"Q3InteractiveRenderer_SetRAVETextureFilter" with "kQATextureFilter_Fast" 
the render of texture is not correct.  If I use "kQATextureFilter_Mid" or 
"kQATextureFilter_Best "  render is ok.
I thought the problem was "oglFilter.magFilter = GL_NEAREST" in 
"ir_texture_convert_rave_filter" function . You can see an examples with 
"oglFilter.magFilter = GL_NEAREST" at link 
http://www.interstudio.net/quesa/nearest.JPG
and an examples with "oglFilter.magFilter = GL_LINEAR" at link 
http://www.interstudio.net/quesa/Linear.JPG
I used  windows  I don't know if with mac os there is the same problem.May 
be the problem in other part of code?

At 19.46 05/08/04, you wrote:
>Daniele Cavallini <dca...@in...> wrote:
>
>>I think there is a bug in the function :
>>
>>static TQ3QualityFilter
>>ir_texture_convert_rave_filter(TQ3ViewObject theView)
>>
>>WRONG:
>>.....
>>
>>         switch (raveFilter) {
>>                 case kQATextureFilter_Fast:
>>                         oglFilter.magFilter = GL_NEAREST;
>>                         oglFilter.minFilter = GL_NEAREST;
>>                         break;
>>......
>>
>>CORRECT:
>>....
>>switch (raveFilter) {
>>                 case kQATextureFilter_Fast:
>>                         oglFilter.magFilter = GL_LINEAR;
>>                         oglFilter.minFilter = GL_NEAREST;
>>                         break;
>>.....
>>What do you think?
>
>
>What's your reasoning?
>
>In the description of GL_TEXTURE_MAG_FILTER in the OpenGL Reference 
>Manual, it says that GL_NEAREST is generally faster than GL_LINEAR. That 
>sounds like what we want for kQATextureFilter_Fast.
>--
>   James W. Walker, ScriptPerfection Enterprises, Inc.
>   <http://www.write-brain.com/>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by OSTG. Have you noticed the changes on
>Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
>one more big change to announce. We are now OSTG- Open Source Technology
>Group. Come see the changes on the new OSTG site. www.ostg.com
>_______________________________________________
>Quesa-develop mailing list
>Que...@li...
>https://lists.sourceforge.net/lists/listinfo/quesa-develop
>

Re: Can someone PLEASE fix this?

[Frank C <li...@si...>]

On 5-Aug-04, at 3:41 PM, Dair Grant wrote:

> Frank C wrote:
>
>> I've sent this patch to the list twice and haven't gotten a shred of
>> interest from anyone with CVS access...
>
> OK, checked in now.

Thanks!

> This does highlight something I've been wanting to get off the ground
> for a while now though - we really need a test harness for running
> automated tests.
>
> I don't have a test case handy for this to confirm the behaviour 
> against
> QD3D - it would be great if we had a simple app that could be run to
> a)demonstrate a fail case and b)catch any regressions in the future.

I hacked up a model viewer a while back that lets you muck with 
attributes, but it's not quite fit for public consumption. Even in it's 
current state it has allowed me to catch a whole lot of bugs though, 
but it's not a regression suite by a long shot. I could fix it up 
and/or add some automated tests and/or release the source, but it's 
written in REALbasic and I'm not sure you guys will embrace and extend 
such a beast.

Frank.

Re: BUG in function "ir_texture_convert_rave_filter" ?

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

James W. Walker wrote:

>In the description of GL_TEXTURE_MAG_FILTER in the OpenGL Reference=20
>Manual, it says that GL_NEAREST is generally faster than GL_LINEAR.=20
>That sounds like what we want for kQATextureFilter_Fast.

The whole kQATexture thing is a bit limited, as really you should be
able to set min/mag/mip filters independently.

We carried it forward just because there wasn't any other way to control
filtering in the QD3D API - what we should probably do is come up with a
more generic solution that's kQ3-based rather than kQA-based that will
let us express everything you can do in GL/D3D.


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

Re: Bug in E3Triangle_InterpolateHit

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

Roger Holmes wrote:

>Perhaps you missed one of my e-mails.

Sorry, think I must have done - didn't see anything after that.


>I think it is the general fix we were testing, it certainly was much
>better than simply multiplying by local to world. I have checked it in
>as it is definitely much better than before. I used some code I wrote
>for my renderer for getting the right normal for the lighting
>calculations.

OK, that should give us the right results - it will mean we're doing
more work up front than we need to if they don't actually want the
normal, so be interesting to see if that does have any noticeable impact
on picking complex scenes.


>I presume the interactive renderer does something similar otherwise
>the lighting would look a little weird as a surface in world
>coordinates gives different lighting to a parallel surface in local
>coordinates with a rotation and non uniform scale transform applied.

Yes, the normal used for lighting will need to go through a similar
transform - GL does this for us, the IR would have had to do it itself
as it did all its own lighting.


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

Re: Can someone PLEASE fix this?

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

=46rank C wrote:

>I've sent this patch to the list twice and haven't gotten a shred of=20
>interest from anyone with CVS access...

OK, checked in now.

This does highlight something I've been wanting to get off the ground
for a while now though - we really need a test harness for running
automated tests.

I don't have a test case handy for this to confirm the behaviour against
QD3D - it would be great if we had a simple app that could be run to
a)demonstrate a fail case and b)catch any regressions in the future.


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