Hi !

for a given scene the parsing takes a lot more time than rendering.

Is there a way to keep the parsed information to use with e.g. another
resolution render ?

thanks

 Andreas

Post a reply to this message

"Grobi" <and### [at] boesmanncom> wrote:
> Hi !
>
> for a given scene the parsing takes a lot more time than rendering.
>
> Is there a way to keep the parsed information to use with e.g. another
> resolution render ?

It depends on what's taking up most of the parsing time. Say you're using some
algorithm to place objects automatically, and the calculations are taking a
long time. You can save the final object positions to a data file once, then
read them back in as many times as you like. I've used this technique before,
when placing 500,000+ brick objects algorithmically. I cut down over an hour of
parsing to 20 minutes by saving the positions to a text file, then simply
reading them back in before the final render. I use this technique for saving
time when generating meshes too - by writing an .inc file that I can use
anywhere, more quickly, later on.

If this sounds like the problem, read up on the #fopen, #fclose, #write and
#read directives:

http://www.povray.org/documentation/view/3.6.1/235/

If, however, the parsing time is already due to large data files being read, I
don't know. I suspect it would be impossible, or extremely difficult.

Hope this helps

Bill

Post a reply to this message

"Grobi" <and### [at] boesmanncom> wrote:
> Is there a way to keep the parsed information to use with e.g. another
> resolution render ?

Not yet.

However, if you precompute anything, you might want to #write data to a file
(maybe "ready to rock" as an #include file)

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> "Grobi" <and### [at] boesmanncom> wrote:
> > Is there a way to keep the parsed information to use with e.g. another
> > resolution render ?
>
> Not yet.
>
> However, if you precompute anything, you might want to #write data to a file
> (maybe "ready to rock" as an #include file)



Wait, did you say yet??  Ooohh, I like the sound of that!

Actually... I was thinking about that the other day, and I thought it might be
neat to introduce a keyword 'static', which would specify that an object need
not be reparsed for animations.  Working with larger sized meshes, image_map
textures, and high resolution heightfields (greater than 10 mb) pretty much
convinced me that such a thing would be very nice.
I fondly imagine code like the following:

// code:
static height_field{
    png "MASSIVE.PNG" // 25 mb image on older, low speed IDE drive
    smooth            //  shared over a WAN connected to by dial-up.
}

// rest of scene is parsed normally for each frame

I was even thinking about how a declaration could be static and not reparsed,
but the object could still be moved:

// code:

static height_field{
    png "MASSIVE1.PNG"
    smooth
    translate <0,0,clock>
// since it is NOT reparsed, hf doesn't move as clock changes.
// instead, it simply sits where it was translated by the initial
// value of clock, when it was first parsed
}


#declare myHF =
static height_field{
    png "MASSIVE2.PNG"
    smooth
}

object{ myHF  translate <0,0,clock> }
// while myHF is not reparsed, this particular instance of myHF
// does move as clock changes, since the instantiation is parsed normally.

Of course, this got me thinking about the whole thing with images, and how they
can be used as an image_map or height_field or some other thing, and how maybe
it would be neat to have a non-object, non-rendering primitive in the form of
an image{}.
Like:

#declare myImage = image{ png "terrain.png" }

//then, later:
height_field
{
  myImage  // no need to re-read myImage
  smooth   // since it was read when it was declared
    pigment{
        image_map{ myImage }
        // could have also used it for image_pattern, etc
    }
}

// then, even later:
#declare myImage = static image{ png "myTexture.png" }


Then, I started thinking about how maybe this 'static' thing is something that
could be better implemented differently, like changing the way included files
or macros are handled (so as to prevent unnecessary file re-reading).  After
thinking that, I remembered that if you only read a file once, one could no
longer write complicated self-modifying scenes that use 3 or fewer files as
easily (not that I would condone such activities), so I stopped thinking about
these things at that point.

Anyway, as much as I like using the keyword 'static' for this, it occurs to me
that it is probably better used for (eventually) declaring permanent-yet-local
identifiers, and using it to mean two different things in two different
contexts is probably not the best idea.


  -Reactor

Post a reply to this message

Grobi nous illumina en ce 2009-02-04 05:33 -->
> Hi !
> 
> for a given scene the parsing takes a lot more time than rendering.
> 
> Is there a way to keep the parsed information to use with e.g. another
> resolution render ?
> 
> thanks
> 
>  Andreas
> 
> 
It all depend on what is causing the parsing to take lot of time.

If it's calculating data, writing them to a file is the way to go.

If it's due to large images files to be used as image_map, bump_map or 
height_fields, try using one or some of the following:
Use another file format as the source. If you use a BMP or TGA, convert it to a 
PNG. Smaler files load faster. The time saving from loading compressed files can 
be much more importent than the extra time required to process them.
Try using a smaler resolution for the image(s), or one with a smaler colour 
range. You don't always need the full resolution or colour depth. It all depends 
on your particuliar needs.

Does the parsing start fast, then slows down to a crawl, while you can notice A 
LOT of disk activity?
This point to your RAM geting full and the system starting swaping/paging the 
data to the disk drive. Install as much RAM as your computer can hold. If you 
have a system with an integrated video, try reducing the memory alocated to the 
video. POV-Ray don't use the video processor nor the video memory.

-- 
Alain
-------------------------------------------------
You know you've been raytracing too long when...
you ever saw a beautiful scenery and regretted not to take your 6" reflective 
ball and a digital camera, thinking "this would have been a perfect light probe"
         -Johnny D

Post a reply to this message

"Reactor" <rea### [at] hotmailcom> wrote:
> "clipka" <nomail@nomail> wrote:
> > "Grobi" <and### [at] boesmanncom> wrote:
> > > Is there a way to keep the parsed information to use with e.g. another
> > > resolution render ?
> >
> > Not yet.
> >
> > However, if you precompute anything, you might want to #write data to a file
> > (maybe "ready to rock" as an #include file)
>
>
>
> Wait, did you say yet??  Ooohh, I like the sound of that!
>

Yes, but it's usually followed by "Don't hold your breath". :-)

Post a reply to this message

"Reactor" <rea### [at] hotmailcom> wrote:
> Wait, did you say yet??  Ooohh, I like the sound of that!

Yup. There's code in the current betas for a feature called "real time
raytracing". The term is a bit misleading I think, because as far as I see it's
basically about rendering animations without re-parsing all the scene all over
again. But I might be mistaken there.

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> "Reactor" <rea### [at] hotmailcom> wrote:
> > Wait, did you say yet??  Ooohh, I like the sound of that!
>
> Yup. There's code in the current betas for a feature called "real time
> raytracing". The term is a bit misleading I think, because as far as I see it's
> basically about rendering animations without re-parsing all the scene all over
> again. But I might be mistaken there.

http://www.povray.org/beta/rtr/

Goes back a bit now. There's a thread here too:

http://news.povray.org/povray.beta-test/thread/%3C4547ff05%40news.povray.org%3E/?mtop=5

Post a reply to this message