POV-Ray : Newsgroups : povray.advanced-users : "Exploded" vector transform Server Time: 18 Jun 2019 05:13:16 GMT
  "Exploded" vector transform (Message 1 to 8 of 8)  
From: Bald Eagle
Subject: "Exploded" vector transform
Date: 4 Aug 2017 18:35:00
Message: <web.5984ba54e77d084cc437ac910@news.povray.org>
I'm interested in hearing different people's ideas about how to [evenly] add
space between a group of objects / points.

I was thinking about this from a number of perspectives.

Making / adjusting 'exploded' diagrams like StephenS's recent vise.
Modeling Hubbel's Law with astronomical bodies
Modeling explosions (of course), smoke, steam, etc
creating parameterizable complex objects like brick/stone walls, [possibly]
parallel curves,
and many more, I'm sure

The best I can figure, is translate all of the data (if necessary) so that one
point is the center, and then scalar multiply all the vectors, and then
translate them back to the proper scene location.


Post a reply to this message

From: Kenneth
Subject: Re: "Exploded" vector transform
Date: 5 Aug 2017 23:40:01
Message: <web.598656975219365e883fb31c0@news.povray.org>
I think the method to go about it would depend on two things: 1) if the objects
have *already* been made and pre-positioned, or not; and 2) the relative sizes
of the objects. You didn't mention that the many objects may have different
sizes; that would complicate things.

*IF* your're making a group of objects from scratch, and ALL of the same size,
then this simple code would suffice--although, I have a funny feeling that this
is WAY too simplistic for the idea you have in mind ;-)  Offhand, I don't have a
good idea for adding equal spacing between objects of *different* sizes. I would
imagine that it would involve finding the sizes of the objects' bounding boxes
first, using max_extent, then... ??


#version 3.71;

global_settings{assumed_gamma 1.0}
#default {texture{pigment {rgb 1} finish{ambient 1 emission 0 diffuse 0}}}

camera {
  perspective
  location  <28, 16, -300>
  look_at   <28, 16,  0>
  right     x*image_width/image_height
  angle 16
}

#declare CX = 0;
#declare CY = 0;
#while(CY < 30)
#while (CX < 30)
sphere{0,.25
translate <-9,-14,0> // just to offset the objects arbitrarily, before
// re-positioning them
translate 1*<CX,CY,0>} // simply change the multiplier!
#declare CX = CX + 1;
#end
#declare CX = 0;
#declare CY = CY + 1;
#end


Post a reply to this message

From: Kenneth
Subject: Re: "Exploded" vector transform
Date: 7 Aug 2017 09:55:00
Message: <web.598837bc5219365e883fb31c0@news.povray.org>
It occured to me just today that my 'city buildings' code might already have
such a feature in it. The thing is, I'm not sure(!). I've been adding and
changing the scene code so much-- in an on-going step-by-step way-- that I need
to step back and take an overall look. If I can dis-entangle the pertinent code
(or maybe just the general idea), I'll post it here.


Post a reply to this message

From: Kenneth
Subject: Re: "Exploded" vector transform
Date: 10 Aug 2017 15:05:00
Message: <web.598c758c5219365e883fb31c0@news.povray.org>
"Kenneth" <kdw### [at] gmailcom> wrote:
> It occured to me just today that my 'city buildings' code might already have
> such a feature in it...

It didn't :-( But it was almost there :-)  With a few changes to it, I came up
with this (just a ONE-dimensional example.) The white boxes are random widths,
and the red lines are there simply to give a better visual indication of the
equal spacing between objects...

-----
#version 3.71; // or 3.7

global_settings{assumed_gamma 1.0}
#default {texture{pigment {rgb 1} finish{ambient 1 emission 0 diffuse 0}}}

camera {
  perspective
  location  <51, 35, -300>
  look_at   <51, 35,  0>
  right     x*image_width/image_height
  angle 21
}

#declare CX = 0;
#declare CY = 0;
#declare X = seed(15);

#declare EQUAL_SPACING = 3.1; // or whatever
#declare MOVER = 0; // to set it up
#while(CX < 20)
#declare MY_OBJECT =
box{0, <.3 + 4*rand(X),10,.1> no_shadow}
#declare SIZE = max_extent(MY_OBJECT);
object{MY_OBJECT translate MOVER*x} // WHITE box
cylinder{0, EQUAL_SPACING*x,.2 // the RED indicators
    texture {pigment{rgb <1,0,0>} finish{ambient 1 emission 0 diffuse 0}}
    translate (MOVER + SIZE.x)*x
    translate 11*y
    }
#declare MOVER = MOVER + (SIZE.x) + (EQUAL_SPACING.x);
#declare CX = CX + 1;
#end
------

HOWEVER... trying to extrapolate this to TWO dimensions (never mind THREE) has
turned out to be a really thorny problem. Basically, it boils down to this: What
part of an IRREGULARLY-shaped object should be considered as the 'point' to
determine its equal spacing from another object? In other words, should it be
the lower left corner of the object? The center? Etc. In either of these cases
(or any other case that I can imagine), the various spacings between one object
and all its adjacent fellows will turn out to be UN-equal.  While trying to work
this out, I put together another trial-code example (which works correctly ONLY
along the X-axis, by the way.) I added round discs to overlap the objects, to
show their 'spheres of influence'. And it doesn't take into account the
possibility that the objects might be randomly ROTATED as well(!)...

--------
#declare EQUAL_SPACING = <6,6,0>; // or whatever
#declare MOVER = <0,0,0>;
#while(CY < 7)
#while (CX < 7)
#declare MY_OBJECT =
box{0,<.3 + 6*rand(X),.3 + 5*rand(X),.1>}
#declare SIZE = max_extent(MY_OBJECT);

object{MY_OBJECT no_shadow translate MOVER}
disc{<.5*(SIZE.x),.5*(SIZE.y),-.01>,<0,0,-1>,.5*sqrt(pow(SIZE.x,2) +
pow(SIZE.y,2))
    texture{pigment{rgbt .85} finish{ambient 1 emission 0 diffuse 0}}
    no_shadow
    translate MOVER
    }

// x_axis equal-length cylinders
cylinder{0, EQUAL_SPACING*x,.2 // RED indicators to show equal spacing
    texture {pigment{rgb <1,0,0>} finish{ambient 1 emission 0 diffuse 0}}
    translate (MOVER + SIZE.x)*x
    translate (MOVER.y -.6)*y
    }
/*
// y-axis equal-length cylinders
cylinder{0, EQUAL_SPACING*y,.2 // CYAN indicators to show equal spacing
    texture {pigment{rgb <0,1,1>} finish{ambient 1 emission 0 diffuse 0}}
    translate (MOVER + SIZE.x)*x
    translate (MOVER.y + SIZE.y)*y
    translate .3*x
    }
*/

#declare MOVER = MOVER + <SIZE.x,0,0> + <EQUAL_SPACING.x,0,0>;
#declare CX = CX + 1;
#end
#declare CX = 0;
#declare CY = CY + 1;

#declare MOVER = <0,CY*EQUAL_SPACING.y,0>; // ???

#end


Post a reply to this message

From: Kenneth
Subject: Re: "Exploded" vector transform
Date: 11 Aug 2017 19:40:01
Message: <web.598e07125219365e883fb31c0@news.povray.org>
"Kenneth" <kdw### [at] gmailcom> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
> HOWEVER... trying to extrapolate this to TWO dimensions (never mind THREE) has
> turned out to be a really thorny problem. Basically, it boils down to
> this: What part of an IRREGULARLY-shaped object should be considered as
> the 'point' to determine its equal spacing from another object?

I've seen some very cool animations of 'exploded archeological structures' on TV
(you probably have as well)-- like the Giza Pyramids, for example-- but I have a
feeling that all of the individual objects are not *truly* equally-spaced. They
just look that way. I would guess that such animations use the much simpler
approach of finding the centers of objects, then moving all the objects away
from each other equally, from those points. Kind of like my very first 'simple'
code example, extrapolated to three dimensions.


Post a reply to this message

From: Bald Eagle
Subject: Re: "Exploded" vector transform
Date: 14 Aug 2017 14:20:00
Message: <web.5991b0be5219365ec437ac910@news.povray.org>
"Kenneth" <kdw### [at] gmailcom> wrote:

> > HOWEVER... trying to extrapolate this to TWO dimensions (never mind THREE) has
> > turned out to be a really thorny problem. Basically, it boils down to
> > this: What part of an IRREGULARLY-shaped object should be considered as
> > the 'point' to determine its equal spacing from another object?

Ha - you seem to have taken a liking to solving this little problem.

I've been away from my work area for a week, so I haven't had much time to
dabble with any of this.

I'm thinking that this might be a situation where trace() is invaluable.

Just off the top of my head:
1. determine the center of mass coordinates of all the parts relative to the
center of the expansion.
2. determine 3 vectors for that piece for use in trace (trivially the
coordinates, interpreted as a vector, one with a negative multiplier) to get the
near and far points of the piece that are in line with the expansion direction,
and the closest point of the center of expansion piece
3. translate the piece along the direction of expansion vector, and keep the
length between the pieces a multiple of the expansion constant for that frame
4.work outwards

Not sure that the distance between ALL of the pieces would be constant - as
that's probably impossible to do - but it's a quick way to do the expansion
without having to resort to a Delaunay tetrahedralization or something along
those lines.


Post a reply to this message

From: Le Forgeron
Subject: Re: "Exploded" vector transform
Date: 15 Aug 2017 05:53:50
Message: <59928c6e$1@news.povray.org>
Le 04/08/2017 à 20:32, Bald Eagle a écrit :
> I'm interested in hearing different people's ideas about how to [evenly] add
> space between a group of objects / points.
> 
> I was thinking about this from a number of perspectives.
> 
> Making / adjusting 'exploded' diagrams like StephenS's recent vise.
> Modeling Hubbel's Law with astronomical bodies
> Modeling explosions (of course), smoke, steam, etc
> creating parameterizable complex objects like brick/stone walls, [possibly]
> parallel curves,
> and many more, I'm sure
> 
> The best I can figure, is translate all of the data (if necessary) so that one
> point is the center, and then scalar multiply all the vectors, and then
> translate them back to the proper scene location.
> 

Have you looked at same charge repulsion ? Each point get a contribution
/ movement on the opposite direction from each other point, and the
strength is proportionally inverse to the square of the distance between
the points.

For N points, you need to evaluate (N)*(N-1)/2 pairs.

You can add complexity by using a different mass for each point, and
dividing the strength by the mass to compute the movement of each step.

Another extension would be "negative gravity", taking into account the
mass of the other point when computing the strength.

You can also explore the domain of replacing the inverse square of
distance by other formulae (constant, linear, cube, log or exp,
fractional power such as 1.6 or 2.4, ... )


Post a reply to this message

From: Bald Eagle
Subject: Re: "Exploded" vector transform
Date: 15 Aug 2017 11:45:00
Message: <web.5992de255219365ec437ac910@news.povray.org>
Le_Forgeron <jgr### [at] freefr> wrote:

> Have you looked at same charge repulsion ? Each point get a contribution
> / movement on the opposite direction from each other point, and the
> strength is proportionally inverse to the square of the distance between
> the points.
>
> For N points, you need to evaluate (N)*(N-1)/2 pairs.
>
> You can add complexity by using a different mass for each point, and
> dividing the strength by the mass to compute the movement of each step.
>
> Another extension would be "negative gravity", taking into account the
> mass of the other point when computing the strength.
>
> You can also explore the domain of replacing the inverse square of
> distance by other formulae (constant, linear, cube, log or exp,
> fractional power such as 1.6 or 2.4, ... )

Oooh - those are some good ideas!
While I'm familiar with people applying those principles, applying them here
hadn't 'clicked'.

Those are great ideas with regard to my original inquiry, yet Kenneth has added
an extra measure of complexity to it by really focusing on the literal meaning
of "evenly spaced".


Jerome, let me ask you - how does one go about computing the complexity O for
any given operation / algorithm?

It seems to me that a lot of us sort of just work out some way to go about doing
something, which is logical and/or very human-readable in SDL, but we have no
idea of how [in]efficient that code is (other than comparing empirical render
time data), and no way to know if there exists a theoretically more efficient
way to accomplish the same task[s].

Thanks for your valuable and interesting input as always  :)


Post a reply to this message

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