 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 1/30/22 15:48, Cousin Ricky wrote:
> On 2022-01-30 12:01 (-4), jr wrote:
>>
>> I had wanted to make an animation of the shapes rotating above the podium, but
>> they .. orbit. because the bounding box "method" doesn't work too well, I need
>> to calculate the geometric centre (?) of a given 'blob'. did some googling on
>> the subject but have only found 2D solutions so far. help please.
>
> I have a couple of suggestions. If you know the surface radius of each
> component, you can create a union of spheres, and take the center of the
> union. Function RE_fn_Blob_surface_radius() in roundedge.inc can
> calculate the surface radii.
> <https://github.com/CousinRicky/POV-RoundEdge>
>
> Alternatively, you can go brute force with trace() or inside(), and take
> the center of all the successful hits. inside() would take longer than
> trace(), due to being volumetric, but it would allow you to compute a
> rough center of gravity, rather than just computing the center of the
> extents.
I'll toss a couple more ideas on the table.
You can still manually bound objects but you have to turn the automatic
bounding strip off. -ur (IIRC). Not sure any advantage over the union of
spheres idea.
The blob object is one of two objects supporting a potential pattern for
itself. Further I think is uses effectively 'raw_wave' internally though
it's not brought all the way out to an official keyword in v3,8/v4.0 as
it is in povr. It should be you can sample actual blob internal values
too though unsure if any better than trace/inside testing. The greatest
inside value (most positive IIRC with blobs) won't necessarily be the
center of mass depending on the shape and construction.
The still image looks cool! :-)
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2022-01-30 17:40 (-4), William F Pokorny wrote:
>
> You can still manually bound objects but you have to turn the automatic
> bounding strip off. -ur (IIRC). Not sure any advantage over the union of
> spheres idea.
The problem with this is that you'd have to know where the bounds are,
which seems to be the unknown here.
As far as defeating automatic bounding (which cannot be entirely turned
off--See clipka's comments in "Apparent bounding bug in sphere_sweep,"
April 2013), I just intersect the object with a bounding shape, which
sidesteps the issue entirely. Potential problems with this approach are
performance issues with complex unions, and that it may not work with
cubic sphere_sweeps.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2022-01-30 16:48 (-4), Cousin Ricky wrote:
>
> I have a couple of suggestions. If you know the surface radius of each
> component, you can create a union of spheres, and take the center of the
> union.
P.S. I notice that there appear to be cylindrical components in your
blobs. Not a problem, as all you need are the end-spheres of the cylinders.
Of course, the spheres would need to have the same transformations as
the corresponding blob components.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"jr" <cre### [at] gmail com> wrote:
> what I want, ideally, is to find the one point in a blob
> which, when placed at origin, would allow me to rotate "the hell out of it" :-).
> unfortunately my maths/knowledge is .. abysmal, I do not (even) know whether
> that specific point is the centre of the extents (what I meant by geometric
> centre) or the centre of gravity.
I'm wondering what you get if you just take all of the coordinates and average
them. It has to be --- some sort of center.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 1/30/22 20:09, Cousin Ricky wrote:
> On 2022-01-30 17:40 (-4), William F Pokorny wrote:
>>
>> You can still manually bound objects but you have to turn the automatic
>> bounding strip off. -ur (IIRC). Not sure any advantage over the union of
>> spheres idea.
>
> The problem with this is that you'd have to know where the bounds are,
> which seems to be the unknown here.
>
> As far as defeating automatic bounding (which cannot be entirely turned
> off--See clipka's comments in "Apparent bounding bug in sphere_sweep,"
> April 2013), I just intersect the object with a bounding shape, which
> sidesteps the issue entirely. Potential problems with this approach are
> performance issues with complex unions, and that it may not work with
> cubic sphere_sweeps.
I expect you're right that - especially with official v3.7+ POV-Ray - a
user bounding approach will be problematic.
---
Sorry too, I wasn't clear. The ur control strips user specified bounding
or not and it defaults to stripping all user specified bounding. My
thinking was it might be possible to quickly dial in the axis of
rotation you want via a larger - as needed on certain sides - user
bounding(a) so long as the user bounding wasn't stripped.
I was forgetting that in POV-Ray proper there is - completely hidden
from users / silent acting - code which measures the volume of the
current bounding box and it prevents users from specifying a smaller by
volume user bounds than exist on the shape currently. Long standing
comments in the code suggest there are problems with this "we know
better than the user" approach to bounding - expect you too can think up
a few pitfalls.
---
It's true, but a somewhat different issue, that the bounds checking set
on the final object cannot be turned off(c) in official v3.7,v3.8,v4.0
versions of POV-Ray.
The -mb or bounding off by < count options do work again in povr as in
v3.6 and prior.
Bill P.
(a) - With the +ur default there are internally exceptions where for a
few constructions/(objects?) the stripping does not happen even with the
+ur default. (d)
(b) - Code I changed in povr a long time ago. I don't recall all the
particulars. (d)
(c) - For a very few simple base objects this last level of bounds
checking is bypassed. I don't recall a compete list (it's a per object
code change), but spheres and boxes are on it. (d)
(d) - Does this sort of secrete, "we'll quietly fix/do it differently
for you," code occasionally lead to brutally confusing situations for
users and coders?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2022-01-30 à 11:01, jr a écrit :
> hi,
>
> I started playing with some code that uses (English) dictionary words + phrases,
> the character ASCII values, to create points used to make the blob components.
> while it's early days, I post this topical image (in anticipation), each blob
> represents one word, no points for guessing them :-). enjoy.
>
> I had wanted to make an animation of the shapes rotating above the podium, but
> they .. orbit. because the bounding box "method" doesn't work too well, I need
> to calculate the geometric centre (?) of a given 'blob'. did some googling on
> the subject but have only found 2D solutions so far. help please.
>
>
> regards, jr.
Start by creating your shapes around the Y axis if possible.
Try using max_extent(Object) and min_extent(Object) like this :
#declare Centre = (max_extent(Object) + min_extent(Object) ) / 2;
//This will find the opposing corners of the bounding box, then find
//their average. That average value is the centre of your object.
#declare Object = object{Object translate -Centre rotate Some_Rotation
translate Centre}
//This translate your object by minus the found value, apply your
//rotation, then translate your object back to it's original location.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain Martel <kua### [at] videotronca> wrote:
> Start by creating your shapes around the Y axis if possible.
>
> Try using max_extent(Object) and min_extent(Object) like this :
>
> #declare Centre = (max_extent(Object) + min_extent(Object) ) / 2;
> //This will find the opposing corners of the bounding box, then find
> //their average. That average value is the centre of your object.
>
> #declare Object = object{Object translate -Centre rotate Some_Rotation
> translate Centre}
> //This translate your object by minus the found value, apply your
> //rotation, then translate your object back to it's original location.
This is mathematically correct and in my opinion the best/simplest solution if
it works properly *but* might not produce the desired result artistically for
each object. For example, picture a ballerina spinning with one arm
outstretched. Her average center of rotation would probably be somewhere near
her shoulder, so a more complex formula (or artistic judgment) is sometimes
necessary. For these abstract shapes perhaps that will suffice, or perhaps it
will look awkward. I would certainly try this method first and see how it looks.
It will probably look great. I'm very curious to see because this is an
interesting artistic question. If it doesn't look right then here's another
possibility that I would try: Place each object in turn inside a vertical
cylinder centered on the y axis. Use highly contrasting colors so you can easily
see where the object extends outside the cylinder. You can also make the
cylinder partially transparent. Adjust the radius of the cylinder and the x and
z positions of the blob object until it "feels right."
I'm looking forward to seeing where this leads!
Kind regards,
Dave Blandston
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> The still image looks cool! :-)
thank you. had wanted the podium flanked by a couple of bay-trees (or
cypresses) in planters, like the "for hire" type seen at events, but could not
find anything "ready made". there are other .. niggles. btw, forgot to say,
the "checkered plane" was added because of the recent "RSOCP" revival. :-)
@Bald Eagle
thanks. quick paper and pen shows it works for axis-aligned cubes, will need to
write some code to test more arbitrary sets of points.
@Cousin Ricky
I guess I don't really need radius/diameter of sphere/cylinder? I think[1] just
the points, as BE suggests, should do.
[1] fwiw.
@Alain
making shapes near/around Y will be difficult/not possible in some cases. I'm
still experimenting with different layouts when using character values to create
"random" points, but only one of those (so far) could be written that way.
@Dave Blandston
"mathematically correct" vs "artistic intention" - good point. thanks for the
cylinder suggestion, yesterday I wrote some code using a wireframe box + three
axes to make a crosshair to aid positioning (but that's a crutch at best because
it means .. _fiddling_). and thanks for the interest, I too am keen "to seeing
where this leads" :-).
re the bounding discussion. reading this with interest. below are the unscaled
sizes of the three shapes in the image. first POV-Ray "max_extent() -
min_extent()" values, then the 'Bounder'[2] macro's take on the objects; the
second set of sizes is the same shapes but with rotations applied (ie oriented
as in the image). much "air" in those bboxes.
[2] using default '<50,50,50>' resolution. (still took about an hour to parse)
-----[ no .Rotate
gold <6.777,7.425,6.777>
silver <10.308,8.902,10.907>
bronze <6.580,5.617,5.396>
----------[Bounder info]------------------------------------------------
BB aligned dimensions: <6.776587, 7.424744, 6.776587>
BB optimised dimensions: <2.518731, 5.263363, 2.238872>
BB aligned dimensions: <10.308336, 8.902399, 10.907174>
BB optimised dimensions: <8.146588, 4.801294, 7.204739>
BB aligned dimensions: <6.580112, 5.616580, 5.396318>
BB optimised dimensions: <3.680063, 3.737724, 3.457641>
-----[ .Rotate
gold <8.300,7.425,8.300>
silver <10.907,10.308,8.902>
bronze <9.945,8.471,8.292>
----------[Bounder info]------------------------------------------------
BB aligned dimensions: <8.299590, 7.424744, 8.299590>
BB optimised dimensions: <2.279887, 5.263363, 2.339884>
BB aligned dimensions: <10.907174, 10.308336, 8.902399>
BB optimised dimensions: <7.204739, 8.146588, 4.801294>
BB aligned dimensions: <9.945232, 8.470688, 8.292479>
BB optimised dimensions: <4.582411, 4.035564, 3.037245>
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"jr" <cre### [at] gmailcom> wrote:
> @Bald Eagle
>
> thanks. quick paper and pen shows it works for axis-aligned cubes, will need to
> write some code to test more arbitrary sets of points.
As far as I can tell, this approach ought to work great with any arbitrary set
of sizeless points.
As Dave points out, once you start to add some volume, things get offset a bit.
If all of the points on the ballerina's surface were used to create a positional
average, it ought to work just as well, so maybe a trace() approach would be
simplest.
I'm sure there might be a way to do it where the point-center is found, and then
the blob sphere center point vectors are weighted according to the radii.
Probably hard to parse and understand that, but I think a diagram would show
what I mean...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2022-02-01 à 01:34, Dave Blandston a écrit :
>
> This is mathematically correct and in my opinion the best/simplest solution if
> it works properly *but* might not produce the desired result artistically for
> each object. For example, picture a ballerina spinning with one arm
> outstretched. Her average center of rotation would probably be somewhere near
> her shoulder, so a more complex formula (or artistic judgment) is sometimes
> necessary. For these abstract shapes perhaps that will suffice, or perhaps it
> will look awkward. I would certainly try this method first and see how it looks.
> It will probably look great. I'm very curious to see because this is an
> interesting artistic question. If it doesn't look right then here's another
> possibility that I would try: Place each object in turn inside a vertical
> cylinder centered on the y axis. Use highly contrasting colors so you can easily
> see where the object extends outside the cylinder. You can also make the
> cylinder partially transparent. Adjust the radius of the cylinder and the x and
> z positions of the blob object until it "feels right."
>
> I'm looking forward to seeing where this leads!
>
> Kind regards,
> Dave Blandston
>
In the case that you mention, the solution would be to add some offset
when translating :
#declare Offset = Artistic_Adjustment_Value;
#declare Centre = (max_extent(Object) + min_extent(Object) ) / 2;
//This will find the opposing corners of the bounding box, then find
//their average. That average value is the centre of your object.
#declare Object = object{Object translate -Centre+Offset rotate
Some_Rotation translate Centre-Offset}
// This translate your object by minus the found value adjusted by
// the artistic offset, apply your rotation, then translate your
// object back to it's original location.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
