 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Excellent piece of work. It looks real.
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Johnson wrote:
> -[hope that helps]-
> Excellent - the effect is very close to what I was looking for.
>
> Also, the fact that a particle system is not included in the source
> forces me to write my own... something I've been meaning to do for a
> long while.
Or - you could use mine if you want to save time... ;)
(It also has trace support for object.)
http://www.runevision.com/3d/include/particles/
But of course there's nothing like doing everything yourself... ;)
Rune
--
3D images and anims, include files, tutorials and more:
rune|vision: http://runevision.com (updated Oct 19)
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
-[Or - you could use mine if you want to save time...]-
True. In fact, Florian Brucker suggested exactly that in an e-mail. As you
say, though, much more instructive to do it myself...
Regards,
Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Perhaps this isn't the place to be asking this - though it is related to the
post.
I've got my (at the moment fairly basic) particle system up and running and
I'd like to generate particles at the end of the arm. However, the arm
movement at the moment is forward kinematics - i.e. the general structure is
#macro ArmPart2(angle 2, angle3...)
// Modelling here
object (ArmPart3(angle3...) rotate y*angle2 translate <5,4,-20>)
#end
#macro Robot(angle1, angle 2, angle3...)
// Modelling here
object (ArmPart1(angle2, angle3...) rotate x*angle1 translate <0,35,2>)
#end
with similar definitions for ArmPart2, ArmPart3 etc, and the robot being
placed by a single call to Robot(...). The position in global coordinates of
the end of the arm doesn't seem to be very easy to get at. At the moment,
I'm finding the position with a long formula with lots of embedded
vrotate(...) functions, but this hardly seems the most elegant solution.
The way I would usually place things at the exact end of the arm is to place
them in the macro that defines the very end part of the arm. However, this
isn't possible in this case, as the particles have to move realistically
relative to the global coordinate system, not relative to the end part of
the arm.
Anyone got any suggestions as to a better way than a very long equation?
Regards,
-Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Well, dependant on how accurate you want it, you
could try this:
declare a small sphere, positioned exactly like the
"fingertip" of the robotarm. Then, do the same
transformations with it.
In effect, this should position the declared sphere
exactly at the same tip as the arm where you want
the particles to come from.
Now, you use min_extent and max_extent to get
the boundary box of the sphere, and since the sphere
is completely round, you should get a box with
equal sides. Calculate the center of the boundary
box ( done like this: (min+max)/2 ) and use that as
position where particle enter the world.
This more or less tracks the arm, instead of you
doing all the calculations.
Aside of that, you're way is probably the only other
possiblity out there, as far as I can tell.
--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
> Perhaps this isn't the place to be asking this - though it is related to
the
> post.
>
> I've got my (at the moment fairly basic) particle system up and running
and
> I'd like to generate particles at the end of the arm. However, the arm
> movement at the moment is forward kinematics - i.e. the general structure
is
>
> #macro ArmPart2(angle 2, angle3...)
> // Modelling here
> object (ArmPart3(angle3...) rotate y*angle2 translate <5,4,-20>)
> #end
>
> #macro Robot(angle1, angle 2, angle3...)
> // Modelling here
> object (ArmPart1(angle2, angle3...) rotate x*angle1 translate <0,35,2>)
> #end
>
> with similar definitions for ArmPart2, ArmPart3 etc, and the robot being
> placed by a single call to Robot(...). The position in global coordinates
of
> the end of the arm doesn't seem to be very easy to get at. At the moment,
> I'm finding the position with a long formula with lots of embedded
> vrotate(...) functions, but this hardly seems the most elegant solution.
>
> The way I would usually place things at the exact end of the arm is to
place
> them in the macro that defines the very end part of the arm. However, this
> isn't possible in this case, as the particles have to move realistically
> relative to the global coordinate system, not relative to the end part of
> the arm.
>
> Anyone got any suggestions as to a better way than a very long equation?
>
> Regards,
>
> -Chris
>
>
---
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
-[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
|
|
| |
| |
|
|
|
|
| |
|
|
