 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/20/2021 4:49 AM, Thomas de Groot wrote:
> 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...
>
Thank you so much for taking a deeper look!
LDraw does not store normal data at all. None whatsoever. It only stores
the vertices. A program called LDCad is used to convert from LDraw
format to POV-Ray mesh2 format.
So, do you think that the LDraw to mesh2 converter is having some
issues? I can inform the programmer.
Thanks!
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot <tho### [at] degroot org> wrote:
> 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.
My day got completely eaten up yesterday, and today my brain is just - off.
What I did notice is that the code is OLD - 20 years - and it's likely
unfinished.
I say that because the vdot function looks to be testing the angle between the
normal and y, but the result is just never used. Trace gets invoked, vdot gets
calculated, and then the result is stored in a throwaway variable that gets
overwritten. Very curious - almost like the author was going to use it, but
simultaneously decided he wasn't...
vlength looks to be getting used as a way to test for the <0, 0, 0> vector.
I like the test scenes so far, and this would be a lovely macro to have
rewritten for clarity, performance, etc. I can imagine this might find heavy
usage for folks wanting to populate landscape and other scenes.
(Were there example renders?)
So, add that to the To-Do pile for any takers.
I have only made meshes (yes, and messes) not mesh2 objects. With regard to
that, at first glance, it seems odd to me that given 3 vertices, a normal needs
to be supplied and isn't simply calculated. But I guess there's involved stuff
with directionality that needs to be unambiguously provided (at this point).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/20/2021 7:45 PM, Bald Eagle wrote:
> I have only made meshes (yes, and messes) not mesh2 objects. With regard to
> that, at first glance, it seems odd to me that given 3 vertices, a normal needs
> to be supplied and isn't simply calculated. But I guess there's involved stuff
> with directionality that needs to be unambiguously provided (at this point).
I suppose an author might want the normal to point somewhere different
than one might expect given the supplied vertices.
For instance, what if a smooth mesh meets another mesh that is at right
angles to it? You likely want the edge where they meet to be super
sharp, but an auto-calculated normal could be rounded or bumpy or whatever.
IIRC, I used a tool a long time ago that asked you to supply an
(arbitrary) cutoff value, at which point the auto-smoothing is turned off.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/20/2021 8:07 PM, Mike Horvath wrote:
> IIRC, I used a tool a long time ago that asked you to supply an
> (arbitrary) cutoff value, at which point the auto-smoothing is turned off.
And even this cutoff value is based on /assumptions/ made about what the
artist wants. A /third/ individual might want to hand-select each and
every normal for each and every vertex for some (valid!) reason.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/17/2021 6:52 PM, Mike Horvath wrote:
> I am teaching myself how to create a BMP file in a hex editor.
>
>
> Mike
I found out that I require 16 bit precision, which is an uncommon mode
for BMP. Are there other 16 bit grayscale uncompressed bitmap formats?
Thanks.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
Mike Horvath <mik### [at] gmailcom> wrote:
> ...
> I found out that I require 16 bit precision, which is an uncommon mode
> for BMP. Are there other 16 bit grayscale uncompressed bitmap formats?
PNG can be stored uncompressed.
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Op 20/05/2021 om 17:46 schreef Mike Horvath:
> On 5/20/2021 4:49 AM, Thomas de Groot wrote:
>> 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...
>>
>
>
> Thank you so much for taking a deeper look!
>
> LDraw does not store normal data at all. None whatsoever. It only stores
> the vertices. A program called LDCad is used to convert from LDraw
> format to POV-Ray mesh2 format.
>
> So, do you think that the LDraw to mesh2 converter is having some
> issues? I can inform the programmer.
>
Well, if no normals are stored you got a problem indeed. What trace
does, on whatever surface it is pointed to, is to control the normal of
the first face it hits, and change its own (preset) normal <0,0,0> to
the normal of the face. With the location of the hit point /and/ the
normal's value, you get a point and orientation for the object to be
posed on the surface. So, it is all about *faces* and their *normals*.
If no normals are present, the object is "transparant" to trace.
I am pretty sure now that the LDraw to mesh2 converter has an issue, but
before that, LDraw has a problem if it only stores vertices. Somewhere
on the road, faces (triangles or quadrangles) need to be generated with
their corresponding normals. That is how all 3D programs I know work,
being it Silo or Wings3D or Poser, to mention a few. Poseray besides, is
one of the best utilities I know to convert a large body of formats
(obj, 3ds, lwo, dxf, raw, inc, pov, wrl, gz) to mesh2 objects.
Unfortunately it does not convert directly from LDraw. If LDraw could
export to one of these formats (inc and pov /only/ for mesh and mesh2),
Poseray would do the job accurately, provided that face normals are present.
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2021-05-21 à 00:45, Mike Horvath a écrit :
> On 5/17/2021 6:52 PM, Mike Horvath wrote:
>> I am teaching myself how to create a BMP file in a hex editor.
>>
>>
>> Mike
>
>
> I found out that I require 16 bit precision, which is an uncommon mode
> for BMP. Are there other 16 bit grayscale uncompressed bitmap formats?
>
> Thanks.
>
>
> Mike
You may try TGA or PPM. Both support arbitrary bit per pixel, from 1 up
to 24 per channel.
TGA is even simpler than BMP, and the data are from top to bottom, not
bottom to top as in BMP.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
