 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hello,
As the subject indicates, the goal is to create a "slice" of the disk.
With this macro, everything works fine (image on the left)
#macro corner(r,e,a)
#if(a<360)
difference {
cylinder { <0, -e, 0>, <0, e, 0>, r }
object { complementWedge(a) }
}
#else
cylinder { <0, -e, 0>, <0, e, 0>, a }
#end
#end
The same macro but using the "disc" object show the issue
(image on the right)
#macro corner(r,e,a)
#if(a<360)
difference {
disc { <0,0,0>, y, r }
object { complementWedge(a) }
}
#else
disc { <0,0,0>, y, r }
#end
#end
With the help of this macro :
#macro complementWedge(a)
object {
Wedge(360-a)
rotate a*y
}
#end
Bug ?
Note that the use of cylinder does not bother me more than that.
--
Kurtz le pirate
Compagnie de la Banquise
Post a reply to this message
Attachments:
Download 'issue.jpg' (29 KB)
Preview of image 'issue.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
kurtz le pirate <kur### [at] gmail com> wrote:
> The same macro but using the "disc" object show the issue
That's pretty weird.
What is "Wedge"? Without that, it's hard to definitively debug this.
- BW
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/10/23 10:49, kurtz le pirate wrote:
> The same macro but using the "disc" object show the issue
> (image on the right)
I believe what your are seeing is the fact the disc, like the plane, is
defined in the code as having and inside (as being a 'basic object'
rather than a 'patch object') so it can be used in CSG.
Neither the disc or plane have an actual finite inside. But, with the
plane especially it's convenient to use it when defining many objects
via csg - though the bounding of the result is often bad (infinite in
some aspect or in total).
The disc being set up in a similar manner to the plane is questionable
in my opinion. Perhaps when it got done 30 plus years ago it made more
sense to do it. There have long been scenes where the disc 'is' getting
used in csg & it's been left as is rather than treating it a pure,
finite patch object.
Aside: The documentation says the disc's inside is no different than a
plane's, but your image makes me wonder if it's not constrained to the
radius of the disc in at least some aspects. Maybe due the
inside/outside csg status flips somehow? There is not a completely,
surface bounded inside region in your example, but it kinda looks like
there is(a).
(a) - Maybe rays are constrained to the disc if they travel through the
plane in which the disc sits though the insided-ness is still like the
plane's when that inside test is run...
Don't know. I've never gone through the disc code in detail & never used
it myself, IIRC, unless it was in code I picked up somewhere. Kinda want
to play a little with it as I wonder, but, have not the time now.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/10/23 14:38, William F Pokorny wrote:
>> The same macro but using the "disc" object show the issue
>> (image on the right)
>
> I believe what your are seeing is the fact the disc, like the plane, is
> defined in the code as having and inside (as being a 'basic object'
> rather than a 'patch object') so it can be used in CSG.
Just hit me I forgot to answer Bald Eagles 'Wedge' question.
It's a macro shipped with POV-Ray which uses the intersections (and
perhaps differences) of two planes to create a wedge (pie slice region)
of space which is usually used in a follow on intersection (or
difference) with other stuff.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William F Pokorny <ano### [at] anonymousorg> wrote:
> I believe what your are seeing is the fact the disc, like the plane, is
> defined in the code as having and inside (as being a 'basic object'
> rather than a 'patch object') so it can be used in CSG.
That's certainly what it looks like to me. That slice is HUGE.
Thanks for the pointer to Wedge () - I thought it was in one of those inc files,
but wasn't sure where. It's shapes.inc
Simply adding clipped_by and bounded_by makes for a quick fix/workaround
//The same macro but using the "disc" object show the issue
//(image on the right)
#macro corner2 (r,e,a)
#if(a<360)
difference {
disc { <0,0,0>, y, r }
object { complementWedge(a) }
clipped_by {box {<-r, -e, -r>, <r, e, r>}}
bounded_by {clipped_by}
}
#else
disc { <0,0,0>, y, r }
#end
#end
- BW
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/11/23 06:40, Bald Eagle wrote:
>> I believe what your are seeing is the fact the disc, like the plane, is
>> defined in the code as having and inside (as being a 'basic object'
>> rather than a 'patch object') so it can be used in CSG.
> That's certainly what it looks like to me. That slice is HUGE.
Thanks for the confirmation.
I spent a little time this morning looking at the code and playing. It
turns out the disc is auto bounded using the radius & other info - as it
can. Where flat relative to the x,z plane the box y min and max values
are set to the initial vector, y value. x and z to the +-r, +-r values.
The automatic bounding box has is infinitely thin and it is rays hitting
this box determine when we look for ray -> surface intersections.
The bounding determination, where things are not simple in being at the
origin and axis aligned, is more complicated.
An alternative to clipping the ray-surface intersections internal to a
shape, would be to use two opposing discs with a very small space
between them (tiny inside sliver region) like this:
#declare DiscOrigin = <0,0,0>;
#declare DiscNormal = <0,1,-1>;
#declare I01 = intersection {
Wedge(275)
disc {
DiscOrigin+(+1e-8*DiscNormal),
+1*DiscNormal, 1, 0.5 }
disc {
DiscOrigin+(-1e-8*DiscNormal),
-1*DiscNormal, 1, 0.5 }
pigment { color Green }
}
This, as a generic approach, is likely more stable numerically as any
'edge noise' has to happen between the to opposing discs. Remembering
here too discs can have holes.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 13/04/2023 13:50, William F Pokorny wrote:
> On 4/11/23 06:40, Bald Eagle wrote:
>>> I believe what your are seeing is the fact the disc, like the plane, is
>>> defined in the code as having and inside (as being a 'basic object'
>>> rather than a 'patch object') so it can be used in CSG.
>
>> That's certainly what it looks like to me. That slice is HUGE.
>
> Thanks for the confirmation.
>
> I spent a little time this morning looking at the code and playing. It
> turns out the disc is auto bounded using the radius & other info - as it
> can. Where flat relative to the x,z plane the box y min and max values
> are set to the initial vector, y value. x and z to the +-r, +-r values.
> The automatic bounding box has is infinitely thin and it is rays hitting
> this box determine when we look for ray -> surface intersections.
>
> The bounding determination, where things are not simple in being at the
> origin and axis aligned, is more complicated.
>
> An alternative to clipping the ray-surface intersections internal to a
> shape, would be to use two opposing discs with a very small space
> between them (tiny inside sliver region) like this:
>
> #declare DiscOrigin = <0,0,0>;
> #declare DiscNormal = <0,1,-1>;
> #declare I01 = intersection {
> Wedge(275)
> disc {
> DiscOrigin+(+1e-8*DiscNormal),
> +1*DiscNormal, 1, 0.5 }
> disc {
> DiscOrigin+(-1e-8*DiscNormal),
> -1*DiscNormal, 1, 0.5 }
> pigment { color Green }
> }
>
> This, as a generic approach, is likely more stable numerically as any
> 'edge noise' has to happen between the to opposing discs. Remembering
> here too discs can have holes.
>
> Bill P.
>
Thank Bill for all these explanations. But as I said, using the cylinder
instead of the disc does the job perfectly.
@Bald Eagles : shapes.inc contains some interesting macros.
I'm surprised you don't know ;)
--
Kurtz le pirate
Compagnie de la Banquise
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
