POV-Ray : Newsgroups : povray.beta-test : SUGGESTION: Hollow 0.05 Server Time
21 Dec 2024 11:52:40 EST (-0500)
  SUGGESTION: Hollow 0.05 (Message 1 to 10 of 21)  
Goto Latest 10 Messages Next 10 Messages >>>
From: Sven Littkowski
Subject: SUGGESTION: Hollow 0.05
Date: 1 Dec 2017 06:04:03
Message: <5a213723$1@news.povray.org>
Hi,

the "hollow" keyword makes a shape hollow. My suggestion is, to make it
possible to add behind this keyword a small number that specifies a
"wall thickness".

Example:

sphere
{
 0.0, 1.0
 hollow 0.05
 ...
}

This would make the sphere hollow but keeps an inner wall thickness of
0.05 units.

Such a new way to specify wall thickness could make it easier than the
"difference" method, to get complicated shapes becoming hollow.

---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com


Post a reply to this message

From: Sven Littkowski
Subject: Re: SUGGESTION: Hollow 0.05
Date: 1 Dec 2017 06:06:14
Message: <5a2137a6$1@news.povray.org>
A related suggestion:

further adding some additional keywords behind "hollow" and its
suggested number, like certain patterns, creates special inside-wall 3D
structures, like rough rock, tiles, and such.

---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com


Post a reply to this message

From: Stephen
Subject: Re: SUGGESTION: Hollow 0.05
Date: 1 Dec 2017 06:32:24
Message: <5a213dc8$1@news.povray.org>
On 01/12/2017 11:03, Sven Littkowski wrote:
> the "hollow" keyword makes a shape hollow. My suggestion is, to make it
> possible to add behind this keyword a small number that specifies a
> "wall thickness".

Hollow is probably not the best word to use. It gives the wrong 
connotations. Maybe "media_container" would be a better keyword.

-- 

Regards
     Stephen


Post a reply to this message

From: clipka
Subject: Re: SUGGESTION: Hollow 0.05
Date: 1 Dec 2017 07:29:05
Message: <5a214b11$1@news.povray.org>
Am 01.12.2017 um 12:03 schrieb Sven Littkowski:

> the "hollow" keyword makes a shape hollow. My suggestion is, to make it
> possible to add behind this keyword a small number that specifies a
> "wall thickness".
> 
> Example:
> 
> sphere
> {
>  0.0, 1.0
>  hollow 0.05
>  ...
> }

I guess you're misunderstanding the keyword (don't worry, everyone does).

When you specify `hollow on`, this changes nothing except that media
effects are enabled inside the object (both the object's own media, as
well as the media of any other objects it is embedded in, and the
general atmospheric media).

When you specify `hollow off` (or nothing) instead, the object will
knock out any media effects (including its own), effectively creating a
"bubble" of perfectly clear air (as far as media is concerned).


> This would make the sphere hollow but keeps an inner wall thickness of
> 0.05 units.

That's technically impossible.

(Well, strictly speaking something along the lines may be possible for
spheres, but it can't be generalized to arbitrary primitives.)


Post a reply to this message

From: Bald Eagle
Subject: Re: SUGGESTION: Hollow 0.05
Date: 1 Dec 2017 07:50:00
Message: <web.5a214f0b627182d0c437ac910@news.povray.org>
clipka <ano### [at] anonymousorg> wrote:

> > This would make the sphere hollow but keeps an inner wall thickness of
> > 0.05 units.
>
> That's technically impossible.
>
> (Well, strictly speaking something along the lines may be possible for
> spheres, but it can't be generalized to arbitrary primitives.)

Well, technically it's possible, and practically it's done.
This is a type of thing called an "offset curve" - such as what Dave Blandston
does with his fancy text.  This is a feature available in graphics programs,
probably Mathematica, CAD software, and Silhouette / Cricut type design
programs.

The problem of course is writing a robust algorithm that does what you expect it
to do given some general, unknown input.
Doing this with a convex hull of points like "O" is fairly easy, the real
problems of course come with concave shapes like "C" where things start to
collide --- and then what?

It would be a NICE feature - but it's anything but trivial to code, which is why
it's usually only seen in commercial software packages, and you almost always
have to pay extra for a "pro" or "plus" version to have that functionality.


Post a reply to this message

From: Bald Eagle
Subject: Re: SUGGESTION: Hollow 0.05
Date: 1 Dec 2017 08:00:01
Message: <web.5a2151de627182d0c437ac910@news.povray.org>
This is something that really highlights the do-it-yourself (DIY) nature of
making scenes with POV-Ray - especially the hand-coded SDL type.

When confronted with a scenario such as Sven's, the instinctual, naive approach
is to simply subtract a slightly scaled down version of the larger object.
The problem is that it's usually a complex shape - so --- exactly where is the
"center"?
The second problem is that the offset-curve has to be offset in all directions -
which reveals the true complexity of performing such an operation, and why a
simple scaling is a naive approach, doomed to certain failure.
Translate it one way, and "this" overlaps.  Translate it another way, and "that"
overlaps.   It's a no-win situation.

What would be required with some CSG objects composed of primitives would be to
define a second set of primitives that are scaled relative to their own
"centers", and then subtract a union of these from the union of the original
primitives.
This of course does not guarantee success - as there is still the "convex"
problem.
Picture an intersecting sphere and cylinder, rather like a "Q" (It intersects on
the typeface of my keyboard).
You could get a hollow cylinder following the above plan, but as soon as you
subtracted the scaled-down sphere, you'd truncate the portion of the cylinder
inside the sphere.


Post a reply to this message

From: clipka
Subject: Re: SUGGESTION: Hollow 0.05
Date: 1 Dec 2017 08:01:04
Message: <5a215290$1@news.povray.org>
Am 01.12.2017 um 13:46 schrieb Bald Eagle:
> clipka <ano### [at] anonymousorg> wrote:
> 
>>> This would make the sphere hollow but keeps an inner wall thickness of
>>> 0.05 units.
>>
>> That's technically impossible.
>>
>> (Well, strictly speaking something along the lines may be possible for
>> spheres, but it can't be generalized to arbitrary primitives.)
> 
> Well, technically it's possible, and practically it's done.
> This is a type of thing called an "offset curve" - such as what Dave Blandston
> does with his fancy text.  This is a feature available in graphics programs,
> probably Mathematica, CAD software, and Silhouette / Cricut type design
> programs.
> 
> The problem of course is writing a robust algorithm that does what you expect it
> to do given some general, unknown input.
> Doing this with a convex hull of points like "O" is fairly easy, the real
> problems of course come with concave shapes like "C" where things start to
> collide --- and then what?
> 
> It would be a NICE feature - but it's anything but trivial to code, which is why
> it's usually only seen in commercial software packages, and you almost always
> have to pay extra for a "pro" or "plus" version to have that functionality.

As I wrote: It can't be generalized. You'd need to implement such a
feature for each and every primitive type separately.

Also, in some cases you'd need to use more complex math than normally
required by the underlying primitives. For instance, the offset curve to
a 3rd order polynomial spline (such as a bezier spline) can't be
represented as a 3rd order polynomial spline itself (except in special
cases).


Post a reply to this message

From: Sven Littkowski
Subject: Re: SUGGESTION: Hollow 0.05
Date: 1 Dec 2017 14:38:33
Message: <5a21afb9$1@news.povray.org>
On 01.12.2017 07:58, Bald Eagle wrote:
> This is something that really highlights the do-it-yourself (DIY) nature 
of
> making scenes with POV-Ray - especially the hand-coded SDL type.
> 
> When confronted with a scenario such as Sven's, the instinctual, naive ap
proach
> is to simply subtract a slightly scaled down version of the larger object
.
> The problem is that it's usually a complex shape - so --- exactly where i
s the
> "center"?
> The second problem is that the offset-curve has to be offset in all direc
tions -
> which reveals the true complexity of performing such an operation, and wh
y a
> simple scaling is a naive approach, doomed to certain failure.
> Translate it one way, and "this" overlaps.  Translate it another way, and
 "that"
> overlaps.   It's a no-win situation.
> 
> What would be required with some CSG objects composed of primitives would
 be to
> define a second set of primitives that are scaled relative to their own
> "centers", and then subtract a union of these from the union of the origi
nal
> primitives.
> This of course does not guarantee success - as there is still the "convex
"
> problem.
> Picture an intersecting sphere and cylinder, rather like a "Q" (It inters
ects on
> the typeface of my keyboard).
> You could get a hollow cylinder following the above plan, but as soon as 
you
> subtracted the scaled-down sphere, you'd truncate the portion of the cyli
nder
> inside the sphere.

Yes, exactly that happens with a DIFFERENCE on a complex combined shape
that I currently try to use for a complex shape, that is how i got the
idea to suggest this HOLLOW feature. :-(


---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com


Post a reply to this message

From: clipka
Subject: Re: SUGGESTION: Hollow 0.05
Date: 1 Dec 2017 14:56:30
Message: <5a21b3ee@news.povray.org>
Am 01.12.2017 um 20:38 schrieb Sven Littkowski:

> Yes, exactly that happens with a DIFFERENCE on a complex combined shape
> that I currently try to use for a complex shape, that is how i got the
> idea to suggest this HOLLOW feature. :-(

... and the reason you're having trouble with this use case is pretty
much the same reason why that suggested feature would be darn difficult
to implement as well.


Post a reply to this message

From: Bald Eagle
Subject: Re: SUGGESTION: Hollow 0.05
Date: 1 Dec 2017 15:20:01
Message: <web.5a21b8c0627182d0c437ac910@news.povray.org>
clipka <ano### [at] anonymousorg> wrote:

> ... and the reason you're having trouble with this use case is pretty
> much the same reason why that suggested feature would be darn difficult
> to implement as well.

Right.
A first step towards a solution would essentially accomplish an efficient
meshification of the object - which may be what Sven might want to play with.

Then you'd translate the points along the normal vector to expand/shrink the
object as a 3D offset-curve.

NOT trivial.


Post a reply to this message

Goto Latest 10 Messages Next 10 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.