Sounds like another language feature better for POV-Ray 4 rather than
the current one.

  In other words, rather hacking tons of tiny features on top of the old
SDL, it's better to design a new SDL which is so flexible that you can do
almost anything with it without the need to add core features.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Sounds like another language feature better for POV-Ray 4 rather than
> the current one.
>
>   In other words, rather hacking tons of tiny features on top of the old
> SDL, it's better to design a new SDL which is so flexible that you can do
> almost anything with it without the need to add core features.

This is a bit different from various other SDL extension proposals, IMO.

SDL is so flexible that you can do virtually everything with it, so most
suggested SDL extensions would just eliminate the need of tons of macros.

Writing DF3 files, however, is something that as of now *cannot* be done with
macros, no matter how sophisticated they are. Not unless you're fine with file
sizes of 16 MB and over at less than 7 bit resolution.

So we have a real gap to be filled here, not just some nice polishing-up.

Plus, IMO there's nothing wrong with polishing up the 3.x SDL a bit either - if
it's easy enough to implement. Which is definitely the case here.


BTW, if we'd be talking about POV 4 SDL, I'd take a totally different approach.
For example, the ability to dump a whole 3D-array to DF3 with just a single
statement would come in handy. But with 3.x SDL being ripe for replacement,
*that* is something I decided to file under "too much effort for too little
gain - to be postponed until POV 4 SDL", as it can easily be done with quite a
simple macro once binary #write is available. Much easier than implementing
native SDL support for an "array dump", as a matter of fact:

#macro Write3DArrayToDf3(filename, a)
  #local sizeX = dimension_size(a,1);
  #local sizeY = dimension_size(a,2);
  #local sizeZ = dimension_size(a,3);
  #fopen WriteToDf3_File filename write
  #write (WriteToDf3_File, int16 sizeX sizeY sizeZ)
  #local iZ = 0;
  #while (iZ < sizeZ)
    #local iY = 0;
    #while (iY < sizeY)
      #local iX = 0;
      #while (iX < sizeX)
        #write (WriteToDf3_File, int16 a[iX][iY][iZ] * 65535)
        #local iX = iX + 1;
      #end
      #local iY = iY + 1;
    #end
    #local iZ = iZ + 1;
  #end
  #fclose WriteToDf3_File
#end

There.

To instead add native support for this to POV, not only would something like the
above have to be implemented somewhere - there would also be extra work to do
thinking about a good syntax, implementing code to parse that syntax, taking
care of file handling, checking for unexpected pitfalls, and maybe changing
code to work around these pitfalls. Then checking that it didn't break
anything. That's why I'd agree that *this* isn't worth the pain for 3.x SDL.

Basic support for binary writes, however, is not much of a pain, and its gain
simply cannot be achieved otherwise without 3rd-party tools.

I hope this gives a clear picture of how I think about extending 3.x SDL. Of
course it's just my opinion - yours may differ.

Post a reply to this message

>  Sounds like another language feature better for POV-Ray 4 rather than
> the current one.
> 
>  In other words, rather hacking tons of tiny features on top of the old
> SDL, it's better to design a new SDL which is so flexible that you can do
> almost anything with it without the need to add core features.

It would be easy enough to fit binary file access into the current SDL
framework.
 
FOPEN_DIRECTIVE:
    #fopen IDENTIFIER "filename" OPEN_TYPE [FILE_MODE]
OPEN_TYPE:
    read | write | append
FILE_MODE
    standard | binary

Post a reply to this message

"Tim Attwood" <tim### [at] anti-spamcomcastnet> wrote:
> It would be easy enough to fit binary file access into the current SDL
> framework.
>
> FOPEN_DIRECTIVE:
>     #fopen IDENTIFIER "filename" OPEN_TYPE [FILE_MODE]
> OPEN_TYPE:
>     read | write | append
> FILE_MODE
>     standard | binary

That alone wouldn't quite do the job: How is POV to know whether to write a
particular value as a byte, 16-bit or 32-bit integer?

So when invoking #write, the parameters would have to be marked accordingly
anyway; and in that case the FILE_MODE isn't required at all.

Post a reply to this message

clipka wrote:
> Well, actually I did already implement a patch, so it's more like a request for
> a "go/no-go" from the POV team to go ahead and integrate it into official POV.
> 
> The mechanism is simple: The statement
> 
>     #write (fOut, someVal, int16 fooBar, otherVal)
> 
> will write fooBar in binary 16-bit unsigned integer format.
> 
> That means, if it is a float, the value is rounded to the nearest integer
> (values outside the valid unsigned 16-bit integer range are "clipped" to 0 or
> 65535, respectively), and written to the file in 16-bit binary format
> (big-endian, i.e. matching the df3 format byte ordering).

I think this will be useful, so please go ahead and integrate it. One request,
though, is that you alter 'int16' to be (for example) 'int16be' (or 'beint16')
to indicate it's a big-endian int that will be written. Optionally you may want
to implement LE and 32-bit words as well.

-- Chris

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> Warp <war### [at] tagpovrayorg> wrote:
> > Sounds like another language feature better for POV-Ray 4 rather than
> > the current one.
> >
> >   In other words, rather hacking tons of tiny features on top of the old
> > SDL, it's better to design a new SDL which is so flexible that you can do
> > almost anything with it without the need to add core features.
>
>
> ...Plus, IMO there's nothing wrong with polishing up the 3.x SDL a bit
> either - if it's easy enough to implement. Which is definitely the case here.


Yes, I'd definitely like to see this feature as well.

I agree that it would be better (that is, 'useful more quickly') to integrate it
into 3.7 rather than 4--which is *somewhere* off in the somewhat-distant future.
IMO, the idea of waiting to integrate features into a 'bigger POV-Ray re-write'
is somewhat hamstringing the usefulness of the program in the here-and-now. (I
kind of feel that way about the 3.7 betas, vs. something like an intermediary
3.6.5 version that could have fixed a few smaller issues more quickly--but
that's a moot point, of course. No real complaints here.)

KW

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> schreef in bericht 
news:web.49c9b0de6dca0b64f50167bc0@news.povray.org...
....... (I
> kind of feel that way about the 3.7 betas, vs. something like an 
> intermediary
> 3.6.5 version that could have fixed a few smaller issues more quickly--but
> that's a moot point, of course. No real complaints here.)

Interesting you mention this. I have a dim memory about the wish (by the POV 
Team?) to upgrade 3.6.1 for some specific things. Nothing really extreme 
(that is what 3.7 is for) but to correct, streamline, update known issues. 
However, somebody has to do the work and I can readily imagine that all 
available time is already spent on 3.7 and beyond. No real complaint either. 
That is life...

Thomas

Post a reply to this message

"Thomas de Groot" <tDOTdegroot@interDOTnlANOTHERDOTnet> wrote:
> Interesting you mention this. I have a dim memory about the wish (by the POV
> Team?) to upgrade 3.6.1 for some specific things. Nothing really extreme
> (that is what 3.7 is for) but to correct, streamline, update known issues.
> However, somebody has to do the work and I can readily imagine that all
> available time is already spent on 3.7 and beyond. No real complaint either.
> That is life...

The 3.7 being as it is, I think a 3.6.2 would be obsolete even before it sees
the light of day.

Just have a look at the beta test newsgroup: What are the most frequent
complaints? Right: People complaining that the current beta isn't yet available
for their system...

Even radiosity seems to be working properly now, except for speed at high
recursion depths (for which a solution is in the making, too).

Yes, 3.7.0.beta.31 is still a long way to go for an official release that meets
the intended quality standards; however, I think it is about fit for practical
use by now (I've actually ceased to use 3.6-generation POV except when I want
special features of MegaPOV or MCPov... or when I need a performance reference
for another benchmarking scene).

Post a reply to this message

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> I think this will be useful, so please go ahead and integrate it.

With pleasure!

> One request,
> though, is that you alter 'int16' to be (for example) 'int16be' (or 'beint16')
> to indicate it's a big-endian int that will be written. Optionally you may want
> to implement LE and 32-bit words as well.

The implementation now supports single bytes as well as 16-bit and 32-bit words,
both big- and little-endian. Both signed and unsigned flavors are supported as
well, except for 32-bit (only signed flavor for now). Keywords follow the
'sint16be' pattern (signed 16-bit big-endian), with the endianness-suffix
dropped for bytes ('sint8'/'uint8').

Ready to be released with the next beta.

Post a reply to this message

clipka wrote:

> Anyone else who thinks this would be a neat idea?

It's a neat idea! ;)

I feel a bit queasy about the syntax though, it doesn't
look right for SDL (or most other languages I know). A few
alternative suggestions

#writeb(fOut, "int16be", someVal1, someVal2)

-> my favourite

#write(fOut, "int16be", someVal1, someVal2)

-> on the unfounded assumption noone has ever written
    a #write statement with multiple values where the first
    one ist the string literal "int16be". Behavior could
    also depend on #version directive, or, with Tim's
    suggestion regarding #fopen, whether fOut refers
    to a binary file.

#writeb(fOut, "%hu%hu", someVal1, someVal2) or

-> well ...

#write(fOut, (int16be) someVal1, (int16be) someVal2)

-> with active suspension of disbelief you can pretend
    it's a cast to select from overloaded #write's ;)

Also, maybe it should be uint instead of int in case
you wish to add signed integers later?

Post a reply to this message