 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Excellent work, William! Looking forward to your macro.
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"William Tracy" <wtr### [at] calpoly edu> wrote in message
news:47ad6383$1@news.povray.org...
> That said, I'm really only intending to use this macro for this month's
> TC-RTC stills round, and next month's animations round. The macro has
> reached a point where I think it's just about good enough for my entries.
Cool, and thanks. :)
For what it's worth, I'm about 4 days into my stills image now, so I
should be submitting soon. ;)
~Steve~
> William Tracy
> afi### [at] gmailcom -- wtr### [at] calpolyedu
>
> If we were told to parse starting *after* the supplied String, then do
> what we need to do to indicate pilot error.
> -- Laird Nelson, blogging on Java programming
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wow!
I love this one, too! Even more!
It looks very, very good!
Sven (with a wicked greedy light in the eyes)
"William Tracy" <wtr### [at] calpolyedu> schrieb im Newsbeitrag
news:47ad2f6b@news.povray.org...
> ... I don't care whether there's enough trees to call it a forest, I'm
> still calling it a forest macro ...
>
> I think the macro is almost finished--I'll post the source sometime next
> week.
>
> Actually, I now have an include file with two macros: One that plants a
> single clump of trees centered at a specified location, and one that
> populates an entire landscape by planting many clumps at random
> locations. I can mix and match the two depending on how much control I
> need over the scene.
>
> Also, the landscape planting macro takes two shape arrays now: An array
> of tree shapes, and an array of bush shapes. The bush clumps are
> centered around the tree clumps, but spread out more.
>
> While I'm posting, is anyone besides Sven interested in my landscape
> mesh generator program? I didn't originally intend to distribute the
> program, since Terragen and Geomorph are both already free and much more
> full-featured. However, if people are interested (one person does not
> count as "people") I'll try to clean up the program and put it online.
>
> --
> William Tracy
> afi### [at] gmailcom -- wtr### [at] calpolyedu
>
> Who could pollute the entire world?
> -- Nausicaa
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The final render is up on the TC-RTC
http://tc-rtc.co.uk/display/index.html
Under the title, "Systema Metropolis: In the Wild."
The code, including the tree macro, is posted to p.b.s-f.
Finally: Surprise!
How many of you saw *that* final scene coming? :-D
--
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu
One time I put my car into reverse while traveling 70 mph on the
freeway. It was a very exciting learning experience.
-- seen on Slashdot
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'm playing with this scene and huge resolutions :)
Of course, to render at super-high resolutions, tiled rendering is
needed (to distribute between computers/cores). But I can't split the
scene into tiles using the "normal method" (setting +w and +h to the
full res, and using +sc +ec +sr +er). I tried it with very high
resolutions (32768 x something) and POV-Ray crashed, or gave out of
memory error, apparently because it attempts to allocate memory for the
whole image. However, I successfully managed huge tiled renders with
zoomin.inc, where I can set +w and +h to the size of a single tile.
#include "zoomin.inc"
#macro Str(N) str(N,0,-1) #end
#declare Rows=4;
#declare Cols=4;
#macro ZoominParams(X,Y)
concat(
" +sr",Str(Y/Rows),
" +er",Str((Y+1)/Rows),
" +sc",Str(X/Cols),
" +ec",Str((X+1)/Cols)
)
#end
#declare Tile = frame_number;
#local X = mod(Tile, Cols);
#local Y = div(Tile, Cols);
Set_Zoom_Area(camera_location, camera_look_at, ZoominParams(X,Y))
Update_Camera_Zoom()
I rendered a 2048x1536 image, using 16 tiles, just for the sake of
testing. I can't really tell how much time it took, since I kept
changing some things while the tiles were being rendered, and then
re-rendered the ones that were left with old parameters.
Area lights and radiosity are disabled. I tested radiosity, and
confirmed it gets noticeable artifacts between one tile and the other.
All trees were loaded from linden-lowres5.inc, including bushes, to
decrease parse time to around 15 seconds.
I just noticed the PNG image is 5.3MB, even after optipng'ing it! JPEG
got it to 800KB while keeping more than acceptable quality. EDIT: and I
had to lower quality a bit more; I forgot how much overhead base64
causes, and the server gave a size limit error. Down to 700KB, retrying.
Post a reply to this message
Attachments:
Download 'inthewild_big.jpg' (680 KB)
Preview of image 'inthewild_big.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez nous apporta ses lumieres en ce 2008/02/13 12:11:
> I'm playing with this scene and huge resolutions :)
>
> Of course, to render at super-high resolutions, tiled rendering is
> needed (to distribute between computers/cores). But I can't split the
> scene into tiles using the "normal method" (setting +w and +h to the
> full res, and using +sc +ec +sr +er). I tried it with very high
> resolutions (32768 x something) and POV-Ray crashed, or gave out of
> memory error, apparently because it attempts to allocate memory for the
> whole image. However, I successfully managed huge tiled renders with
> zoomin.inc, where I can set +w and +h to the size of a single tile.
>
When rendering at very large dimentions, add "+d" to suppress the prevew window.
This will save memory.
--
Alain
-------------------------------------------------
I believe that banking institutions are more dangerous to our liberties than
standing armies. Already they have raised up a monied aristocracy that has
set the government at defiance. The issuing power should be taken from the
banks and restored to the people to whom it properly belongs.
Thomas Jefferson
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain escribió:
> When rendering at very large dimentions, add "+d" to suppress the prevew
> window. This will save memory.
>
With display enabled, I got an out of memory error. When using -d, I got
a crash.
zoomin will do :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> I'm playing with this scene and huge resolutions :)
On the one hand, that is really cool.
On the other hand, all the little mistakes I'd hoped nobody would notice
are now magnified (several of the machines are levitating slightly ...).
Eek!
--
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu
In Fig. 3.18 we define two local variables, four and twenty (no jokes
about blackbirds, please).
-- Jeffrey D. Ullman, _Elements of ML Programming_
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> On the other hand, all the little mistakes I'd hoped nobody would notice
> are now magnified (several of the machines are levitating slightly ...).
> Eek!
>
Hey, most people would have faked the trees at the resolution you
originally used... (fake meaning they wouldn't be meshes with individual
leaves!)
Anyway, take it as an opportunity to do those little fixes :) It could
be even more res next time:
http://stuff.povaddict.com.ar.nyud.net/inthewild_tile52-100.png
tile <5,2> (on a 10x10 grid), all trees linden-lowres5, area lights on,
radiosity off
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> Hey, most people would have faked the trees at the resolution you
> originally used... (fake meaning they wouldn't be meshes with individual
> leaves!)
I was running out of modeling time, and had the choice of trying to fake
the trees with a texture on the ground, or using (mostly) pre-modeled
trees from Povtree. normal{bumps} wasn't cutting it at this resolution,
so I used Povtree trees.
> Anyway, take it as an opportunity to do those little fixes :) It could
> be even more res next time:
What are the specs on the machine you're running this on? You've
inspired me to try a 2048x1536 RSOCP render; I'm finding that I have
more than enough memory to do it in one shot, but it is taxing my processor.
--
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu
And the Format source code tells me that *really* the indicator of an
error is whether the index has changed value or not. If it has *not*
changed value, then some of the Format class' innards assume that since
parsing didn't happen, an error must have occurred. (Pause for
Buddhist-like contemplation of this leap of logic and faith.)
-- Laird Nelson, blogging on the "dank recesses" of java.text
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
