POV-Ray : Newsgroups : povray.advanced-users : clutter.mcr and trace() Server Time
25 Jul 2021 08:33:13 EDT (-0400)
  clutter.mcr and trace() (Message 11 to 20 of 28)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 8 Messages >>>
From: Mike Horvath
Subject: Re: clutter.mcr and trace()
Date: 17 May 2021 14:05:25
Message: <60a2b065$1@news.povray.org>
On 5/17/2021 9:39 AM, Thomas de Groot wrote:
> Op 17-5-2021 om 10:59 schreef Mike Horvath:
>> It is still not working for me. There are no errors or warnings, but 
>> the spheres and cones are still at y = 0 instead of conforming to the 
>> hills.
>>
>> Can you upload your working files?
>>
> 
> I only changed terrain.pov in the package. Attached also a render of the 
> scene.
> 
> 

You can see in the render that the balls are not on _top_ of the hill. 
(They should be!)


Mike


Post a reply to this message

From: Mike Horvath
Subject: Re: clutter.mcr and trace()
Date: 17 May 2021 18:52:31
Message: <60a2f3af$1@news.povray.org>
On 5/17/2021 4:39 AM, Mike Horvath wrote:
> On 5/17/2021 2:40 AM, Thomas de Groot wrote:
>> I had not loaded the code before in POV-Ray, but it appears that each 
>> mesh is only 1 (one!) triangle... This is terrible, and no wonder 
>> trace does not work well. You need to have at least one mesh 
>> containing /all/ the triangles to start with if you want it to work at 
>> all.
>>
> 
> Alternatively, do you know how I might create a bitmap heightfield image 
> from this data?
> 
> For instance, if I were to copy the coordinates into an array and loop 
> through the array?
> 
> Thanks.
> 
> 
> Mike


I am teaching myself how to create a BMP file in a hex editor.


Mike


Post a reply to this message

From: Bald Eagle
Subject: Re: clutter.mcr and trace()
Date: 17 May 2021 19:55:00
Message: <web.60a301c0584c33991f9dae3025979125@news.povray.org>
Mike Horvath <mik### [at] gmailcom> wrote:
> On 5/17/2021 4:56 AM, Thomas de Groot wrote:
> > Thinking aloud here... assuming that you can render the landscape itself
> > without trouble (I assume you can) then using a gradient texture going
> > e.g. from black (bottom) to white (top) on the landscape, and rendering
> > that with an orthographic camera from above, within a white sphere
> > containing a finish {emission 1 diffuse 0}... that would do the job imo.
> > Make a large render, at least 2048x2048px.
> >
>
> The problem is that the pixels in a heightmap represent _vertices_ (and
> are therefore n+1 pixels per side) whereas a rendered image as you
> describe shows _faces_. So there will be a discrepancy (that I would
> like to avoid).

Why don't you just set up an orthographic scene, and plot 1-unit-square box with
a grayscale rgb value corresponding to the height.  Then you have an image with
each pixel representing a vertex.


Post a reply to this message

From: Mike Horvath
Subject: Re: clutter.mcr and trace()
Date: 17 May 2021 23:49:21
Message: <60a33941$1@news.povray.org>
On 5/17/2021 7:52 PM, Bald Eagle wrote:
> Why don't you just set up an orthographic scene, and plot 1-unit-square box with
> a grayscale rgb value corresponding to the height.  Then you have an image with
> each pixel representing a vertex.
> 
> 
> 

I have done this. But vertices have zero area/volume. They would not 
appear in a render.


Mike


Post a reply to this message

From: Thomas de Groot
Subject: Re: clutter.mcr and trace()
Date: 18 May 2021 02:07:42
Message: <60a359ae$1@news.povray.org>
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?

-- 
Thomas


Post a reply to this message

From: Mike Horvath
Subject: Re: clutter.mcr and trace()
Date: 18 May 2021 13:23:24
Message: <60a3f80c$1@news.povray.org>
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?


Mike


Post a reply to this message

From: Thomas de Groot
Subject: Re: clutter.mcr and trace()
Date: 19 May 2021 02:57:55
Message: <60a4b6f3$1@news.povray.org>
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

From: Thomas de Groot
Subject: Re: clutter.mcr and trace()
Date: 19 May 2021 07:24:20
Message: <60a4f564$1@news.povray.org>
Op 19-5-2021 om 08:57 schreef Thomas de Groot:
>   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?
> 

I give up. I have absolutely no idea what/how clutter works exactly, and 
why trace returns 0. Personally, I guess it is the macro misbehaving as 
the mesh2 is sound. I don't know either why vdot or vlength are used 
within the trace command. An expert is needed here.

-- 
Thomas


Post a reply to this message

From: Thomas de Groot
Subject: Re: clutter.mcr and trace()
Date: 20 May 2021 02:38:40
Message: <60a603f0$1@news.povray.org>
I may have found the problem.

I converted the mesh2 terrain.pov to an obj file in Poseray, and 
imported that into Silo. It appears that the faces of the terrain do 
/not/ have normals. I know that your mesh2 objects /have/ normals in 
their normals block, but somehow those are not read by the trace 
function. So, what are they? Do they refer to the triangle faces or are 
they related to the triangle vertices? If the later, trace will not work 
I believe.

-- 
Thomas


Post a reply to this message

From: Thomas de Groot
Subject: Re: clutter.mcr and trace()
Date: 20 May 2021 04:49:16
Message: <60a6228c$1@news.povray.org>
I did some more testing. I think you should look at the /original/ 
landscape file and see how that was converted to mesh and/or mesh2. I 
guess something is wrong (as far as POV-Ray is concerned) with its 
normal handling: the .ldr file? the .stl file? Either LDraw or MeshLab 
do not do the job correctly; I guess LDraw more than MeshLab...

-- 
Thomas


Post a reply to this message

<<< Previous 10 Messages Goto Latest 10 Messages Next 8 Messages >>>

Copyright 2003-2021 Persistence of Vision Raytracer Pty. Ltd.