 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 01.12.2017 14:56, clipka 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.
Yes, I understood that already. :-)
---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 01/12/2017 à 13:46, Bald Eagle a écrit :
> 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.
>
>
I second CLipka: it's technically impossible.
You can do it when all you have is mesh of triangles, but that's not
what POV-Ray is made of.
And if you want to manipulate meshes, you'd better do it in one of the
nice visual editors that exist. (I'm familiar with meshlab, but that's
not the only one)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 02/12/2017 09:18, Le_Forgeron wrote:
> And if you want to manipulate meshes, you'd better do it in one of the
> nice visual editors that exist. (I'm familiar with meshlab, but that's
> not the only one)
Blender has a modifier called "Solidify" which does that very thing.
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 17-12-02 à 04:57, Stephen a écrit :
> On 02/12/2017 09:18, Le_Forgeron wrote:
>> And if you want to manipulate meshes, you'd better do it in one of the
>> nice visual editors that exist. (I'm familiar with meshlab, but that's
>> not the only one)
>
> Blender has a modifier called "Solidify" which does that very thing.
>
Yes, and it only work when you are using meshes.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 02/12/2017 18:58, Alain wrote:
> Le 17-12-02 à 04:57, Stephen a écrit :
>> On 02/12/2017 09:18, Le_Forgeron wrote:
>>> And if you want to manipulate meshes, you'd better do it in one of the
>>> nice visual editors that exist. (I'm familiar with meshlab, but that's
>>> not the only one)
>>
>> Blender has a modifier called "Solidify" which does that very thing.
>>
>
> Yes, and it only work when you are using meshes.
Isn't that what you were talking about in what I quoted?
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12/01/2017 07:03 AM, 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".
No, no, no, no, NO!
This is not the purpose of the 'hollow' keyword, as you have indicated
that you understand, elsewhere in this thread. In addition to the
prohibitive difficulty in implementing such a feature, it would just add
to the confusion over the purpose of 'hollow', a confusion that is
acknowledged even in the documentation (Questions and Tips, formerly in
the tutorial, but now in the online knowledge base).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Happy to see, that we get now, despite the technical hurdles, an
interesting discussion coming up. I will follow. :-)
---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 02.12.2017 15:10, Cousin Ricky wrote:
> No, no, no, no, NO!
Noted. :-)
---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> 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.
Hi, this is my first post to this group. You did wonderful job ;)
To the point. Yes, I've attempted to do that, called it "thick wall style". It
was part of a project of visualization of uncertainty, namely structure of
cardiac veins (yes, POVRay may be used as a scientific tool ;) or just interval
data.
It is really hard to do that without artifacts.
Ref:
http://ieeexplore.ieee.org/document/7973435/ DOI:10.23919/MIPRO.2017.7973435
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> 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.
If you can make an isosurface out of it, then it's possible to make an 'offset
surface' general solution, which can be combined with CSG to create the skin.
Caveat: it might be slow to render, especially if you're using several 'power'
functions for smooth transitions.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"MessyBlob" <nomail@nomail> wrote:
> If you can make an isosurface out of it, then it's possible to make an 'offset
> surface' general solution, which can be combined with CSG to create the skin.
> Caveat: it might be slow to render, especially if you're using several 'power'
> functions for smooth transitions.
In order to have a "general" solution - you'd have to process what to do with
the offset result of convex regions.
And I can assure you that's not trivial.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
