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