POV-Ray : Newsgroups : povray.general : Detail-Tracker... Asking for Features Server Time
17 Nov 2024 15:14:08 EST (-0500)
  Detail-Tracker... Asking for Features (Message 1 to 9 of 9)  
From: Tim Nikias
Subject: Detail-Tracker... Asking for Features
Date: 15 Feb 2003 18:45:26
Message: <3e4ed116$1@news.povray.org>
As some might have already seen, I've kept working
on my Worldbowl image for some time now, and I've
stumbled across and idea whilst doing that...

As I've written the Mesh-Modifying-Macros, these have
the ability to save and load the meshes modified (and to
a certain degree modelled) with them. I've also written
the IO-Macros some time ago, which easily save and
load arrays and single identifiers, though they don't
support strings, at least not yet.

Now, Worldbowl has got several meshes using my
MMM, and I've kept saving them to disk, loading
them for renders, doing some tests in between with
larger resolution-meshes, which were saved and loaded...
Problem was, all these worked with the same few
identifiers:
Mesh_To_Disk & Mesh_From_Disk, boolean switches
used to determine if Meshes should be saved, just generated,
or just loaded. I've switched to some more complicated
boolean checks in between (is the file present? If not, generate
the data and load, but if switch is set, generate anyway, etc).

This was getting quiet painful.

Now I've had the final idea: A set of macros designed to keep
track of the details being used, versus the former details, and
thus the need to generate anew or just load.
What the system would do was to attach an identifier (a string)
to a vector (5-component internally) and a filename (again, string).
You initialize the system, if possible, it loads and checks the old
data.
Then, with some simple macros, it tells you to either:
generate and save the data (reply= false),
or load it (reply= true).
It hands the required filenames and uses these to track the files
itself.

Some Macros would be added, in order to return a uv-vector,
or just an rgb one, instead of the full 5-component vector.

I was wondering if anyone had any further ideas I might add
to the system (its gonna be pure pov, keep that in mind),
so I'd thought I'd ask for suggestions here.

Regards,
Tim

--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html
Email: Tim### [at] gmxde


Post a reply to this message

From: Christoph Hormann
Subject: Re: Detail-Tracker... Asking for Features
Date: 16 Feb 2003 08:40:53
Message: <3E4F94E5.7D19139F@gmx.de>
Tim Nikias wrote:
> 
> [...]
> 
> Now I've had the final idea: A set of macros designed to keep
> track of the details being used, versus the former details, and
> thus the need to generate anew or just load.
> What the system would do was to attach an identifier (a string)
> to a vector (5-component internally) and a filename (again, string).
> You initialize the system, if possible, it loads and checks the old
> data.
> [...]

Until here your writing was quite understandable but now you completely
lost me - i have no idea what you are talking about.

Christoph

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


Post a reply to this message

From: Tim Nikias
Subject: Re: Detail-Tracker... Asking for Features
Date: 16 Feb 2003 13:30:24
Message: <3e4fd8c0@news.povray.org>
What I want is to write some macros which keep
track of the resolutions of meshes which were
saved to disk.

Here's an example:
I've designed some cloth-mesh with a resolution of 50x50 Nodes.
I'd use the system as follows:
Create an identifier named "cloth_res", *attaching* "cloth.dat" as
filename and <50,50> as vector to it using the system.
I'd render the scene, those settings will be saved to disk.

The second time I trace the image, the system will check the
formerly saved stats. It returns "true" if I want to load "cloth.dat"
with a resolution of 50x50, since these were the values I've
used before.
If I'd try to trace the image with a new resolution, like 100x100 for
more detail, the system would check and find that the resolution
saved to disk was 50x50. Thus, it returns "false", the file "cloth.dat"
must be parsed anew.
It would also return "false" if the file that should be loaded is
non-existant (due to deleting or such).

In this manner, it keeps track of the recently used variables and
would only reparse data if it can not be loaded with the
desired settings (defined by the vectors).

Am I still talking nonsense?

--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html
Email: Tim### [at] gmxde

>
>
> Tim Nikias wrote:
> >
> > [...]
> >
> > Now I've had the final idea: A set of macros designed to keep
> > track of the details being used, versus the former details, and
> > thus the need to generate anew or just load.
> > What the system would do was to attach an identifier (a string)
> > to a vector (5-component internally) and a filename (again, string).
> > You initialize the system, if possible, it loads and checks the old
> > data.
> > [...]
>
> Until here your writing was quite understandable but now you completely
> lost me - i have no idea what you are talking about.
>
> Christoph
>
> --
> POV-Ray tutorials, include files, Sim-POV,
> HCR-Edit and more: http://www.tu-bs.de/~y0013390/
> Last updated 31 Dec. 2002 _____./\/^>_*_<^\/\.______


Post a reply to this message

From: Christoph Hormann
Subject: Re: Detail-Tracker... Asking for Features
Date: 16 Feb 2003 14:24:32
Message: <3E4FE56F.EE3C5566@gmx.de>
Tim Nikias wrote:
> 
> What I want is to write some macros which keep
> track of the resolutions of meshes which were
> saved to disk.
> 
> [...]

I have the impression that you want the functionality that is usually
obtained with a makefile.  You generate certain data files and render a
scene which is using that data and later change certain settings in the
scene and want a method automatically generating certain data files
again.  A makefile would take care of this.  It checks the modification
dates of the files and rebuilds files that depend on those files that have
been changed.  Of course it can't check the content of the files if
certain values are changed.  

Implementing something similar in SDL would be quite impossible since you
don't have access to the file modification dates and also can't read
binary files (determining if an image file is changed would be impossible
for example).

> 
> Am I still talking nonsense?

I never said it is nonsense, i just did not understand it.

Christoph

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


Post a reply to this message

From: Tim Nikias
Subject: Re: Detail-Tracker... Asking for Features
Date: 16 Feb 2003 16:01:14
Message: <3e4ffc1a$1@news.povray.org>
> > Am I still talking nonsense?
>
> I never said it is nonsense, i just did not understand it.

What I meant was that what I am saying is making no sense to
you, so its non-sense, right? :-)

About the functionality you're mentioning, yes, thats what
I want. But instead of accessing the actual files and checking
the data inside them, I want to save the settings that have been
used to generate those files, and then compare these to the former
settings. In this manner, I can tell if the files should be the
same as the ones I'm requiring.
And then I just have to let POV parse the required stuff, instead
of everything.

This all is of course pure POV-SDL, and the generation part
also takes place inside POV, so I think it should work, at least
to the degree that I explained above.
What I'm asking for is some features that might be expected from
this sort of system.
You know some?

--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html
Email: Tim### [at] gmxde
>
>
> Tim Nikias wrote:
> >
> > What I want is to write some macros which keep
> > track of the resolutions of meshes which were
> > saved to disk.
> >
> > [...]
>
> I have the impression that you want the functionality that is usually
> obtained with a makefile.  You generate certain data files and render a
> scene which is using that data and later change certain settings in the
> scene and want a method automatically generating certain data files
> again.  A makefile would take care of this.  It checks the modification
> dates of the files and rebuilds files that depend on those files that have
> been changed.  Of course it can't check the content of the files if
> certain values are changed.
>
> Implementing something similar in SDL would be quite impossible since you
> don't have access to the file modification dates and also can't read
> binary files (determining if an image file is changed would be impossible
> for example).
>
> >
> > Am I still talking nonsense?
>
> I never said it is nonsense, i just did not understand it.
>
> Christoph
>
> --
> POV-Ray tutorials, include files, Sim-POV,
> HCR-Edit and more: http://www.tu-bs.de/~y0013390/
> Last updated 31 Dec. 2002 _____./\/^>_*_<^\/\.______


Post a reply to this message

From: ABX
Subject: Re: Detail-Tracker... Asking for Features
Date: 17 Feb 2003 02:51:47
Message: <1v415v8sjg3cob5qcmbkbeubdadnadvcl3@4ax.com>
On Sun, 16 Feb 2003 22:03:44 +0100, "Tim Nikias" <tim### [at] gmxde> wrote:
> I want to save the settings that have been
> used to generate those files, and then compare these to the former
> settings. In this manner, I can tell if the files should be the
> same as the ones I'm requiring.

In that case you have to modify your file format and add input settings at
begining of file. First read header, compare with current input setting. If
file not fits, you can regenerate the file. You could also concatenate input
settings into filename and use file_exist function to find such file was
already created.

ABX


Post a reply to this message

From: Tim Nikias
Subject: Re: Detail-Tracker... Asking for Features
Date: 17 Feb 2003 07:21:10
Message: <3e50d3b6@news.povray.org>
Hm, it seems I'm not making myself clear.

I'm not saving the data as input settings at the beginning
of the file.
In a seperate file, I'm saving all input settings, and then
compare these input settings to the ones formerly saved.
If they are the same, and if the file exists, it will just
be loaded.

This makes it possible to use the system for all kinds of
files, may it be meshes as pure vector-data, or the meshes
plus triangles themselves, or CSG etc etc.


--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html
Email: Tim### [at] gmxde

> > I want to save the settings that have been
> > used to generate those files, and then compare these to the former
> > settings. In this manner, I can tell if the files should be the
> > same as the ones I'm requiring.
>
> In that case you have to modify your file format and add input settings at
> begining of file. First read header, compare with current input setting. If
> file not fits, you can regenerate the file. You could also concatenate input
> settings into filename and use file_exist function to find such file was
> already created.
>
> ABX


Post a reply to this message

From: ABX
Subject: Re: Detail-Tracker... Asking for Features
Date: 17 Feb 2003 07:34:57
Message: <r3l15v4ppao807hso2le32731m9ipa1aal@4ax.com>
On Mon, 17 Feb 2003 13:23:38 +0100, "Tim Nikias" <tim### [at] gmxde> wrote:
> In a seperate file, I'm saving all input settings, and then
> compare these input settings to the ones formerly saved.
> If they are the same, and if the file exists, it will just
> be loaded.

My idea was that instead of having second file with parameters, you can use
filename to store settings. Whole version checking is made via file_exist().
For example:

#macro Make_Mesh(X_Grid,Y_Grid)
  #local FileName = "my_mesh_" ;
  #local FileName = concat( FileName , str( X_Grid , 0 , 0 ) );
  #local FileName = concat( FileName , "_" );
  #local FileName = concat( FileName , str( Y_Grid , 0 , 0 ) );
  #local FileName = concat( FileName , ".mcr" );
  #if(file_exist(FileName))
    #include FileName
  #else
    #fopen MyFile FileName write
    :
    #write (MyFile,...)
    :
    #fclose MyFile
  #end
#end

> This makes it possible to use the system for all kinds of
> files, may it be meshes as pure vector-data, or the meshes
> plus triangles themselves, or CSG etc etc.

This makes it possible too :-)

ABX


Post a reply to this message

From: Tim Nikias
Subject: Re: Detail-Tracker... Asking for Features
Date: 17 Feb 2003 08:24:30
Message: <3e50e28e@news.povray.org>
Hm, thats an idea...

But its not very platform-unspecific. Your system might end up with
filenames like "foo_243515_124512.dat" which would be too long
for some platforms.
On the other hand, your system makes it possible to keep older
files...
Perhaps I should keep track of several changes instead of the last
one? I'm not sure, but IMHO you mostly need only a max of 4
levels of details, these I could keep track of. The ending of the filename
would be referred by that...
Hm, I could even go as far as 1000 backtraces, using that idea for
the settings-saving-file itself...

I'll ponder a little more, suggestions?

--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html
Email: Tim### [at] gmxde

> > In a seperate file, I'm saving all input settings, and then
> > compare these input settings to the ones formerly saved.
> > If they are the same, and if the file exists, it will just
> > be loaded.
>
> My idea was that instead of having second file with parameters, you can use
> filename to store settings. Whole version checking is made via file_exist().
> For example:
>
> #macro Make_Mesh(X_Grid,Y_Grid)
>   #local FileName = "my_mesh_" ;
>   #local FileName = concat( FileName , str( X_Grid , 0 , 0 ) );
>   #local FileName = concat( FileName , "_" );
>   #local FileName = concat( FileName , str( Y_Grid , 0 , 0 ) );
>   #local FileName = concat( FileName , ".mcr" );
>   #if(file_exist(FileName))
>     #include FileName
>   #else
>     #fopen MyFile FileName write
>     :
>     #write (MyFile,...)
>     :
>     #fclose MyFile
>   #end
> #end
>
> > This makes it possible to use the system for all kinds of
> > files, may it be meshes as pure vector-data, or the meshes
> > plus triangles themselves, or CSG etc etc.
>
> This makes it possible too :-)
>
> ABX


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.