 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Horvath <mik### [at] gmail com> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
