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)

In article <38A8D08B.BF35F77E@hotmail.com> , Pabs <pab### [at] hotmailcom>  
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

"Pabs" <pab### [at] hotmailcom> 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

In article <38a8f1c8@news.povray.org>, "Bob Hughes" 
<per### [at] aolcom?subject=PoV-News:> wrote:

> "Pabs" <pab### [at] hotmailcom> 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] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Chris Huff <chr### [at] yahoocom> 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

In article <38a97257@news.povray.org>, "Nathan Kopp" <Nat### [at] Koppcom> 
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] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message