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

> Ah, thanks indeed! I was just starting to work on this - from a
> different angle I must confess, but to the same ultimate result. THis
> comes just in time.

Certainly  :)
With so many people with so few Round Tuits, it's a lot easier to pitch in
1/4-of-a-Round-Tuit each and get 1 full final result.

I'll see if I can work on this some more - if you have any questions or ideas
for improvements, let me know.
One thing that comes to mind is to use trace() to limit scanning the entire
bounding box, though it seems to go fast enough at the moment.
Maybe that could be a switchable enable/disable feature for when high-density
scanning of sparse objects are used.

Post a reply to this message

On 2-12-2017 17:23, Bald Eagle wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
>> Ah, thanks indeed! I was just starting to work on this - from a
>> different angle I must confess, but to the same ultimate result. THis
>> comes just in time.
> 
> Certainly  :)
> With so many people with so few Round Tuits, it's a lot easier to pitch in
> 1/4-of-a-Round-Tuit each and get 1 full final result.

Like bitcoins, their value increases worryingly.

> 
> I'll see if I can work on this some more - if you have any questions or ideas
> for improvements, let me know.
> One thing that comes to mind is to use trace() to limit scanning the entire
> bounding box, though it seems to go fast enough at the moment.
> Maybe that could be a switchable enable/disable feature for when high-density
> scanning of sparse objects are used.
> 

At this point, I have the following code ready (write/read) installed, 
based on (the first part of) your own code. I increased the container a 
bit to be sure the model was completely inside. Nice to be working again 
with arrays. I am not using them as often as I should:

//start code-----------------------
#if (Write)
   #debug "   writing object locations...\n"
   #fopen ObjLocs "ArrayFill.inc" write

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

#declare ZRange = (MaxZ - MinZ)/Step;
#declare YRange = (MaxY - MinY)/Step;
#declare XRange = (MaxX - MinX)/Step;

#declare ArraySize = XRange*YRange*ZRange;
#declare TestArray = array [ArraySize];

#declare N = 0;
#for (Z, MinZ, MaxZ, Step)
   #for (Y, MinY, MaxY, Step)
     #for (X, MinX, MaxX, Step)
       #if(inside (Model, <X, Y, Z>))
         #declare TestArray [N] = <X, Y, Z>;
         //#debug concat ( "Point ", str (N, 3, 1), " = ", vstr(3, 
TestArray[N], ", ", 3, 3), " \n")
         #write (ObjLocs,"<",vstr(3, TestArray[N], ", ", 3, 3),">",",\n")
         #declare N = N +1;
       #end
     #end
   #end
#end

   #fclose ObjLocs

#end  //of Write

#debug "   reading sand locations...\n"
#fopen ObjLocs "ArrayFill.inc" read

union {
   #while (defined(ObjLocs))
     #read (ObjLocs, Locs)
     sphere {0, 0.01 translate Locs}
   #end
   rotate 20*y
}
//end code--------------------------------

I have to correct the original model a bit: welding vertices and filling 
holes. This has become critical for this method. The example image shows 
why (eyes and mouth still with holes).

I have to study the second part of your code now. I do not yet fully 
understand it.


-- 
Thomas

Post a reply to this message

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

Preview of image 'antony gormley sim.png'

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.

I think this is something Stephen would have fun playing with, and I'd have to
think about how to make it apply to DF3 files.
On the flip-side, if you wrote the points of the array to a DF3-format, then you
could create DF3 point clouds from any solid mesh or CSG construct, which would
be very cool indeed   :)

I have some explanatory comments on the code below to speed you along in your
studies.


"Bald Eagle" <cre### [at] netscapenet> wrote:

> #declare Min = min_extent (Object);
> #declare Max = max_extent (Object);

obviously this just gives the opposing bounding box coordinates

> #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);

Then we do some rounding up and down

> #declare Step = 0.5;
>
> #declare ZRange = (MaxZ - MinZ)/Step;
> #declare YRange = (MaxY - MinY)/Step;
> #declare XRange = (MaxX - MinX)/Step;

This compensates for any "off-origin" positioning

> #declare ArraySize = XRange*YRange*ZRange;
>
> #declare TestArray = array [ArraySize];
>
> #declare N = 0;
> #for (Z, MinZ, MaxZ, Step)
>  #for (Y, MinY, MaxY, Step)
>   #for (X, MinX, MaxX, Step)
>    #if(inside (Object, <X, Y, Z>))
>     #declare TestArray [N] = <X, Y, Z>;

If the point being scanned is inside the object, stick that point on the array
"stack", and increment the stack pointer / array position.
If not, just keep scanning.

>     //#debug concat ( "Point ", str (N, 3, 1), " = ", vstr(3, TestArray[N], ",
> ", 3, 0), " \n")
>     #declare N = N +1;
>    #end
>   #end
>  #end
> #end
>
> #declare InSize = N - 1;

Nudge this back down to the pre-increment value to avoid unknown array element
error.

> #declare Stream  = seed (123456789);
> #declare Stream1 = seed (456123789);
> #declare Stream2 = seed (789456123);
> #declare Stream3 = seed (135791113);
> #declare Stream4 = seed (987654321);
> #declare Stream5 = seed (987654321);
> #declare ScaleRange = 3;

Random seeds and a varying scale between 1 and ScaleRange

> #declare Tries = 2000;

How many objects do you want to populate the inside of the arrayed space with?

> #for (N, 1, Tries)
>  #declare P = int(rand (Stream5)*InSize);

Since rand() returns 0-1, and Insize is the number of points in the array, you
get a position somewhere in that array.

>  #declare rx = rand(Stream1)*90;
>  #declare ry = rand(Stream2)*90;
>  #declare rz = rand(Stream3)*90;
>  #declare Scale = rand(Stream4)*ScaleRange;
>  #declare TexNum = int (rand (Stream4) * dimension_size (TexArray, 1) );

I just had an array here to vary the textures of the jacks randomly

>  object {Jack rotate <rx, ry, rz> scale Scale translate TestArray [P] texture
> {TexArray[TexNum]} }

Put an object at the randomly selected array position.  It gets rotated some
random amount around x, y, and z, and given a random texture before translation.

> #end

Post a reply to this message

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 think this is something Stephen would have fun playing with, and I'd have to
> think about how to make it apply to DF3 files.
> On the flip-side, if you wrote the points of the array to a DF3-format, then you
> could create DF3 point clouds from any solid mesh or CSG construct, which would
> be very cool indeed   :)

Stephen, your turn ;-)

> 
> I have some explanatory comments on the code below to speed you along in your
> studies.
> 
> [snip]

ah-HA! I see. Thanks indeed.

-- 
Thomas

Post a reply to this message

On 04/12/2017 08: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 think this is something Stephen would have fun playing with, and I'd
>> have to
>> think about how to make it apply to DF3 files.
>> On the flip-side, if you wrote the points of the array to a
>> DF3-format, then you
>> could create DF3 point clouds from any solid mesh or CSG construct,
>> which would
>> be very cool indeed   :)
>
> Stephen, your turn ;-)
>

I don't think writing the points from the array to a df3 would give you 
the results you want. I think it would just give you a surface with 
holes in it.
If you used the slicing method to create a df3. You would get spikes in 
the direction of the inside vector extending to the edge of the container.
I have been thinking of trying to do the same with bullet physics. But I 
am having PC problems.

>


-- 

Regards
     Stephen

Post a reply to this message

Stephen <mca### [at] aolcom> wrote:

> I don't think writing the points from the array to a df3 would give you
> the results you want. I think it would just give you a surface with
> holes in it.

Well, I scan the entire solid, so it ought to give more than that.

> If you used the slicing method to create a df3. You would get spikes in
> the direction of the inside vector extending to the edge of the container.

Ah, yes.  The inside_vector.   Good point.


I think Thomas was merely suggesting that you poke a few holes in a mesh for
testing purposes.


Apparently I'm having "PC issues" as well.   ;)

Post a reply to this message

On 04/12/2017 11:38, Bald Eagle wrote:
> Stephen <mca### [at] aolcom> wrote:
>
>> I don't think writing the points from the array to a df3 would give you
>> the results you want. I think it would just give you a surface with
>> holes in it.
>
> Well, I scan the entire solid, so it ought to give more than that.
>

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.

>> If you used the slicing method to create a df3. You would get spikes in
>> the direction of the inside vector extending to the edge of the container.
>
> Ah, yes.  The inside_vector.   Good point.
>
>
> 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. ;)

 >
> Apparently I'm having "PC issues" as well.   ;)
>

Indeed. One man's humour can be another man's deceleration to war. :)


-- 

Regards
     Stephen

Post a reply to this message

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?

-- 
Thomas

Post a reply to this message

On 4-12-2017 9:11, Thomas de Groot wrote:
> ah-HA! I see. Thanks indeed.
> 

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

-- 
Thomas

Post a reply to this message

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

Preview of image 'antony gormley sim.png'

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 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.

Post a reply to this message