POV-Ray : Newsgroups : povray.advanced-users : clutter.mcr and trace() Server Time
7 Oct 2024 07:07:00 EDT (-0400)
  clutter.mcr and trace() (Message 21 to 28 of 28)  
<<< Previous 10 Messages Goto Initial 10 Messages
From: Mike Horvath
Subject: Re: clutter.mcr and trace()
Date: 20 May 2021 11:46:24
Message: <60a68450$1@news.povray.org>
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

From: Bald Eagle
Subject: Re: clutter.mcr and trace()
Date: 20 May 2021 19:50:00
Message: <web.60a6f47d584c33991f9dae3025979125@news.povray.org>
Thomas de Groot <tho### [at] degrootorg> 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

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

From: Mike Horvath
Subject: Re: clutter.mcr and trace()
Date: 20 May 2021 20:12:05
Message: <60a6fad5$1@news.povray.org>
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

From: Mike Horvath
Subject: Re: clutter.mcr and trace()
Date: 21 May 2021 00:45:26
Message: <60a73ae6$1@news.povray.org>
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

From: jr
Subject: Re: clutter.mcr and trace()
Date: 21 May 2021 02:30:00
Message: <web.60a7524c584c339979819d986cde94f1@news.povray.org>
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

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

From: Alain Martel
Subject: Re: clutter.mcr and trace()
Date: 21 May 2021 12:34:41
Message: <60a7e121$1@news.povray.org>
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

<<< Previous 10 Messages Goto Initial 10 Messages

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