gdalgorithms-list

Re: [Algorithms] FPS Questions

[Stephen J B. <sj...@li...>]

On Sun, 30 Jul 2000, Pai-Hung Chen wrote:

> (1) Is there a universally agreed way to calculate
> Frame-Per-Second information?
 
Well, if you have a good timer, you could try to measure
the duration of a single frame - and then do a moving
average of a few dozen frames in order to filter the
results a bit - but the problem is that graphics cards
are typically quite heavily pipelined - so you can't
just measure the time from (say) swap-buffer to swap-buffer.

What I usually do is to use the 'time()' function (which returns
time in seconds) and count the number of frames between
the returned value changing and it changing again.  The result
is an integer number of frames that's only accurate to +/- 1Hz,
but that's good enough for most purposes.

Call this every frame for example:

  static time_t old_t = 0 ;
  static int  nframes = 0 ;
  static int  hz_rate = 0 ;

  time_t t = time ( NULL ) ;
 
  if ( t != old_t )
  {
    hz_rate = nframes / ( t - old_t ) ;
    nframes = 1 ;
    old_t = t ;
  }
  else
    nframes++ ;

  display ( hz_rate ) ;

Of course you should disable the vertical retrace sync before
you do any measurement - or else the rate will always be
an integer sub-multiple of the CRT refresh rate! (eg for a
60Hz CRT, you'd only see 60,30,20,15 etc.)

> (2) What is the acceptable FPS for today's 3D games?
 
IMHO (and opinions vary), you should achieve the exact
frame rate of the monitor you are driving - which could
be anywhere from 60 to 76Hz for most users.  You should
enforce that exact rate by syncing the buffer swap to
the CRT vertical retrace using whatever means your
driver offers.

My reasoning is:

  Faster than that is silly because at best your users
  won't see many of the frames that you draw and at
  worst you'll get a tear in the middle of your image
  somewhere because you aren't synced to the vertical
  retrace.

  Slower will also produce that annoying tear - unless
  you are locked to the retrace in which case your
  frame rate will automatically drop to half the video
  rate.  At 30 to 38Hz (half the frame rate), you'll
  get REALLY annoying double-imaging whenever something
  moves fast on the screen.  The reasons for the double-
  imaging are interesting - but not relevent to the
  discussion.

What is actually "acceptable" to gamers will depend on
the individual.  If I was using an older 133MHz PC with
a Voodoo-1 card, I'd count myself lucky to get a barely
playable 10Hz with a modern game.  If I'd just spent a
packet on an 1.3GHz overclocked *beast* with a GeForce-2,
I'd be rather upset if I didn't get 60Hz on my 60Hz CRT
or 72Hz on my 72Hz CRT.

I work in flight simulation where people are VERY
picky about the quality of their imagery - and anything
other than the exact frame rate of the CRT would result
in my customer justifiably refusing to certify the simulator.

Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

Re: [Algorithms] Maximum Distance Point To AABB

[Joe A. <jo...@ti...>]

> I wouldn't worry about trying to bin the smaller mipmap levels - they are so
> much less memory than the larger ones that it's pointless trying to bin them
> - (a) you save very little memory, (b) even close-to things can use smaller
> mipmaps (if they are edge-on) and (c) most hardware doesn't support having
> missing small mipmaps - you'll only confuse it horribly.
Good point, but I have a another problem I need the maximum point for, I
want to have different detailTextures, which are not to be drawn when they
are very far away.

But having spent some background thinking on the problem now, is it true
that the point(on the AABB) with maximum distance to the other point, is
always on one of the 8 vertices? Which means I only have to find out which
of the 8 vertices is most far away from the other point.

bye joe

Re: [Algorithms] Scaling Models

[Stephen J B. <sj...@li...>]

On Sun, 30 Jul 2000 Chr...@pl... wrote:

> Ron Levine wrote:
> >A frightening demonstration of the folly of relying on spell checkers,
> >rather than careful proof reading, in the wee small hours.
> 
> Sorry to be an off-topic smartass, but I cannot resist: that should be
> *spelling* checker. A spell checker is something only a witch would use.
 
Seems fair...

  "He who lives by the pedantry shall die by the pedantry."

Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

Re: [Algorithms] 3d Lines Intersection

[Stephen J B. <sj...@li...>]

On Sun, 30 Jul 2000, Ron Levine wrote:

> Jim Offerman  wrote:
> 
> >> Is there a good algo for finding a point of intersection between two *3D
> >lines*?
> >> The lines is specified by their point (x,y,z) and their direction
> >(dx,dy,dz)
> >
> >When I wrote my first renderer, I used a simple 3D intersection algorithm in
> >my (very alternative) projection system:
> >
> >- calculate (x, y) intersection (result <x1, y>)
> >- calculate (x, z) intersection (result <x2, z>)
> >- if (x1 == x2) the lines intersect at <x1, y, z>
> >
> >Of the top of my head I can't say whether this algorithm is 100% correct
> 
> It is my sad duty to have to inform you (and I dearly hope that the
> news causes no undue emotional stress), that this putative algorithm
> is wrong.  
> 
> Here is the clearest, simplest to understand counterexample that I
> could construct (and there are clearly a bazillion others).
> 
> Let line 1 be the x axis, so the line with parametric representation
> (s, 0, 0)   
> 
> Let line 2 be the line with parametric representation (0, t, t+1).
> Thus line 2 lies in the yz plane where it has the implicit equation 
> z = y+1.
> 
> The projection of line 1 on the xy plane is just the x axis.
> The projection of line 2 on the xy plane is the y axis,
> The intersection of these projections is (0,0,0).
> 
> The projection of line1 on the xz plane is the x axis
> The projection of line 2 on the xz plane is the z axis
> The intersection of these projections is (0,0,0)
> 
> So in your notation  x1 = 0 = x2,  and by your algorithm you claim
> that the lines intersect at (0,0,0).  In fact they do not.  Line 2
> does not even pass through the point (0,0,0),  In fact these two lines
> do not intersect at all, ever, nowhere, no way.  In fact, it is a
> problem in freshman analytic geometry to show that the distance of
> closest approach of these two lines is sqrt(1/2), but I could as
> easily have made it a billion units. 
> 
> > (I
> >am not a math guy...),
> 
> Which is no license to post wrong stuff..
> 
> > but, if properly implemented, it will certainly be
> >fast and provide at least a reasonable estimation.
> >
> 
> Bah.
> 
> I'm growing weary of playing math cop.  Soon gonna turn in my badge.
> 
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> 
> 

Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

[Algorithms] Animation tricks.

[Ben H. <jb...@ho...>]

> > rather low frame rates, which is why movies are 24 fps and cartoons are
> > typically half of that.
>
>don't use traditional cartooning framerate as an example.. animators >use 
>*lots* of tricks in order to trick human perception.. more >recently, I've 
>started to see a lot of web flash animators >rediscovering these 
>fundamentals of animation to compensate for low >framerates.

Hi,

Could you point me in the direction of a good document on this subject? It 
sounds like the same tricks could be of use if you
want to do animation in Java.

Cheers in advance,

BEN

________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

Re: [Algorithms] Modifying the min and max altitude in a heightmap

[Allan B. <A.B...@Re...>]

Why not have a lower resolution height map that simply contains the values
of the max and min height 'hiexels' in that particular cell?

That way you can more easily reject a large (depending of course on your
chosen resolution) number of 'heixels'.

You'll still have to do a complete scan of your low res map but it will be
faster than goin through the individual 'hiexel' map.


Al.

----- Original Message -----
From: "Robert Dibley" <RD...@ac...>
To: <gda...@li...>
Sent: Tuesday, August 01, 2000 12:00 PM
Subject: RE: [Algorithms] Modifying the min and max altitude in a heightmap


> He could however optimise the occasions when he does the full rescan, by
> checking to see if the value you are replacing was the maximum value, in
> which case it is _possible_ but by no means certain that your max value
has
> decreased.
>
> Or even, when tracking the maximum value, keep a count of how many match
the
> maximum (after all you will have to scan at the outset, so can get the
> initial count there) and then if you increase the max, it becomes 1 (ie
just
> the new entry) and if you replace an entry with the current max height,
with
> a lower value, you can decrement the count.  If the count of max height
> entries reaches zero, then do a rescan.  Oh, and make sure if you replace
an
> entry with a new one which matches the max value that you increment the
> count too.
>
> Still doesn't solve the basic problem that you have to do a rescan
> occasionally, but stops you doing it when you really don't need to.
>
> Rob
>
> -----Original Message-----
> From: Jamie Fowlston [mailto:j.f...@re...]
> Sent: 01 August 2000 11:35
> To: gda...@li...
> Subject: Re: [Algorithms] Modifying the min and max altitude in a
> heightmap
>
>
> Unless you maintain a list of heixels sorted by height, I'm pretty sure
you
> can't do what you want. Sorry.
>
> Jamie
>
>
> Sam McGrath wrote:
>
> > This may have a simple solution, but I haven't thought of one yet...
> >
> > I have a heightmap of altitude values.  The heightmap is subject to
> > modification during the course of my program.  When I load the heightmap
I
> > compute the maximum and minimum values (altitudes).  During the program,
> if
> > a value in heightmap that is modified goes beyond the maximum altitude,
I
> > assign that value to the maximum altitude (and similarly for the minimum
> > altitude).
> >
> > However, I also want to be able to tell if the maximum value has
_shrunk_
> > (or if this minimum value has increased).  So far I can't think of a
> simple
> > way to do this other than rescanning the whole heightmap whenever a
value
> is
> > modified, and clearly this is not a practical solution.
> >
> > Hopefully there's a nice simple method that I'm blind to, so please
> > enlighten me if you can.  (-:
> >
> > -Sam
> > ______________________
> > Sam McGrath
> > sa...@dn...
> > http://www.dnai.com/~sammy
> > ICQ 5151160
> >
> > _______________________________________________
> > GDAlgorithms-list mailing list
> > GDA...@li...
> > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

Re: [Algorithms] Modifying the min and max altitude in a heightmap

[Jamie F. <j.f...@re...>]

True. I tend to think of worst cases :)

Jamie


Robert Dibley wrote:

> He could however optimise the occasions when he does the full rescan, by
> checking to see if the value you are replacing was the maximum value, in
> which case it is _possible_ but by no means certain that your max value has
> decreased.
>
> Or even, when tracking the maximum value, keep a count of how many match the
> maximum (after all you will have to scan at the outset, so can get the
> initial count there) and then if you increase the max, it becomes 1 (ie just
> the new entry) and if you replace an entry with the current max height, with
> a lower value, you can decrement the count.  If the count of max height
> entries reaches zero, then do a rescan.  Oh, and make sure if you replace an
> entry with a new one which matches the max value that you increment the
> count too.
>
> Still doesn't solve the basic problem that you have to do a rescan
> occasionally, but stops you doing it when you really don't need to.
>
> Rob
>
> -----Original Message-----
> From: Jamie Fowlston [mailto:j.f...@re...]
> Sent: 01 August 2000 11:35
> To: gda...@li...
> Subject: Re: [Algorithms] Modifying the min and max altitude in a
> heightmap
>
> Unless you maintain a list of heixels sorted by height, I'm pretty sure you
> can't do what you want. Sorry.
>
> Jamie
>
> Sam McGrath wrote:
>
> > This may have a simple solution, but I haven't thought of one yet...
> >
> > I have a heightmap of altitude values.  The heightmap is subject to
> > modification during the course of my program.  When I load the heightmap I
> > compute the maximum and minimum values (altitudes).  During the program,
> if
> > a value in heightmap that is modified goes beyond the maximum altitude, I
> > assign that value to the maximum altitude (and similarly for the minimum
> > altitude).
> >
> > However, I also want to be able to tell if the maximum value has _shrunk_
> > (or if this minimum value has increased).  So far I can't think of a
> simple
> > way to do this other than rescanning the whole heightmap whenever a value
> is
> > modified, and clearly this is not a practical solution.
> >
> > Hopefully there's a nice simple method that I'm blind to, so please
> > enlighten me if you can.  (-:
> >
> > -Sam
> > ______________________
> > Sam McGrath
> > sa...@dn...
> > http://www.dnai.com/~sammy
> > ICQ 5151160
> >
> > _______________________________________________
> > GDAlgorithms-list mailing list
> > GDA...@li...
> > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

RE: [Algorithms] Modifying the min and max altitude in a heightma p

[Robert D. <RD...@ac...>]

He could however optimise the occasions when he does the full rescan, by
checking to see if the value you are replacing was the maximum value, in
which case it is _possible_ but by no means certain that your max value has
decreased.

Or even, when tracking the maximum value, keep a count of how many match the
maximum (after all you will have to scan at the outset, so can get the
initial count there) and then if you increase the max, it becomes 1 (ie just
the new entry) and if you replace an entry with the current max height, with
a lower value, you can decrement the count.  If the count of max height
entries reaches zero, then do a rescan.  Oh, and make sure if you replace an
entry with a new one which matches the max value that you increment the
count too.

Still doesn't solve the basic problem that you have to do a rescan
occasionally, but stops you doing it when you really don't need to.

Rob

-----Original Message-----
From: Jamie Fowlston [mailto:j.f...@re...]
Sent: 01 August 2000 11:35
To: gda...@li...
Subject: Re: [Algorithms] Modifying the min and max altitude in a
heightmap


Unless you maintain a list of heixels sorted by height, I'm pretty sure you
can't do what you want. Sorry.

Jamie


Sam McGrath wrote:

> This may have a simple solution, but I haven't thought of one yet...
>
> I have a heightmap of altitude values.  The heightmap is subject to
> modification during the course of my program.  When I load the heightmap I
> compute the maximum and minimum values (altitudes).  During the program,
if
> a value in heightmap that is modified goes beyond the maximum altitude, I
> assign that value to the maximum altitude (and similarly for the minimum
> altitude).
>
> However, I also want to be able to tell if the maximum value has _shrunk_
> (or if this minimum value has increased).  So far I can't think of a
simple
> way to do this other than rescanning the whole heightmap whenever a value
is
> modified, and clearly this is not a practical solution.
>
> Hopefully there's a nice simple method that I'm blind to, so please
> enlighten me if you can.  (-:
>
> -Sam
> ______________________
> Sam McGrath
> sa...@dn...
> http://www.dnai.com/~sammy
> ICQ 5151160
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list


_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

Re: [Algorithms] Smooth movement of camera along a path

[Jamie F. <j.f...@re...>]

Easiest spline to use for this is Catmull Rom, which if I remember
correctly allows you to keyframe the way you want to.

For a Java link, try

http://www.media.mit.edu/~rich/research/java/docs/acg.stuttgart.rich.spline.CatmullRomSplineLoop3D.html

I've no idea how good it is, I was only searching to remind myself of
the name :)

Jamie


Mark Wilczynski wrote:

> I'm trying to write a fly-by sequence (similar to the Unreal
> intro) for my 3d engine.  Can anyone tell me how to smoothly
> move the camera along a set of predefined 3d points?
> Ideally,  I would like a system where I manually move the
> camera around the environment and record keyframes at
> certain positions/orientations.  Then I would like the
> system to automatically move the camera along a path
> interpolated from these keyframes.  I'm guessing I need some
> sort of spline or other curve to do the job?
>
> -Mark
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

Re: [Algorithms] Modifying the min and max altitude in a heightmap

[Jamie F. <j.f...@re...>]

Unless you maintain a list of heixels sorted by height, I'm pretty sure you
can't do what you want. Sorry.

Jamie


Sam McGrath wrote:

> This may have a simple solution, but I haven't thought of one yet...
>
> I have a heightmap of altitude values.  The heightmap is subject to
> modification during the course of my program.  When I load the heightmap I
> compute the maximum and minimum values (altitudes).  During the program, if
> a value in heightmap that is modified goes beyond the maximum altitude, I
> assign that value to the maximum altitude (and similarly for the minimum
> altitude).
>
> However, I also want to be able to tell if the maximum value has _shrunk_
> (or if this minimum value has increased).  So far I can't think of a simple
> way to do this other than rescanning the whole heightmap whenever a value is
> modified, and clearly this is not a practical solution.
>
> Hopefully there's a nice simple method that I'm blind to, so please
> enlighten me if you can.  (-:
>
> -Sam
> ______________________
> Sam McGrath
> sa...@dn...
> http://www.dnai.com/~sammy
> ICQ 5151160
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

Re: [Algorithms] VIPM on a machine with DMA :)

[Jamie F. <j.f...@re...>]

Tom Forsyth wrote:

> The 12 bytes per vertex may be worth it if it means you can draw many
> instances at once without any extra indices being DMA'd in for each one.
> Hmmm... actually, that may not be true - it's total memory that is a problem
> as well - once DMA bandwidth is below a certain level (which it probably
> will be for indices), it ceases to be the bottleneck. You're right - do the
> expand/collapses on the CPU.

There's a whole load of balancing to do, and being in the first wave means noone
has any real idea of where the balance should be struck. Hohum :)

I may actually get round to reading the papers this time :)

>
>
> I'm sure you must be able to get indices fast. Vertex reuse (_after_ the T&L
> is done) will be a fairly big timesaver - it certainly is in the PC/DX
> world.

We're not sure whether it would be a win or not, as the degree of vertex reuse
is currently unclear. Then we'll see :)

Jamie

RE: [Algorithms] VIPM on a machine with DMA :)

[Tom F. <to...@mu...>]

The 12 bytes per vertex may be worth it if it means you can draw many
instances at once without any extra indices being DMA'd in for each one.
Hmmm... actually, that may not be true - it's total memory that is a problem
as well - once DMA bandwidth is below a certain level (which it probably
will be for indices), it ceases to be the bottleneck. You're right - do the
expand/collapses on the CPU.

I'm sure you must be able to get indices fast. Vertex reuse (_after_ the T&L
is done) will be a fairly big timesaver - it certainly is in the PC/DX
world.

Tom Forsyth - Muckyfoot bloke.
Whizzing and pasting and pooting through the day.

> -----Original Message-----
> From: Jamie Fowlston [mailto:j.f...@re...]
> Sent: 01 August 2000 10:39
> To: gda...@li...
> Subject: Re: [Algorithms] VIPM on a machine with DMA :)
> 
> 
> Tom Forsyth wrote:
> 
> > > From: Jamie Fowlston 
> [mailto:j.f...@re...]
> > >
> > >
> > > Still have to DMA the vertex data, which is larger for VIPMed
> > > models (am I
> > > right? I've not implemented VIPM, but think I've understood
> > > the general idea).
> >
> > No, the vertex data is precisely as big as your 
> most-detailed model - that
> > is, the most detailed model you want to draw that frame (or 
> that instance or
> > whatever). There is zero bloating of vertex data.
> 
> That sounds a lot saner then.
> 
> >
> >
> > The index data is indexed lists, so that's very slightly 
> bloated from
> > indexed strips in some cases, but probably not so you'd 
> notice - indices are
> > tiny compared to the vertices anyway.
> 
> True. Just using indices in the first place can significantly 
> slow things down,
> though.... Hmmm. Rethink time on aspects of inherited 
> graphics engine. Not so
> sure about that now... depends on vertex reuse.... 
> Possibilities there.
> 
> > And the collapse/expand info is
> > moderately big thinking about it (12 bytes per collapse on 
> average I think -
> > I can't remember), so it may not be a win to do the 
> collapse/expand on the
> > "non-CPU unit" - who can tell? It's pretty quick on both to 
> be honest.
> 
> That's too much data for us if it turns into roughly 12 bytes 
> per vertex.
> 
> >
> > > So total transfer is larger than it would be for non-VIPMed
> > > model. We're
> > > expecting to be DMA speed constrained rather than draw speed
> > > constrained.
> >
> > Indeed, that's what I woudl expect too - the DMA seems to 
> be the hardest
> > thing to get right about the machine. But fortunately there 
> is no bloat. Go
> > and read Charles Bloom's excellent VIPM tutorial (one day 
> I'll get around to
> > doing my own - actually, there's not much point - it'll be 
> identical to
> > Charles'). (http://208.55.130.3/3d/ - sixth link down).
> 
> I've been meaning to :) I'm too busy to do the things that 
> would save me
> time.... :)
> 
> Jamie
> 
> 
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> 

[Algorithms] Modifying the min and max altitude in a heightmap

[Sam M. <sa...@dn...>]

This may have a simple solution, but I haven't thought of one yet...

I have a heightmap of altitude values.  The heightmap is subject to
modification during the course of my program.  When I load the heightmap I
compute the maximum and minimum values (altitudes).  During the program, if
a value in heightmap that is modified goes beyond the maximum altitude, I
assign that value to the maximum altitude (and similarly for the minimum
altitude).

However, I also want to be able to tell if the maximum value has _shrunk_
(or if this minimum value has increased).  So far I can't think of a simple
way to do this other than rescanning the whole heightmap whenever a value is
modified, and clearly this is not a practical solution.

Hopefully there's a nice simple method that I'm blind to, so please
enlighten me if you can.  (-:

-Sam
______________________
Sam McGrath
sa...@dn...
http://www.dnai.com/~sammy
ICQ 5151160

Re: [Algorithms] VIPM on a machine with DMA :)

[Jamie F. <j.f...@re...>]

Tom Forsyth wrote:

> > From: Jamie Fowlston [mailto:j.f...@re...]
> >
> >
> > Still have to DMA the vertex data, which is larger for VIPMed
> > models (am I
> > right? I've not implemented VIPM, but think I've understood
> > the general idea).
>
> No, the vertex data is precisely as big as your most-detailed model - that
> is, the most detailed model you want to draw that frame (or that instance or
> whatever). There is zero bloating of vertex data.

That sounds a lot saner then.

>
>
> The index data is indexed lists, so that's very slightly bloated from
> indexed strips in some cases, but probably not so you'd notice - indices are
> tiny compared to the vertices anyway.

True. Just using indices in the first place can significantly slow things down,
though.... Hmmm. Rethink time on aspects of inherited graphics engine. Not so
sure about that now... depends on vertex reuse.... Possibilities there.

> And the collapse/expand info is
> moderately big thinking about it (12 bytes per collapse on average I think -
> I can't remember), so it may not be a win to do the collapse/expand on the
> "non-CPU unit" - who can tell? It's pretty quick on both to be honest.

That's too much data for us if it turns into roughly 12 bytes per vertex.

>
> > So total transfer is larger than it would be for non-VIPMed
> > model. We're
> > expecting to be DMA speed constrained rather than draw speed
> > constrained.
>
> Indeed, that's what I woudl expect too - the DMA seems to be the hardest
> thing to get right about the machine. But fortunately there is no bloat. Go
> and read Charles Bloom's excellent VIPM tutorial (one day I'll get around to
> doing my own - actually, there's not much point - it'll be identical to
> Charles'). (http://208.55.130.3/3d/ - sixth link down).

I've been meaning to :) I'm too busy to do the things that would save me
time.... :)

Jamie

RE: [Algorithms] Maximum Distance Point To AABB

[Tom F. <to...@mu...>]

I wouldn't worry about trying to bin the smaller mipmap levels - they are so
much less memory than the larger ones that it's pointless trying to bin them
- (a) you save very little memory, (b) even close-to things can use smaller
mipmaps (if they are edge-on) and (c) most hardware doesn't support having
missing small mipmaps - you'll only confuse it horribly.

Saving the larger mipmaps is obviously a win though.

Tom Forsyth - Muckyfoot bloke.
Whizzing and pasting and pooting through the day.

> -----Original Message-----
> From: Joe Ante [mailto:jo...@ti...]
> Sent: 31 July 2000 22:43
> To: 3D Algorithms
> Subject: [Algorithms] Maximum Distance Point To AABB
> 
> 
> Hi,
> 
> For my terrain engine texture synthesizer, I want to 
> dynamically load the
> mipmap levels only when they are needed and delete them when 
> they are not
> needed anymore.
> The terrain is subdivided into little chunks which all have their own
> texture. So I would like to find out the minimum and maximum 
> Distance from a
> point to the AABB enclosing the terrain chunk.
> 
> The minimum distance was easy, but how do I get the maximum 
> distance to the
> AABB?
> 
> Thanks in advance.
> bye joe
> 
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> 

RE: [Algorithms] FPS Questions

[Mark A. <MA...@ac...>]

Why not just ask the player what they want and then scale the engine to that
speed.  If they want 'liquidity' at high frame rates then scale back and use
lower level of detail models.  If they can't tell the difference then
they'll pull the frame rate down to 30fps and get better looking visuals.

> -----Original Message-----
> From: Steve Wood [mailto:Ste...@im...]
> Sent: 31 July 2000 21:22
> To: 'gda...@li...'
> Subject: RE: [Algorithms] FPS Questions
> 
> 
> > -----Original Message-----
> > From: Jim Offerman [mailto:j.o...@in...]
> > 
> > > 60fps is the ideal target.
> > 
> > I blindly follow the masses here, but I can't help wondering 
> > why... Anything
> > above 24-25 fps will not be noticed by the human eye, 30 fps 
> > animations look
> > _really_ smooth. So why are we all targetting for 60 fps? 
> Shouldn't we
> > rather crank up the detail some more and all target 30 fps? 
> > What makes a 60
> > fps game more playable than a 30 fps game?
> > 
> 
> I think the ideal target fps needs to detailed further since 
> fps is relative
> to the bits per pixel and window or screen size.  I'm 
> assuming that Keith's
> ideal 60fps is at 640x480x32 fullscreen...so that someone can 
> play it at
> 800x600x32 and get about 30fps, or 1024x768 and get the 24-25fps.
> 
> R&R
> 
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> 

Re: [Algorithms] FPS Questions

[Davide P. <da...@pr...>]

> > 60fps is the ideal target.
>
> I blindly follow the masses here, but I can't help wondering why...
Anything
> above 24-25 fps will not be noticed by the human eye, 30 fps animations
look
> _really_ smooth. So why are we all targetting for 60 fps? Shouldn't we

Because at 60fps there are 60 rendered images in one second, more animation
frames, so more global quality, more detail, less missing particular between
one
frame and another.

Imagine you have an high speed movement, at 30 fps you can get only 30
images
for that movement in that second, with 60fps you have 60 images, so more
detail,
with 200fps or hz you have an incredible detailed rendered sequence...

So more fps better interpolation better detail, in theory there's no a
maximum...

Davide Pirola
www.prograph.it
www.protonic.net

Re: [Algorithms] Maximum Distance Point To AABB

[Tom H. <to...@3d...>]

At 11:42 PM 7/31/2000 +0200, you wrote:
>Hi,
>
>For my terrain engine texture synthesizer, I want to dynamically load the
>mipmap levels only when they are needed and delete them when they are not
>needed anymore.
>The terrain is subdivided into little chunks which all have their own
>texture. So I would like to find out the minimum and maximum Distance from a
>point to the AABB enclosing the terrain chunk.
>
>The minimum distance was easy, but how do I get the maximum distance to the
>AABB?

If you know which corner of the AABB is the minimum, then the maximum is 
the corner farthest from that corner. If the nearest point is the lower 
left, then the farthest point always the upper right. You should be able to 
figure out the actual distance pretty easily. Of course depending on the 
type of checks your doing to find the minimum, you should be able to 
reverse the sense of the tests and get the maximum instead.

Tom

Re: [Algorithms] FPS Questions

[jason w. <jas...@po...>]

> No they didn't start "doing this as theatres started getting larger
> and larger screens", I don't know where you got that from.

I got it from a projectionist friend, if you really care to know. Nice to
know the real deal tho.

Re: [Algorithms] FPS Questions

[<Chr...@Pl...>]

Jason Watkins wrote:
>ohh.. btw, most cinema projectors actually flash each frame twice before
>advancing to the next. they only started doing this as theaters started
>getting larger and larger screens.. as the screen starts to dominate more
>and more of the viewers fov, the viewer becomes more and more sensitive to
>flashing, aliasing and so on. good to keep in mind when the norm right now
>is a gamer sitting 2" away from a 19" monitor :)

No they didn't start "doing this as theatres started getting larger
and larger screens", I don't know where you got that from.

They started double shuttering at the same time they made the move from
the silent periods ca 16 fps (which was shown triple shuttered) to today's
24 fps (which is typically double shuttered). 16 * 3 = 24 * 2 incidentally.


Christer Ericson
SCEA, Santa Monica

Re: [Algorithms] FPS Questions

[Ales M. <ja...@sl...>]

Yeah, but still, I think that the 60 fps is ideal becouse of developers
working the game on the the best available computer and stuff, so that means
that It should work at 20-30 fps on a normal-gamers computer anyway. Quake
didn't work at 60 fps when they released it, but it did a ~year after. So
thinking in how much Fps do you want wont bring you nowhere. It didn't bring
Me nowhere when I was thinking too much about it anyway.

> Ever played Classic Quake with 30 fps? I have, and you really Feel the
> difference between 30 and 60 fps, or 30 and 100 fps...It's so much
> smooother...
> You also have to remember that fps-number is just the __Average__ number
of
> frames. There's alot more work involved in rendering when you see a whole
> room with furniture, plants etc. than just a single wall. So if you're
> average is 30 fps, you get 30+ when see a wall and 30- when you see a more
> complex scene. (Hope ye get the idea...I'm no good story teller...)
>
> >> 60fps is the ideal target.
> >
> >I blindly follow the masses here, but I can't help wondering why...
Anything
> >above 24-25 fps will not be noticed by the human eye, 30 fps animations
look
> >_really_ smooth. So why are we all targetting for 60 fps? Shouldn't we
> >rather crank up the detail some more and all target 30 fps? What makes a
60
> >fps game more playable than a 30 fps game?
> >
> >Jim Offerman
> >
> >Innovade
> >- designing the designer
> >
> >
> >_______________________________________________
> >GDAlgorithms-list mailing list
> >GDA...@li...
> >http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
> >
>
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

Re: [Algorithms] FPS Questions

[jason w. <jas...@po...>]

> rather low frame rates, which is why movies are 24 fps and cartoons are
> typically half of that.

don't use traditional cartooning framerate as an example.. animators use
*lots* of tricks in order to trick human perception.. more recently, I've
started to see a lot of web flash animators rediscovering these fundamentals
of animation to compensate for low framerates.

console games often use the same tricks... especially fighting games.

Re: [Algorithms] FPS Questions

[jason w. <jas...@po...>]

> > Incidentally, 24fps panning at the cinema does EVIL things to my eyes -
> can
> > no-one else see it? It's really really awful and stuttery and blurry and
> yuk
> > - ruins a good movie. Roll on digital projection....
>
> Oh yeah.  It's a mess.  Best when your sitting really close to the
screen -
> enough to make you puke :).

Yeah.. usually what's happening there is that they're shooting with way to
fast a film.. so they shorted the exposure window to a small portion of the
24sec period, or they drop frames if the camera was rollign at a higher
framerate. Some movies use this as an intentional effect.. I think the first
(biggest) was saving private ryan.. it has a nice effect of eliminating all
motion blur.

in many ways, this is the same perceptual problem current games have.. lack
of motion blur ruins the sensation of continous motion.. I _do_ think that
rendering at 30fps with *good* motion blur may feel as "nice" or "nicer"
than rendering at 60 fps without it.. but motion blur is such a fill burn
we'll have to wait a cycle or 2 before truely exploiting it (sorry... the 4
way sampling 3dfx is pushing doesn't cut it, at least for me, but it is a
step in the right way). I've been thinking about splat based rendering a lot
lately.. one of the advantages is you could hack in motion blur like this
fairly easily, and the fill rate overhead is proportional to the amount of
moving splats and the severity of their movement, not constant accross the
entire frame.

ohh.. btw, most cinema projectors actually flash each frame twice before
advancing to the next. they only started doing this as theaters started
getting larger and larger screens.. as the screen starts to dominate more
and more of the viewers fov, the viewer becomes more and more sensitive to
flashing, aliasing and so on. good to keep in mind when the norm right now
is a gamer sitting 2" away from a 19" monitor :)

Re: [Algorithms] FPS Questions

[gl <gl...@nt...>]

> Apparent motion is the term used to describe the visual phenomenon where
> the display of different distinct static images is perceived as continuous
> motion. This phenomenon known as the 'phi phenomenon', first happens at
> rather low frame rates, which is why movies are 24 fps and cartoons are
> typically half of that.

Yes, but motion in TV & film cannot be compared to motion in computer
graphics, due to motion blur (see my other post).  The biggest mistake in
these arguments is justifying low gfx fps with TV/film fps - it's not a
valid comparison.
--
gl

Re: [Algorithms] Smooth movement of camera along a path

[Will P. <wi...@cs...>]

Catmull-Rom splines interpolate all control points, so they would be worth
checking out.  Look at:

http://graphics.cs.ucdavis.edu/CAGDNotes/Catmull-Rom-Spline/Catmull-Rom-Spline.html

The standard graphics textbooks have better expositions than this web page
if you have access to them.

Will

----
Will Portnoy
http://www.cs.washington.edu/homes/will

On Mon, 31 Jul 2000, Mark Wilczynski wrote:

> I'm trying to write a fly-by sequence (similar to the Unreal
> intro) for my 3d engine.  Can anyone tell me how to smoothly
> move the camera along a set of predefined 3d points?
> Ideally,  I would like a system where I manually move the
> camera around the environment and record keyframes at
> certain positions/orientations.  Then I would like the
> system to automatically move the camera along a path
> interpolated from these keyframes.  I'm guessing I need some
> sort of spline or other curve to do the job?
> 
> -Mark
> 
> 
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>