Angus Dorbie (dorbie++at++bitch.reading.sgi.com)
Sat, 24 Aug 1996 20:47:31 +0100
With the Infinite Reality you finally have a machine which can usefully
employ multipass algorithms in a real-time scene, even RE2 had some success
here. You can bump map with a local light source and specular highlights in
real-time, yes its slow compared to normal shading but I'm not cheating in
any way when I say that this is real-time, the tricks I mentioned were
optional for enhancing the performance. There are lots of ways you could
make this kind of bump mapping even more viable, like round robin your
bump mapped object calculations, but any tricks would depend on the
application.
I don't think approximating the shading on the sea with the assumption that
it is flat would be noticeable, the actual deviation would be less
than a degree from a ships bridge, and you still have the shading operation
on the base polygons. The specularity is a real showstopper here,
but you could blend in a surface with a specular calculation using a tlut to
trancparency for parts of the bump texture, this could look great (ouch even
more passes :-)). Is this any more usefull than any other kludge?
I have to agree with you that for bump mapped seas you'd probably want to
ignore this approach.
Angus.
On Aug 23, 2:24pm, Steve Baker wrote:
> Subject: Re: bump mapping.
>
> 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
>-- End of excerpt from Steve Baker
=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
Submissions: info-performer++at++sgi.com
Admin. requests: info-performer-request++at++sgi.com
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:53:24 PDT