Hi all,

I have a large, detailed kaleidoscopic scene I would like to render large enough
to print out and fill an entire wall of my apartment at 150 DPI at least.  This
means I would be working with at least 18000x18000 images, so I am trying to
break up the output into chunks and use a batch file.  Start_Row, End_Row, etc.
are almost what I want, but despite only rendering a portion of the scene,
POV-Ray still seems to allocate a buffer for the entire output size, and it
saves a full-size image that is only rendered in part.  Is there any way to get
it to only allocate memory/save image to the restricted window size?

++automated rendering in chunks would be a really nice feature to have!

Thanks!
Andy

Post a reply to this message

Le 03/01/2012 04:09, Andy a écrit :
> Hi all,
> 
> I have a large, detailed kaleidoscopic scene I would like to render large enough
> to print out and fill an entire wall of my apartment at 150 DPI at least.  This
> means I would be working with at least 18000x18000 images, so I am trying to
> break up the output into chunks and use a batch file.  Start_Row, End_Row, etc.
> are almost what I want, but despite only rendering a portion of the scene,
> POV-Ray still seems to allocate a buffer for the entire output size, and it
> saves a full-size image that is only rendered in part.  Is there any way to get
> it to only allocate memory/save image to the restricted window size?

IMHO,
short answer: no.
medium answer: not with the current versions.
long answer: Maybe... you might try to play with the camera settings to
render full images of relevant size. Notice that some camera type (like
orthographic) are ok with such manipulation, but most are not.

Rhetorical question: why don't you render a single full images at 18k x
18k once ? At least with povray 3.7RC3, it will go into a disk-buffer
while rendering and the transformation into a file-format (such as png)
will be done per line, so it's not like you would have it in memory at
once, at least in povray ?

> 
> ++automated rendering in chunks would be a really nice feature to have!

why do you need chunks ?
Aren't you thinking backward ( printing need chunks (1), so I need
povray to output chunks ? what about typing "splitting image in chunk
for poster" in a search engine ?) ?

(1): some printer's driver/interface even have a poster mode, splitting
the image in as many pages in both directions as desired... so why bother ?

To each program its purpose, IMNSHO.


-- 
Software is like dirt - it costs time and money to change it and move it
around.

Just because you can't see it, it doesn't weigh anything,
and you can't drill a hole in it and stick a rivet into it doesn't mean
it's free.

Post a reply to this message

Le_Forgeron <lef### [at] freefr> wrote:

> IMHO,
> short answer: no.
> medium answer: not with the current versions.
> long answer: Maybe... you might try to play with the camera settings to
> render full images of relevant size. Notice that some camera type (like
> orthographic) are ok with such manipulation, but most are not.

To your medium answer, I've thought about this before:  It seems like there
should be a camera type where the point location of the camera is not on the
line extending perpendicularly from the center of the "pixel grid/array."
(Sorry, I haven't reminded myself recently on the proper terminology.)  Or, to
put it another way, the "pixel grid" would still be on a plane perpendicular to
the direction vector, but offset.

If that made any sense, such a camera type would solve his problem neatly.

Charles

Post a reply to this message

Le 04/01/2012 08:15, Charles C a écrit :
> Le_Forgeron <lef### [at] freefr> wrote:
> 
>> IMHO,
>> short answer: no.
>> medium answer: not with the current versions.
>> long answer: Maybe... you might try to play with the camera settings to
>> render full images of relevant size. Notice that some camera type (like
>> orthographic) are ok with such manipulation, but most are not.
> 
> To your medium answer, I've thought about this before:  It seems like there
> should be a camera type where the point location of the camera is not on the
> line extending perpendicularly from the center of the "pixel grid/array."
> (Sorry, I haven't reminded myself recently on the proper terminology.)  Or, to
> put it another way, the "pixel grid" would still be on a plane perpendicular to
> the direction vector, but offset.
> 
> If that made any sense, such a camera type would solve his problem neatly.

Yes, it does make sense, it was implemented physically in some actual
photograph apparatus (most often used to take straight picture of front
of house & building from the corner of the street: a normal perspective
camera would end up with 2 or 3 horizon points (as in classical
painting), whereas these strange and complex apparatus would move the
picture in the focal plane, or whatever, to achieve parallel lines on
the picture for the parallel in reality which are also on a parallel
plan to the picture... The lens is mobile in many way (translate &
rotate (tilt)), the diaphragm might be considered fixed, and the picture
is taken on mobile plate (which also translate & tilt...), all with
gussets/bellows to keep the inside dark.

Now... to code that for povray... some camera types (orthographic &
spherical, even maybe some cylindrical) are just "a tuning away" from
your need: no need to change the code, just change the parameter such as
location, up&right for othographic, look_at & angle for spherical.

The perspective type need specific code and new properties to achieve
that effect. Same would go for panoramic & ultrawide_angle, and at least
2 of the cylindrical types.

I guess you're interested only in the perspective one, right ?

Post a reply to this message

On 4-1-2012 9:49, Le_Forgeron wrote:

> Now... to code that for povray... some camera types (orthographic&
> spherical, even maybe some cylindrical) are just "a tuning away" from
> your need: no need to change the code, just change the parameter such as
> location, up&right for othographic, look_at&  angle for spherical.
>

Doctor John wrote the following code (2005). Is that what you need?

Thomas

//start code
// Persistence of Vision SDL include file
// Description: A macro to simulate lens movements in architectural scenes
//		Helps prevent the "falling verticals syndrome"
// Author: John Guthkelch (Doctor John) <doc### [at] linuxmailorg>
// Version 2.0 Released September 2005
// Changes: 1. Improved warning so that camera automatically reverts to 
default
//	    type if insane values are given for CamPos and/or CamLook
//	    2. Corrected silly mathematical error in vertical scaling.This
//	    is now correct so switch has been taken out.

/***********************************************************************
Don't forget to switch off Vista Buffers by using -uv on the command line
or Vista_Buffer=0 in your .ini file before attempting to render your image
***********************************************************************/

#macro FieldCam (CP, CL)
	#local CD=CL-CP;
	#if (CD.x!=0 | CD.z!=0) // Note: That's a Boolean OR not an uppercase i
				// or a lowercase L!
		#local HypoXZ=sqrt(pow(CD.x, 2)+pow(CD.z, 2));
		#local VCorr=pow(vlength(CD), 2)/pow(HypoXZ, 2);
		#local CosThetaX=CD.x/HypoXZ;
		#local CosThetaZ=CD.z/HypoXZ;
		#if (CD.x=0)
			#local ShearX=0;
		#else
			#local ShearX=(CD.y/CD.x)*pow(CosThetaX, 2);
		#end
		#if (CD.z=0)
			#local ShearZ=0;
		#else
			#local ShearZ=(CD.y/CD.z)*pow(CosThetaZ, 2);
		#end
		#declare NoFall=transform {
			matrix <1, 0, 0, ShearX, VCorr, ShearZ, 0, 0, 1, 0, 0, 0>
		}
	#else
		#warning "Viewing vector is perpendicular to XZ-plane.\n"
		#warning "Camera changed to default type.\n"
		#declare NoFall=transform {
			matrix <1, 0, 0, 0, 1, 0, 0, 0, 1, 0, 0, 0>
		}
	#end
#end

/*********************************USAGE**************************************

#declare CamPos=<Xc, Yc, Zc>;   //Just replace <Xc,Yc,Zc> with location 
vector
#declare CamLook=<Xl, Yl, Zl>;  // -"-   -"-   <Xl,Yl,Zl> with look_at 
vector

camera {
	FieldCam (CamPos, CamLook)
	perspective
	location CamPos
	[angle Whatever] // Not essential but can be used
	[right If_you_want] // Also not essential but can be used
	transform {NoFall}
	look_at CamLook
}
****************************************************************************/
//end code

Post a reply to this message

> Hi all,
>
> I have a large, detailed kaleidoscopic scene I would like to render large enough
> to print out and fill an entire wall of my apartment at 150 DPI at least.  This
> means I would be working with at least 18000x18000 images, so I am trying to
> break up the output into chunks and use a batch file.  Start_Row, End_Row, etc.
> are almost what I want, but despite only rendering a portion of the scene,
> POV-Ray still seems to allocate a buffer for the entire output size, and it
> saves a full-size image that is only rendered in part.  Is there any way to get
> it to only allocate memory/save image to the restricted window size?
>
> ++automated rendering in chunks would be a really nice feature to have!
>
> Thanks!
> Andy
>
>

To cover a whole wall, 150 DPI is gross overkill. Most of the time, you 
only need half as much or even less, something in the 50 to 75 DPI 
range. Anyway, you won't usualy look at it from less than a few feet... 
You can then use interpolation and error diffusion type dithering if you 
wish.
It can make an image of about 640 by 480 printed at 1400 DPI, 8" by 6" 
look very smooth with absolutely no pixellisation. I know, I've done it 
a few times with excellent results.

You can render in pieces, or tiles. Use an orthographic camera, 
translate it as needed and render several smaller parts. It can be done 
automaticaly using animation.


Alain

Post a reply to this message

Le 04/01/2012 09:55, Thomas de Groot a écrit :
> 
> Doctor John wrote the following code (2005). Is that what you need?

I bow to your wits, storage capacity and skills.

(I always forgot one can apply a transform on the camera)

Post a reply to this message

On 6-1-2012 9:51, Le_Forgeron wrote:
> I bow to your wits, storage capacity and skills.
>
> (I always forgot one can apply a transform on the camera)

I try to emulate Uncle Ken  ;-)

Thomas

Post a reply to this message