![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
For height feilds would it be possible to use bicubic patches to smooth
it out esp for low res ( spatial & colour ) height feilds in the
foreground of an image
&
using background { rgba <1,1,1,1>} (a for alpha) when outputing an image
should (if the selected file format supports it) add an alpha channel to
the image - this would be useful
&
Post-process - add a lens flare - I saw this done in a separate program
(command line) somewhere in the pov-links/Kens links - Not to take
anything from NKFlare & Colefaxe's lens include
&
a question - Is the post-process legal for submissions to the IRTC
Post a reply to this message
Attachments:
Download 'us-ascii' (1 KB)
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <38A8D08B.BF35F77E@hotmail.com> , Pabs <pab### [at] hotmail com>
wrote:
> using background { rgba <1,1,1,1>} (a for alpha) when outputing an image
> should (if the selected file format supports it) add an alpha channel to
> the image - this would be useful
Alpha channel output is already support by POV-Ray using the "+UA" switch.
See section "File Output Options" in the official documentation for details.
Thorsten
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Pabs" <pab### [at] hotmail com> wrote in message
news:38A8D08B.BF35F77E@hotmail.com...
| For height feilds would it be possible to use bicubic patches to smooth
| it out esp for low res ( spatial & colour ) height feilds in the
| foreground of an image
Guess that would take a rewrite of the height_field.
| using background { rgba <1,1,1,1>} (a for alpha) when outputing an image
| should (if the selected file format supports it) add an alpha channel to
| the image - this would be useful
rgbt (or transmit) already goes into the alpha channel but background is another
matter I suppose. Also, render a fisheye lensed camera scene and the unrendered
parts outside the field of view will be fully transparent in the alpha channel.
That probably needs to be changed I would think.
| Post-process - add a lens flare - I saw this done in a separate program
| (command line) somewhere in the pov-links/Kens links - Not to take
| anything from NKFlare & Colefaxe's lens include
Guessing you might mean Sparkle but not sure, that does a pixel color check
grows a white flare object of the proportionate size to the area of lightness.
I think so anyway. Nathan has said he might someday add flares if he can or
will.
| a question - Is the post-process legal for submissions to the IRTC
Maybe the 'focal_blur' and 'depth' would be considered okay for IRTC since they
use the scene 3D info, not so for the 'soft_glow' apparently but if scan-line
renders can be submitted then why not any of those?
Disclaimer: be aware that the person saying all of this might not be of sound
mind... or at least not knowledgeable enough to say anything.
Hey! I resent myself saying that about myself! No I don't. Yes I do.
Bob
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <38a8f1c8@news.povray.org>, "Bob Hughes"
<per### [at] aol com?subject=PoV-News:> wrote:
> "Pabs" <pab### [at] hotmail com> wrote in message
> news:38A8D08B.BF35F77E@hotmail.com...
> | For height feilds would it be possible to use bicubic patches to smooth
> | it out esp for low res ( spatial & colour ) height feilds in the
> | foreground of an image
>
> Guess that would take a rewrite of the height_field.
It could be done with a macro, using eval_pattern(), eval_pigment(), or
trace() to calculate the height for each point. You might not get the
memory advantages of a height field(*)...but that wouldn't be a problem
if there is only one of them in a scene.
(*)Another idea, make bicubic patches act like meshes, so pointers to
the patch are used instead of copies. Or maybe a "store_references"
aspect for all objects, which controls the way they are copied. Maybe
for POV-4.0?(It might be too difficult/ugly to implement in the current
C source, but should be quite easy in C++)
--
Chris Huff
e-mail: chr### [at] yahoo com
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Chris Huff <chr### [at] yahoo com> wrote...
> (*)Another idea, make bicubic patches act like meshes, so pointers to
> the patch are used instead of copies. Or maybe a "store_references"
> aspect for all objects, which controls the way they are copied. Maybe
> for POV-4.0?(It might be too difficult/ugly to implement in the current
> C source, but should be quite easy in C++)
This would be more memory efficient, to be sure. It might be slower (due to
more render-time transformation calculations), but if done properly, it
shouldn't be too bad, and the option could exist to expand all references
for speed reasons if the computer has lots of memory.
-Nathan
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <38a97257@news.povray.org>, "Nathan Kopp" <Nat### [at] Kopp com>
wrote:
> This would be more memory efficient, to be sure. It might be slower
> (due to more render-time transformation calculations), but if done
> properly, it shouldn't be too bad, and the option could exist to
> expand all references for speed reasons if the computer has lots of
> memory.
Hmm, although the transformations would slow things down slightly, they
might prevent some people from having to go to virtual memory, so it
could in some cases be faster.
Now that I have thought about it more, it shouldn't be too hard to
implement even in the C source. Just add a flag to each object
specifying the storage method, maybe add a counter of objects using the
data, and make some small modifications in the functions which copy and
destroy the objects. Make sure the data isn't destroyed if an object is
using it. And of course modify the object data structures and the code
which uses them so they can share data.
I don't really have the time to look at the source right now, though, so
I am just going by memory...I am too busy with my particle simulator, a
couple other potential projects, learning the MacZoop application
framework, thinking of learning more Java, and of course school. :-(
I am beginning to wish days could have 36 hours...although I am sure
school would just take more of them...
--
Chris Huff
e-mail: chr### [at] yahoo com
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |