steve_stallings is now known as steves_logging
jepler: can you point me at any docs that describe how the axis/vismach mouse based viewpoint rotation works?
it seems I can rotate around my model's X and Z axes, but not around Y
for a horizontal spindle machine that is a bit limiting
jmkasunich: I think it happens in the file lib/python/rs274/OpenGLTk.py, function glRotateScene
* jmkasunich looks
jmkasunich: the rotation is based around euler angles, you get two angles from the mouse coordinates
glRotatef(snap(lat), 1., 0., 0.)
glRotatef(snap(lon), 0., 0., 1.)
so we're trying to position the viewer using latitude and longitude
but the axis of the globe is aligned with Z
instead of being vertical wtr to a human looking at the machine
you could experiment with hard-coding the two vectors you want
sounds like all I need to do is rotate the machine
that might work too
anyway, the code could be changed around so that the axes are settable, just like min/max latitude
how are the initial values of lat and lon determined?
in class Opengl's init
self.lat = 0
self.lon = 0
t = O(app, double=1, depth=1)
you could set it just below here
just after that you'd write: t.lat = ...; t.lon = ...
I just rotated my model so that the machine's "up" (which happens to be Y) is pointing at world "up" (Z)
and now panning works fine
is this about panning or about rotating?
(fine = intuitively, you can move up/down, and spin around the vertical axis
moving the viewer around the machine
the "hmm" is because the initial viewpoint is now from straight above the machine
I'm used to lat = 0 being the equator, poles are +/- 90
is lat = 0 straight up in opengl?
I guess its not opengl, its OpenGLTk.py
I think you're right that in that code 0 is the "north pole"
so, I could change lat to conform to the traditional globe definition, but that would break other things
yes it would
or I could figure out how to let each caller of the opengltk lib specify an initial lat and lon
I think you can just write 't.lat = <initial lat value>' in vismach right below t = O(...)
but in a minute I'll have a way that script using vismach can set it
because they all want different things
what can we get in two minutes? :)
btw, what is HUD?
heads up display
ie, the data overlaid on the 3D model
thats what I thought
but I don't think I've ever seen it
doesn't AXIS use the same 3D library?
HUD is something specific to vismach
HUD is defined in vismach.py
axis has a different way of doing its DRO overlay
in that case - nevermind me
I think HUD is used by some hexapod visualization that fenn did
huh why are my changes having no effect?
(I'm wrong about just being able to set lat and lon there)
class OpenGL has a set_latitudelimits method, does it need method(s) to set lat and lon as well?
EMC: 03jepler 07TRUNK * 10emc2/lib/python/rs274/OpenGLTk.py: allow calling code to control the rotation vectors
EMC: 03jepler 07TRUNK * 10emc2/lib/python/vismach.py: allow calling code to control the rotation vectors and initial orientation
example: main(model, tooltip, work, 1500, rotation_vectors=[(0,1,0),(0,0,1)], lat=90, lon=45)
thank you very much
(not a particularly useful example, mind you)
actually, I'm not sure why you made the vectors user settable
originally it sounded like that was the solution
I guess that would let me avoid rotating my model to align it with world coords
did you mean to leave the prints in there?
of course nolt
so far I've just looked at the diff
EMC: 03jepler 07TRUNK * 10emc2/lib/python/vismach.py: remove debugging print
EMC: 03jepler 07TRUNK * 10emc2/lib/python/rs274/OpenGLTk.py: remove debugging print
why does set_viewangle() need to call RotateScene? can't it just set lat and lon?
glRotateScene actually does the dirty work
but the dirty work was being done before
setting lat and lon directly has no effect until the next rotation
.. next mouse event with the right button pressed
I think I see - it isn;t actually possible to set the initial values of lat and lon before the first rendering, so when you do set them, you need to re-render?
I'm not sure why the "after" is necessary
(or that it's sufficient)
I was gonna ask you what after means
there's some other detail of the initialization that I'm overlooking
it causes the code to be called after no less than 100ms, during the course of regular event handling by Tk
how is the handling of lat and lon initial values different than "latitudelimits"?
setting latitude limits has no immediate effect, so there's no need for any of those shenanigans
someday I'll wrap my head around the combination of OO and event loops
when you decide to try, don't look at my code
it's not the greatest at anything except working mostly
to be honest, that someday is probably a long way from now - I have other things I'd rather do
trying to understand - the lambda tells python to evaluate "t.set_viewangle" when the t.after "triggers" instead of when t.after is initially invoked?
seems to work nicely
the vectors take a bit of getting used to
the 2nd vector is the "up" axis (the one that goes thru the poles of the globe in the lat/lon mental model
I'm not sure what the first one is
but it sure looks like anything other than 1,0,0 gives very non-intuitive results
jepler: would you mind if I redid your vector change so you specify a single "up" vector, instead of a pair
hmm, this is more complex than I thought
the 2nd vector alone isn't "up" either
well now you're in geometry and I'm really helpless there
well, I'm just playing around now, seeing what different combos do
twisting my brain it is
the other thing you might want to vary -- but can't -- is whether lat or lon is applied first
the order seems to be right for what I'm trying to do
I want to be able to visualise the user/camera as being able to move up/down, and walk around
left-right mouse motion should just spin the model around a vertical axis, and that's what it does
something tells me if the order was reversed it would do weird things
you can test it by swapping the order of the rotation vectors
(you will, of course, have a hard time because mouse movement won't correspond to model movement :) )
I'm trying hard to wrap my brain around the default orientation
I should probably make a model with three colored rods representing the three axes
if I set the vectors to 100 010, I get the Y axis as "up", and the XZ plane is the ground
I was testing with initial lat = 45, bad choice
ok, with 100 010, lat and lon both zero, I start out standing on the XZ plane, looking along the Z axis
left right mouse movement spins around Y (as expected)
up/down moves me above or below the plane
that rotation doesn't take place around the model's X axis, it is around an axis perpendicular to the eye-model line, and horizontal
maybe it makes more sense to do what you did at first: just rotate the model so that it works well with the one style of rotation available..
that was where I was going
but I was having trouble
I just went back to the original vectors, lat and lon zero
the initial view is the same - I'm on the XZ plane, looking along Z
mouse left/right spins around the object Z axis
duh, ok, I think I understand now
jepler: still here?
there is a sign error somewhere, but I'm having trouble deciding where
I made a model with nothing but three arrows for the three axes, red/green/blue for XYZ
if the initial lat and lon are zero, I find myself staring at the point of the blue/Z arros
with green (Y) pointing down and red (X) right
if I move the mouse up, after 90 degrees, green (Y) is pointing at me, blue/Z is pointing up, red X is still pointing right
since I moved up, I assumed that direction is positive latitude
so I set initial latitude to +90 and expected to see the same thing, Y at me, Z up, X right
instead, Y is away from me, Z is down, and X is right
I could "fix" this by inverting the initial lat value, but I'm not sure that is right
going back to the lat = lon = 0 case, if I'm somewhere out on the +Z axis looking at the origin, and we have a right handed coord system, shouldn't +Y be up and +X be right? I have Y down and X right
lol - I just found a bug in CylinderY() - it makes a cylinder pointing the wrong direction along the axis
so it was building a left-handed coordinate system
(the test = put a box at the end of each arrow)
EMC: 03jmkasunich 07TRUNK * 10emc2/lib/python/vismach.py: fix bug in CylinderY() - cylinder pointed wrong direction along axis - also fix invocations of CylinderY()
EMC: 03jmkasunich 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/ (5axisgui.py maho600gui.py max5gui.py): fix bug in CylinderY() - cylinder pointed wrong direction along axis - also fix invocations of CylinderY()
looking at the invocations, that bug should have been apparent before - when you have to start a cylinder at -18 to butt it against a box that ends at +18, the mental bug detector should go off
(I wrote most of those invocations - it's my mental bug detector that needs fixed)
back to lat and lon
ok, lat = lon = 0, starts out looking at the sharp end of the Z arrow, Y is up, X is right
mouse up, rotates so that you are looking at the dull end of the Y arrow, Z up, X right
exactly what you'd expect
since I moved the mouse up, I set lat = 90
and behold, I'm seeing the sharp end of Y, Z points down, X right
sure enough, moving the mouse up actually makes lat go down
I guess that makes sense
mouse up means viewer is moving down from the north pole, so latitude should be getting smaller
yay, got the initial view and rotations working they way I want
oh I didn't think about this machine being sideways...
did you see the screenshot I just posted?
yes, you did
I looked at your screenshot too, very nice. Is that vismach?
EMC: 03cradek 07TRUNK * 10emc2/src/emc/iotask/ioControl.cc: make pretty columns instead of using tabs (which never look right)
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/index.tmpl: add ladder section to html docs
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/index.tmpl: that looks better
EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/ (Master_User.lyx index.tmpl): minor edits
EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/common/GPLD_Copyright.lyx: minor edits
How is it going?
started working on the electric wiring in the app.
Boy - it has been a while. You found a place?
how is the wiring? Old?
yeah, bought an app. 1 month ago
not all is old, but I still want to replace everything
it's only 2-wire
A good portion of my house is cloth wiring.
well.. since the app is empty I can easily irp it all out, and redo
but it's not very easy (doing this on brick walls ;)
how is it run now?
inside the wall in old metalic tubes
which I'm replacing with plastic
bbl.. running home to do some more work on this
cradek, did you ever do that linuxcnc.org backup (in case I decide to move to the unlimited plan)?
SWPadnos: I will run one tonight, and also right before you make any change, if you let me know.
haven't done it, and I'm not sure if/when I will - just wondering what had happened with it
do they still have openings?
dunno. I think it may have been two different offers
one for new customers, the other for current subscribers
anyways, I didn't see anything yet
any changes I mean
oh- as far as actually moving your account over?
yeah, they updated the info all over the panel, but nothing more
looks like the offer is still open
I have another friend with an account - I'll have to see if the forums have been screwed up or if the move has been done yet
Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2008-10-20.txt
in emcmodule.cc axis["inpos"] is updated when jogging axis
but doesn't update while in MDI mode
is this correct ?
micges: yes, it's purely for the "free planner". It is emphatically not a "this axis is not moving at this time" flag to use to reduce hold current or the like.
Jepler: did you troubleshoot the following error on plutostep?
skunworks: no, I have no idea what went wrong
heh - yecky
it has only happened once so far though - right?
I'd be happier if it happened every time :-P
yes - those are a lot easier to find.