-[Now, you use min_extent and max_extent to get the boundary box of the
sphere]-
Cunning stuff. Thanks for this tip: as you can see in the attached test
render the accuracy doesn't really matter a great deal, as the sparks are
going all over the place anyway. Just the mystery floating particle and the
rather ugly lighting artifacts on the floor to tidy up now (and something to
weld, of course...)

Is there any reason why the min_extent/max_extent functions should be
innaccurate? I noticed in the "PartixGen is BACK!" thread a discussion about
innacuracies in the trace function too. I suppose if these are calculated
using general iterative intersection formulae rather than mathematically
perfect equations, there is a small accuracy loss, but the renderings rarely
show up these accuracy errors, except in the case of two or more coincident
surfaces.

Post a reply to this message

Attachments:
Download 'kawazx17.jpg' (12 KB)

Preview of image 'kawazx17.jpg'

No no, min- and max_extent return the boundary
box, and trace() returns the intersection of the
defined ray to the object in question with (I assuming)
most possible precision.

What I was talking about in the other thread is that
when doing iterative estimations (using trace) to find
when and where a particle (which fly curved paths
and thus can't be handled easily with just on straight
trace) hits an object, that is less precise than compared
to solving an actual formula to find when EXACTLY
a curved path will intersect with a plane.
For a particle system it is crucial to know *when* a
particle hits a wall, so its path to the wall isn't suddenly
shorter or longer than it would be in RL. It can also
matter very much *where* a particle hits, because with
imprecision, it might even happen that a very small
object is missed during the iterative trace-ing.

-- 
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights


> -[Now, you use min_extent and max_extent to get the boundary box of the
> sphere]-
> Cunning stuff. Thanks for this tip: as you can see in the attached test
> render the accuracy doesn't really matter a great deal, as the sparks are
> going all over the place anyway. Just the mystery floating particle and
the
> rather ugly lighting artifacts on the floor to tidy up now (and something
to
> weld, of course...)
>
> Is there any reason why the min_extent/max_extent functions should be
> innaccurate? I noticed in the "PartixGen is BACK!" thread a discussion
about
> innacuracies in the trace function too. I suppose if these are calculated
> using general iterative intersection formulae rather than mathematically
> perfect equations, there is a small accuracy loss, but the renderings
rarely
> show up these accuracy errors, except in the case of two or more
coincident
> surfaces.
>
>
>


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.501 / Virus Database: 299 - Release Date: 14.07.2003

Post a reply to this message

-[doing iterative estimations (using trace) to find when and where a
particle (which fly curved paths and thus can't be handled easily with just
on straight trace) hits an object]-

Ah sorry, I misunderstood this to mean that there was an innacuracy inherent
in the trace function (and also possibly the max_extent/min_extent
functions). Thanks for the clarification,

-Chris

Post a reply to this message

Looks great (at least at this image size)!

The cylinder with yellow label looks misplaced: it can't move the
arm because it is pointing to its axis of rotation. The base point
of this cylinder should lie a bit backwards.

If you want the direction of the "fingertips" (not only the position),
you will either need a

  second sphere on the "finger", transform it the same way as the
  position-sphere, detect its final position with the min_extent/max_extent
  trick and find Direction = SphereMidpoint1 minus SphereMidpoint2,

or

  use additional parameters Position and Direction (possibly Rotation also)
  with the construction macros and transform them along with the components
  of the arm,

or

  use a parameter Transform to describe the position, direction and rotation
  of the robot's tool.

This would enable you to spray the sparks (or water, paint, laser beam, ...)
in a direction relative to the robot's tool. You also could attach a tool
*after* the arm is positioned.

You will show us two more robots holding the parts to be welded together,
won't you?!? And more of them in the background for preprocessing and
postprocessing, grabbing the material, stacking the final products?!?
Robots building a robot?!? Animated?!? I'll stay tuned ...

   Sputnik

Post a reply to this message

-[Looks great (at least at this image size)!]-
That is one small issue at the moment... much bigger than 640x480 and it
becomes clear that the model is not as detailed as it could be. However, the
intention is to produce an animation with this, so this should be fine.

-[The cylinder with yellow label looks misplaced: it can't move the arm
because it is pointing to its axis of rotation]-
Agreed. However, this is "true to life", as the robot is roughly modelled on
a Kawasaki ZX series one:
http://www.kawasakirobotics.com/products/Robots/RobotModels/Robots_ZSeries.a
sp. I have been wondering what this cylinder actually does in real life. The
motion of the arm is done entirely by electric motors, so my only guess is
that the cylinder acts to push the arm to the vertical position, to partly
counter the not insignificant weight of the arm and so require less torque
from the driving motor.

Thanks for the help on the direction/position of the "fingertips". The next
fairly fairly big problem is inverse kinematics. A general IK solver is
mathematically a rather difficult problem, but by specifying the angle as
well as the position of the "fingertip", I specify 6 degrees of freedom,
which coincidentally is the same as the number of joints in the arm. This
should make things somewhat easier.

-[Robots building a robot?!? Animated?!? I'll stay tuned ...]-
I've been thinking very much the same things, but hadn't quite got round to
thinking exactly what. So for inspiration, I've just loaded up my Minority
Report DVD to see what sort of things happen in the scene in the car
factory. Bizarrely, and totally coincidentally, every robot in the factory
is a Kawasaki ZX series... makes my POV-Ray one look a bit pathetic...

-Chris

Post a reply to this message