Re: bump mapping.

New Message Reply Date view Thread view Subject view Author view

Steve Baker (steve++at++mred.bgm.link.com)
Fri, 23 Aug 96 14:24:11 -0500


Ooops! I accidentally flamed again - sorry everyone. :-)

I'll try to stick with the bump-mapping issue....

OK, let's see - Angus said:-

> Hmmm.. I made it clear that this was multi-pass and the limitations are
> there to see.

Indeed - but you can claim *any* feature in your system if you are
prepared to run slowly enough. We *could* ray-trace or used radiosity
methods and claim that the iR can do these things. What matters in
practice is whether it can do it in a general database and
at a reasonable cost.

In most (if not all) cases, doing two passes has the effect of doubling the
pixel fill and doubling the polygon loads. This typically comes close to
doubling the cost of the IG - more pipes, more RM's, more CPU's to drive
the extra pipes.

> You seem to understand the technique although you haven't realised that
> bumpmapping can tile over planar surfaces....

Oh, I had no problem realising that - but it just isn't useful.

1) The ocean isn't flat (I can give you the URL of the Flat Earth Society
   if you want to subscribe :-) if you look at the ocean from an aircraft
   window when the sun is low in the sky, this is very apparent.

2) Although the sun is near-enough infinite, lights on your own vehicle at night
   are not - and the eye certainly *isn't* infinite.

> for distant sources & no
> specularity, or at least localviewer lighting equivalent, and can be as
> cheap as texture mapping under some circumstances ie diffuse only or
> loalviewer and static light source.

Bump mapping is really a waste of effort if all of the conditions you describe
are met. If all the polygons are planar and we ignore specularity,
then you might as well pre-compute a complete set of pre-illuminated
maps, one for every hour of the day (or whatever) and trickle-load them
into the IG as virtual time progresses.

Bump mapping is really only useful where these simpler and cheaper tricks
break down.

> I thought the question was can the iR perform bump mapping in real time and
> the answer is emphatically *YES*. If you want to ask a different question
> then fine maybe you get a different answer. Nobody was being suckered and
> the explanation of the technique was clear.

Yes, and my 386 PC can do ray-tracing in realtime (I have 'DOOM' and it does
kindof kludgy limited case raytracing)...if the conditions are exactly right
and you limit the conditions enough. So is it valid to say that PC's can
do real-time raytracing? Of course not.

> There is another view here, the RE2 & iR are systems which can perform
> all of these tricks because of the flexibility of the GL. Youre not limited
> to what the demos show.

This much I understand - and I have used a LOT of these tricks myself -
I would strongly agree with all your sentiments about the generality of
the design of SGI graphics and the power that comes with flexibility.

I'd like to urge extreme caution with presenting and viewing demos - it's
critial to explain the limitations of the techniques being used. People
see demos at SigGraph and come to us saying "SGI are showing bump mapping"
and we have to patiently explain that it's all a clever hack and that
they can't have fancy ocean models on their next F16 simulator.

This makes SGI look bad because they mislead the customer (nobody on the stand
at SigGraph explains that this awesome demo is completely inapplicable
to real applications). It also makes me look incompetant because I can't
do bump mapping in my simulations "but SGI can" using the same hardware.

  Steve Baker 817-323-1361 (Vox-Lab)
  Hughes Training Inc. 817-695-8776 (Vox-Office/vMail)
  2200 Arlington Downs Road 817-695-4028 (Fax)
  Arlington, Texas. TX 76005-6171 steve++at++mred.bgm.link.com (eMail)

=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
            Submissions: info-performer++at++sgi.com
        Admin. requests: info-performer-request++at++sgi.com


New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:53:24 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.