I finally got around to this. Thanks!

I don't quite understand the code yet. A few questions:

1. How do I make it so that the probability is lower depending on the
    slope of the terrain? This should vary depending on the type of
    object. For instance, the sphere might not like a high slope. The
    spike might not care very much.
2. The spikes seem to point in the direction of the normal. Can I
    disable this? I want them to always be vertical.
3. Is there a way to round the y coordinate to the nearest 8 units and
    the x and z coordinates to the nearest 10 units? I am working with
    virtual LEGO and the precision is very coarse.

Thanks again!


Michael


On 4/21/2021 2:07 PM, Norbert Kern wrote:
> I know that Thomas made some very nice macros public in this thread, but I want
> to point to an old macro made by JRG (Jonathan Rafael Ghiglia) back in 2001 -
> his "clutter macro". Since I wasn't able to find the link on this server I
> include the macro here.
> 
> With some modifications every point of your list is doable - perhaps I'm able to
> do it in the next days. Especially interesting is your first point - but I
> haven't looked into Thomas macro regarding it - perhaps this problem is already
> solved...
> 
> Furthermore, if you want to use a very large number of trees, you should use
> only visible coordinates. Back in 2005 I published a method
>
(http://news.povray.org/povray.binaries.scene-files/message/%3C432414bf%40news.povray.org%3E/#%3C432414bf%40news.povray
> .org%3E
> for macro -
>
http://news.povray.org/povray.binaries.images/thread/%3Cdg0ifb%242oi%241%40chho.imagico.de%3E/
> for the thread).
> 
> 
> Stay healthy
> Norbert
>

Post a reply to this message

> I finally got around to this. Thanks!
> 
> I don't quite understand the code yet. A few questions:
> 
> 1. How do I make it so that the probability is lower depending on the



> 2. The spikes seem to point in the direction of the normal. Can I

> 3. Is there a way to round the y coordinate to the nearest 8 units and


> 
> Thanks again!
> 
> 
> Michael
> 
> 
For the spikes. You just need to ignore the normal returned by the trace 
function when placing them.
So, remove any vrotate or vorient.

For the rounding... I would try using the modulo function.
Something like this :
#declare LEGO_Position = <Position.x-mod(Position.x, 10), 
Position.y-mod(Position.y, 8), Position.z-mod(Position.z, 10)>

Post a reply to this message

Do the size and orientation of the landscape and probability functions 
matter? The example seems to be contained in a 10 unit square with one 
corner at the origin, but can it be a 100 unit square? Can the square be 
located elsewhere than the origin?

The documentation is lacking/confusing.


Mike

Post a reply to this message

On 5/12/2021 10:19 AM, Alain Martel wrote:
> For the spikes. You just need to ignore the normal returned by the trace 
> function when placing them.
> So, remove any vrotate or vorient.

There is actually a macro setting for this, I found out. But it is for 
*all* the objects, not for each object individually.


> 
> For the rounding... I would try using the modulo function.
> Something like this :
> #declare LEGO_Position = <Position.x-mod(Position.x, 10), 
> Position.y-mod(Position.y, 8), Position.z-mod(Position.z, 10)>

Thanks!


Mike

Post a reply to this message

Mike Horvath <mik### [at] gmailcom> wrote:

> 1. How do I make it so that the probability is lower depending on the
>     slope of the terrain? This should vary depending on the type of
>     object. For instance, the sphere might not like a high slope. The
>     spike might not care very much.

I just took a brief look at this.

Since your objects get placed using a loop, you can add conditionals and
multipliers.

So maybe have a rand value selecting for each type of object.  Using #switch,
you can do object-specific things like define values, orientation, etc.

In each block of object code you can simply do a calculation on the slope to see
if it's a good value.  If it is, you can just use another rand value and if it's
below a certain threshold, then place your object.  #if (RandVal < 80)  object
{Object} #end  Would place it 80% if the time.

There's a terrain scale that gets used to adjust other calculations in the
scene.  That ought to make the fairly code size independent.

Looks like everything is at the origin, so you'll have to do it and then
translate, or translate to the origin, do it, and then translate back.

That's all I picked up / thought up on a quick read-through.

Post a reply to this message

On 5/13/2021 7:03 AM, Bald Eagle wrote:
> In each block of object code you can simply do a calculation on the slope to see
> if it's a good value.  If it is, you can just use another rand value and if it's
> below a certain threshold, then place your object.  #if (RandVal < 80)  object
> {Object} #end  Would place it 80% if the time.
> 
> There's a terrain scale that gets used to adjust other calculations in the
> scene.  That ought to make the fairly code size independent.
> 
> Looks like everything is at the origin, so you'll have to do it and then
> translate, or translate to the origin, do it, and then translate back.
> 
> That's all I picked up / thought up on a quick read-through.
> 


Could I create a slope map or object pigment? That would be a lot 
smoother gradient I think than doing a few checks here and there using 
conditionals.

I would need to feed the 3D mesh into some function or macro and get a 
2D pigment as output. Dunno how to do that.


Mike

Post a reply to this message

Mike Horvath <mik### [at] gmailcom> wrote:

> Could I create a slope map or object pigment? That would be a lot
> smoother gradient I think than doing a few checks here and there using
> conditionals.

Not having implemented any of this in a working scene, I don't presently have
any practical knowledge of everything that's going on.  As it appeared to me,
there were a few pigments/functions that governed stuff, and a trace to get a
normal at a point.  I'm not sure why more maps or pigments would be required or
how they would be used.

If you're placing objects based on the sampling results of the ground plane /
heightfield, then the decision about what object to place and how would be done
in the loop.
Maybe there's a way to have several loops, but I think that would be less
efficient.

As for an object pigment, there is NO gradient at all - or rather - an abrupt,
infinite gradient - a sudden discontinuity from inside to outside.  Bill
Pokorny, myself, and possibly others have experimented with sampling methods
geared toward creating an actual smooth gradient for the object pattern to
(IIRC) use it in isosurfaces.

> I would need to feed the 3D mesh into some function or macro and get a
> 2D pigment as output. Dunno how to do that.

You're gonna have to give me a sample image or a drawing that shows what the 3D
mesh is and what needs to go where and why - and then maybe I tell you how to
accomplish your goal.

You _can_ trivially turn your 3D mesh into a "2D" pigment by just using the mesh
as an object in an object pigment, or if you want that silhouette effect, using
an object pigment in a function, setting y to 0, and putting that back into a
pigment pattern....

But I'm presently just guessing / speculating about what your actual needs and
final goals are.

Post a reply to this message

On 5/13/2021 2:55 PM, Bald Eagle wrote:
> Mike Horvath <mik### [at] gmailcom> wrote:
> 
>> Could I create a slope map or object pigment? That would be a lot
>> smoother gradient I think than doing a few checks here and there using
>> conditionals.
> 
> Not having implemented any of this in a working scene, I don't presently have
> any practical knowledge of everything that's going on.  As it appeared to me,
> there were a few pigments/functions that governed stuff, and a trace to get a
> normal at a point.  I'm not sure why more maps or pigments would be required or
> how they would be used.
> 

The clutter script already determines the probability of placing an 
object using a grayscale pigment. I am thinking I could leverage that by 
supplying a grayscale pigment representing the slope of the terrain 
object. Not sure how though.

Any heightmap will do right now such as this one:

https://en.wikipedia.org/wiki/File:Heightmap.png

I have attached the code I am working on right now.


Mike

Post a reply to this message

Attachments:
Download 'clutter_001.zip' (105 KB)

Alternatively I can render an overhead shot of the terrain with a 
grayscale pigment determined by slope, and feed the resulting image back 
into the macro as an image map.


Mike

Post a reply to this message

This version should work better.

It adjusts the probability of the spheres based on:

1. slope of terrain
2. altitude of terrain

Low flat areas have more spheres.

Cones are evenly distributed.


Mike

Post a reply to this message

Attachments:
Download 'clutter_002.zip' (306 KB)