Op 18/05/2021 om 19:23 schreef Mike Horvath:
> On 5/18/2021 2:07 AM, Thomas de Groot wrote:
>> Op 17/05/2021 om 20:05 schreef Mike Horvath:
>>>
>>> You can see in the render that the balls are not on _top_ of the 
>>> hill. (They should be!)
>>>
>>
>> Well, that was not the /initial/ question, was it? ;-)
>>
>> "I am having trouble getting the `trace` function to detect 
>> intersections with a mesh object. Does `trace` not recognize meshes?"
>>
>> So, what /is/ exactly the problem, and /what/ do you want to achieve?
>>
> 
> Sorry.
> 
> The clutter macro is supposed to place the spheres and cones on top of 
> the mesh terrain. Instead, it is placing them all at y = 0. I assumed it 
> was an issue with `trace`, but this appears not to be the case according 
> to my tests.
> 
> The problem does _not_ occur with the test isosurface or the test 
> heightfield. I assumed it was a mesh or mesh2 issue, but it is likely 
> something else. But what?
> 

  OK, I see what you mean. I had not been aware of the problem when 
looking casually at the rendered scene and thought that was on purpose.

I loaded terrain.pov into Poseray but apart from the fact that the 
object is showing +y pointing downwards, it seems ok. Normals are 
oriented correctly too. For good measure, I scaled the terrain by y*-1 
and saved a copy which I rendered in your scene file (taking care to 
comment-out your rotation x*180) but that did not help either. [your 
terrain looks better btw when transformed as I did].

So, something fishy happening here. Not the mesh2 which should work (I 
know by experience). Interestingly, switching 'on' normal orientation in 
the clutter macro, resulted in an 'error in normal calculation' 
somewhere during parsing.

I have no time to dig deeper presently, but that is as far as I got now. 
Maybe the terrain needs a finer subdivision?

-- 
Thomas

Post a reply to this message