@tig said:

Why not use 90.degrees etc and return the angle.radians to see what it is in degrees too... skip all of the PI and radian confusion...

=====> I tested with 90.degrees, but I thought it was the conversion that was bad

Why are you making your axe/up vectors so complex ?
Your figures are off too...
axe = Geom::Vector3d.new(-0.999782867743517, -0.0208378829670674, 0.0)

=====> because it is real vectors returned with axe.inspect
I was given a real example.

Which is a very tiny number that's ALMOST zero

This is a a simple tolerance issue...

======>Tolerance has importance here because it is cumulative.

BUT to test for tiny values use something like:

a 'rounding' method - here to 6dp.

angle=(angle*106).round.to_f/106
angle==0
true

This will then trap for these tiny inaccuracies...

...

thank's Dan Rathbun

i have sketchup 8 !!!

it's not angle between, but the subtraction.
because the calculation of the angle is good.

Hi all,

I have a strange result when I subtract two angle in radians!!!!

example :

<span class="syntaxdefault">axe </span><span class="syntaxkeyword">=</span><span class="syntaxdefault"> Geom</span><span class="syntaxkeyword">;;</span><span class="syntaxdefault">Vector3d</span><span class="syntaxkeyword">.new(-</span><span class="syntaxdefault">0.999782867743517</span><span class="syntaxkeyword">,</span><span class="syntaxdefault"> </span><span class="syntaxkeyword">-</span><span class="syntaxdefault">0.0208378829670674</span><span class="syntaxkeyword">,</span><span class="syntaxdefault"> 0.0</span><span class="syntaxkeyword">)<br /></span><span class="syntaxdefault">up </span><span class="syntaxkeyword">=</span><span class="syntaxdefault"> Geom</span><span class="syntaxkeyword">;;</span><span class="syntaxdefault">Vector3d</span><span class="syntaxkeyword">.new(</span><span class="syntaxdefault">0.00335712544250249</span><span class="syntaxkeyword">,</span><span class="syntaxdefault"> </span><span class="syntaxkeyword">-</span><span class="syntaxdefault">0.161071856847676</span><span class="syntaxkeyword">,</span><span class="syntaxdefault"> 0.98693697196954</span><span class="syntaxkeyword">)<br /></span><span class="syntaxdefault">axe</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">normalize</span><span class="syntaxkeyword">!<br /></span><span class="syntaxdefault">up</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">normalize</span><span class="syntaxkeyword">!<br /></span><span class="syntaxcomment"># (90 deg) = 1.5707963267948966 in rad<br />#(Math;;PI/2.0) = 90.0 in degrees, 1.5707963267949 in radians<br /><br /># angle between up-axe = 90.0 in degrees, 1.5707963267949 in radians<br /></span><span class="syntaxdefault">angle </span><span class="syntaxkeyword">=</span><span class="syntaxdefault"> </span><span class="syntaxkeyword">(</span><span class="syntaxdefault">Math</span><span class="syntaxkeyword">;;</span><span class="syntaxdefault">PI</span><span class="syntaxkeyword">/</span><span class="syntaxdefault">2.0</span><span class="syntaxkeyword">)</span><span class="syntaxdefault"> </span><span class="syntaxkeyword">+</span><span class="syntaxdefault"> </span><span class="syntaxkeyword">(</span><span class="syntaxdefault">up</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">angle_between axe</span><span class="syntaxkeyword">)<br /></span><span class="syntaxdefault">puts angle</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">radians  </span><span class="syntaxcomment">#=> 180 degrees, 3.14159265358979 radians GOOD !!!<br /><br /></span><span class="syntaxdefault">angle </span><span class="syntaxkeyword">=</span><span class="syntaxdefault"> </span><span class="syntaxkeyword">(</span><span class="syntaxdefault">Math</span><span class="syntaxkeyword">;;</span><span class="syntaxdefault">PI</span><span class="syntaxkeyword">/</span><span class="syntaxdefault">2.0</span><span class="syntaxkeyword">)</span><span class="syntaxdefault"> </span><span class="syntaxkeyword">-</span><span class="syntaxdefault"> </span><span class="syntaxkeyword">(</span><span class="syntaxdefault">up</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">angle_between axe</span><span class="syntaxkeyword">)<br /></span><span class="syntaxdefault">puts angle</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">radians  </span><span class="syntaxcomment">#=> 1.27222187258541e-014 BAD,  2.22044604925031e-016 in radians BAD &nbsp;</span><span class="syntaxdefault"></span>

can you help me ?

@tig said:

I do not know this tool in any detail... but in passing... I see that there are $ global variables like '$preview' these are dangerous - especially if they have simplistic names [like 'preview'] as other authors might have used them [ill-advisedly] too, as globals works across all scripts in that session - better to use '@preview' as an instance variable, or '@@preview' as a class variable, to hold your data specifically for your own tool so such potential clashes are avoided...

Yes TIG

when I developed this plugin I had only one months experience the ruby language and API sketchup.
certainly you will find other errors of this type in the source, but I perfecting every day.
in the next release several beginner mistakes are corrected but it will remain.

best regard

@jim said:

@macgile said:

I thought the result would be near to 0 and not of 4.

macguile,

4.44089209850063e-016

The e-016 at the end of the number means to move the decimal place 16 places to the left - making the actual number:

0.0000000000000000444089209850063

or very nearly zero. The reason the result is not exactly zero is due to floating point errors as linked above.

thank i nderstand now

regard

@dan rathbun said:

A singleton method to increment a float a, by an argument arg, to dec number of decimal places. (It defaults to 1 decimal place.)

a = 9.0
> def a.incr( arg = 1.0, dec = 1 )
>   dec = dec.to_i
>   arg = round( arg.to_f * 10**dec  )
>   # self is object a
>   temp =( round( self * 10**dec ) + arg ).to_f
>   self =( temp / 10**dec )
> end

use it like:
a = 9.0 b = -1.8 a.incr(b)

THANK for this solution Dan

Best Regard

@voljanko said:

@unknownuser said:

i dont compare anything !!!
i have tested with a = a + b the result is same

I just meant that is always good to avoid considering floats as exact numbers.

oh yes

I thought the result would be near to 0 and not of 4.

@dan rathbun said:

@macgile said:

i have tested with a = a + b the result is same

That is because the Ruby interpreter converts
a += b
to
a = a + b
before the expression is evaluated.

i dont understand your explanation Dan !!!!

@voljanko said:

This is almost zero
It is always a risk when you use floats, in all languages.You should never compare float == float if you don't want problems.

i dont compare anything !!!
i have tested with a = a + b the result is same

hi rallouD

try this : http://pleac.sourceforge.net/pleac_ruby/dbaccess.html

Hi all

i tryed this code:

a = 9.0
b = -1.8
 

a += b  
puts a  # => 7.2 good
a += b  
puts a  # => 5.4 good
a += b  
puts a  # => 3.6 good
a += b  
puts a  # => 1.8 good
a += b  
puts a  # => 4.44089209850063e-016 BAD RESULT !!!!

you had an explanation for this strange result?

regard

hi Dan Rathbun,

first thank's to reply

i have found this solution

windows :
K_CTRL_ALT = COPY_MODIFIER_KEY.to_s << ALT_MODIFIER_KEY.to_s
K_ALT_DEL = ALT_MODIFIER_KEY.to_s << VK_DELETE.to_s

mac:
K_CTRL_ALT = VK_CONTROL.to_s << VK_ALT.to_s
K_ALT_DEL = VK_ALT.to_s << VK_DELETE.to_s

@flags =""

CTRL + ALT or ALT + DEL

def onKeyDown(key, repeat, flags, view)

SAVE KEY to string

@flags += key.to_s
end

def onKeyUp(key, repeat, flags, view)

if (@flags == K_CTRL_ALT)

do something

end

#window or mac (on mac, delete it triggers only in onKeyUp)
if(@flags == K_ALT_DEL || (@flags + key.to_s) == K_ALT_DEL))

do something

end

@flags = ""
end

it's not "très élégant" but it works with any key combination

best regard

oups

fix for mac :
K_CTRL_ALT = VK_CONTROL.to_s << VK_ALT.to_s
K_ALT_DEL = VK_ALT.to_s << VK_DELETE.to_s

onKeyUp
#window || mac (on mac, delete it triggers only in onKeyUp)
if(@flags == K_ALT_DEL || (@flags + key.to_s) == K_ALT_DEL))

do something

end

@thomthom said:

@macgile said:

In the MAC OSX (ALT + DELETE) it's available only on onKeyUp and work fine
on the PC it's available on the onkeyDow AND onkeyup.

Here is what I find, under Windows:

When only Delete is pressed, it triggers only onKeyUp.
When Shift+ Delete is pressed, it only onKeyUp.
When Ctrl+ Delete is pressed, it triggers both onKeyDown and onKeyUp.
When Alt+ Delete is pressed, it triggers both onKeyDown and onKeyUp.

Thank's thomthom

thank you it is very useful

@driven said:

hi macgile

sorry that path pic was me trying to edit out the camera rotate,
on this simple version the camera rotates on scene 4.

john[attachment=0:1hzgzkb0]<!-- ia0 -->loop2.png<!-- ia0 -->[/attachment:1hzgzkb0]

hi driven
Ok in the next release you can do it with rotate around camera target.

best regard

@putnik said:

macgile, this is awesome! Thank you!

Thank's putnik

best regard

@isda said:

In the next version this offset will be smaller, and higher accuracy.

I also added the ability to move around the target (the locked or not)
or rotate the eye of the camera.
This should facilitate the zigzagging between objects.

Hi Macgile,

Can't wait to try the next version (I don't mean to pressure you by this.. haha (= ). God bless you in your pursuit to excellence.

The ability to rotate the eye of the camera is a great idea, as well.

I don't know if I am pushing the limit but I remember one 3D software where you can see the camera on the path and being able to see (from the top view) in what direction the cam is facing much like the AdvanceCameraTool... but anyways, as it is, I believe this plugin is great already.. kudos to you.

hi isda
yes drarq already suggesting this improvement.
but it will be for a future release.
now I made ​​a version that works for everyone (PC and MAC OS)
I fix bugs and improve the design.

best regards

@driven said:

this is basically working on the mac using ShiftQ, and mac arrow keycodes, the html needs some work as you need to right click after the dialog appears to load the page content, but then it works.

is it possible to loop over an object, the camera rotates twice with this path [see pic]

cheers

john
[attachment=0:2glsdkjl]<!-- ia0 -->loopAnim.png<!-- ia0 -->[/attachment:2glsdkjl]

hi driven
I don't understand what you want?
in the picture the camera rotates around object but look to outside!!!!

@isda said:

macgile, i have edited the script as you suggested and it's working fine with me, too. thanks very much, i can now move the camera keys from all views now. I have another question... have you tried using this on a walkthrough? I seem to lose the camera angle even if I edit the camera path and the target to make sure that I see my models as I glide through them. the line between the key and the target does not seem to be what it is supposed to be when I hit up button..

going around a single model is a breeze but zigzagging through different models is a different story.

hope this script really develops into a plugin all of us cannot do without... keep it up, sir. thanks much!!!

hi isda

The final path of the eye and the target is smoothed by Bezier interpolation.
you can see into view because they are drawn dashed.
Consider the offset between keys and smoothed path to adjust the control keys.

In the next version this offset will be smaller, and higher accuracy.

I also added the ability to move around the target (the locked or not)
or rotate the eye of the camera.
This should facilitate the zigzagging between objects.

Your suggestions are welcomed

@dbalex said:

No it still only works partially for me but I didn't try the new version, I will do it soon and reply here. We should wait for the next release when bezier.rb will not be needed anymore, maybe that will make it work for us..

Hi dbalex

Currently I am looking for a way not to use Bezier curves.
I test the natural cubic spline and B-spline.
The cubic spline requires too much precision in their adjustment to smooth the path.
The B-spline is my preference because it is more accurate than Beziers and less than the Cubic Spline.
But the algorithm is very greedy for the moment.
So maybe I'll use both.

To correct the bug in edit mode:
I used the old pick_point_to_move method of bezier.rb
This method has been corrected in the new version (see http://forums.sketchucation.com/viewtopic.php?f=323&t=30973)
Thank's TT and Fredo

you can make the following changes
in file camera_key_maker.rb:

in
def pick_point_to_move (x, y, view)

change:

if ph.pick_segment @points_eye
 path       = "eye"
 @selection = ph.pick_segment @points_eye
elsif ph.pick_segment @points_target
 path       = "target"
 @selection = ph.pick_segment @points_target
end

by :

if ph.pick_segment(@points_eye, x, y)
path = "eye"
@selection = ph.pick_segment(@points_eye, x, y)
elsif ph.pick_segment(@points_target, x, y)
path = "target"
@selection = ph.pick_segment(@points_target, x, y)
end

Best Regard