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

Christian Froeschlin <chr### [at] chrfrde> wrote:
> I feel a bit queasy about the syntax though, it doesn't
> look right for SDL (or most other languages I know).

I guess that's mainly because it is an unconventional approach.

> #writeb(fOut, "int16be", someVal1, someVal2)
>
> -> my favourite

Not mine, because it would have introduced a whole different branch for the
parser.

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

That's plain crap, and I guess you know that ;)

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

Ugly to parse.

> #write(fOut, (int16be) someVal1, (int16be) someVal2)
>
> -> with active suspension of disbelief you can pretend
>     it's a cast to select from overloaded #write's ;)

Why the hassle of adding the parentheses? It would happen to make parsing quite
cumbersome, at no real benefit - aside from looking more like Java or the like.

*This* is something that would go against all conventions of SDL: There is not a
single keyword anywhere else that needs to be enclosed in parentheses.

Lining up keywords separated only by spaces is not uncommon for POV.


So, what's the benefit of any of those proposals?

I can name one benefit of the (unparenthesized) prefix approach I went for: It
was darn easy to integrate. No hassle with additional state variables. No
duplication of huge code blocks.

And I think it's as good as any other approach, regarding usability.


I think all your proposals are tinted by the way other languages do it. But POV
SDL is POV SDL and nothing else.


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

Happened already.

Post a reply to this message

"clipka" <nomail@nomail> wrote:

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

Ah, but would it have been obsolete say, two years ago?  :-)  (I think 3.7 was
still in it's beta stage back then?) But all is well, of course.  And I do
understand the reality of the time constraints that the POV-team volunteers
have. No squawking from my end; I *greatly* appreciate the efforts that have
been put into 3.7.

As Thomas says, that's life...

Looking forward to your DF3 integration!

Hey, while you're at it...

How about native import for DXF and OBJ files?  Maybe????  (That would be on my
own wish-list.) I figure it shouldn't take you more than a couple of days...
;-)

KW

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote:
> Looking forward to your DF3 integration!

Hey, for now it's just writing binary data, which *can* be used to generate
DF3...


> How about native import for DXF and OBJ files?  Maybe????  (That would be on my
> own wish-list.) I figure it shouldn't take you more than a couple of days...
> ;-)

Should be darn simple indeed (as far as OBJ goes), as long as it enforces
certain constraints (e.g. triangles only, or braindead automatic
triangulation). After all, the structure is strikingly close to the mesh2
object.

As a matter of fact, it's on my own wish-list as well.

Still, there are a few things to put some brains into:

- What SDL syntax?
- How do you handle materials?
- How about groups?

And then, someone would have to implement the whole smash... someone not
currently busy with radiosity speed and subsurface scattering, ideally... ;)

Post a reply to this message

>> 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.

Obviously the standard for binary files is 8 bit bytes.

POV supports encoding and decoding byte values with the
chr(N) and asc(S) functions in ASCII mode.

You can already write byte values as #write(handle,chr(N)).

In binary mode undeclared_identifiers and strings in a #read could just be
treated as 1 byte string chars instead of trying to determine the type from 
the
file content, or trying to find enclosing quotes. Float and vector handling
could be left as-is, or produce a warning.

There is no handling for integer types in POV SDL, everything is really a 
float,
or a string. Still, it might be fun to read in some ASCII art text file and 
try to
render something based on it, or other such stuff. In particular it's a 
bummer
having a big CSV file where the strings aren't enclosed in quotes, or some
other "defect". It would be nice to be able to directly use such stuff in 
POV.

Post a reply to this message