|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 29.08.2012 10:31, schrieb mathieu_r:
> Hi,
>
> Me again..
> Sorry if I post a lot..
That's what the newsgroups are there for :-)
> I wanted to clip a height_field by a box using clipped_by but it doesn't work
Can you be more specific about the "doesn't work" part?
The difference between intersection and clipped_by is that an
intersection will generate new surfaces where the original object is cut
apart, while clipped_by will let you look inside the object as if it was
just a hollow shell.
> However, intersection works. Intersection isn't the best, I think, for that
> purpose?
If it works, it works.
> clipped_by or bounding-by seems more convenient.
Do /not/ use bounded_by for such purposes. It is intended solely as a
hint for the renderer about how big (and where) a complicated object
actually is, to speed up finding the object's surface. Any attempt to
use it for shaping your object /will/ lead to unexpected results.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ok, so Intersection seems the right way to do it.
I have another question:
I've intersected my height_field with my box. Ok but between my height_field and
the bottom of my box there is an empty gap. How to fill it? You know, like city
models
If possible with the same texture as the height_field object.
clipka <ano### [at] anonymousorg> wrote:
> Am 29.08.2012 10:31, schrieb mathieu_r:
> > Hi,
> >
> > Me again..
> > Sorry if I post a lot..
>
> That's what the newsgroups are there for :-)
>
> > I wanted to clip a height_field by a box using clipped_by but it doesn't work
>
> Can you be more specific about the "doesn't work" part?
>
> The difference between intersection and clipped_by is that an
> intersection will generate new surfaces where the original object is cut
> apart, while clipped_by will let you look inside the object as if it was
> just a hollow shell.
>
> > However, intersection works. Intersection isn't the best, I think, for that
> > purpose?
>
> If it works, it works.
>
> > clipped_by or bounding-by seems more convenient.
>
> Do /not/ use bounded_by for such purposes. It is intended solely as a
> hint for the renderer about how big (and where) a complicated object
> actually is, to speed up finding the object's surface. Any attempt to
> use it for shaping your object /will/ lead to unexpected results.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 29.08.2012 15:09, schrieb mathieu_r:
> Ok, so Intersection seems the right way to do it.
>
> I have another question:
>
> I've intersected my height_field with my box. Ok but between my height_field and
> the bottom of my box there is an empty gap. How to fill it? You know, like city
> models
>
> If possible with the same texture as the height_field object.
Intersect the height field with a slightly smaller box; i.e, instead of:
height_field {
...
texture { ... }
translate ... scale ... rotate ...
}
use the following:
intersection {
height_field { ... }
box { <0.0001, 0.0001, 0.0001>, <0.9999, 1.0001, 0.9999> }
texture { ... }
translate ... scale ... rotate ...
}
This works due to some inconsistency of the height_field object:
Although it lacks a visible bottom and sides, it is nonetheless
considered to be filling the entire space below the surface; so if you
cut off its "non-sides" and "non-bottom", you'll get visible surfaces at
the cuts.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nice! Thanks. It works!
clipka <ano### [at] anonymousorg> wrote:
> Am 29.08.2012 15:09, schrieb mathieu_r:
> > Ok, so Intersection seems the right way to do it.
> >
> > I have another question:
> >
> > I've intersected my height_field with my box. Ok but between my height_field and
> > the bottom of my box there is an empty gap. How to fill it? You know, like city
> > models
> >
> > If possible with the same texture as the height_field object.
>
> Intersect the height field with a slightly smaller box; i.e, instead of:
>
> height_field {
> ...
> texture { ... }
> translate ... scale ... rotate ...
> }
>
> use the following:
>
> intersection {
> height_field { ... }
> box { <0.0001, 0.0001, 0.0001>, <0.9999, 1.0001, 0.9999> }
> texture { ... }
> translate ... scale ... rotate ...
> }
>
> This works due to some inconsistency of the height_field object:
> Although it lacks a visible bottom and sides, it is nonetheless
> considered to be filling the entire space below the surface; so if you
> cut off its "non-sides" and "non-bottom", you'll get visible surfaces at
> the cuts.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Sorry, I come back..
Actually, filling my object is easier than making it empty..
To make it empty, I tried to clip my height_object with a sphere with a value of
transmit equal to 1.
But I can still see the sphere contours even if they're smoothened.
Maybe I didn't use the transmit keyword the right way?
Here is the code:
intersection {
height_field {
png
"IN\PNG\dem.png"
smooth
texture{
pigment {
White
}
finish {
ambient 0.1
diffuse 0.55
}
}
translate <-0.5,0,-0.48>
scale <14,4,14>
}
sphere {
<0, 1, 0>
5
pigment {
White
transmit 1
}
hollow on
}
}
"mathieu_r" <nomail@nomail> wrote:
> Nice! Thanks. It works!
>
> clipka <ano### [at] anonymousorg> wrote:
> > Am 29.08.2012 15:09, schrieb mathieu_r:
> > > Ok, so Intersection seems the right way to do it.
> > >
> > > I have another question:
> > >
> > > I've intersected my height_field with my box. Ok but between my height_field and
> > > the bottom of my box there is an empty gap. How to fill it? You know, like city
> > > models
> > >
> > > If possible with the same texture as the height_field object.
> >
> > Intersect the height field with a slightly smaller box; i.e, instead of:
> >
> > height_field {
> > ...
> > texture { ... }
> > translate ... scale ... rotate ...
> > }
> >
> > use the following:
> >
> > intersection {
> > height_field { ... }
> > box { <0.0001, 0.0001, 0.0001>, <0.9999, 1.0001, 0.9999> }
> > texture { ... }
> > translate ... scale ... rotate ...
> > }
> >
> > This works due to some inconsistency of the height_field object:
> > Although it lacks a visible bottom and sides, it is nonetheless
> > considered to be filling the entire space below the surface; so if you
> > cut off its "non-sides" and "non-bottom", you'll get visible surfaces at
> > the cuts.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 31.08.2012 13:17, schrieb mathieu_r:
> Sorry, I come back..
>
> Actually, filling my object is easier than making it empty..
>
> To make it empty, I tried to clip my height_object with a sphere with a value of
> transmit equal to 1.
Why not simply use clipped_by for that purpose?
> But I can still see the sphere contours even if they're smoothened.
Try explicitly specifying the sphere's finish as "ambient 0 diffuse 0
specular 0 phong 0 emission 0 reflection 0"; maybe some earlier
"default" statement is setting one of these values to non-zero by default.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Hi,
>
> Me again..
> Sorry if I post a lot..
>
> I wanted to clip a height_field by a box using clipped_by but it doesn't work
>
> height_field {
> png
> "IN\dem.png"
> smooth
> texture{
>
> pigment {
> White
> }
>
> finish {
> ambient 0.1
> diffuse 0.55
> } }
>
> clipped_by { box { <0,0,0>,<10,10,10 > }}
>
> translate <-0.5,0,-0.48>
> scale <14,4,14>
> }
>
> However, intersection works. Intersection isn't the best, I think, for that
> purpose? clipped_by or bounding-by seems more convenient.
>
>
>
> Mat
>
>
>
>
You clip your hight_field by a box that is 10 times to big.
You need to:
1 - make the box buch smaller.
OR
2 - Use your actual box AFTER you scale the hight_field, but before you
move it. Also, adjust the translate by your scale.
scale <14,4,14>
clipped_by { box { <0,0,0>,<10,10,10 > }}
translate <-0.5,0,-0.48>*14
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2-9-2012 20:23, Alain wrote:
> You clip your hight_field by a box that is 10 times to big.
>
> You need to:
> 1 - make the box buch smaller.
> OR
> 2 - Use your actual box AFTER you scale the hight_field, but before you
> move it. Also, adjust the translate by your scale.
>
> scale <14,4,14>
> clipped_by { box { <0,0,0>,<10,10,10 > }}
> translate <-0.5,0,-0.48>*14
>
>
Expanding a bit on this (see also the corresponding Docs paragraphs):
- A height_field starts as a 1x1x1 object. If you use clipped_by
/before/ scaling the height_field it should be smaller than the unit object.
- The order in which you perform the transformations is crucial and you
should always think about them as operating from the origin. The basic
order is /scale/ then /rotate/ then /translate/. Any other order will
lead to (possibly) unexpected results. Example:
box {-1, 1 rotate 45*y translate 10*x} will show a box rotated 45
degrees around the vertical axis and translated 10 units along the x-axis.
box {-1, 1 translate 10*x rotate 45*y} will rotate a box placed at 10
units on the +x-axis, 45 degrees towards the -z-axis.
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi,
I didn't know all of these prerequisites, in particular the scale / transmate
order.
I think that clipka's right. I'll try his solution, that is setting ambient,
diffuse, specular, phong,... to 0
I'll try this out and let you know.
Thanks for all your advice!
Mat
Thomas de Groot <tho### [at] degrootorg> wrote:
> On 2-9-2012 20:23, Alain wrote:
>
> > You clip your hight_field by a box that is 10 times to big.
> >
> > You need to:
> > 1 - make the box buch smaller.
> > OR
> > 2 - Use your actual box AFTER you scale the hight_field, but before you
> > move it. Also, adjust the translate by your scale.
> >
> > scale <14,4,14>
> > clipped_by { box { <0,0,0>,<10,10,10 > }}
> > translate <-0.5,0,-0.48>*14
> >
> >
> Expanding a bit on this (see also the corresponding Docs paragraphs):
>
> - A height_field starts as a 1x1x1 object. If you use clipped_by
> /before/ scaling the height_field it should be smaller than the unit object.
>
> - The order in which you perform the transformations is crucial and you
> should always think about them as operating from the origin. The basic
> order is /scale/ then /rotate/ then /translate/. Any other order will
> lead to (possibly) unexpected results. Example:
>
> box {-1, 1 rotate 45*y translate 10*x} will show a box rotated 45
> degrees around the vertical axis and translated 10 units along the x-axis.
>
> box {-1, 1 translate 10*x rotate 45*y} will rotate a box placed at 10
> units on the +x-axis, 45 degrees towards the -z-axis.
>
> Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Hi,
>
> I didn't know all of these prerequisites, in particular the scale / transmate
> order.
>
> I think that clipka's right. I'll try his solution, that is setting ambient,
> diffuse, specular, phong,... to 0
>
> I'll try this out and let you know.
>
> Thanks for all your advice!
>
> Mat
>
Think of that like this:
If you translate THEN scale, the scaling will also affect the translate.
If you translate an object then rotate it or rotate an object NOT
created at the origin, it will make the object orbit around the origin.
When you do an isotropic scalling, like scale 3, and a rotation, the
order is not important because the scaling don't affect the shape of the
object.
But, if you do a deforming scaling, like scale<1,2,3>, and a rotation,
then the order WILL be very important.
scale<1,2,3> rotate<12,60,-15> gives a rotated, elongated object.
rotate<12,60,-15> scale<1,2,3> will result in a sheared object.
Try it with an unit box to see the difference by yourself.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|