Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!ufqtp!sutherla
From: sutherla@qtp.ufl.edu (scott sutherland)
Newsgroups: comp.graphics
Subject: 3D Texture Mapping Problems in TurboSilver
Message-ID: <661@orange6.qtp.ufl.edu>
Date: 12 Sep 89 14:11:41 GMT
Reply-To: sutherla@orange6 (scott sutherland)
Distribution: na
Organization: University of Florida Quantum Theory Project
Lines: 59




In article <14266.netnews.upenn.edu> Ranjit Bhatnagar writes:


>In article <170@vsserv.scri.fsu.edu> prem@geomag.UUCP (Prem Subrahmanyam) writes:
>
>   I would strongly recommend obtaining copies of both DBW_Render and
>   QRT, as both have very good texture mapping routines.  DBW uses 
>   absolute spatial coordinates to determine texture, while QRT uses
>   a relative position per each object type mapping. 

>The combination of 3-d spatial texture-mapping (where the map for a 
>particular point is determined by its position in space rather than
>its position on the patch or polygon) with a nice 3-d turbulence function
>can give really neat results for marble, wood, and such.  Because the
>texture is 3-d, objects look like they are carved out of the texture
>function rather than veneered with it.  It works well with non-turbulent
>texture functions too, like bricks, 3-d checkerboards, waves, and so
>on.  However, there's a disadvantage to this kind of texture function 
>that I haven't seen discussed before: as generally proposed, it's highly
>unsuited to _animation._  The problem is that you generally define one
>texture function throughout all of space.  If an object happens to move,
>its texture changes accordingly.  It's a neat effect - try it - but it's
>not what one usually wants to see.



	These packages are not the only ones that suffer from problems 
with Texture mapping (3D) and animation. I have the commercial package
Turbo Silver 3.0 (and SV), which does something called Texture Bumping.
I created a brick texture and set its "roughness" to a fairly large 
value, hoping to get a rough looking brick. This works very well. I was
also able to get a very realistic (IMHO) looking road in front of the
brick building. I then proceeded to use these objects in a camera fly-by
animation and then in a stationary camera animation with moving objects
flying into the picture. What I saw was a "shimmering" of the brick 
surface and of the road surface. It was somewhat random, since, if I 
looked at frame-by-frame changes, sometimes the image would change and
sometimes it would not. I called the company who created TS, Impulse,
and asked them about it. I even sent them a copy of the animation to
show them the effect, along with the objects, CELS, etc needed to re-
create the animation. They were very helpful in that they took the time
to use the objects and generate a portion of the animation themselves. 
The conclusion: they use a random "bumping" of the surface normals to
create their "Texture Bumping" or roughening. Since this process is 
"random", there is no way to fix this from frame to frame, thus animation
of roughened objects will always create this problem. 

	I was curious about this "not being able to "FIX" the roughening
pattern from frame to frame". They were able to "FIX" the variable sky
dithering from frame to frame. Thus, when I choose a Horizon and Zenith
color and tell TS to use extreme blending, the dither pattern created is
complex, BUT does NOT change from frame to frame in an animation. Is the
problem with the surface normals that much more difficult?


Scott Sutherland
sutherla@qtp.ufl.edu