GeForce2 announcement
Skint
To quote Nvidias website
"Achieving Pixar-level animation in real-time has been an industry
dream for years," explains Jen-Hsun Huang, president and CEO at
NVIDIA. "With twice the performance of the GeForce 256 and per-pixel
shading technology, the GeForce2 GTS is a major step toward achieving
that goal."
Does this mean were going to be able to render in real time soon? Any
chance of shading language bein made available for OpenGL? :o)
I'm guessing per pixel shading should at least give realtime phong
illumination for the first time - am I right??
Simon
MG
But I don't think many companies will make them so soon...
It's all $$$, they are going to develope them in certain stages!
But let's wait and see!....
Greetings,
Stephen H. Westin
> To quote Nvidias website
>
> "Achieving Pixar-level animation in real-time has been an industry
> dream for years," explains Jen-Hsun Huang, president and CEO at
> NVIDIA. "With twice the performance of the GeForce 256 and per-pixel
> shading technology, the GeForce2 GTS is a major step toward achieving
> that goal."
>
>
> Does this mean were going to be able to render in real time soon?
Well, not Toy Story 2.
> Any
> chance of shading language bein made available for OpenGL? :o)
Yes. At least some sort of subset. SGI is working on it, and will be
presenting a paper at SIGGRAPH.
> I'm guessing per pixel shading should at least give realtime phong
> illumination for the first time - am I right??
There's a reasonable hope for that. And about time :).
--
-Stephen H. Westin
Any information or opinions in this message are mine: they do not
represent the position of Cornell University or any of its sponsors.
erik robson
(Stephen H. Westin) wrote:
[snip]
>
>Yes. At least some sort of subset. SGI is working on it, and will be
>presenting a paper at SIGGRAPH.
>
In the latest talk that John Carmack (Quake) gave, he was talking
about eventually hardware-accelerating a reasonable subset of
Renderman shader functionality.
At the same time, MS' Directx8 is going to feature per-vertex and
per-pixel shaders, and I'm assuming that the next generation of video
cards will support them with hardware acceleration.
Good times ahead for realtime graphics, I think...
erik
Tom Duff
>
> To quote Nvidias website
>
> "Achieving Pixar-level animation in real-time has been an industry
> dream for years," explains Jen-Hsun Huang, president and CEO at
> NVIDIA. "With twice the performance of the GeForce 256 and per-pixel
> shading technology, the GeForce2 GTS is a major step toward achieving
> that goal."
>
> chance of shading language bein made available for OpenGL? :o)
You know, this should be in the FAQ.
These guys just have no idea what goes into `Pixar-level animation.'
(That's not quite fair, their engineers do, they come and visit all
the time. But their managers and marketing monkeys haven't a clue, or
possibly just think that you don't.)
`Pixar-level animation' runs about 8 hundred thousand times slower than
real-time
on our renderfarm cpus. (I'm guessing. There's about 1000 cpus in
the renderfarm and I guess we could produce all the frames in TS2 in
about 50 days of renderfarm time. That comes to 1.2 million cpu hours
for a 1.5 hour movie. That lags real time by a factor of 800,000.)
Do you really believe that their toy is a million times faster
than one of the cpus on our Ultra Sparc servers? What's the chance that
we wouldn't put one of these babies on every desk in the building? They
cost a couple of hundred bucks, right? Why hasn't NVIDIA tried to give
us a carton of these things? -- think of the publicity milage they could
get out of it!
Don't forget that the scene descriptions of TS2 frames average between 500MB
and 1GB. The data rate required to read the data in real time is at least
96Gb/sec. Think your AGP port can do that? Think again. 96 Gb/sec means
that if they clock data in at 250 MHz, they need a bus 384 bits wide. NBL!
At Moore's Law-like rates (a factor of 10 in 5 years), even if
the hardware they have today is 80 times more powerful than
what we use now, it will take them 20 years before they can do
the frames we do today in real time. And 20 years from now, Pixar
won't be even remotely interested in TS2-level images, and I'll be
retired, sitting on the front porch and picking my banjo, laughing
at the same press release, recycled by NVIDIA's heirs and assigns.
--
Tom Duff. Early exceptions eclipse eventual essentials.
Stephen H. Westin
> On 28 Apr 2000 10:30:50 -0400, westin*nos...@graphics.cornell.edu
> (Stephen H. Westin) wrote:
>
> [snip]
>
> >
> >Yes. At least some sort of subset. SGI is working on it, and will be
> >presenting a paper at SIGGRAPH.
> In the latest talk that John Carmack (Quake) gave, he was talking
> about eventually hardware-accelerating a reasonable subset of
> Renderman shader functionality.
I'm not familiar with the particular limitations of what SGI is doing,
so I was being conservative. See
<http://reality.sgi.com/blythe/sig99/shading99/course_slides/progshading/sld004.htm>
for a very rough (and probably outdated) explanation.
> At the same time, MS' Directx8 is going to feature per-vertex and
> per-pixel shaders, and I'm assuming that the next generation of video
> cards will support them with hardware acceleration.
The SGI people, as one might expect, have some objections to that
approach. Probably the most fundamental is that hardware is designed
to do things in predictable clock cycles; sticking some bit of
arbitrary user-written code in the middle of that is likely to slow
things down in a very bad way, not to mention buying debugging
nightmares. I think the MS approach to this problem is to limit the
shader severely (no branching, only 128 instructions in a shader,
etc.), which kinda loses the point of programmable shaders. SGI's
approach is to put the programmable shading on top, basically calling
OpenGL-like functions. This means that hardware upgrades for
programmable shading performance are likely to benefit even those who
live on Gouraud-shaded triangles.
Anyway, there's some discussion at
<http://www.gamasutra.com/features/20000329/gfx_01.htm>.
Eric Haines recommends searching for "Akeley" in the second page of
the article.
> Good times ahead for realtime graphics, I think...
Maybe. There's a bit of upheaval, but vendors seem to be bailing out
(S3, Intergraph). The perception seems to be that 3D graphics hardware
is a hard way to make a buck.
Allen McPherson
> `Pixar-level animation' runs about 8 hundred thousand times slower than
> real-time
> on our renderfarm cpus. (I'm guessing. There's about 1000 cpus in
> the renderfarm and I guess we could produce all the frames in TS2 in
> about 50 days of renderfarm time. That comes to 1.2 million cpu hours
> for a 1.5 hour movie. That lags real time by a factor of 800,000.)
I'm curious. Obviously, real-time TS2 frame generation is
very difficult, especially given the required data rates you
provided. On the other hand, would it be useful to use this
technology to preview shaders, different animation scenarios,
develop new shading algorithms, etc? [on lower resolution
models and image resolutions of course]
Also, rather than one on every desk, what about one in each of
your 1000+ nodes of the render farm? We work in very different
domains, but we're looking at building just such a system (though
only on 32-64 nodes for now).
--
Allen L. McPherson Member Holstein Aerobatic Club
Los Alamos National Laboratory Scientific Viz / Advanced Computing Lab
Box 1663 Group:CIC-ACL MS:B287 mcph...@lanl.gov
Los Alamos, NM 87545 Voice: (505) 665-6548 Fax: (505) 665-4939
[Personal mail to: allen.m...@bigfoot.com]
Tom Duff
> I'm curious. Obviously, real-time TS2 frame generation is
> very difficult, especially given the required data rates you
> provided. On the other hand, would it be useful to use this
> technology to preview shaders, different animation scenarios,
> develop new shading algorithms, etc? [on lower resolution
> models and image resolutions of course]
We certainly use 3D accelerators (SGI rather than NVIDIA) to preview
animation. Until you can compile shading language programs to run on them,
they won't be much use for shading and lighting.
> Also, rather than one on every desk, what about one in each of
> your 1000+ nodes of the render farm? We work in very different
> domains, but we're looking at building just such a system (though
> only on 32-64 nodes for now).
3D accelerators mostly don't do anyting we're interested in doing a lot of.
Of the 1.2 million hours of CPU time that goes into making a set of TS2
frames, about 1.1 million hours is devoted to executing shading language
code, for which NVIDIA's cards are essentially no help at all. If they could
cache texture off a several-gigabyte UNIX filesystem and pull filtered
texture samples at arbitrary coordinates out at the rates they advertise,
they might be some use, since I think about half of the time we spend in
shading is devoted to sampling texture maps. But note that by Ahmdahl's
law, if their boards were infinitely fast, we'd stilly only see a 50%
rendering speed-up.
--
Tom Duff. Some sort of background check is in order.
Thad Beier
>
> 3D accelerators mostly don't do anyting we're interested in doing a lot of.
> Of the 1.2 million hours of CPU time that goes into making a set of TS2
> frames, about 1.1 million hours is devoted to executing shading language
> code, for which NVIDIA's cards are essentially no help at all. If they could
> cache texture off a several-gigabyte UNIX filesystem and pull filtered
> texture samples at arbitrary coordinates out at the rates they advertise,
> they might be some use, since I think about half of the time we spend in
> shading is devoted to sampling texture maps. But note that by Ahmdahl's
> law, if their boards were infinitely fast, we'd stilly only see a 50%
> rendering speed-up.
>
> --
> Tom Duff. Some sort of background check is in order.
You know, it's always nice to see the real numbers; it grinds hype
against the stone of reality; and shows the fluff that it really is.
50% of the time sampling textures -- that's an amazing number; and
while it is completely believable, and something that I should have
been able to figure out ab initio; I was unaware what a huge part
of rendering this was.
It's funny, rendering used to be about hidden-surface calculation;
then for a while there was an approximate balance between hidden
surface and shading, and now it's all shading -- and likely to
stay that way.
I'm sure people at Pixar are working on this; but I don't recall
seeing articles on high-speed texture filtering. It actually does
seem like something that would respond well to hardware assist;
I have to believe that texture accesses will cache relatively well;
that nearby pixels will use nearby regions of a map -- so while
you'll have to potentially read gigabytes of textures every frame
into this hypothetical texture-hardware, you should be able to
do that relatively efficiently.
Alternatively, I'll be thinking about ways of filtering textures
more quickly in software. Clearly this is something that the
MMX and SSE new instructions could help with; makes me almost
want to start programming in assembly again.
And of course, custom hardware is much more expensive that commodity
hardware; and unless you were going to be making thousands of these
boards it probably doesn't make any sense. Of course, Pixar's
render farm does have a thousand machines or so...
thad
Mark VandeWettering
>
> Tom Duff wrote:
> > 3D accelerators mostly don't do anyting we're interested in doing a lot of.
> > Of the 1.2 million hours of CPU time that goes into making a set of TS2
> > frames, about 1.1 million hours is devoted to executing shading language
> > code, for which NVIDIA's cards are essentially no help at all. If they could
> > cache texture off a several-gigabyte UNIX filesystem and pull filtered
> > texture samples at arbitrary coordinates out at the rates they advertise,
> > they might be some use, since I think about half of the time we spend in
> > shading is devoted to sampling texture maps. But note that by Ahmdahl's
> > law, if their boards were infinitely fast, we'd stilly only see a 50%
> > rendering speed-up.
> >
> > --
> > Tom Duff. Some sort of background check is in order.
>
> You know, it's always nice to see the real numbers; it grinds hype
> against the stone of reality; and shows the fluff that it really is.
Tom has a way of deflating stuff like this. :-)
> 50% of the time sampling textures -- that's an amazing number; and
> while it is completely believable, and something that I should have
> been able to figure out ab initio; I was unaware what a huge part
> of rendering this was.
>
> It's funny, rendering used to be about hidden-surface calculation;
> then for a while there was an approximate balance between hidden
> surface and shading, and now it's all shading -- and likely to
> stay that way.
I suspect that you are right. It has changed significantly. When I began
at Pixar a decade ago, we thought that the Reyes pipeline was relatively
balanced between the geometric calculations (splitting and dicing), shading,
and sampling/filtering. By the time Toy Story came out, we knew that shading
had shifted to #1, and that prompted a vast number of improvements in
RenderMan just to make Toy Story possible. Bug's Life was worse, and the
trend continues to accelerate. If we hadn't begun to use more depth of
field (which is hider intensive), we'd be entirely dominated by shading
now.
> I'm sure people at Pixar are working on this; but I don't recall
> seeing articles on high-speed texture filtering. It actually does
> seem like something that would respond well to hardware assist;
> I have to believe that texture accesses will cache relatively well;
> that nearby pixels will use nearby regions of a map -- so while
> you'll have to potentially read gigabytes of textures every frame
> into this hypothetical texture-hardware, you should be able to
> do that relatively efficiently.
Our renderer utilized texture map caching to perform most of the
optimizations you describe. Again, if hardware were infinitely
fast for texture mapping, you could still only get a 50% speedup,
and you have to build the hardware. This prevents you from quickly
adopting to the next generation of 2x faster hardware in 18 months
as well.
> Alternatively, I'll be thinking about ways of filtering textures
> more quickly in software. Clearly this is something that the
> MMX and SSE new instructions could help with; makes me almost
> want to start programming in assembly again.
The portability of prman has always been more valuable than coding
to any particular platform. Besides, Sparcs don't have MMX instructions.
:-)
> And of course, custom hardware is much more expensive that commodity
> hardware; and unless you were going to be making thousands of these
> boards it probably doesn't make any sense. Of course, Pixar's
> render farm does have a thousand machines or so...
Yes, a thousand machines that are off the shelf commodity items.
Mark
>
> thad
--
Mark T. VandeWettering Telescope Information (and more)
Email: <ma...@pixar.com> http://raytracer.org
Eric Antanavich
other more expensive system
at
http://riva3d.com/geforce2/cad2.htm
"Skint" <sibunks@hotmaildotcom.> wrote in message
news:39099210...@news.ntlworld.com...
>
> To quote Nvidias website
>
> "Achieving Pixar-level animation in real-time has been an industry
> dream for years," explains Jen-Hsun Huang, president and CEO at
> NVIDIA. "With twice the performance of the GeForce 256 and per-pixel
> shading technology, the GeForce2 GTS is a major step toward achieving
> that goal."
>
>
> Does this mean were going to be able to render in real time soon? Any
> chance of shading language bein made available for OpenGL? :o)
>
> I'm guessing per pixel shading should at least give realtime phong
> illumination for the first time - am I right??
>
> Simon
Bjorke
Mark VandeWettering <ma...@pixar.com> wrote:
> Thad Beier wrote:
> > I'm sure people at Pixar are working on this; but I don't recall
>
> Our renderer utilized texture map caching to perform most of the
This being the case, the size of the per-frame texture load seems just
as salient as the size of the RIB itself. 100MB? 800MB? 10MB? I
personally suspect that our production is even more texture-intensive
that Bugs or TS2, so it's a topic of great interest to me.
Are there any big dropoff numbers to avoid with texture load versus
texture memory size? (other than fitting the textures into memory
entirely)? Say, 8x texture memory or somewhere, where the performance
takes a dip? Do any of those targets slide around much depending upon
the speed of disk service, in any way that might be disproportionate to
the raw access speed itself?
How about soft shadows? I would think they take a big access hit. Is
there any way to prioritize certain textures to have a prefered place in
the caching?
--
kb
LT Supv
Final Fantasy
http://www.finalfantasy.com/
Sent via Deja.com http://www.deja.com/
Before you buy.
Larry Gritz
>In article <390E036D...@pixar.com>,
>This being the case, the size of the per-frame texture load seems just
>as salient as the size of the RIB itself. 100MB? 800MB? 10MB? I
>personally suspect that our production is even more texture-intensive
>that Bugs or TS2, so it's a topic of great interest to me.
>
>Are there any big dropoff numbers to avoid with texture load versus
>texture memory size? (other than fitting the textures into memory
>entirely)? Say, 8x texture memory or somewhere, where the performance
>takes a dip? Do any of those targets slide around much depending upon
>the speed of disk service, in any way that might be disproportionate to
>the raw access speed itself?
I have not yet seen a production that PRMan can't render efficiently
with a texture cache of 10-20 Mb.
It's easy to test -- generate what you think is a texture-heavy RIB
file, and put this in the options section:
Option "limits" "texturememory" [10000]
Render, time it, look at the stats. Then try:
Option "limits" "texturememory" [20000]
You are then comparing a 10Mb cache to a 20 Mb cache. If the timings
and texture stats are very similar, then you're getting no additional
benefit to the bigger cache and can stick to something in the 10Mb
range. If you see a big difference, try again with 30Mb, and so on,
until you clearly see that you've hit the cache size that is optimal.
I strongly suspect that no matter how much texture you actually use,
you will need no more than a fixed 20Mb or so of texture memory.
The same option works in more or less the same way for BMRT (remember,
though, that the cache only really works with tiled textures made by
mkmip, not with ordinary scanline TIFF files). Dunno about RDC or
Siren.
-- lg
--
Larry Gritz Pixar Animation Studios
l...@pixar.com Richmond, CA
Rick LaMont
> The same option works in more or less the same way for BMRT
> (remember, though, that the cache only really works with tiled
> textures made by mkmip, not with ordinary scanline TIFF files).
> Dunno about RDC or Siren.
The "texturememory" option is supported by RenderDotC. The texture
cache even works with ordinary strip and scanline oriented TIFF, but is
optimized for mip-maps created by texdc:
http://www.dotcsw.com/doc/options.html#texturememory
RDC has an additional option called "openmaps". It controls the number
of texture files that are kept open in case they are referenced again:
http://www.dotcsw.com/doc/options.html#openmaps
Each option controls the size of a Least Recently Used (LRU) cache.
Rick LaMont
Dot C Software, Inc.
http://www.dotcsw.com/
--
Free audio & video emails, greeting cards and forums
Talkway - http://www.talkway.com - Talk more ways (sm)
Mark VandeWettering
> This being the case, the size of the per-frame texture load seems just
> as salient as the size of the RIB itself. 100MB? 800MB? 10MB? I
> personally suspect that our production is even more texture-intensive
> that Bugs or TS2, so it's a topic of great interest to me.
We find that reasonably sized texture map caches (say 10-20 mbytes)
seldom produce additional gains when expanded beyond this, even in our
most aggressively texture mapped scenes. This comes from a couple of
causes...
a) Because prman is rather careful to compute filter sizes and makes pervasive
use of mipmaps, it often only accesses smaller prefiltered versions of the
textures.
b) locality is preserved because grids are shaded simultaneously. This helps
prevent texture thrashing, especially when large numbers of textures are used
on a primitive simultaneously.
Mark
Bjorke
Mark VandeWettering <ma...@pixar.com> wrote:
> a) Because prman is rather careful to compute filter sizes and makes pervasive
> use of mipmaps, it often only accesses smaller prefiltered versions of the
> textures.
Does this gain also come across when accessing single channels of
multichannel maps? (I ask this because texture artists usually don't
know anything about filtering, and often save much deeper images than
are necessary -- should I really care about policing that, other than
for the sake of disk space used? Or is it not harmful to render/texture-
access times?)
> b) locality is preserved because grids are shaded simultaneously. This helps
> prevent texture thrashing, especially when large numbers of textures are used
> on a primitive simultaneously.
So would a fair corollary be: "detailed polygonal data + heavy texture
mapping is the worst case"? (I guess it could be worse -- the textures
could be accessed across the network)?
Matt Pharr
Bjorke <bjo...@botzilla.com> writes:
> > Mark VandeWettering <ma...@pixar.com> wrote:
> > a) Because prman is rather careful to compute filter sizes and makes
> > pervasive use of mipmaps, it often only accesses smaller prefiltered
> > versions of the textures.
>
> Does this gain also come across when accessing single channels of
> multichannel maps?
This I don't know off hand, but I suspect that the implementation that
would be most efficient would store textures as RGBRGB... rather than
RRR.. GGG.. BBB.. This way, in the usual case where all three channels of a
texel are used, a maximum of only one I/O operation is needed to read the
texel if it's not in the cache.
> > b) locality is preserved because grids are shaded simultaneously. This
> > helps prevent texture thrashing, especially when large numbers of
> > textures are used on a primitive simultaneously.
>
> So would a fair corollary be: "detailed polygonal data + heavy texture
> mapping is the worst case"? (I guess it could be worse -- the textures
> could be accessed across the network)?
That's definitely something of a worst case, though not so much from the
texture angle. Since prman tends to shade with a fair amount of spatial
locality (i.e. it tends to shade primitives that are close spatially to
just previously-shaded primitives), and since 3D spatial locality tends to
have a pretty good correlation with texture-space locality, I'd expect the
texture cache to perform well even with detailed polygonal data.
What kills you with polygonal data is that you end up having really small
grids, so shading is a lot less efficient--both since there's much less of
a win from uniform stuff, and since the general shader interpreter overhead
is amortized over many fewer shaded points.
Texture access over the network won't necessarily totally kill you; again,
since only tiles surrounding regions of the texture that are accessed are
being loaded into memory, there's a counting argument similar to the one
that explains why texture tiling/caching works that says that network
traffic for may not be too bad. (Though obviously a x-hundred machine
render farm, all getting textures from a single fileserver is going to have
problems.) Option "statistics" "endofframe" [2] gives some statistics
about how much I/O the texture cache did and how long that took, if I
remember correctly.
-matt
--
Matt Pharr | m...@graphics.stanford.edu <URL:http://graphics.stanford.edu/~mmp>
===============================================================================
In a cruel and evil world, being cynical can allow you to get some
entertainment out of it. --Daniel Waters
Bjorke
Matt Pharr <m...@graphics.stanford.edu> wrote:
>
> This I don't know off hand, but I suspect that the implementation that
> would be most efficient would store textures as RGBRGB... rather than
> RRR.. GGG.. BBB.. This way, in the usual case where all three channels
of a
> texel are used, a maximum of only one I/O operation is needed to read
the
> texel if it's not in the cache.
I would think so too, but it's worth asking just in case...
> That's definitely something of a worst case, though not so much from
the
> texture angle. Since prman tends to shade with a fair amount of
spatial
> locality (i.e. it tends to shade primitives that are close spatially
to
> just previously-shaded primitives), and since 3D spatial locality
tends to
> have a pretty good correlation with texture-space locality, I'd expect
the
> texture cache to perform well even with detailed polygonal data.
>
> What kills you with polygonal data is that you end up having really
small
> grids,
The "small grids" problem is exactly why I consider it a worst-case.
What's unknown (to me) is how much additional baggage each texture might
carry around to each grid -- if each grid gets its own cache data and
lots of polys == lots of grids all in the same bucket, that could be.. a
problem. We've seen some landscape renderings here that have had
outrageous memory demands -- running into two-digit GBytes -- and sure
enough, some buckets had tons of tiny, distant, texture-mapped (and
displaced, heh) polygons.
> problems.) Option "statistics" "endofframe" [2] gives some statistics
> about how much I/O the texture cache did and how long that took, if I
> remember correctly.
That's [3]
Larry Gritz
Matt Pharr <m...@graphics.stanford.edu> wrote:
>
>This I don't know off hand, but I suspect that the implementation that
>would be most efficient would store textures as RGBRGB... rather than
>RRR.. GGG.. BBB.. This way, in the usual case where all three channels of a
>texel are used, a maximum of only one I/O operation is needed to read the
>texel if it's not in the cache.
BMRT does this (store RGBRGBRGB), but at the cost of extra memory
if you're only using one channel of the texture.
PRMan stores channels separately (i.e., RRR is one tile, GGG for the
same pixels is another time). No wasted effort if you only access
one of the channels, but I guess if you access them all there's
probably some extra price (I think it's small, though).
Larry Gritz
>
>The "small grids" problem is exactly why I consider it a worst-case.
>What's unknown (to me) is how much additional baggage each texture might
>carry around to each grid -- if each grid gets its own cache data and
No, it doesn't work that way at all. The cache is of texture
file tiles. It's not tied to the grids in any way.
Stephen H. Westin
> Bjorke <bjo...@botzilla.com> writes:
<snip>
> > So would a fair corollary be: "detailed polygonal data + heavy texture
> > mapping is the worst case"? (I guess it could be worse -- the textures
> > could be accessed across the network)?
>
> That's definitely something of a worst case, though not so much from the
> texture angle. Since prman tends to shade with a fair amount of spatial
> locality (i.e. it tends to shade primitives that are close spatially to
> just previously-shaded primitives), and since 3D spatial locality tends to
> have a pretty good correlation with texture-space locality, I'd expect the
> texture cache to perform well even with detailed polygonal data.
Aren't bets off on environment maps? I could imagine a heavily
displacement-mapped reflective surface that would destroy locality of
access to the environment map. I suppose that's only 6 maps maximum,
and quite possibly at tolerable resolution (say 512) if low-res
reflections are tolerable. But say, 2K faces on a cube map could
easily get you beyond 50MB. But then, I suppose, each grid would tend
to have a limited range of normal directions, and displacement mapping
might not disturb that enough to demand all six faces at once...
<snip>
Larry Gritz
Stephen H. Westin <westin*nos...@graphics.cornell.edu> wrote:
>
>Aren't bets off on environment maps? I could imagine a heavily
>displacement-mapped reflective surface that would destroy locality of
>access to the environment map.
No! That's the beauty of MIP-maps. Remember that we're computing
derivatives as we go, so a heavily displaced grid will not only want
to sample many directions, but will effectively be sampling it with
very large blurs, since the directions will vary greatly between
adjacent grid points. So it will sample tiles from low-res levels of
the mipmap, with each tile covering a larger solid angle, pretty
much preserving the number of texture tiles read and texels filtered
no matter how spread out the rays get.
This is also why environment mapping is so much cheaper than ray
tracing, especially for large blurs or roughly displaced surfaces.
The environment map is effectively fixed cost in both time and memory,
regardless of blur amount. Ray tracing the reflections grows in cost
with the *square* of the blur size (assuming you want to maintain
constant noise level), and rapidly destroys your memory locality to
boot.
Rick LaMont
> PRMan stores channels separately (i.e., RRR is one tile, GGG for the
> same pixels is another time). No wasted effort if you only access
> one of the channels, but I guess if you access them all there's
> probably some extra price (I think it's small, though).
In PRMan's level 3 statistics, there's a column called "SAME" defined
as "the percentage of all pixel accesses which were found in the
'current' (most recently accessed) texture tile." If tiles are RRR and
textures were accessed in RGBRGB order, then SAME would be 0%,
right? Does PRMan access textures in RRR, GGG order?
Larry Gritz
Rick LaMont <lam...@lava.net> wrote:
>In PRMan's level 3 statistics, there's a column called "SAME" defined
>as "the percentage of all pixel accesses which were found in the
>'current' (most recently accessed) texture tile." If tiles are RRR and
>textures were accessed in RGBRGB order, then SAME would be 0%,
>right?
Don't forget, you're working with grids. So it's RRR for all points
on the grid (high chance of them all being the same tile), then GGG
for all points on the grid (definitely different tile than the RRR's,
but same as each other), etc.
Rick LaMont
> Don't forget, you're working with grids. So it's RRR for all points
> on the grid (high chance of them all being the same tile)
Okay. Given this line of SL:
c = color texture("logo");
RDC (conceptually) does this:
for (g in grid)
for (i = 0 to 2)
g->c[i] = texture("logo"[i]);
Whereas PRMan inverts the loops:
for (i = 0 to 2)
for (g in grid)
g->c[i] = texture("logo"[i]);
Colors seem like small, atomic types. It just surprised me that PRMan
takes three passes over the grid, one per color channel. To each his
own...
Adam
Someone mentioned resolutions of maps.. I'm curious as to what resolution
most people make their texture maps for film res characters?
-Adam
mohd.ta...@gmail.com
I am not even sure if you are still following this :)
I read about your original rebuttal to NVIDIA's marketing hype 16 years ago and for some reason, I wanted to hear your thoughts about modern 3D accelerators with programmable shading languages.
How would you compare a modern accelerator in the following context:
1) Replacing/complimenting a render farm from 16 years ago. Do you think a modern graphics card begins to approach the original promise from NVIDIA (comparing against a render farm from 2000).
2) A modern graphics card vs a modern render farm
I would really love to hear your thoughts, especially, what needs to change/improve, how much more complex shaders in offline renderers are vs a modern graphics card etc.
Thanks,
On Monday, May 1, 2000 at 12:00:00 AM UTC-7, Tom Duff wrote:
> Allen McPherson wrote:
> > I'm curious. Obviously, real-time TS2 frame generation is
> > very difficult, especially given the required data rates you
> > provided. On the other hand, would it be useful to use this
> > technology to preview shaders, different animation scenarios,
> > develop new shading algorithms, etc? [on lower resolution
> > models and image resolutions of course]
>
> We certainly use 3D accelerators (SGI rather than NVIDIA) to preview
> animation. Until you can compile shading language programs to run on them,
> they won't be much use for shading and lighting.
>
> > Also, rather than one on every desk, what about one in each of
> > your 1000+ nodes of the render farm? We work in very different
> > domains, but we're looking at building just such a system (though
> > only on 32-64 nodes for now).
>