 | | | Elliptical filtering | Elliptical filtering 2005-05-31 - By Brad Friedman
Back
That would make sense if its using pyramid maps as a base for its
lookup. Once you read the top level of the map, you can't get any more
optimization out of it. So if the map scrolls 20 times in the same
pixel, its 20 lookups. 40 times, 40 lookups. No more help from the
pyramid. Back to brute force sampling.
-brad
kim aldis wrote:
>I'm going from memory here but I recall that with elliptical filtering
>render times can vary wildly dependant upon the amound of compression of the
>visible image in screen space. I seem to remember that, for example, on
>landscapes the render time would go through the roof toward the horizon of a
>textured landmass.
>
>
>kim@(protected)
>kim@(protected)
>
>
>
>
>
>>-- --Original Message-- --
>>From: owner-xsi@(protected)
>>[mailto:owner-xsi@(protected)] On Behalf Of Bernard Lebel
>>Sent: 31 May 2005 22:09
>>To: XSI@(protected)
>>Subject: Re: Elliptical filtering
>>
>>Brad: elliptical filtering is necessary to take advantage of
>>the multi-resolution of the pyramidal map file. Otherwise the
>>maximum resolution is always the one lookedup by mental ray
>>(thus more memory).
>>
>>Alan: I also suspect network issue, although as you said,
>>such a dramatic increase in render time is quite strange.
>>
>>
>>Bernard
>>
>>
>>On 5/31/05, Alan Jones <skyphyr@(protected)> wrote:
>>
>>
>>>Maybe with that render time a lot of it's reading the files off the
>>>disk? Pulling the .pic into memory then uncompressing it
>>>
>>>
>>within memory
>>
>>
>>>may be signicantly faster. Though I wouldn't expect it to
>>>
>>>
>>make such a
>>
>>
>>>huge difference.
>>>
>>>That's the only guess that comes to mind though sorry.
>>>
>>>Cheers,
>>>
>>>Alan.
>>>
>>>On 5/31/05, Brad Friedman <xsibrad@(protected)> wrote:
>>>
>>>
>>>>This is a question more than an answer:
>>>>
>>>>Why convert to pyramid if you're going to use elliptical
>>>>
>>>>
>>filtering?
>>
>>
>>>>I thought the two were entirely different types of
>>>>
>>>>
>>filters. Or can
>>
>>
>>>>elliptical filtering take advantage of a pyramid texture?
>>>>
>>>>-brad
>>>>
>>>>Bernard Lebel wrote:
>>>>
>>>>
>>>>
>>>>>Hi,
>>>>>
>>>>>I am baffled at something. I have a scene with rather large
>>>>>textures (3500x3500 and higher). In Pic format, it
>>>>>
>>>>>
>>renders in 45 seconds.
>>
>>
>>>>>So I'm looking to save render time, and memory while
>>>>>
>>>>>
>>we're at it,
>>
>>
>>>>>so I convert textures to pyramidal map float files (imf_copy -p
>>>>>[...] map rgba_fp).
>>>>>Then I turn on elliptical filtering, set the Maximum Pixels for
>>>>>Minimum Radius to a low value 1.3, because higher than that is
>>>>>generally not necessary.
>>>>>
>>>>>In the past, I got much faster render times. However
>>>>>
>>>>>
>>right now the
>>
>>
>>>>>render time explodes: it's at least 5 times longer than
>>>>>
>>>>>
>>with the
>>
>>
>>>>>Pic version.
>>>>>
>>>>>Any idea?
>>>>>
>>>>>
>>>>>Thanks
>>>>>Bernard
>>>>>---
>>>>>Unsubscribe? Mail Majordomo@(protected) with the
>>>>>
>>>>>
>>following text
>>
>>
>>>>>in
>>>>>body:
>>>>>unsubscribe xsi
>>>>>
>>>>>
>>>>---
>>>>Unsubscribe? Mail Majordomo@(protected) with the
>>>>
>>>>
>>following text in body:
>>
>>
>>>>unsubscribe xsi
>>>>
>>>>
>>>>
>>>---
>>>Unsubscribe? Mail Majordomo@(protected) with the
>>>
>>>
>>following text in body:
>>
>>
>>>unsubscribe xsi
>>>
>>>
>>>
>>---
>>Unsubscribe? Mail Majordomo@(protected) with the following
>>text in body:
>>unsubscribe xsi
>>
>>
>>
>>
>
>---
>Unsubscribe? Mail Majordomo@(protected) with the following text in body:
>unsubscribe xsi
>
>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859 (See http://ISO-8859.ora-code.com)-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
That would make sense if its using pyramid maps as a base for its
lookup. Once you read the top level of the map, you can't get any more
optimization out of it. So if the map scrolls 20 times in the same
pixel, its 20 lookups. 40 times, 40 lookups. No more help from the
pyramid. Back to brute force sampling.<br>
<br>
-brad<br>
<br>
kim aldis wrote:
<blockquote
cite="mid20050531215218.E54A6E00025E@(protected)"
type="cite">
<pre wrap="">I'm going from memory here but I recall that with elliptical
filtering
render times can vary wildly dependant upon the amound of compression of the
visible image in screen space. I seem to remember that, for example, on
landscapes the render time would go through the roof toward the horizon of a
textured landmass.
<a class="moz-txt-link-abbreviated" href="mailto:kim@(protected)">kim@(protected)
.com</a>
<a class="moz-txt-link-abbreviated" href="mailto:kim@(protected)">kim@(protected)
.org.uk</a>
</pre>
<blockquote type="cite">
<pre wrap="">-- --Original Message-- --
From: <a class="moz-txt-link-abbreviated" href="mailto:owner-xsi@(protected)"
>owner-xsi@(protected)</a>
[<a class="moz-txt-link-freetext" href="mailto:owner-xsi@(protected)">mailto
:owner-xsi@(protected)</a>] On Behalf Of Bernard Lebel
Sent: 31 May 2005 22:09
To: <a class="moz-txt-link-abbreviated" href="mailto:XSI@(protected)">XSI
@(protected)</a>
Subject: Re: Elliptical filtering
Brad: elliptical filtering is necessary to take advantage of
the multi-resolution of the pyramidal map file. Otherwise the
maximum resolution is always the one lookedup by mental ray
(thus more memory).
Alan: I also suspect network issue, although as you said,
such a dramatic increase in render time is quite strange.
Bernard
On 5/31/05, Alan Jones <a class="moz-txt-link-rfc2396E" href="mailto:skyphyr
@(protected)"><skyphyr@(protected)></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Maybe with that render time a lot of it's reading the files
off the
disk? Pulling the .pic into memory then uncompressing it
</pre>
</blockquote>
<pre wrap="">within memory
</pre>
<blockquote type="cite">
<pre wrap="">may be signicantly faster. Though I wouldn't expect it to
</pre>
</blockquote>
<pre wrap="">make such a
</pre>
<blockquote type="cite">
<pre wrap="">huge difference.
That's the only guess that comes to mind though sorry.
Cheers,
Alan.
On 5/31/05, Brad Friedman <a class="moz-txt-link-rfc2396E" href="mailto:xsibrad
@(protected)"><xsibrad@(protected)></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">This is a question more than an answer:
Why convert to pyramid if you're going to use elliptical
</pre>
</blockquote>
</blockquote>
<pre wrap="">filtering?
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">I thought the two were entirely different types of
</pre>
</blockquote>
</blockquote>
<pre wrap="">filters. Or can
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">elliptical filtering take advantage of a pyramid texture?
-brad
Bernard Lebel wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi,
I am baffled at something. I have a scene with rather large
textures (3500x3500 and higher). In Pic format, it
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">renders in 45 seconds.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">So I'm looking to save render time, and memory while
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">we're at it,
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">so I convert textures to pyramidal map float files (imf
_copy -p
[...] map rgba_fp).
Then I turn on elliptical filtering, set the Maximum Pixels for
Minimum Radius to a low value 1.3, because higher than that is
generally not necessary.
In the past, I got much faster render times. However
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">right now the
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">render time explodes: it's at least 5 times longer than
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">with the
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Pic version.
Any idea?
Thanks
Bernard
---
Unsubscribe? Mail <a class="moz-txt-link-abbreviated" href="mailto:Majordomo
@(protected)">Majordomo@(protected)</a> with the
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">following text
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">in
body:
unsubscribe xsi
</pre>
</blockquote>
<pre wrap="">
---
Unsubscribe? Mail <a class="moz-txt-link-abbreviated" href="mailto:Majordomo
@(protected)">Majordomo@(protected)</a> with the
</pre>
</blockquote>
</blockquote>
<pre wrap="">following text in body:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">unsubscribe xsi
</pre>
</blockquote>
<pre wrap="">---
Unsubscribe? Mail <a class="moz-txt-link-abbreviated" href="mailto:Majordomo
@(protected)">Majordomo@(protected)</a> with the
</pre>
</blockquote>
<pre wrap="">following text in body:
</pre>
<blockquote type="cite">
<pre wrap="">unsubscribe xsi
</pre>
</blockquote>
<pre wrap="">---
Unsubscribe? Mail <a class="moz-txt-link-abbreviated" href="mailto:Majordomo
@(protected)">Majordomo@(protected)</a> with the following
text in body:
unsubscribe xsi
</pre>
</blockquote>
<pre wrap=""><!---->
---
Unsubscribe? Mail <a class="moz-txt-link-abbreviated" href="mailto:Majordomo
@(protected)">Majordomo@(protected)</a> with the following text in body:
unsubscribe xsi
</pre>
</blockquote>
<br>
</body>
</html>
|
|
|