Is there any way to save an object (IE, a union of lots of other objects) to
disk and then read it back in?

THis could potentially save me tons of parsing time if there's a way to do
it.

Post a reply to this message

On Mon, 07 Apr 2003 11:33:31 -0400, Tyler Eaves <tyl### [at] hotpopcom> wrote:
> Is there any way to save an object (IE, a union of lots of other objects) to
> disk and then read it back in?
>
> THis could potentially save me tons of parsing time if there's a way to do
> it.

During first parsing you can parallel create file on drive with equivalent of
content you creating for parsing. This is common habit in case of creation of
meshes. For example look for HF_* macros in standard distribution. There is a
parameter for choosing output to file.

ABX

Post a reply to this message

ABX wrote:

> On Mon, 07 Apr 2003 11:33:31 -0400, Tyler Eaves <tyl### [at] hotpopcom> wrote:
>> Is there any way to save an object (IE, a union of lots of other objects)
>> to disk and then read it back in?
>>
>> THis could potentially save me tons of parsing time if there's a way to
>> do it.
> 
> During first parsing you can parallel create file on drive with equivalent
> of content you creating for parsing. This is common habit in case of
> creation of meshes. For example look for HF_* macros in standard
> distribution. There is a parameter for choosing output to file.
> 
> ABX
That makes sense.

Post a reply to this message

ABX wrote:

> On Mon, 07 Apr 2003 11:33:31 -0400, Tyler Eaves <tyl### [at] hotpopcom> wrote:
>> Is there any way to save an object (IE, a union of lots of other objects)
>> to disk and then read it back in?
>>
>> THis could potentially save me tons of parsing time if there's a way to
>> do it.
> 
> During first parsing you can parallel create file on drive with equivalent
> of content you creating for parsing. This is common habit in case of
> creation of meshes. For example look for HF_* macros in standard
> distribution. There is a parameter for choosing output to file.
> 
> ABX

Ack, hit send too soon.

What I was really hoping for was some sort of binary save,
ala photons. But that'll help, since my code is VERY loop intensive. 
Speaking of that, is there any real speed hit for unioning a number of
objcets together, as opposed to not unioning?

Post a reply to this message

On Mon, 07 Apr 2003 11:43:31 -0400, Tyler Eaves <tyl### [at] hotpopcom> wrote:
> What I was really hoping for was some sort of binary save,
> ala photons.

AFAIK photons related files are not binary. They are probably fully portable
ascii files. Supported portable format for exchenging objects are ascii files
with scripts written in SDL.

> But that'll help, since my code is VERY loop intensive. 
> Speaking of that, is there any real speed hit for unioning a number of
> objcets together, as opposed to not unioning?

As usually depends it depends on situation. Hard to say without knowing objects,
environment, complexity of scene. 

ABX

Post a reply to this message

ABX wrote:

> 
> As usually depends it depends on situation. Hard to say without knowing
> objects, environment, complexity of scene.

One thing I've done, that helps quite a bit, is calculating the posistions
where the objects should be placed along the spline in my python code.

so instead of doing something akin to.

#while(pos < end)
#declare d = d + distance_from_the_last_point;
#if (d > somenumber)
#declare d = 0;
//Do something
#end
#declare pos = pos + .0001
#end

Now I loop over an array of the positions. Helps quite a bit.

Post a reply to this message

ABX wrote:
> 
> > What I was really hoping for was some sort of binary save,
> > ala photons.
> 
> AFAIK photons related files are not binary. They are probably fully portable
> ascii files. Supported portable format for exchenging objects are ascii files
> with scripts written in SDL.

photons are not stored in ascii but in binary form.  This of ocurse also
means that photon data files are not as portable as POV-Ray itself.  This
does not matter that much since photon data is not really intended to be
moved between different platforms.  

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

On Mon, 07 Apr 2003 18:53:26 +0200, Christoph Hormann <chr### [at] gmxde>
wrote:
> photons are not stored in ascii but in binary form.  This of ocurse also
> means that photon data files are not as portable as POV-Ray itself.  This
> does not matter that much since photon data is not really intended to be
> moved between different platforms.

So there is no way to use photons data for multiplatform distributed rendering ?
I'm surprised.

ABX

Post a reply to this message

ABX wrote:
> 
> > photons are not stored in ascii but in binary form.  This of ocurse also
> > means that photon data files are not as portable as POV-Ray itself.  This
> > does not matter that much since photon data is not really intended to be
> > moved between different platforms.
> 
> So there is no way to use photons data for multiplatform distributed rendering ?
> I'm surprised.

Not necessarily, the most common platforms are compatible in terms of the
photon data (there are no byte order problems, only non-IEEE floating
point numbers will be difficult).  But as i said this compatibility is
less than what is possible with POV-Ray itself.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

In article <78b39vs5bju40d2eu1otajq7hksq0imic0@4ax.com> , ABX 
<abx### [at] abxartpl>  wrote:

> So there is no way to use photons data for multiplatform distributed rendering
?
> I'm surprised.

Since when is "multiplatform distributed rendering" a feature of an official
version of POV-Ray?

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

On Mon, 07 Apr 2003 21:32:24 +0200, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> In article <78b39vs5bju40d2eu1otajq7hksq0imic0@4ax.com> , ABX 
> <abx### [at] abxartpl>  wrote:
>
> > So there is no way to use photons data for multiplatform distributed rendering?
> > I'm surprised.
>
> Since when is "multiplatform distributed rendering" a feature of an official
> version of POV-Ray?

It's very popular to split animation into parts rendered on various machines.
6.10.5.4: "The photon map itself is view-independent, so if you want to animate
a scene that contains photons and you know the photon map will not change during
the animation, you can save it on the first frame and then load it for all
subsequent frames". Perhaps this should be extended about binary nature of this
file and portability limitations.

ABX

Post a reply to this message

In article <qa159vss0903hu8oms990f7nees385mv0q@4ax.com> , ABX 
<abx### [at] abxartpl>  wrote:

> Perhaps this should be extended about binary nature of this
> file and portability limitations.

No, because that is not of concern of, nor understandable by, users.  There
is such a thing as "too much" documentation for users.  Keep in mind this
document isn't a software engineering style document, but a simple user
manual.  Users are not be able able to understand what is behind it because
they cannot know the technical background.  Thus, it doesn't belong into a
user manual.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:
>In article <qa159vss0903hu8oms990f7nees385mv0q[at]4ax.com> , ABX
><abx### [at] abxartpl>  wrote:
>
>> Perhaps this should be extended about binary nature of this
>> file and portability limitations.
>
>No, because that is not of concern of, nor understandable by, users.  There
>is such a thing as "too much" documentation for users.  Keep in mind this
>document isn't a software engineering style document, but a simple user
>manual.  Users are not be able able to understand what is behind it because
>they cannot know the technical background.  Thus, it doesn't belong into a
>user manual.
>
>    Thorsten

Then maybe there need to be two manuals.  One for regular users, and one for
power users.  The first one could be a stripped down version of the current
documentation, since it already has several topics that are covered in
graphic mathematical detail.

The second one could be a beefed up version of the current documentation,
for those who are curious about how the innards work, without having to
resort to the most in-depth documentation, i.e. the source code.  I find
myself venturing into the code to see how things work that should be
documented, such as how POV-Ray handles refraction between multiple objects
(such as water in a glass bottle; see my thread a couple posts before this
one).

In fact, my latter example (refraction) is not some esoteric quirk that no
one will ever use.  It is a very commonly used feature that, in my opinion,
was implemented incorrectly.  Had there been better documentation, perhaps
the design team would have found the flaw earlier (nothing points out a
mistake like trying to document how something works), or someone else would
have come forward with a fix earlier.

Post a reply to this message

I've cut the parse time for a single frame from 45 seconds to 6.5 seconds.
Slight improvement when doing a 1500 frame animaiton *g*

Post a reply to this message

Retsam wrote:

> Then maybe there need to be two manuals.  One for regular users, and one for
> power users.

You obviously have no clue what is involved in just maintaining the current
documentation and all the hard tedious work that went into getting it where
it is now.

-- 
Ken Tyler

Post a reply to this message