Hi all,

I've been working on an idea to give my various spaceships "shields" via a
shield macro. You should find three attachments:

1) Shield_off.jpg - the test object without shield.

2) Shield_on.jpg - the test object with shield. (In this example the shield
is filled with emission/absorption media with values to enhance the
visibility of the edges.)

3) shield.zip - zipped copy of shield.pov

The macro relies on the trace() function in MegaPov, the Shield_on.jpg
example uses the solid mesh capabilities of MegaPov to fill the generated
mesh with media.

Justin

Post a reply to this message

Attachments:
Download 'shield_off.jpg' (5 KB) Download 'shield_on.jpg' (6 KB) Download 'shield.zip' (3 KB)

Preview of image 'shield_off.jpg'

Preview of image 'shield_on.jpg'

Super_Kewl

Thanks a lot,

Peter Warren
war### [at] hotmailcom

Post a reply to this message

Innovative, as Bill Gates might say.  Seems the ship is getting obscured a lot,
shouldn't it be more visible?  Other than that this is great.

Bob

"Justin Whitton" <jus### [at] bigfootcom> wrote in message
news:3898cbd1@news.povray.org...
| Hi all,
|
| I've been working on an idea to give my various spaceships "shields" via a
| shield macro. You should find three attachments:
|
| 1) Shield_off.jpg - the test object without shield.
|
| 2) Shield_on.jpg - the test object with shield. (In this example the shield
| is filled with emission/absorption media with values to enhance the
| visibility of the edges.)
|
| 3) shield.zip - zipped copy of shield.pov
|
| The macro relies on the trace() function in MegaPov, the Shield_on.jpg
| example uses the solid mesh capabilities of MegaPov to fill the generated
| mesh with media.
|
| Justin

Post a reply to this message

In article <3898cbd1@news.povray.org>, "Justin Whitton" 
<jus### [at] bigfootcom> wrote:

> Hi all,
> 
> I've been working on an idea to give my various spaceships "shields" 
> via a shield macro. You should find three attachments:
> 
> 1) Shield_off.jpg - the test object without shield.
> 
> 2) Shield_on.jpg - the test object with shield. (In this example the 
> shield is filled with emission/absorption media with values to 
> enhance the visibility of the edges.)
> 
> 3) shield.zip - zipped copy of shield.pov
> 
> The macro relies on the trace() function in MegaPov, the 
> Shield_on.jpg example uses the solid mesh capabilities of MegaPov to 
> fill the generated mesh with media.


This is one of the things I designed my proximity pattern for...it is 
included in the latest release of MegaPOV, you might want to have a look 
at it. It is probably slower than this method, though...

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Bob Hughes wrote in message <38994152@news.povray.org>...
>Innovative, as Bill Gates might say.  Seems the ship is getting obscured a
lot,
>shouldn't it be more visible?  Other than that this is great.
>

The macro creates a mesh surrounding the object. The visibility is then
defined by what texture and interior you apply to the mesh. In the examples
posted I filled the interior with a media that enhanced the viewing edges of
the mesh to show the shape.

When I render with more "shieldish" textures the shape is not readily seen.
(Most shields/forcefields don't appear to have an interior.)

Justin

Post a reply to this message

Chris Huff wrote in message ...
>
>This is one of the things I designed my proximity pattern for...it is
>included in the latest release of MegaPOV, you might want to have a look
>at it. It is probably slower than this method, though...
>

Chris,

I didn't see the proximity pattern when I did my glance through of features
in MegaPov 0.4. I could have saved myself all that coding by using the
proximity pattern as a pigment function in an ISO surface to get exactly
what I was after. (I was trying to get a real surface around the object,
although the proximity pattern will do when I only need an apparent surface
created from media.) Time to do a speed check and to see if I understand the
proximity docs properly.

Oh well, another short lived POV coding high for me.

Justin

Post a reply to this message

>It is probably slower than this method, though...


It's too slow for any practical use... at least on my computer. It chugs
away at very slooow speeds, like the old media. Can't you do something to
speed it up? I haven't been able to finish any of the demo files included.
:(

Post a reply to this message

In article <38998f02@news.povray.org>, "Justin Whitton" 
<jus### [at] bigfootcom> wrote:

> I didn't see the proximity pattern when I did my glance through of 
> features in MegaPov 0.4. I could have saved myself all that coding by 
> using the proximity pattern as a pigment function in an ISO surface 
> to get exactly what I was after. (I was trying to get a real surface 
> around the object, although the proximity pattern will do when I only 
> need an apparent surface created from media.) Time to do a speed 
> check and to see if I understand the proximity docs properly.

I still haven't done a test of using the proximity pattern in an 
isosurface, I am a bit afraid of how slow it might be.
One thing, media doesn't require as many proximity samples as an 
ordinary texture, since things get smoothed out along the media samples. 
An isosurface would probably need it as smooth(many samples) as possible 
for the solver to make any sense of things.

And your trace() + mesh technique certainly has possibilities...don't 
give up on it yet. :-)

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

In article <3899a328@news.povray.org>, "TonyB" 
<ben### [at] panamac-comnet> wrote:

> It's too slow for any practical use... at least on my computer. It chugs
> away at very slooow speeds, like the old media. Can't you do something to
> speed it up? I haven't been able to finish any of the demo files included.

What processor are you on? I have a 266 MHz PowerPC G3, and although it 
was slow, it wasn't too slow to be practical.
The demo scenes had a very high samples value, a lower value can lead to 
graininess but is much faster. Also, there are 3 different methods of 
shooting the rays: one is very slow for points far from the target 
object, but is the most accurate. Another one is faster, but doesn't 
give an even distribution of samples. The third one switches between the 
other two depending on where the point being evaluated is. It is faster 
outside the object bounding box and more accurate inside, but can 
sometimes leave artifacts around the boundary between the two types.

And I can't really do anything about the speed...it figures out how far 
it is from the parts of the object by shooting a bunch of rays at it. 
For simple things like spheres, this isn't a good method(spherical works 
fine), and many other objects could be approximated with function 
patterns, but it is needed for complex CSG's and other objects.
Someone else who knows more advanced math might be able to find a better 
way...

Something I just thought of-you could use the trace function to place 
blob components for my blob pattern on the surface of the object. If you 
get the placement right, you could get a pretty good approximation of 
the proximity pattern. And although the blob pattern is still 
un-optimized, it would be faster.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

It'd be interesting to see an animated morph.

-- 
Cheers
Steve              email mailto:sjl### [at] ndirectcouk

%HAV-A-NICEDAY Error not enough coffee  0 pps. 

web http://www.ndirect.co.uk/~sjlen/

or  http://start.at/zero-pps

  3:00pm  up 23:38,  3 users,  load average: 1.01, 1.06, 1.03

Post a reply to this message