Thomas de Groot <tho### [at] degrootorg> wrote:


> Finally, as first approximation, I found it more expedient to randomise
> the points in the array when reading them.

Hmmm.
Without seeing how you're going about that, I'm not sure I understand the
advantage of that over selecting a (pseudo)random point in an ordered array.

I do think that one thing that could be done is add a bit of randomization to
the point itself - since they are all regularly spaced in a cubic grid.
("cubic" is just easier to say/write than "rectangular solid")

So, perhaps define half the grid spacing as a multiplier (M), and randomly
translate along x, y, and z by rand_between (-M and M).
Add a rotation if you're using an asymmetric filler.

Or draw a cylinder between the original point and a randomly translated or
chosen outside point.


It's certainly looking more evenly filled - which I think is what you wanted.

Post a reply to this message

On 04/12/2017 12:45, Bald Eagle wrote:
> Stephen <mca### [at] aolcom> wrote:
> 
>> I've not been following the technical side of the discussion. I thought
>> you were scanning a mesh. Which generally only defines a surface. At
>> least Poser ones do.
> 
> They are, until you define an inside_vector, and then it's a solid.
> POV-Ray squawked about the mesh I was using not being a solid object when I
> tried to use inside() until I defined an inside_vector.
> 
> 

I need to look at your code and hope I can see what you are doing.
I don't recognise that warning/error. But I always use PoseRay to 
convert OBJ files to Mesh2 and it always includes an inside vector.
What version of Pov are you using?


>>> I think Thomas was merely suggesting that you poke a few holes in a mesh for
>>> testing purposes.
>>
>> I had better read the thread again. Something is not meshing. ;)
> 
> You're either not sober and should be, or sober and shouldn't be.
> 
> 
> 
> 

I resemble that remark. :(

-- 

Regards
     Stephen

Post a reply to this message

Am 04.12.2017 um 13:40 schrieb Thomas de Groot:
> On 4-12-2017 9:11, Thomas de Groot wrote:
>> On 3-12-2017 14:17, Bald Eagle wrote:
>>> Hey!
>>> I like the results you're getting.
>>> In fact, I like the holes in the mesh so much, that maybe you could
>>> think about
>>> exploiting that effect by randomly creating holes in the mesh to give a
>>> "spiking" effect - I think that would be an excellent Gormley-inspired
>>> methodology.
>>
>> For the time being I treat them as artefacts.
>>
> 
> I don't know what those spikes represent finally. I closed the model and
> still the eyes show them, except if I increase minutely the Step
> parameter. Any idea?

My guess would be that your mesh is "closed" in a different sense than
what would constitute a "closed" mesh in the sense POV-Ray interprets it.

For instance, a human figure mesh may be comprised of (1) a surface
representing the skin, which is open at the eyes, and (2) a pair of
convex spheres representing the eyeballs.

In such a setup, no ray could travel from the "inside" of the figure's
head to the outside without encountering /at least one/ surface, which
you might consider "closed".

However, in POV-Ray's sense a mesh is only "closed" if a ray traveling
from the "inside" of the figure's head to the outside always encounters
an /odd number/ of surfaces.

This is the case if, and only if, there are no "open edges" in the mesh,
i.e. each edge joins an even number of triangles.

Post a reply to this message

On 4-12-2017 16:47, clipka wrote:
> Am 04.12.2017 um 13:40 schrieb Thomas de Groot:
>> I don't know what those spikes represent finally. I closed the model and
>> still the eyes show them, except if I increase minutely the Step
>> parameter. Any idea?
> 
> My guess would be that your mesh is "closed" in a different sense than
> what would constitute a "closed" mesh in the sense POV-Ray interprets it.
> 
> For instance, a human figure mesh may be comprised of (1) a surface
> representing the skin, which is open at the eyes, and (2) a pair of
> convex spheres representing the eyeballs.
> 
> In such a setup, no ray could travel from the "inside" of the figure's
> head to the outside without encountering /at least one/ surface, which
> you might consider "closed".
> 
> However, in POV-Ray's sense a mesh is only "closed" if a ray traveling
> from the "inside" of the figure's head to the outside always encounters
> an /odd number/ of surfaces.
> 
> This is the case if, and only if, there are no "open edges" in the mesh,
> i.e. each edge joins an even number of triangles.
> 

I agree about those eye orbits and balls. However, I deleted the eye 
balls and closed the eye orbits. So, strictly speaking, the mesh is 
completely 'closed'.

Remembering a more ancient discussion, I change the inside vector of the 
mesh from the standard (Poseray-generated) <0,0,1> to <1,0,1>. 
Interestingly, that generates an additional spike (see image).

-- 
Thomas

Post a reply to this message

Attachments:
Download 'antony gormley sim.png' (364 KB)

Preview of image 'antony gormley sim.png'

On 4-12-2017 14:20, Bald Eagle wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
> 
>> Finally, as first approximation, I found it more expedient to randomise
>> the points in the array when reading them.
> 
> Hmmm.
> Without seeing how you're going about that, I'm not sure I understand the
> advantage of that over selecting a (pseudo)random point in an ordered array.
> 
> I do think that one thing that could be done is add a bit of randomization to
> the point itself - since they are all regularly spaced in a cubic grid.
> ("cubic" is just easier to say/write than "rectangular solid")
> 
> So, perhaps define half the grid spacing as a multiplier (M), and randomly
> translate along x, y, and z by rand_between (-M and M).
> Add a rotation if you're using an asymmetric filler.
> 
> Or draw a cylinder between the original point and a randomly translated or
> chosen outside point.
> 
> 
> It's certainly looking more evenly filled - which I think is what you wanted.
> 

Sorry, indeed. I use the following code:

union {
   #while (defined(ObjLocs))
     #read (ObjLocs, Locs)
     sphere {0, 0.01
       #local Locs = Locs*RRand(0.99, 1.01, Stream0);
       translate Locs
       pigment {Red}
     }
   #end
   rotate 20*y
}

As you can have noticed from my answer to Clipka, I am really puzzled by 
the 'spikes'...

-- 
Thomas

Post a reply to this message

Incidentally, replacing:

#declare MinZ = floor(Min.z);
#declare MinY = floor(Min.y);
#declare MinX = floor(Min.x);
#declare MaxZ = ceil(Max.z);
#declare MaxY = ceil(Max.y);
#declare MaxX = ceil(Max.x);

by:

#declare MinZ = Min.z;
#declare MinY = Min.y;
#declare MinX = Min.x;
#declare MaxZ = Max.z;
#declare MaxY = Max.y;
#declare MaxX = Max.x;

speeds up the parsing manifold. From a couple of minutes (Steps=0.01;) 
to a couple of seconds. Results are identical though it may generate 
problems of course where the the limit and the object are identical.

-- 
Thomas

Post a reply to this message

On 4-12-2017 16:47, clipka wrote:
> My guess would be that your mesh is "closed" in a different sense than
> what would constitute a "closed" mesh in the sense POV-Ray interprets it.
> 

Problem SOLVED (I guess).

To close the mesh, I left a number of quadrangular new surfaces. I 
re-triangulated the model and the spikes disappeared. No entirely sure 
/why/ this happened though; I do not remember having met this before.

-- 
Thomas

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> Incidentally, replacing:
>
> #declare MinZ = floor(Min.z);
> #declare MinY = floor(Min.y);
> #declare MinX = floor(Min.x);
> #declare MaxZ = ceil(Max.z);
> #declare MaxY = ceil(Max.y);
> #declare MaxX = ceil(Max.x);
>
> by:
>
> #declare MinZ = Min.z;
> #declare MinY = Min.y;
> #declare MinX = Min.x;
> #declare MaxZ = Max.z;
> #declare MaxY = Max.y;
> #declare MaxX = Max.x;
>
> speeds up the parsing manifold. From a couple of minutes (Steps=0.01;)
> to a couple of seconds. Results are identical though it may generate
> problems of course where the the limit and the object are identical.
>
> --
> Thomas

That's HIGHLY unexpected, since it's only 6 rounding directives.
I only did that to give integers for referencing array items.

It's not like any of that gets looped...   :O

Post a reply to this message

On 5-12-2017 13:35, Bald Eagle wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> Incidentally, replacing:
>>
>> #declare MinZ = floor(Min.z);
>> #declare MinY = floor(Min.y);
>> #declare MinX = floor(Min.x);
>> #declare MaxZ = ceil(Max.z);
>> #declare MaxY = ceil(Max.y);
>> #declare MaxX = ceil(Max.x);
>>
>> by:
>>
>> #declare MinZ = Min.z;
>> #declare MinY = Min.y;
>> #declare MinX = Min.x;
>> #declare MaxZ = Max.z;
>> #declare MaxY = Max.y;
>> #declare MaxX = Max.x;
>>
>> speeds up the parsing manifold. From a couple of minutes (Steps=0.01;)
>> to a couple of seconds. Results are identical though it may generate
>> problems of course where the the limit and the object are identical.
>>
>> --
>> Thomas
> 
> That's HIGHLY unexpected, since it's only 6 rounding directives.
> I only did that to give integers for referencing array items.
> 
> It's not like any of that gets looped...   :O
> 

Yes, I did not expect that at all either. I am baffled.

-- 
Thomas

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:

> >> Finally, as first approximation, I found it more expedient to randomise
> >> the points in the array when reading them.

Ah. I understand now.

"I found it more expedient to add a random translation to the point values
before storing them in the array, as they are read in from the file."

(I will admit, it's one of those things that's a bit hard to phrase before 2nd
coffee..   I'm likely further challenged by the damage that American compulsory
public education caused me.)

I think it's something that would save the time of one addition per point if the
number of points to be plotted exceeded the number of entries in the array, and
it would prevent overlap of objects slightly differing in position for the same
array entry.






http://izquotes.com/quotes-pictures/quote-schools-were-designed-by-horace-mann-and-barnard-sears-and-harper-of-the-univ
ersity-of-chicago-and-john-gatto-343105.jpg
https://i.pinimg.com/736x/57/14/a2/5714a25f482e091f882ffc1a52fed042--compulsory-education-education-system.jpg
https://i.pinimg.com/736x/c5/9f/3f/c59f3f93df48042001f325789ac42439--public-school-quotations.jpg

Post a reply to this message