 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tag povrayorg> wrote:
> MichaelJF <mi-### [at] t-onlinede> wrote:
> > What could be the usage of this? A very simple example would be that you would
> > be able to write a POV-macro to convert wavefront-OBJ-Files to POV-mesh2-syntax
> > in POV itself.
>
> This has been an idea for years for the hypothetical new SDL that POV-Ray
> might get some day. (The idea is for the SDL to be redesigned so that,
> while being at least as easy to use as the current SDL, it additionally
> supports all kinds of features that would make an expressive and powerful
> scripting language where doing things like making an input file parser
> would be much easier than with the current SDL. Also, it would be a lot
> faster than the current SDL, as it would optimally be byte-compiled.)
>
> The current SDL is far from being optimal for that task.
>
> --
> - Warp
Thank you,
in my eyes your respone settles the matter completely. I apologize for being a
bit more frank yesterday than usual but sometimes things are "lost in
translation", especially when it comes to figures of speech. At the moment I'm
hunting down a flaw with baking occlusion maps using Jaimes macros. The only
thing that is clear totally, is that it has nothing to do with Jaimes work. It
is an problem with my input. So I analyze the special meshes with my statistcal
software and use features like sorting big data sets (to have the actual
coordinates of the vertices and the normals to a face in one line - or
observation, as we statisticians call it), which cannot be implemented in POV
even with a kind of a new readln-directive. So far I detected that Wings
produces some inverted normals (normals into the object, which would produce
wrong results with the meshcam) but not very much. This result could have been
yielded with a readln-feature because no sorting was needed. In this case the
normal_indices were identical to the face_indices and every vertex has its own
normal (and only one). But this should only give an impression of the things I'm
working at. May be my failure is only having a wrong uv-mapping (the next issue
I would address). But if my suspicions are right, one could be able to write a
macro to repair this things (in the most simple situation of only smooth edges),
and this was my original intention.
Best regards,
Michael
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 17.10.2012 17:01, schrieb MichaelJF:
> Hello,
>
> for the first time I tried to use the read-directive and was heavily
> disappointed as I noticed that you can nearly write everything to a file, but
> are very restricted to read from a text-file. If one would have a directive like
> readln in c or c++ which reads a line from a file into a string one could build
> parsers only with the existing string-functions (o.k. some more convient ones
> would be fine, but the existing like strlen, strcmp or concat are enough to
> build macros for text exchanges, substring-detection and so on). So my question
> is simple: Is it possible to implent such a feature without too much effort?
Yes, it is possible. I've recently coded a patch that would allow this,
but it won't be in 3.7 because we're way past feature freeze for the
release.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 17.10.2012 19:34, schrieb MichaelJF:
> I can not see a reason for that. I think a feature like readln would be a bigger
> improvement to POV as the sslt feature for example since you could parse files.
As the author of the SSLT feature, I *strongly* disagree! :-P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 18.10.2012 17:39, schrieb MichaelJF:
> Hm, I think you didn't understand me. I will parse everything, or better I would
> like to able to. Technically I can see no reason to use the comma or the \n as
> seperator.
The reason is that CSV is a very common and well-established file format
for exchanging data between different applications.
(Then again, POV-Ray's support for CSV is somewhat bogus in that it
requires a comma at the end of each line.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 19.10.2012 10:39, schrieb Le_Forgeron:
> Le 19/10/2012 06:53, Tim Cook nous fit lire :
>> How about adding a #binaryread command or something, that's supplementary?
>
> what would be the usage of it ?
> I mean, the SDL is able to handle floating point, vector up to 5
> dimensions of floating point, and string of text (and I might be
> forgetting some things like square matrix). It cannot handle a binary
> blob like a PNG or JPG image or a collection of traced photons directly
> (not in a generic way for more manipulation)
Note that text can only be read if placed between quotes. Hence you
can't even read (and parse) arbitrary ASCII text files, which I think is
a pretty essential feature when it comes to importing data from other
programs.
(As a matter of fact, POV-Ray SDL is better at retrieving data from PNG
or JPG images than it is at retrieving data from well-formed CSV files.
After all, with image files it's just a matter of defining an image_map
pigment and retrieving the data with eval_pigment, while retrieval from
a normal CSV file typically fails because POV-Ray needs trailing commas.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 20.10.2012 20:11, schrieb MichaelJF:
> So far I detected that Wings
> produces some inverted normals (normals into the object, which would produce
> wrong results with the meshcam) but not very much.
Are you sure about this? Wings uses a data model that /exclusively/
supports solid objects, where it is always well-defined where "inside" is.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Am 20.10.2012 20:11, schrieb MichaelJF:
>
> > So far I detected that Wings
> > produces some inverted normals (normals into the object, which would produce
> > wrong results with the meshcam) but not very much.
>
> Are you sure about this? Wings uses a data model that /exclusively/
> supports solid objects, where it is always well-defined where "inside" is.
First, yes the SSLT-feature is a great achievement as Jaime showed us with his
piano very impressively. But the possibility to read not only quoted text would
be even a great one. In a completely other way of course.
Second, no, I'm not sure about it. In one case I am. Wings had produced a wrong
normal with my stone of orloff (the middle point at the base) and showed a very
strange behaviour while rotating the object. Since this object has only a few
vertices, I noticed it. As I inspected my incense alarm clock (some 40.000
vertices) more closely (with MeshLab showing the normals) I found that there
seems to be some inverted normals but some of the normals pointing inside the
object are most likely correct due to close folds. But not all. I wrote a macro
with a third party software with allowed me to write a POV macro to show the
normals at the vertices using Point_At_Trans to indicate the direction. Within
some 40.000 vertices only very few appeared red (which means the normals are
inverted) the most are green (normals are correct). But the idea of having wrong
normals in some regions was not completely wrong. But they stemmed from other
faces since the uv-mapping was not correct. Wings had placed uv-areas over
another so that different faces used the same uv-regions. POV decided for one of
them and at the second it choose the first. So my incense alarm clock has a
sonny side and the other side shows the flaws. So at last I did the mistake,
having not understood the way Wings does the uv-mapping (I tried nearly all
options, but yielded no better results). I habe noticed a very strange behaviour
with only one wings object so far but cannot reproduce it unfortunatelly. This
behaviour could only be explained with wrong normals. If I experience this
phenomenon again I will soon save and post it. Meanwhile I think It must have
been an coincidence most likely due to my small skils with Wings.
Best regards,
Michael
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"MichaelJF" <mi-### [at] t-onlinede> wrote:
> for the first time I tried to use the read-directive and was heavily
> disappointed as I noticed that you can nearly write everything to a file, but
> are very restricted to read from a text-file.
Is it really necessary to #read from a text file and than to parse?
read and write is very useful for transporting informations from one image to
the next in an animated scenes like the marble machine
http://www.alzinger.de/cms5/robert/raytracing/marble-machine-in-povray.html
see the source below.
But if you have more complex problems like transforming mashes. Use an external
program. It is faster.
#macro read_objects ()
// scene lesen
#fopen rscene "objects.txt" read
#declare anz =0;
#while (defined(rscene))
#read (rscene,obj)
#declare objec[anz] = obj;
#if ( objec[anz] != "end")
#read (rscene,p)
#read (rscene,s)
#read (rscene,sp)
#read (rscene,r)
#read (rscene,ri)
#declare position[anz] = p;
#declare siz[anz] = s;
#declare speed[anz] = sp;
#declare rotat[anz] = r;
#declare rotat_inc[anz] = ri;
#declare anz=anz+1;
#end
#end
#fclose rscene
#end
#macro write_objects()
// scene schreiben
#declare i = 0;
#fopen rscene "objects.txt" write
#while (i<=anz)
#write (rscene,"\"",objec[i],"\"",",\n")
#if ( objec[i] != "end")
#write (rscene,position[i],",\n")
#write (rscene,siz[i],",\n")
#write (rscene,speed[i],",\n")
#write (rscene,rotat[i],",\n")
#write (rscene,rotat_inc[i],",\n")
#else
#declare i=anz+1;
#end
#declare i=i+1;
#end
#fclose rscene
#end
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"robert alzinger" <nomail@nomail> wrote:
> Is it really necessary to #read from a text file and than to parse?
>
> read and write is very useful for transporting informations from one image to
> the next in an animated scenes like the marble machine
>
>
> But if you have more complex problems like transforming mashes. Use an external
> program. It is faster.
>
Yes and most likely more convenient, has more features and so on. But, you did
not read the whole thread here. If you will share code with the POV community it
is best to use POV itself and not a third party software like my SAS (Stastical
Analysis System, a very well known software by epidemiologists or pharmacists -
but not to others unfortunatelly) you have most likely never heard of.
Best regards,
Michael
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
