 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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-spam comcastnet> 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
|
|
| |
| |
|
|
|
|
| |
