 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
Post a reply to this message
Attachments:
Download 'o22.png' (257 KB)
Preview of image 'o22.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
Cousin Ricky <ric### [at] yahoo com> 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. Function RE_fn_Blob_surface_radius() in roundedge.inc can
> calculate the surface radii.
> <https://github.com/CousinRicky/POV-RoundEdge>
yes, I can specify the radii, so, excellent, thanks, will check out the code.
> 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.
ah, there's the rub. 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.
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] gmailcom> 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
|
|
| |
| |
|
|
|
|
| |
|
|
