 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
SAS wrote:
> Achill wrote:
>
>
>>>Let's say we have a unit cube between <0,0,0> and <1,1,1> and a sphere at
>>><0,0,0> with radius 1. What is the 'vector sum' of these objects?
>>
>>As far as I understand the macro
>>"Round_Box_Union(PtA, PtB, EdgeRadius)",
>>it would be "Round_Box_Union(<0,0,0>, <1,1,1>, 1)".
>
>
> It would be Round_Box_Union(<-1,-1,-1>, <2,2,2>, 1), because the
> Round_Box macros cut away from the specified box, rather than
> adding to it.
So I did not understand the macro too far... :-)
Should have tried before mailing...
Achill
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3EA### [at] ma tumde>, Achill <ach### [at] matumde>
wrote:
> > Let's say we have a unit cube between <0,0,0> and <1,1,1> and a sphere at
> > <0,0,0> with radius 1. What is the 'vector sum' of these objects?
>
> As far as I understand the macro
> "Round_Box_Union(PtA, PtB, EdgeRadius)",
> it would be "Round_Box_Union(<0,0,0>, <1,1,1>, 1)".
The vector sum of a sphere and a box is 3 boxes, 8 spheres, and 12
cylinders?
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff wrote:
> In article <3EA### [at] matumde>, Achill <ach### [at] matumde>
> wrote:
>
>
>>>Let's say we have a unit cube between <0,0,0> and <1,1,1> and a sphere at
>>><0,0,0> with radius 1. What is the 'vector sum' of these objects?
>>
>>As far as I understand the macro
>>"Round_Box_Union(PtA, PtB, EdgeRadius)",
>>it would be "Round_Box_Union(<0,0,0>, <1,1,1>, 1)".
>
>
> The vector sum of a sphere and a box is 3 boxes, 8 spheres, and 12
> cylinders?
Its the union of them, yes.
That is a consequence of the so called "Steiner Theorem" in "convex
geometry".
Achill
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff wrote:
> In article <3EA### [at] matumde>, Achill <ach### [at] matumde>
> wrote:
>
> I think you need to learn more about how raytracing works.
That is certainly true --- as it is with most things... :-)
(That's why I am posting to "newusers".)
> POV can not
> take the "vector sum of all points on an object", because it doesn't
> know all points on the object. Raytracing works by finding the
> intersection point of rays with surfaces, the various shape types use a
> wide variety of methods to do this, ranging from simple geometric
> formulas to complex root-finding algorithms. You can't just add these
> intersection finding algorithms together to get a new one.
>
> Your idea seems to depend on having two sets of points and resulting in
> a third set, POV does not have the first two sets and wouldn't be able
> to do anything with the third (though there is a method for raytracing
> point fields that might be useful with this, it is not currently
> implemented in POV).
I saw on http://www.f-lohmueller.de/pov_tut/csg/povcsg1e.htm that CSG
operations may be used with all shapes which have a clear defined
"inside" and "outside", in particular with solids. My idea was that it
should be possible to determine "inside" and "outside" of the sum (at
least for the sum of solids) as well...?!?
I must admit, I do not know how povray "knows" to distiguish "inside"
and "outside".
> Yes, a general rounding algorithm would be nice sometimes, but it is not
> possible without completely changing the way POV handles shapes. If it
> is ever added to POV, it will probably be a mesh processing feature.
I see that I will have to learn much more about povray and raytracing in
general... :-)
Achill
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 24 Apr 2003 16:11:30 +0200, Achill <ach### [at] matumde> wrote:
> I must admit, I do not know how povray "knows" to distiguish "inside"
> and "outside".
It's hardcoded definition of each primitive object. Like math representation of
its surface, function to calculate normal vectors, mapping uv space on its
surface etc.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3EA### [at] matumde>, Achill <ach### [at] matumde>
wrote:
> Its the union of them, yes.
> That is a consequence of the so called "Steiner Theorem" in "convex
> geometry".
And how do you compute a union of primitives equivalent to a given "sum"
of objects? Your reasoning process seems to have been "it will make a
rounded box, and here's a rounded box macro".
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3EA### [at] matumde>, Achill <ach### [at] matumde>
wrote:
> I saw on http://www.f-lohmueller.de/pov_tut/csg/povcsg1e.htm that CSG
> operations may be used with all shapes which have a clear defined
> "inside" and "outside", in particular with solids. My idea was that it
> should be possible to determine "inside" and "outside" of the sum (at
> least for the sum of solids) as well...?!?
>
> I must admit, I do not know how povray "knows" to distiguish "inside"
> and "outside".
It can check whether a given point is inside or outside the object,
using a hard-coded object-specific algorithm. How does that help? It
doesn't get you any closer to summing objects.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 24 Apr 2003 11:51:09 -0400, Christopher James Huff
<cja### [at] earthlinknet> wrote:
> Your reasoning process seems to have been "it will make a
> rounded box, and here's a rounded box macro".
That's me who suggested that macro. When I refered to it I wasn't sure if he is
interested in METHOD or RESULT of his description. Since there was no way to
duplicate METHOD in universal way I could only help with referring tool where
similiar RESULT he described was achived. As to the newuser who come here to
achive something I showed him shortest way to achive RESULT he described in
example. I thought it could save him learning of full POV SDL power.
I'm still not sure if he is rather interested in RESULT of specific case of his
sum or in general METHOD. I hope my hints helped him and I hope you are not
angry that I answered instead of licensed TAG member ;-)
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <h32gavo8csv7vcgefdsi0fl3ei8orr0cdq@4ax.com>,
ABX <abx### [at] abxartpl> wrote:
> That's me who suggested that macro. When I refered to it I wasn't sure if he
> is interested in METHOD or RESULT of his description.
Oh, sorry about that then.
> I'm still not sure if he is rather interested in RESULT of specific
> case of his sum or in general METHOD. I hope my hints helped him and
> I hope you are not angry that I answered instead of licensed TAG
> member ;-)
The TAG does not have any exclusive rights on giving help. ;-)
Anyway, I've been assuming he wants a general "sum" object similar to
the CSG union object. In this case, a way of finding an intersection
between a ray and the sum of the objects is necessary. The given
descriptions involve adding points on the objects together to get new
points, but POV doesn't have those points in the first place, it finds
them as necessary using object-specific methods. The original poster
asked about insideness testing...each object has a function that can
determine if a given point is inside it, which doesn't seem at all
helpful for this.
It might be possible to find a large enough number of points do get fair
approximations of the surfaces by randomly tracing rays at the objects.
You could then operate on these point fields and either patch POV to
render them directly (there are algorithms for directly raytracing point
fields) or convert them into a mesh. I'm not sure how good the results
will look, and you will need to handle a *lot* of points. The original
poster seems to be expecting something more like a CSG operation, which
is just impossible as far as I can tell. The macro mentioned can do it,
but it was created by hand...I see no way of telling a program to
combine arbitrary shapes and get a composite of several objects of
different types (spheres, boxes, and cylinders in this case) as a result.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff wrote:
> In article <h32gavo8csv7vcgefdsi0fl3ei8orr0cdq@4ax.com>,
> ABX <abx### [at] abxartpl> wrote:
>
>
>>That's me who suggested that macro. When I refered to it I wasn't sure if he
>>is interested in METHOD or RESULT of his description.
>
>
> Oh, sorry about that then.
>
>
>
>>I'm still not sure if he is rather interested in RESULT of specific
>>case of his sum or in general METHOD. I hope my hints helped him and
>>I hope you are not angry that I answered instead of licensed TAG
>>member ;-)
>
>
> The TAG does not have any exclusive rights on giving help. ;-)
>
> Anyway, I've been assuming he wants a general "sum" object similar to
> the CSG union object. In this case, a way of finding an intersection
> between a ray and the sum of the objects is necessary. The given
> descriptions involve adding points on the objects together to get new
> points, but POV doesn't have those points in the first place, it finds
> them as necessary using object-specific methods. The original poster
> asked about insideness testing...each object has a function that can
> determine if a given point is inside it, which doesn't seem at all
> helpful for this.
>
> It might be possible to find a large enough number of points do get fair
> approximations of the surfaces by randomly tracing rays at the objects.
> You could then operate on these point fields and either patch POV to
> render them directly (there are algorithms for directly raytracing point
> fields) or convert them into a mesh.
Converting arbitrary point sets into meshes or surfaces is a difficult
task (known as "surface reconstruction"). Are there algorithms for this
task used with (or in) povray?
> I'm not sure how good the results
> will look, and you will need to handle a *lot* of points. The original
> poster seems to be expecting something more like a CSG operation, which
> is just impossible as far as I can tell. The macro mentioned can do it,
> but it was created by hand...I see no way of telling a program to
> combine arbitrary shapes and get a composite of several objects of
> different types (spheres, boxes, and cylinders in this case) as a result.
>
I agree... :-)
Achill
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
