Posts made by avariant

Unfortunately, it doesn't work the same way.
In linetool, it is creating an inputpoint on mouse click, then when the user enters a length in the VCB, the tool creates the line and that iteration of operation is done, no inference lock necessary. It works in linetool because it only needs 2 points. I need 3 points.

what I need is like this:

1. Mouse click -> Create InputPoint1
2. Mouse moves -> Update InputPoint2
3. User types into VCB
4. Point created by taking the vector from IP1 to IP2, length from VCB
   - up to now, no problem, just like linetool -
5. Mouse moves -> Update InputPoint3

And here is the problem. I have IP3, but IP2 either doesn't exist or is at the least not in the right place because the user never clicked the mouse in steps 3 & 4, they entered text in the VCB. So I don't have and input point at the real location for Point 2.

Maybe you are suggesting I grab IP2 at the point the user enters text into the VCB. But that would put IP2 at, quite likely, the wrong location, since length along the vector is from the VCB.

I have a tool that requires 3 points. After the first point, the user can use the VCB to enter a length to get the second point, then the third. The problem is, I want to allow inference lock. But view.lock_inference only accepts an InputPoint. However, InputPoint's new method doesn't accept parameters. I can get the points I need using Point3d, but have no way to produce the InputPoint needed for inference lock.

Any ideas? Thanks!

I think some of the built in tools, like the line tool, return a more specific name. But a lot of them are generic. I suspect that Ruby Tool is a default name that tools can override but seldom do (though I do see any method for that in the API).

I have a question about aspect ratio.
I know that when you set the aspect_ratio to something other than 0, it letterboxes the view. That's a great feature. My question though is, why does SU change the view? It zooms in if the ratio is >1, out if ratio is <1 and doesn't zoom if =1.

I get that it is probably trying to fit the Field of View into the now-letterbox-reduced rectangle, and that explains some of the sizing. But when I set an aspect ratio that exactly matches what my view is already, it still zooms! And when AR=1, that definitely doesn't match the previous Field of view, yet there is no zooming.

Anyone know what's going on? Is this bug city?

I guess my blanket comments about the MaterialObserver were not entirely accurate I was under the impression that unless some of the methods weren't explicitly implemented in the observer, SU would crash when it attempted to call the method since it's not implemented on the base. However, I seem to be wrong.
The documentation on onMaterialChange is a little inadequate. It says it is called whenever a material is altered, but it doesn't get called when you change size or color, just texture.

I'm pretty certain the material observer is completely wrong. The base class defines all but two methods incorrectly, and doesn't appear to use them all that correctly either.

I've seen a ruby gem called ruby_debug, but I don't know anything about gems, or if such a thing is compatible with SU. It seems to imply it's like a command-line debugger.

Hm... I'm curious, does edge order control the face winding, which side is the "back side" or the "front side"? I assumed so, but maybe SU just makes some assumptions based on the overall geometry...

It looks like that's what's going on to me.

My mistake. Gouraud is the default shading for OpenGL, not Phong.

SU lists it's entities as a kind of tree, as you've seen. The list of entities can contain groups, which in turn have there own entity lists, etc. If you want a "flat" list, I think you have to do it yourself by crawling the tree and copying the entities into another list. However this can be pretty time consuming if you have a big scene.

I don't know the right answer, but I suspect it's whatever OpenGL uses as a default lighting. I think that it is "Phong" lighting. I know there are lots of equations out there for Phong. Sorry if that's no help.

Implementing a tool is as simple as creating a class an implementing the methods.

Look at the linetool.rb in examples

class LineTool
def initialize
...
end
def activate
...
end

etc...
def onLButtonDown(flags, x, y, view)
...
end
...
end

As for why the observer method is returning odd values... no idea, I'll have to try it.

EDIT: I implemented a test observer and it works fine.

class MyTestObserver < Sketchup;;ToolsObserver
	def onActiveToolChanged(tools, name, toolid)
		puts tools.to_s + " " + name.to_s + " " + toolid.to_s
	end
	
	def onToolStateChanged(tools, name, toolid, xxx)
		puts tools.to_s + " " + name.to_s + " " + toolid.to_s + " " + xxx.to_s
	end
end

It ouput "#Sketchup::Tools:0x5c1b690 CircleTool 21096" to the ruby console.
You'll notice there is a fourth parameter for onToolStateChanged. The API is wrong; it doesn't list that parameter but without it there will be an error.

Ok. thanks!

I think I know the answer, and the answer is no, but I figured I'd check.
Can you nest start_operation, commit_operation calls? For example:

model.start_operation "Operation A"
#do something
model.start_operation "Operation B"
#do some more stuff
model.commit_operation  #ending operation B
#do some final stuff
model.commit_operation  #ending operation A

I figure the answer is that it at least won't work the way I want. What I would expect is that the outermost start / commit (Operation A), would be the only one exposed in the Undo / Redo because it contains Operation B within it. But what I think I see is that both A and B show up in the menu. This seems bad, because it implies that some operations from A are either being attributed to B, or being handled outside all the operations entirely. Anyway, does anyone know a more official explanation? The API, as usual, says very little on the subject.

Thanks very much for your replies. I think, knowing that SU doesn't provide any inherent method for this kind of inference, that I can see how it might be done. I'll tinker around a bit; even if I never use it, it will be good to familiarize myself with this area of the Ruby API. Thanks again.

BTW, I mentioned earlier that passing two points to lock_inference does nothing different for me than one point. Any thoughts on that, as to what two points should do?

The behavior seen from the "Line on Surface" tool, when you hit an arrow key, is exactly what I'm looking for. I'm not trying to draw lines, it's actually a "positioning" tool of sorts, but that behavior is very much what I'm looking for. Can you make suggestions on how to do it?

[EDIT] glancing through the Surface Tools code, I can see that there is some very significant trigonometry / vector math going on to implement that axis constraint. I had high hopes that this was something built into SU's inference, but apparently not.

Sure.
From the line tool, if you hit the up arrow, you get a constraint along the vertical axis, running through whatever point you were on at the time you hit the up arrow.

But this doesn't appear to be a standard behavior for the lock_inference command. The best I can do is lock to an edge, if I happen to pass it a point on an edge, or in the plane of a face, if the point I pass is on a face. I'd like to imitate the behavior of the line tool, where I constrain along an axis no matter what point I have.

Isn't it the plane equation: Ax + By + Cz + D = 0 ?
A,B,C is the normal, D is an offset (though I don't think you can say it's the "elevation"; it's more like if you placed the normal vector at the origin, it's the distance along that vector until you intersect the plane. It can be elevation, but could just as easily be along any arbitrary axis).

Not that I know of. You have to recurse through every group, component, etc (which can be a bit time consuming). A suggestion is that you create a table where you store the entity and your own key (just an incremental index probably), then you pass that key back and forth. I don't know how you plan on using it but if it's just a way to retrieve an entity it may work for you. As long as you keep an active instance of the entity, like in a table, I'm pretty sure ruby won't trash it out from under you and you can use that key to retrieve it at any time.