As it seems, POV can write *every* file format it can read (and more)... except
that one file format which was specifically *designed* for POV: DF3.

You just can't write that format with POV. No way. You need a 3rd party tool to
create such files.

That sucks.

I therefore propose to extend the #write mechanism to allow for writing binary
data.

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

If fooBar is a vector, all components are written in this manner.

A sequence of values can be written in binary format using either of the
following syntax:

    #write (fOut, int16 a, int16 b, int16 c, int16 d)
    #write (fOut, int16 a b c d)

(Note the absence of commata in the second variant)

Well, that's it. Equipped with this tool, creating DF3 files still remains some
bit of work, but now at least it's possible, and actually not too complicated.

So far I have only implemented 16-bit because for now my main goal is creating
DF3 files, which have 16-bit values in the header and come in a 16-bit voxel
flavor (among other). However, adding support for 8-bit data isn't too
difficult either.

Anyone else who thinks this would be a neat idea?

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> As it seems, POV can write *every* file format it can read (and more)... except
> that one file format which was specifically *designed* for POV: DF3.
>
> You just can't write that format with POV. No way. You need a 3rd party tool to
> create such files.
>
> That sucks.
>
> I therefore propose to extend the #write mechanism to allow for writing binary
> data.
>
> 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).
>
> If fooBar is a vector, all components are written in this manner.
>
> A sequence of values can be written in binary format using either of the
> following syntax:
>
>     #write (fOut, int16 a, int16 b, int16 c, int16 d)
>     #write (fOut, int16 a b c d)
>
> (Note the absence of commata in the second variant)
>
> Well, that's it. Equipped with this tool, creating DF3 files still remains some
> bit of work, but now at least it's possible, and actually not too complicated.
>
> So far I have only implemented 16-bit because for now my main goal is creating
> DF3 files, which have 16-bit values in the header and come in a 16-bit voxel
> flavor (among other). However, adding support for 8-bit data isn't too
> difficult either.
>
> Anyone else who thinks this would be a neat idea?

Absolutely - I'd love that feature. Raw 8 bit support is critical though.

Cheers,
Edouard.

Post a reply to this message

"clipka" <nomail@nomail> schreef in bericht 
news:web.49c83b4b7972c2f3c7b40aac0@news.povray.org...
>
> Anyone else who thinks this would be a neat idea?
>

Absolutely. Without any question.

Thomas

Post a reply to this message

"Thomas de Groot" <tDOTdegroot@interDOTnlANOTHERDOTnet> wrote:
> "clipka" <nomail@nomail> schreef in bericht
> news:web.49c83b4b7972c2f3c7b40aac0@news.povray.org...
> >
> > Anyone else who thinks this would be a neat idea?
> >
>
> Absolutely. Without any question.

Agreed. I've played with df3 briefly in the past, and SDL access would make it
much easier.

Post a reply to this message

"clipka" <nomail@nomail> wrote:

My! Sounds interesting!

These links may be useful?

- Using POVRay as a volume renderer:
http://local.wasp.uwa.edu.au/~pbourke/miscellaneous/df3/

- DF3 utility from Woody:
http://news.povray.org/web.4799e4c49ec55a3e94e61a50%40news.povray.org

- Request for *.df4 format (ASCII text based):
http://news.povray.org/web.47b586279e245a8f94e61a50%40news.povray.org

:-)

--
Carlo

Post a reply to this message

On Mon, 23 Mar 2009 21:45:47 EDT, "clipka" <nomail@nomail> wrote:

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

Me too.
-- 

Regards
     Stephen

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.

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

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

"clipka" <nomail@nomail> schreef in bericht 
news:web.49ca59866dca0b64c1f399840@news.povray.org...
>
> The 3.7 being as it is, I think a 3.6.2 would be obsolete even before it 
> sees
> the light of day.
>

Yes, as things are developing now (with a deep bow to you) 3.6 is only 
worthwhile for the Megapov things.

How are ideas, by the way, to integrate *those* into 3.7?

Thomas

Post a reply to this message

Tim Attwood wrote:

> FOPEN_DIRECTIVE:
>     #fopen IDENTIFIER "filename" OPEN_TYPE [FILE_MODE]
> OPEN_TYPE:
>     read | write | append
> FILE_MODE
>     standard | binary

This I like hugely.



Clipka wrote:

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

Personally I think it's far cleaner to just be able to write raw bytes (in an
8bit clean stream), and not support 16 or 32 bit values. Once you have raw
bytes, you can trivially write a macro to write big endian 16 bit values. Or
little endian. Or 64 bit values. Or anything.



Tim Attwood wrote:

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

And this seems like the perfect way to write bytes to a binary stream.

Doesn't work on the Mac OS X beta of 3.7 now - NULLs get swallowed, and anything
over 0x7f gets written as a space. And the global_settings{ charset ... }
directive doesn't really seem to do much in this version either.

So my ideal solution would be to add the "binary" flag to a file open command,
and then fix write( ..., chr() ) to actually write bytes cleanly. I could write
a DF3 file once that was done with ease.

But I'm not doing the work, so I'll gratefully accept whatever actually gets
done. :-)

Cheers,
Edouard.

Post a reply to this message

> > The 3.7 being as it is, I think a 3.6.2 would be obsolete even before it
> > sees the light of day.
>
> Yes, as things are developing now (with a deep bow to you) 3.6 is only
> worthwhile for the Megapov things.
>
> How are ideas, by the way, to integrate *those* into 3.7?

The only thing in Megapov I can't do without is the AOI pattern.

Oh, and "no_radiosity". Umm, and bicubic Interpolation is nice. And glows.
Uhhhh, and the user_defined camera.

But mainly AOI.

Cheers,
Edouard.

Post a reply to this message

"Tim Attwood" <tim### [at] anti-spamcomcastnet> wrote:
> POV supports encoding and decoding byte values with the
> chr(N) and asc(S) functions in ASCII mode.

It does indeed, but...

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

.... no, you can't. Not reliably, that is. Ever tried? There's no way to get POV
to #write a 0x00. Or a 0x0D on windows machines. Or any value > 0x7F, as it
seems.

Post a reply to this message

"Thomas de Groot" <tDOTdegroot@interDOTnlANOTHERDOTnet> wrote:
> Yes, as things are developing now (with a deep bow to you) 3.6 is only
> worthwhile for the Megapov things.
>
> How are ideas, by the way, to integrate *those* into 3.7?

How are ideas, by the way, to develop a 3.7-based Megapov version?


I guess the main point is that Megapov currently is a collection of 3.6 patches.
To integrate them into 3.7 requires a rewrite, so it's not just a copy-and-paste
job.

Maybe that is why, of all things, HDR images was one of the first Megapov
features to find its way into 3.7 POV: It's mostly about reading & writing an
image file format, which is, so to speak, "located comparatively far from 3.7
architectural changes": Image file handling has traditionally been done via
libraries, and POV 3.7 didn't modify those.

Other things, like the mechanics sim, are probably beyond POV ambitions ("Damn
it Jim, I'm a renderer, not a physics simulaition!").


The two things that would be ranking highest on my personal
to-be-integrated-in-3.7 list are probably the "#set" directive and the aoi
pattern.

Post a reply to this message

"Edouard" <pov### [at] edouardinfo> wrote:
> The only thing in Megapov I can't do without is the AOI pattern.

Yeah, that's really a gap in POV.

> Oh, and "no_radiosity".

Parts of the necessary code already exist in POV 3.7, so intention to integrate
it must have been there. Unfinished work though (started by someone else, not
me).

Post a reply to this message

clipka <nomail@nomail> wrote:
> > You can already write byte values as #write(handle,chr(N)).

> .... no, you can't. Not reliably, that is. Ever tried? There's no way to get POV
> to #write a 0x00.

  The problem is that in C/C++ a string is ended with 0x00, and #write
does nothing else than output strings (rather than an array of bytes).

  The solution to that problem would be rather simple: Make it output
the array of bytes represented by the parameter, rather than writing it
as a string.

  (OTOH I don't know how povray internally handles string identifiers.
If it handles them as arrays of chars, with a separate length variable,
then there would be no problem.)

  But the proposed changes might be a better approach anyways.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   (OTOH I don't know how povray internally handles string identifiers.
> If it handles them as arrays of chars, with a separate length variable,
> then there would be no problem.)

No, unfortunately they're not. After all, POV used to be a C program. So chr(0)
always collapses to a zero-length string in POV-Ray's eyes (in *any* context,
btw).

>   But the proposed changes might be a better approach anyways.

I wouldn't generally call them better, but I'd definitely call them easiest to
implement.

Post a reply to this message

clipka wrote:
> Maybe that is why, of all things, HDR images was one of the first Megapov
> features to find its way into 3.7 POV: It's mostly about reading & writing an
> image file format, which is, so to speak, "located comparatively far from 3.7
> architectural changes": Image file handling has traditionally been done via
> libraries, and POV 3.7 didn't modify those.

What I'm missing in 3.7 is 'map_type 7' for using light probes. I'm glad 
HDR support is there, but I have all my HDR images in probe format. 
Spherical mapping isn't the same, I keep seeing the blue outline around 
the real image in parts of the sky.

Post a reply to this message

"clipka" <nomail@nomail> schreef in bericht 
news:web.49cb647b6dca0b6493bfb07f0@news.povray.org...
> The two things that would be ranking highest on my personal
> to-be-integrated-in-3.7 list are probably the "#set" directive and the aoi
> pattern.
>

Yes indeed. Among others, I am also specially interested in the Glow macro 
and the Clip_Colors macro as well as the HDRI. Motion_blur is another of 
those macros I am using quite often.

I suspect that Cloth simulation and Mechanics simulation should be available 
as some kind of *plugins* (maybe indeed Megapov 3.7 ?)

Thomas

Post a reply to this message

CShake <cshake+pov### [at] gmailcom> wrote:
> > Maybe that is why, of all things, HDR images was one of the first Megapov
> > features to find its way into 3.7 POV: It's mostly about reading & writing an
> > image file format, which is, so to speak, "located comparatively far from 3.7
> > architectural changes": Image file handling has traditionally been done via
> > libraries, and POV 3.7 didn't modify those.
>
> What I'm missing in 3.7 is 'map_type 7' for using light probes. I'm glad
> HDR support is there, but I have all my HDR images in probe format.
> Spherical mapping isn't the same, I keep seeing the blue outline around
> the real image in parts of the sky.

.... which may be because image map types are implemented in the engine, and not
somewhere on the periphery, so integrating the 3.6 patch into 3.7 code may be
more difficult than integrating the HDR image format support.

Post a reply to this message

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

I agree.

It's a bit frustrating that this otherwise excellent piece of software has a
feature which depends on a particular file format, which is only used in said
software, but cannot be created in said software.

Translation: Density File feature depends on the DF3 format, which is only used
by POVRAY, but which cannot be created by POVRAY. Which forces the use of
another program.

I think POVRAY purists (people who only use the POV program and not any
modellers or esternal editors), such as myself, would have the greatest problem
with this. However, I don't know of any "purists".

Post a reply to this message

"clipka" <nomail@nomail> 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.

Clipka, How can I get ahold of the code for said patch?

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

So would this add to the expected time until POVRAY v4 would be released? Or
would it be such a minor request that it would not add to the time.

When is this supposed to be again?

I would like to help with the development. However, my programming knowledge
only extends to VBA and a little C++ / C#.

If you need a tester I'm all for it.

Post a reply to this message

"Woody" <nomail@nomail> wrote:
> Clipka, How can I get ahold of the code for said patch?

Simple: Just get the beta.32 ;)

Post a reply to this message

Woody nous illumina en ce 2009-04-19 13:53 -->
>> Anyone else who thinks this would be a neat idea?
> 
> I agree.
> 
> It's a bit frustrating that this otherwise excellent piece of software has a
> feature which depends on a particular file format, which is only used in said
> software, but cannot be created in said software.
> 
> Translation: Density File feature depends on the DF3 format, which is only used
> by POVRAY, but which cannot be created by POVRAY. Which forces the use of
> another program.
> 
> I think POVRAY purists (people who only use the POV program and not any
> modellers or esternal editors), such as myself, would have the greatest problem
> with this. However, I don't know of any "purists".
> 
> 
> 
> 
The current V3.7 beta 32 now does support writing DF3s.

-- 
Alain
-------------------------------------------------
You know you've been raytracing too long when you look at real clouds and 
criticise their media and radiosity settings.
Tom Melly

Post a reply to this message