quesa-develop — Mailing list for Quesa development

Re: [Quesa-develop] Re: Quesa - Optimization ideas.

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

Roger Holmes wrote:

>Would it not be better to call GLFinish in Sync?

Yes, that's how it works - I'd assumed _EndFrame in the renderer was
called at the end of each frame, but it looks like it's only actually
called by Q3View_Sync.

That method is a bit mis-named, as it's optional: it's only meant to be
implemented by renderers which might have this async behaviour.


I.e., a renderer that's completely synchronous doesn't need to provide
_EndFrame - and Q3View_Sync will do nothing.

A renderer which can run asynchronously needs to provide it, so that if
an app does call Q3View_Sync we can block until the renderer is done.

So if an app isn't calling Q3View_Sync, we shouldn't explicitly make GL
block.


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

Re: [Quesa-develop] Re: Quesa - Optimization ideas.

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

On Tuesday, February 10, 2004, at 09:50  pm, Dair Grant wrote:

> We currently do it to preserve QD3D's behaviour, where everything would
> have finished rendering at the end of the frame.


Actually that is not what QD3D did. From very early on we had an Apple
accelerator card, and if we did not call the Sync function before we 
called
the menu manager, we could get our menus overwritten by the 3D image
and when the menu went away, the 3D window underneath showed the
image as it was before rendering completed. We had to call it at certain
other times too which are still in my code but I can't remember the 
details.

Would it not be better to call GLFinish in Sync?

Roger.

[Quesa-develop] Re: Quesa - Optimization ideas.

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

On Tuesday, February 10, 2004, at 09:15  pm, Chris Dillman wrote:

> Now what would you consider a large table?
> I mean in size etc?

Ah, it depends on a number of factors:

The more accesses per unit time the bigger it can be.
The more complicated the operation it replaces the bigger it can be.
The slower the processor the bigger it can be.
The faster the RAM the bigger it can be.
The bigger the RAM cache the bigger it can be.
The more concentrated the usage, in terms of other data access not 
causing
	parts of it to be removed from the cache, the bigger it can be.
The longer the period of use, from the point of view of the overhead of
	loading into the cache, the bigger it can be.

I expect there are more factors to consider too.

I still use look ups in raster printer drivers for when I have to 
convert the
red, green and blue components of a colour to floating point cyan, 
magenta
and yellow and gamma adjust the floating value. This whole operation can
be done with one table of 256 floats and is done 3 times for every 
single pixel
in the image. As our drivers are for large format printers, typically 
600dpi on a
typically 40 by 54 inch image, then using the lookup table 2,000,000,000
times in twenty or thirty seconds is worthwhile, but I will be keeping 
an eye
on the efficiency as faster processors come along, but at the moment 
the way
the PowerPC converts an integer to a float requires it to be written to 
RAM by
the integer processor unit and read back by the floating point 
processing unit,
and as I think the cache is normally configured as write-through, I 
doubt if
using a look up table of 256 floats  will become counter productive for 
some time.

Roger Holmes.

Re: [Quesa-develop] Some Quesa bugs and QD3D inconsistencies

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

=46rank C wrote:

>That sounds reasonable. I don't think it will come up often in=20
>real-world apps (or at least the dev/artist should try to minimize it).=20

Yes, as really any high-level geometries should be generating optimal
TriMeshes anyway (as we control their cached form ourselves).

That has had some improvements recently (e.g., we now always
pre-normalise normals, so renderers can assume that any TriMeshes they
see have normalised normals), but if we have an identifiable fast-path
we can do something like post a notice if we go off it.


>I'm _all_ for that. I think the lack of these are keeping many people=20
>from even trying Quesa in the first place. Personally I'd be happy with=20
>modulating vertex colors/alphas with textures, but multitexturing=20
>(and/or multi-pass texturing) and register combiners would be=20
>fantastic.

Yeah, I think the best approach would be to go for the full thing: the
classic behaviour and the light-usage of it can both be implemented in
terms of that.

There are some subtle differences between GL and D3D in this area, so
we'd need to assume we could be using either GL or D3D at some point and
go for the intersection in terms of specifying what Quesa allowed.

E.g., in D3D you can use a combine on a unit without a texture, provided
the combine parameters don't reference the texture. In GL you always
need to have a texture bound, or the results of the combine are
undefined.

=46or that case it's probably easier to restrict ourselves to the GL
functionality as the requirement for renderers which can support a
combine model. The more general case would only be available if a
renderer says it can do it, if it's based on D3D say.


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

Re: [Quesa-develop] Some Quesa bugs and QD3D inconsistencies

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

On 10-Feb-04, at 4:50 PM, Dair Grant wrote:

>> 2). Face and geometry attribute sets on primitives don't always get
>> along. ...

> After going round this several times, I think the proper solution is to
> divide the TriMesh rendering code into two paths:
>
> 1. Pass the TriMesh data directly to OpenGL (or whoever) with no 
> further
> processing.
>
> 2. Break anything more complex down into individual triangles, and 
> shove
> them into a triangle buffer.

That sounds reasonable. I don't think it will come up often in 
real-world apps (or at least the dev/artist should try to minimize it). 
I only noticed the problem after stress-testing some classes that wrap 
Quesa geometries. I thought I was doing something wrong till I tried it 
with QD3D...

>> 3). Diffuse/Transparency colours ... no effect on textured geometry.
>
> ...what we should do is decide what our updated API is going to
> look like and then implement the "classic" behaviour in terms of that.
>
> ...texture combine and multi-texturing

I'm _all_ for that. I think the lack of these are keeping many people 
from even trying Quesa in the first place. Personally I'd be happy with 
modulating vertex colors/alphas with textures, but multitexturing 
(and/or multi-pass texturing) and register combiners would be 
fantastic.

>> I can plop these into the bug base...

> Use the SF tracker...

Will do.

Frank.

Re: [Quesa-develop] Some Quesa bugs and QD3D inconsistencies

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

Dair Grant wrote:

>Use the SF tracker: the old Bugzilla will still be around for a while,
>but I'll get the contents moved over this week.

=2E..but not tonight I guess, as SF is apparently in "read-only mode".


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

Re: [Quesa-develop] Re: Quesa - Optimization ideas.

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

=46rank C wrote:

>According to the docs, the Q3Math_SquareRoot and Q3Math_InvSquareRoot=20
>functions use approximations - but looking at the source, they return=20
>sqrt(x) and 1.0/sqrt(x). I guess this was a "todo" that never got=20
>done...

The plan was they'd use __frsqrte/the G5 sqrt if available, and fall
back to sqrt if not.

This would have to be done through a function pointer approach, as
obviously those intrinsics aren't available on non-PowerPC platforms (or
even on all PowerPCs for the G5-specific stuff).

I think we have a bug for it on Bugzilla, if not I'll add one to the SF
tracker when moving them over.


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

[Quesa-develop] Re: Quesa - Optimization ideas.

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

Chris Dillman wrote:

>1. Eliminate any calls to glFinish();
>Apple advise againts using this at all for any high speed GL
>application. So is there a reason it is in Quesa?

We currently do it to preserve QD3D's behaviour, where everything would
have finished rendering at the end of the frame.

That behaviour did predate widespread acceleration though, so I suspect
we can probably lose that without any real side effects.

There's one in the _EndFrame method of the IR and WF renderers: if you
can try a build with them commented out, and it's fine, let me know and
I'll drop them and add a note to the docs that our behaviour differs
from QD3D.


>2. Move to vertex array range in "shared" state if possible.
>WC3 uses this to very good effect.
=2E..
>3. How about a state flag of some sort so that Quesa knows which=20
>objects have basically become static and have not changed from frame=20
>to frame so that it does not need to keep building them as GL calls=20
>everyframe?

Yes, these have always been long term plans - in fact this ties in to
the idea of having TriMesh processing be as simple as possible (for the
fast case), as you can just divide your code into:

  if (fast)
      ; // send the pointers over as-is
  else
      ; // do the complicated break down

What really needs to happen to use the vertex array range extension (on
the Mac) is for the renderer to be able to say it wants to manage the
state for the object.

I.e., we have built-in synchronisation through the API (the app has to
call _SetData/_UnlockData-after-mutable-lock if they want to touch the
geometry), so really all that needs to happen is some more communication
between Quesa and the renderer.

This would allow the renderer to say that it must be told whenever
access is needed to the data, so it can lock the data when app/Quesa is
going to touch it and make sure GL is synchronised afterwards.


>4. Does Quesa make a lot of sqrt calls?

Not really - the main usage will be for normalising vectors, but that
shouldn't be happening too much for the "normal" cases now (i.e., the
cached form of all geometries now pre-normalises the normals, and
renderers can assume they're all normalised when they get the data).


>Would a look up table be faster in some cases or a less accurate sqrt
>call? Or is the more accurate called really needed in Quesa?

A look-up table wouldn't really be faster (see other mail), and we
probably do need the precision.

We might want some kind of config flag to say if you're happy to accept
less precise results, but since we should really support both
interactive and non-interactive renderers we can't really say what an
app would want ahead of time.

If your frame is over in 30ms then little glitches don't really matter,
but for something like a ray-tracer it's better to be more accurate
rather than less.


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

Re: [Quesa-develop] Some Quesa bugs and QD3D inconsistencies

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

(sorry, sent this to the cvs list by mistake)

=46rank C wrote:

>1). Edge/point fill styles are textured if an object has a texture=20
>shader further down the pipe.

Hmm, yes, that sounds like a bug - the edge/point styles should never be
drawn textured.


>2). Face and geometry attribute sets on primitives don't always get=20
>along. e.g. Add a texture shader to a Box's attribute set, then add a=20
>face attribute set with another texture shader to a single face. This=20
>will result in the other five faces drawing without a texture. QD3D=20
>handles this correctly, drawing the first texture on the other five=20
>faces.

This has been a long-standing problem, whereby we don't correctly handle
attributes that are shared across faces.

After going round this several times, I think the proper solution is to
divide the TriMesh rendering code into two paths:

1. Pass the TriMesh data directly to OpenGL (or whoever) with no further
processing.

2. Break anything more complex down into individual triangles, and shove
them into a triangle buffer.


We've been back and forth between the two approaches over time, but this
is really the only way to handle it - if you have to accept arbitrarily
complicated objects (a TriMesh with a unique texture object on each
triangle), we should just take the hit of breaking them up to simplify
the actual submission.

In practical terms this is probably fine: the best performance is always
going to come when we don't have the CPU touch the data and can just
give it straight to the GPU.

Breaking things into individual triangles will mean those submits are
slower than the ideal case, but if they're that general then they're
always going to be slower anyway.


We have most of this in place already, since we have a triangle buffer
to batch up individual triangles into as much of a TriMesh as we can.

All we really need to do is to make the TriMesh renderer handle the
simple case itself, and break anything else up and feed it to the
triangle buffer.


>3). Diffuse/Transparency colours (either global, or on a face or=20
>vertex) have no effect on textured geometry. ir_texture_set_state sets=20
>TexEnv to modulate when lighting is enabled, so it appears the intended=20
>behaviour is too modulate geometry color as well. QD3D has this same=20
>problem, but modulates geometry colour when a null shader is being=20
>used, something Quesa explicitly prevents - So - What's intended here=20
>and what's broken? Personally I'd like to see geometry colour modulate=20
>with textures regardless of the current illumination, or at least the=20
>same behaviour as QD3D.

We should be as per QD3D, and were at one point, however I think this
was broken a while ago.

We really need to think about moving past what QD3D offered here (have
been meaning to reply to Frank's mail on this to the old list for a
while).

Nowadays there is a lot more control over how colours and textures
interact to produce the final fragment colour. QD3D predated all of
that, so what we should do is decide what our updated API is going to
look like and then implement the "classic" behaviour in terms of that.

By "lot more control" I mean texture combine and multi-texturing: those
are two key concepts in any modern 3D API, but QD3D predated those
appearing on consumer HW.


>- Transparent objects are jumbled when some or all vertices are outside=20
>the frustum (can lead to infinite point errors). I mentioned this on=20
>the old list before the move to Sourceforge - it seems to be tied to=20
>the new view transforms.

Yes, that's when this broke.

I'm going to go through the old Bugzilla and log bugs in the SF bug
tracker for them - can you do the same for these issues?


>- Major sorting errors. I realize some geometry simply can't be sorted=20
>properly, but it's consistently bad frame-to-frame.

I think this is a side effect of the above: we're now doing all the
sorting in frustum coordinates but that's either invalid or we're not
doing it correctly.


>I can plop these into the bug base, but I'm not sure which: Sourceforge=20
>or the old Bugzilla? I'm also hoping to have some sort of regression=20
>suite built later this week to help track these down.

Use the SF tracker: the old Bugzilla will still be around for a while,
but I'll get the contents moved over this week.


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

[Quesa-develop] Re: Quesa - Optimization ideas.

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

Roger Holmes wrote:

>With the current architecture of the Mac at least, using a look up
>table is actually slower as the processor has to load four words from
>main RAM into the processor cache, and each of the four accesses take
>so long compared with the speed of the processor that is actually
>quicker to work out the value.

Definitely - the biggest performance bottleneck nowadays is just memory
bandwidth. Even on something like the G5, you can never have enough. :-)


>Somehow turning off the cache before accessing RAM might help but that
>is something which sounds dangerous, maybe even more so in dual
>processor Macs.

I don't think you can disable the automatic bus snooping that MP
machines (certainly PowerPCs) do to ensure cache coherency between
processors (at least not from user mode code).
=20

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

[Quesa-develop] Bugdom help?

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

If anyone is interested, I'd be happy to supply the code to Bugdom (under
NDA) to test Quesa with. I'd also supply my "buggered" version of Quesa
that has to be used with Bugdom, since the CVS version has never worked.

Might help further solidify Quesa's QD3D compatibility.

If anyone is interested, let me know.

Later!

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Lane Roathe, President                          Ideas From the Deep
<mailto:la...@if...>                          <http://www.ifd.com>
___________________________________________________________________
Forget about world peace, visualize using your turn signals!

[Quesa-develop] Re: Quesa - Optimization ideas.

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

on Tue, Feb 10, 2004 Chris Dillman may have said:

The Quesa list is moving to the Source Forge list, although the dc one is
still active for now. Just fyi.

<http://www.sf.net/projects/quesa>

>Just some ideas for optimizing Quesa.
>Feel free to tell me if these won't work etc or if they are being worked on.

Seems like good ideas if they are not already happening. I'm building a
new version of nanosaur using the latest quesa CVS archive on SF
currently. Not sure how old the quesa version is in the download on the
IFD site.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Lane Roathe, President                          Ideas From the Deep
<mailto:la...@if...>                          <http://www.ifd.com>
___________________________________________________________________
Life is cheap, but the accessories will break you.

[Quesa-develop] Re: Quesa - Optimization ideas.

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

>On 10-Feb-04, at 2:11 PM, Chris Dillman wrote:
>
>>  4. Does Quesa make a lot of sqrt calls?
>>  Would a look up table be faster in some cases or a less accurate sqrt call?
>>  Or is the more accurate called really needed in Quesa?

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

>According to the docs, the Q3Math_SquareRoot and
>Q3Math_InvSquareRoot functions use approximations - but looking at
>the source, they return sqrt(x) and 1.0/sqrt(x). I guess this was a
>"todo" that never got done...

I don't think that either Q3Math_SquareRoot or Q3Math_InvSquareRoot 
(or the E3* versions) are called frequently by Quesa during 
rendering.  There are also a few "naked" calls to sqrt in Quesa, but 
again it looks like they don't happen during rendering.  If sqrt is 
showing up in Shark, I suspect it's being called by OpenGL.
-- 
   James W. Walker, ScriptPerfection Enterprises, Inc.
   <http://www.write-brain.com/>

[Quesa-develop] Re: Quesa - Optimization ideas.

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

On 10-Feb-04, at 2:11 PM, Chris Dillman wrote:

> 4. Does Quesa make a lot of sqrt calls?
> Would a look up table be faster in some cases or a less accurate sqrt 
> call?
> Or is the more accurate called really needed in Quesa?

According to the docs, the Q3Math_SquareRoot and Q3Math_InvSquareRoot 
functions use approximations - but looking at the source, they return 
sqrt(x) and 1.0/sqrt(x). I guess this was a "todo" that never got 
done...

Frank.

[Quesa-develop] Some Quesa bugs and QD3D inconsistencies

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

I've been hammering Quesa recently and noticed a few problems, and some 
behaviour that may or may not be intentional. I plan at looking at 
these closer later this week but figured I'd post my findings in the 
meantime. NOTE: Everything below refers to Quesa's interactive renderer 
on the CVS.

1). Edge/point fill styles are textured if an object has a texture 
shader further down the pipe.
This seems to be unintended behaviour, since 
IRRenderer_Update_Style_Fill deliberately turns off texturing for 
edge/point styles, and QD3D also draws these styles with color info 
only.

2). Face and geometry attribute sets on primitives don't always get 
along. e.g. Add a texture shader to a Box's attribute set, then add a 
face attribute set with another texture shader to a single face. This 
will result in the other five faces drawing without a texture. QD3D 
handles this correctly, drawing the first texture on the other five 
faces.

3). Diffuse/Transparency colours (either global, or on a face or 
vertex) have no effect on textured geometry. ir_texture_set_state sets 
TexEnv to modulate when lighting is enabled, so it appears the intended 
behaviour is too modulate geometry color as well. QD3D has this same 
problem, but modulates geometry colour when a null shader is being 
used, something Quesa explicitly prevents - So - What's intended here 
and what's broken? Personally I'd like to see geometry colour modulate 
with textures regardless of the current illumination, or at least the 
same behaviour as QD3D.

4). Transparency rendering is just plain broken. I don't even know 
where to start...

- Transparent objects are jumbled when some or all vertices are outside 
the frustum (can lead to infinite point errors). I mentioned this on 
the old list before the move to Sourceforge - it seems to be tied to 
the new view transforms.

- Transparency color vertex attributes on trimeshes are fudged (almost 
looks like every other one is skipped). Works on face attributes 
though...

- An interpolation style of none disables lighting on transparent 
geometry.

- Transparent objects with a null shader are lit Phong.

- The lighting state doesn't seem to reset properly. e.g. a transparent 
object lit Phong will be lit Lambert if another object in the scene is 
using Lambert lighting (this may be related to the point above).

- Major sorting errors. I realize some geometry simply can't be sorted 
properly, but it's consistently bad frame-to-frame.

--

I can plop these into the bug base, but I'm not sure which: Sourceforge 
or the old Bugzilla? I'm also hoping to have some sort of regression 
suite built later this week to help track these down.

Thanks,
Frank.

Re: [Quesa-develop] Re: Quesa rendering speed

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

Tom Sanham wrote:

>Thanks, that's a really useful bit of information.

The texture will be resized to the next largest - so for 250x250 you
would have ended up with 256x256, which isn't much of a difference. For
260x260 you would have ended up with 512x512 internally, which can
quickly chew up vram.

There are some extensions to allow support of non-power-of-2 textures,
but unfortunately they come with fairly severe restrictions.

Adding support for them would be a possibility, but they're really
intended for "straight on" texture usage (e.g., drawing textured quads
to the screen as per Quartz Extreme) rather than general purpose
texturing.


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

Re: [Quesa-develop] Re: Quesa rendering speed

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

Thanks, that's a really useful bit of information.

Tom

----- Original Message ----- 
From: "James W. Walker" <os...@jw...>
To: <Que...@li...>
Sent: Monday, February 02, 2004 5:03 PM
Subject: Re: [Quesa-develop] Re: Quesa rendering speed


> 
> On Feb 2, 2004, at 4:57 AM, Tom Sanham wrote:
> 
> > a) texture w:250 h:250, render time: 94 - 109 ms
> > b) texture w:260 h:260, render time: 297 - 328 ms
> > c) texture w:500 h:500, render time: 297 - 328 ms
> 
> You should use dimensions that are powers of 2.  Otherwise Quesa must 
> resize them.
> --
> <http://www.jwwalker.com/>
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop

Re: [Quesa-develop] Re: Quesa rendering speed

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

On Feb 2, 2004, at 4:57 AM, Tom Sanham wrote:

> a) texture w:250 h:250, render time: 94 - 109 ms
> b) texture w:260 h:260, render time: 297 - 328 ms
> c) texture w:500 h:500, render time: 297 - 328 ms

You should use dimensions that are powers of 2.  Otherwise Quesa must 
resize them.
--
<http://www.jwwalker.com/>

[Quesa-develop] Re: Quesa rendering speed

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

Hi,

... just found the problem - I had a bit of code in there
from ages ago that was redundantly updating the drawcontext
with each frame! Much faster now :)

Tom

[Quesa-develop] Re: Quesa rendering speed

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

To clarify the problem, here are the results of some timed tests:

I tried the rendering the same simple model with many different
sizes of texture:

Here are the results:
a) texture w:250 h:250, render time: 94 - 109 ms
b) texture w:260 h:260, render time: 297 - 328 ms
c) texture w:500 h:500, render time: 297 - 328 ms

-Computer used: Celeron 2.2GHz, WinXP, 192MB RAM
-Quesa 1.6d18 (release version), 32bpp PixmapDrawContext, w:163, h:193
-Model was: 6 4-sided TQ3Polygons, immediate mode
-In each test, one 32bpp texture was used to texture all the faces.
-Model was rendered more than once in each test to avoid
any 1st-render overhead. The program was restarted in each case.

I find these results interesting, because the texture in
test b is just 8% larger than in a, yet takes
3x as long to render. Something to do with
a cache limit, perhaps?

Any ideas/more info on this are gratefully received.

Tom



> Hi,
> 
> I am experiencing the following issue with a Quesa based
> app I am writing:
> 
> Win32 and Mac OS X (I havent tested on other platforms):
> Rendering any textured model to an offscreen DrawContext seems
> to take a very long time. I get roughly 3 fps on a 2.2GHz P4 for the
> simplest of textured models in a 160x200, 32bpp PixmapDrawContext.
> 
> Non textured models render much faster, and on-screen rendering
> of any model performs great.
> 
> Is this expected behaviour for Quesa, or am I doing something wrong?
> 
> Thanks,
> 
> Tom

[Quesa-develop] Quesa rendering speed

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

Hi,

I am experiencing the following issue with a Quesa based
app I am writing:

Win32 and Mac OS X (I havent tested on other platforms):
Rendering any textured model to an offscreen DrawContext seems
to take a very long time. I get roughly 3 fps on a 2.2GHz P4 for the
simplest of textured models in a 160x200, 32bpp PixmapDrawContext.

Non textured models render much faster, and on-screen rendering
of any model performs great.

Is this expected behaviour for Quesa, or am I doing something wrong?

Thanks,

Tom

Re: [Quesa-develop] Re: Quesa - SourceForge

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

Lane Roathe wrote:

>Will do; in the meantime, the problem with compiling I am having is in
>E3Viewer.c; e3view_new and E3Viewer_SetBounds;
>
>The following code was added to each, but is Mac OS specific.

Thanks - should be fixed now.

BTW it looks like anonymous CVS is up as well, although I believe the
pserver CVS access may not be completely live (i.e., the public CVS is
synchronised periodically, rather than being a live view onto the real
repository).


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

Re: [Quesa-develop] Re: Quesa - SourceForge

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

on Sat, Jan 31, 2004 Dair Grant may have said:

>Probably best to just try periodically until it comes back up. I'll see
>if I can fix up the Mac specific stuff.

Will do; in the meantime, the problem with compiling I am having is in
E3Viewer.c; e3view_new and E3Viewer_SetBounds;

The following code was added to each, but is Mac OS specific.

	Rect					portBounds;

	// Convert from port coordinates to window coordinates
	GetPortBounds(instanceData->mWindow, &portBounds);
	instanceData->mArea.min.x -= portBounds.left;
	instanceData->mArea.min.y -= portBounds.top;
	instanceData->mArea.max.x -= portBounds.left;
	instanceData->mArea.max.y -= portBounds.top;


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Lane Roathe, President                          Ideas From the Deep
<mailto:la...@if...>                          <http://www.ifd.com>
___________________________________________________________________
If we aren't supposed to eat animals, why are they made with meat?

Re: [Quesa-develop] Re: Quesa - SourceForge

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

Lane Roathe wrote:

>Anonymous CVS does not seem to be working; get a disconnect as if the
>password was wrong. Is the design community CVS archive up to date? (I
>grabbed that, but the Windows build doesn't, some Mac OS stuff snuck
>into the general code base.)

Yes, the DC CVS should be up to date - there haven't been any check-ins
into that since it was cloned to SF, however there have been some
changes made to the SF CVS.

Anonymous CVS access was working a couple of days ago, but it looks like
it's broken at the moment. There's nothing on the SF status page, but
there are a couple of projects reporting problems in the support queue,
so I've logged a support request as well:

<http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D888066&
group_id=3D1&atid=3D200001>=20

Probably best to just try periodically until it comes back up. I'll see
if I can fix up the Mac specific stuff.


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

[Quesa-develop] Re: Quesa - Models & Files

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

Seth Willits wrote:

>> The only thing I can think of is that when multiple models are in one =
=20
>> big file, they can share parts.  E.g., the same texture might be used =
=20
>> on two different models, and this not only saves disk space, it saves =
=20
>> texture RAM.  You can't (easily) do that with separate files.

We don't currently support it, but the last rev of QD3D did introduce
the concept of an "external reference". This would let you build a 3DMF
that refers to other 3DMFs, so you could keep a shared texture in one
file and then reference it from other models.


>Ahh. That makes sense. But there wouldn't be anything wrong with using =20
>separate files at least during development and fiddling would there?

No, to be honest either approach is fine - a lot of games tend to keep
each asset (model, texture, sound, whatever) in a separate file during
development and then ship them as a .zip (or custom format) on release.


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