![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Okay, so i've got this image, and i was hoping to do a difference of the
back wall (a union of these mesh bricks) with a cylinder-cube union to cut
away the wall, leaving an archway. now the bricks in the wall are individual
bricks, not a texture. the original brick was a rounded cube kind of thing i
made in Ray Dream, then exported with 3dWin4 to pov format.
i tried the difference, getting a warning message, but it proceeded to start
rendering. at an insanely slow rate. So i was wondering, is there a way to
keep the brick as a mesh, and use the cylinder-cube union object in some way
to dictate where not to place a brick?
on the other hand, if i use a regular primitive box object instead of a mesh
for the bricks, i could do a difference that would be more successfull (in
terms of rendering speed), right?
btw, this is my first extensive use of handcoding. so be gentle :)
gonna go post this question in the general forum too.
thanks,
ross
Post a reply to this message
Attachments:
Download 'round-sqr.jpg' (83 KB)
Preview of image 'round-sqr.jpg'
![round-sqr.jpg](/povray.binaries.images/attachment/%3C3bce2497%40news.povray.org%3E/round-sqr.jpg?preview=1)
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Bonzai has an interesting brick arch macro here:
http://www.b0n541.net/povray/povmacro.html
Ross Litscher wrote:
> Okay, so i've got this image, and i was hoping to do a difference of the
> back wall (a union of these mesh bricks) with a cylinder-cube union to cut
> away the wall, leaving an archway. now the bricks in the wall are individual
> bricks, not a texture. the original brick was a rounded cube kind of thing i
> made in Ray Dream, then exported with 3dWin4 to pov format.
>
> i tried the difference, getting a warning message, but it proceeded to start
> rendering. at an insanely slow rate. So i was wondering, is there a way to
> keep the brick as a mesh, and use the cylinder-cube union object in some way
> to dictate where not to place a brick?
>
> on the other hand, if i use a regular primitive box object instead of a mesh
> for the bricks, i could do a difference that would be more successfull (in
> terms of rendering speed), right?
>
> btw, this is my first extensive use of handcoding. so be gentle :)
>
> gonna go post this question in the general forum too.
>
> thanks,
> ross
>
> [Image]
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Wasn't it Ross Litscher who wrote:
>Okay, so i've got this image, and i was hoping to do a difference of the
>back wall (a union of these mesh bricks) with a cylinder-cube union to cut
>away the wall, leaving an archway. now the bricks in the wall are individual
>bricks, not a texture. the original brick was a rounded cube kind of thing i
>made in Ray Dream, then exported with 3dWin4 to pov format.
>
>i tried the difference, getting a warning message, but it proceeded to start
>rendering. at an insanely slow rate. So i was wondering, is there a way to
>keep the brick as a mesh, and use the cylinder-cube union object in some way
>to dictate where not to place a brick?
>
>on the other hand, if i use a regular primitive box object instead of a mesh
>for the bricks, i could do a difference that would be more successfull (in
>terms of rendering speed), right?
>
>btw, this is my first extensive use of handcoding. so be gentle :)
Firstly, it would be useful to know what the warning was, and what the
code was that provoked it.
Secondly, differencing with collections of many small objects can
sometimes defeat POVRay's automatic bounding algorithm. Effectively you
end up with POV having to check every brick for every ray, rather than
only those that bricks that are close to the ray.
I'd suggest that you try converting it from
difference {
union {
lots of {
individual_brick
}
}
arch
}
to
union {
lots of {
difference {
individual_brick
arch
}
}
}
Which will probably allow POV to apply sensible automatic bounds around
each brick.
Keep an eye on the statistics in the Messages pane. You want to see lots
of bounds tests and few "rounded cube kind of thing" tests (because they
are probably expensive.)
--
Mike Williams
Gentleman of Leisure
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> [...] So i was wondering, is there a way to
> keep the brick as a mesh, and use the cylinder-cube union object in some way
> to dictate where not to place a brick?
Hmmm... seems I've a fixation with trace(), but I'm envisioning a nice
use for it here. You can have some "reference" objects behind the "wall"
plane, and then use a #while loop to place the bricks, tracing first a
ray perpendicular to the wall plane, to see if it intersect with the
"reference" objects. Then you end having a "individual-bricks" wall,
with holes "replicating" the reference objects behind. It would leave
some work to do with the edges, but then you can place your
windows/door/whatever into the holes, with enough "frame" width. Sounds
reasonable... must try it later.
--
Jaime Vives Piqueres
La Persistencia de la Ignorancia
http://www.ignorancia.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
thanks all for the ideas. i think this sounds like what i had in mind.
i'l have to go read up on trace(). this was a megapov feature that got
put into 3.5, right?
btw, the warning was something like "Cannot use patch objects in
intersection".
thanks,
ross.
> Hmmm... seems I've a fixation with trace(), but I'm envisioning a nice
> use for it here. You can have some "reference" objects behind the "wall"
> plane, and then use a #while loop to place the bricks, tracing first a
> ray perpendicular to the wall plane, to see if it intersect with the
> "reference" objects. Then you end having a "individual-bricks" wall,
> with holes "replicating" the reference objects behind. It would leave
> some work to do with the edges, but then you can place your
> windows/door/whatever into the holes, with enough "frame" width. Sounds
> reasonable... must try it later.
>
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Wasn't it Ross Litscher who wrote:
>thanks all for the ideas. i think this sounds like what i had in mind.
>i'l have to go read up on trace(). this was a megapov feature that got
>put into 3.5, right?
>
>btw, the warning was something like "Cannot use patch objects in
>intersection".
Sounds like those bricks might have been meshes rather than solid
objects then. Meshes are not supposed to work properly in differences
and intersections.
--
Mike Williams
Gentleman of Leisure
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |