Camera Rays wanted

August · 13 May 2010, 03:50

This is driving me crazy and now I've spent nearly another full day on it. Arrgh!

I can draw Camera Ray lines just fine. But not clines unless there is an object to reference.

I can get one, single unreferenced cline. Once a cline fails to get an input point because of a lack of a reference object, I cannot get another valid @ip for a line, only for clines that have reference objects. Doesn't matter if I reload the file, I have to restart SU to clear this state.

I thought I could draw the line first, and then use its endpoints to create the vector (that works) and the cline (that doesn't work).

To demonstrate, I have two files. The only difference between them is that in the first one, some code is commented out: the single line of code that creates a cline from a point and a vector and some following messages to report on it.

Both versions create a vector from the original line and that appears to work fine.

Here's the version that creates plain old ordinary edge lines. I call it rayL.txt:


class Clf_august_lines;

  def onMouseMove(flags, x, y, view);
    @ip = view.inputpoint(x,y);
    view.invalidate;
  end;

  def onLButtonUp(flags, x, y, view);

line1 = Sketchup.active_model.active_entities\
.add_line(view.camera.eye, @ip.position);
 if (line1)
   UI.messagebox "line1 SUCCESS\n
view.camera.eye = " + view.camera.eye.to_s + "\n
@ip.position = " + @ip.position.to_s else
 else
   UI.messagebox "line1 Failure\n
view.camera.eye = " + view.camera.eye.to_s + "\n
@ip.position = " + @ip.position.to_s
 end

vector1 = line1.start.position\
.vector_to(line1.end.position);
 if (vector1)
   UI.messagebox "vector 1 = " + vector1.to_s
 else
   UI.messagebox "vector1 Failure"
 end

#cline1 = Sketchup.active_model.active_entities\
#.add_cline(line1.start.position, vector1);
# if (cline1)
#   UI.messagebox "cline1 = " + cline1.to_s
#   line1.erase!
# else
#   UI.messagebox "cline1 Failure"
# end

  end;

  def draw(view);
    @ip.draw view;
  end;

end;

Sketchup.active_model.select_tool\
(Clf_august_lines.new)

And here's the version that creates a line, then uses that line's endpoints to create a vector, which works in both versions, and then creates a cline from one endpoint of the line and the vector. It is this cline which initiates the problem.

I call this one rayLC.txt because it attempts to create a line and then a cline:


class Clf_august_lines;

  def onMouseMove(flags, x, y, view);
    @ip = view.inputpoint(x,y);
    view.invalidate;
  end;

  def onLButtonUp(flags, x, y, view);

line1 = Sketchup.active_model.active_entities\
.add_line(view.camera.eye, @ip.position);
 if (line1)
   UI.messagebox "line1 SUCCESS\n
view.camera.eye = " + view.camera.eye.to_s + "\n
@ip.position = " + @ip.position.to_s
 else
   UI.messagebox "line1 Failure!\n
view.camera.eye = " + view.camera.eye.to_s + "\n
@ip.position = " + @ip.position.to_s
 end

vector1 = line1.start.position\
.vector_to(line1.end.position);
 if (vector1)
   UI.messagebox "vector 1 = " + vector1.to_s
 else
   UI.messagebox "vector1 Failure"
 end

cline1 = Sketchup.active_model.active_entities\
.add_cline(line1.start.position, vector1);
 if (cline1)
   UI.messagebox "cline1 = " + cline1.to_s
#   line1.erase!
 else
   UI.messagebox "cline1 Failure"
 end

  end;

  def draw(view);
    @ip.draw view;
  end;

end;

Sketchup.active_model.select_tool\
(Clf_august_lines.new)

If I open a new SU drawing and load 'rayL.txt', it will draw lines whereever I click. But unless there is an object for them to reference, they stop at the bounding planes of the near quadrant.

If I then either load 'rayLC.txt' or open a new SU file and load it, I can draw clines that reference existing objects, e.g., Sang, and there is no problem.

But when I attempt to draw a cline that does not reference an existing object, I can create just that one, single cline and then all subsequent attmpts to create clines will fail because @ip.position is stuck at the camera.eye position or line1.start.position.

Even if I load rayL.txt again to create just lines, they fail, referencing Sang, the origin, or whatever. After one cline, @ip.position is stuck on camera.eye.

I have tried TIG's suggestion of inserting @ip = nil but everywhere I have tried it produces error messages.

This doesn't seem like it should be this hard.

I have been poring over the SketchUp Ruby doc about view and inputpoint etc. and unfortunatley it all seems written for those who already get it. It also says things like the inputpoint should "normally" be obtained using [ruby:11qtfq9b]pick[/ruby:11qtfq9b], but I've followed those examples and not even gotten a working start. At least this one based on Chris Fullmer's version works sometimes.

It appears to be one of three things:

It really is this hard.
I'm overlooking something very basic.
There is a bug in creating clines from a point and a vector.

Can someone help me figure out which it is, and/or possibly suggest a workaround?

Thanks,
August

Chris Fullmer · 13 May 2010, 04:57

There is something wrong going on here and I'm not sure if its something in the script or an SU bug. But after the cline is created, focus is not given back to the mouse correctly. You will notice that it is no longer drawing the inference dots after the first line is drawn correctly. That shows me that somehow the on_Mouse_move is not being called after the mouse button is clicked. But once you orbit, then it all gets reset.

I'm looking it over right now, but so far I am not seeing any obvious error.

Chris

PS somehow I never got intot he habit of using contrsution geometry. I always just use regular lines to act as guides

Chris Fullmer · 13 May 2010, 05:14

Well, I don't know why that is broken and I got tired of looking at it so I took a new approach. I just used the pickray method to make the point and vector. It is much simpler and seems to be working great. So try this little code.

class Clf_august_lines

	def onMouseMove(flags, x, y, view)
		@ip = view.inputpoint(x,y)
		view.invalidate
	end

	def onLButtonUp(flags, x, y, view)
		Sketchup.active_model.active_entities.add_cpoint(view.camera.eye)
		ray = Sketchup.active_model.active_view.pickray(x,y)
		Sketchup.active_model.active_entities.add_cline(ray.to_a[0], ray.to_a[1])
	end

	def draw(view)
		@ip.draw view
	end

end

Sketchup.active_model.select_tool(Clf_august_lines.new)

Oh and I erased out all the semi-colons. They look messy to me. I only put them in the original code so I could condense it all to one line to run from the console. But since you are not doing it that way, I didn't feel there was a need to keep them around. Feel free to put them back if you miss them though

Chris

August · 13 May 2010, 23:08

@chris fullmer said:

There is something wrong going on here and I'm not sure if its something in the script or an SU bug. ...

Thanks for that confirmation.

It's worse than you had so-far discovered.

After the tool fails, if you activate the Select tool, it will not select. If you activate the Line tool, it will not draw. After a bunch of tool changes and attempts, I got function back, I presume because one tool or another did a better job of resetting things.

It's a bug.

I will try your new approach.

I had tried my own "new approach" by taking linetool.rb and hacking out the two-point construction to get just one point. I also didn't try calculating a vector, I just drew the cline between view.camera.eye and @ip1 and gave it a name, newRay, then set newRay.end = nil.

But the core construction method of my new version is still the same and it has the same problem as the old version. I'm convinced it's a bug.

Thanks again,
August

August · 13 May 2010, 23:34

@chris fullmer said:

... I got tired of looking at it so I took a new approach. ...

Thanks. I tried it; it works great. No bugs.

However, like the earlier versions, it creates an infinite cline in both directions, not a true ray that starts at a point and goes infinitely in one direction. That's not a problem, just a curiosity. (If it's not "supposed" to be that way, it may be related to the bug -- just guessing.)

Do you know why the cpoint at view.camera.eye is necessary? You don't appear to use the point. Is it a requirement for pickray to work? (Maybe the omission of a cpoint there is the source of the bug? More guessing.)

Thanks again.

Chris Fullmer · 13 May 2010, 23:56

The cpoint is not needed for the code. I just like to put it there so I can see exactly where the camera was.

As for the bug, I know that 7.1 added some sort of infinite line viewing bug. I thought it had been fixed, but maybe not? Or maybe we've uncovered another iteration of their bug. I noticed that clines are not clipping like they should. They do not appear to clip at the near clipping plane. i'm not sure if it has always worked that way. I really hate construction geometry, so I haven't used it enough to know how it used to behave compared to how it currently behaves.

But the part where you said that it still produces an infinite line instead of a ray, I think that is a known bug. I'll see if I can track down the info on that bug if you'd like.

Chris

August · 14 May 2010, 01:03

@chris fullmer said:

... But the part where you said that it still produces an infinite line instead of a ray, I think that is a known bug. I'll see if I can track down the info on that bug if you'd like.

Thanks, but no need. It doesn't interfere with anything that I'm trying to do. I'm just curious.

You have already been most helpful, and you've helped me get my feet wet in SketchUp Ruby again (after they'd dried out for nearly a year).

And now that I've started wrestling with this, I've begun to appreciate your dislike/aversion for construction geometry. Modifying something that already exists is clearly much easier.

Thanks again,
August

August · 14 May 2010, 04:00

@august said:

[... if you activate the Select tool, it will not select. If you activate the Line tool, it will not draw. ...

This bug is still there. Just to make it stranger, it seems to go away if you orbit, but if you return to the exact viewpoint, using either Previous View or a Scene, it appears to be stuck again.

For example, with the Rectangle Tool active, the first InputPoint appears to be stuck at the Camera Eye. The second InputPoint will not go just anywhere, it appears to have to inference an object, just like when drawing a CLine. If you orbit away with Rectangle active, you can see that the first point is already set. If you press Escape, you can draw a normal rectangle, but if you return to the exact Eye view, that point is pre-picked again.

Similarly for the Line tool. The first point is already picked and the only allowable lines are the ones that terminate on a pre-existing point.

Clearly a bug.

Chris Fullmer · 14 May 2010, 19:10

August, are you saying the that the bug is still present in the most recent snippet I posted?

Chris

August · 14 May 2010, 20:59

@chris fullmer said:

August, are you saying the that the bug is still present in the most recent snippet I posted?

Yes, the above image was generated using your newest snippet, unchanged.

I load your snippet, saved as a separate .txt file, make a few clicks that generate the desired clines, and then when I select the rectangle tool, as described above, the first rectangle inputpoint seems locked to camera.eye and the second point will, in this drawing, only reference one of Sang's points.

I can orbit, draw a normal rectangle, and when I return to the original view, using Previous View or my Scene, the first inputpoint is locked at camera.eye again and the second inputpoint will not reference anything except Sang.

I am getting the lines I want, and I can work around that input point locking, but I do think this is a bug in SketchUp, probably in .add_cline, maybe in view.

Chris Fullmer · 14 May 2010, 21:31

I am starting to think it has to do with the way I am making an inputpoint with view.inputpoint(x,y ). I think I might need to look that over a little closer. I think I am messing something up with the IP associated to that view. I don't really undestand how IP points work behind the scenes, but I have a feeling the way I am calling it is messing things up. Might be a bug, or could just be un-intended usage of an input point. This is something I would like to understand better, so I'll try to figure it out this weekend (I have been excited about a few ruby projects lately, so I am spending some time on ruby again, it is fun!)

Chris

August · 15 May 2010, 05:34

@chris fullmer said:

... I think I might need to look that over a little closer. I think I am messing something up with the IP associated to that view. ...

If you are, then I have to presume that it is simply exposing the bug.

The fact that I can draw a normal rectangle after I have orbited to a new camera.eye position, but when I return to the previous camera.eye the bug returns, to my mind that cannot be your fault.

At the very least, that is a serious side effect that is not documented. I have pored over the doc for InputPoint, camera, and view, and I have found lots of typos and incomplete examples (my hunch is most of it was generated by @Last and has never been reviewed or edited since) but I have not seen anything that implies a locked InputPoint or that such a lock or any other status is restored when the camera.eye returns to a previous position.

Maybe somebody is trying some "optimization" to restore view parameters when using Previous View or Scenes and is accidentally restoring too much. That's a wild guess. I suppose that could be tested by seeing if there were some minimum number of other views to go to that would make the bug go away when you returned to the original view, maybe if you ensured that you didn't return using a Scene (which would be a logical state to restore to) but used manually saved and input camera parameters instead.

That's too much work for me to chase a bug, unless I had a hope that the effort would result in the bug getting fixed, but right now I don't have a minimal code fragment that shows the bug, and I'm not going to try to find one. If you do, let me know and I might be inspired to put some energy into writing up a bug report to Google.

@unknownuser said:

(I have been excited about a few ruby projects lately, so I am spending some time on ruby again, it is fun!)

Except when you spend hours and hours wrestling with a bug while presuming it's you not the implementation or the documentation.

OTOH, when it works, it's very satisfying, and there's something about getting an aesthetic, visual result that touches something primal.

Again, thanks for the help.
August

thomthom · 15 May 2010, 07:21

@august said:

At the very least, that is a serious side effect that is not documented. I have pored over the doc for InputPoint, camera, and view, and I have found lots of typos and incomplete examples (my hunch is most of it was generated by @Last and has never been reviewed or edited since) but I have not seen anything that implies a locked InputPoint or that such a lock or any other status is restored when the camera.eye returns to a previous position.

Yes... there are a few typos mentioned in this thread: http://forums.sketchucation.com/viewtopic.php?f=180&t=17047 But they have been review since @Last was taken over by Google. The state of the API docs are much better now then what they where. But there is still lots of room for improvements.

Now you can add your comments yourself to the API pages if you log in.

August · 15 May 2010, 08:34

@thomthom said:

... Now you can add your comments yourself to the API pages if you log in.

Cool!

I'll look for the link the next time I see something.

@august said:

... (my hunch is most of it was generated by @Last and has never been reviewed or edited since) ...

Sorry for the sarcasm.

August · 15 May 2010, 08:37

@august said:

Sorry for the sarcasm.

I should have remembered a rule from one of my college professors, Gregory Bateson, "Never an untrue word spoken in jest." Can still allow sarcasm, just not hyperbole.