Hi Todd,

@unknownuser said:

Get your requests in now, during the early design stages.

I've done lots and lots of API doc, sometimes writing SED scripts to extract info from header files etc., but I'm not really at the SOTA when it comes to RDoc, JavaDoc, Doxygen, etc.

I'd like to help in this project, if I can, but it looks from the discussion like I'm way down on the curve compared to other folks.

Could you put together an outline of what it might take to catch up?

One thing I'm going to throw out here that might make a difference if it's still early stages.

I've been seeing over and over in other doc projects that the idea of going from the code comments to a Wiki seems to be catching on. From a Wiki, you have immediate collaboration on updating the doc and there are lots of ways of going from Wiki to PDF and/or print.

And if it's just about any Wiki besides SharePoint, you have some kind of standard markup format for the Wiki text that can be a very simple rework of the code comments format. Then the Wiki manages the cross-references and the formatting and display and you don't have to reinvent all of that in your HTML output from the code comments.

The piece I've been looking for and have not been seeing anywhere is going backwards from the collaborative Wiki edits to merge those changes back into the source so that the "master" does live in the code and can be updated when the code is changed.

Any interest in pursuing that idea? Building systems that do the code>Wiki>PDF and Wiki>Code round trip is something I've been brainstorming about doing professionally, so getting into that with this project might just add to my portfolio.

Let me know what you think,
August

Hi Coen,

@philem said:

@august said:

@edson said:

btw, what app do you use to make your tuts?

Yes, please, a tutorial on how to make that tutorial would be nice!

Yes please, A tutorial on how to make the tutorials and how to upload them to this forum would be great..

Did this ever get covered anywhere else? To have it interactive right there in the forum post is really sweet. Pointers, tips, tricks, etc. would all be appreciated.

Thanks,
August

@unknownuser said:

p[0] and p.x are always x
p[1] and p.y are always y
p[2] and p.z are always z ...

Thanks Todd,

That confirms the way I read the code, so I'm not going to worry about there being any subtle tricks embedded in using px and p.y in the same tuple. The py variable is defined and never used. Gee.

[If I were editing this for publication, I'd probably suggest leaving out the definitions of px and py as only saving a single character later in the p.x and p.y constructions while the definitions take up two full lines of example space. If I were debugging it for speed and px and py were being used thousands of times, I'd probably go with the variable rather than thousands of p.x and p.y method lookups. Case in point on the difference between an Engineering and an API Doc mindset.]

HOWEVER, the question remains, is the x,y,z of a Point3D based in screen coordinates or model coordinates? It sure looks from Didier's usage that it's screen-based, but you would think (and you could be wrong) that it would be mentioned in the Point3D doc.

For now, I will assume that a Point3D refers to screen-space, since that's the way Didier uses it and I trust that the script works and I have other evidence of the doc being incomplete on rather basic issues. Since screen-space is the dominant coordinate system for the problem I posed in starting this thread, that's really useful.

Thanks to all,
August

@chris fullmer said:

http://groups.google.com/group/SketchUp-Plugins-Dev/web/Ruby-View.html#pickray

The sample code for pickray uses vertex.position[0] and vertex.position[1] as the x, y screen position of the vertex.

But the doc for the position method for a vertex says that it returns a Point3D object. The doc for the Point3D class says "The Point3d class allows you to work with a point in 3d space. The point is basically just a series of values representing x, y and z coordinates. The values are specified as [x,y,z]. For example [100,200,300]."

So the only way that makes sense to me, for the doc to actually be completely accurate, is for the x and y of a Point3D object to be the x and y of the current view, rather than being SU's red and green axes. But if that is the case, why doesn't the Point3D doc SAY that? But if the x,y,z of a Point3D is not the view, with z being distance from the camera plane, then what part of the doc is wrong?

Am I interpreting it wrong, or is the doc just skipping over a very basic concept that is essential to understanding the object being described?

Anybody?

Thanks,
August

@chris fullmer said:

... So it looks like thy are interchangeable since he's defined the x and y into px and py. px = p.y and py = p.y I think. ...

Thanks Chris,

That's the way I read it, but being a Newbie, my first impulse is to blame my lack of understanding rather than to assume that a master like Didier used an accurate but inconsistent syntax nine times in a row. (Obviously cut and pasted, but it's still there nine times).

My debugging my own code depends a lot on being very anal about spaces and forms and indents and punctuation, adding lots of extra spaces to make as much as possible line up to show the parallel structures etc. so the errors will stand out. Obviously Didier does not need the same kinds of crutches because he just reads what it means.

Thanks for the reassurance that I did read it right in the first place.

Unless there is a trick here that we're both missing.

August

P.S. And thanks for the link to a pickray reference.

Hi folks,

I'm trying to understand "pickray" from Didier's use of it, since I cannot find it documented.

Didier's script uses raytest and pickray like this:

    p = view.screen_coords(v.position) 
    px=p[0] 
    py=p[1] 
    #test each pixel around each vertex 
    ### 
    # # 
    ### 
    #test the vertex itself first 
    ray = view.pickray [px,p.y] 
    rt = m.raytest([ray[0], ray[1]]) 
    return true if rt and rt[1][0] == self 
    ray = view.pickray [px-1,p.y+1] 
    rt = m.raytest([ray[0], ray[1]]) 
    return true if rt and rt[1][0] == self 
    ... 

From that, it looks like view.pickray might be exacly what I am
looking for, but I can't find it defined or documented anywhere.

Also, as Ruby Newbie, I am confused at the asymmetry of the arguments
to pickray.

Didier defines px=p[0] and py=p[1] yet for pickray he supplies
[px,p.y] and increments and decrements both of them similarly to test
all the adjacent pixels, but he maintains that distinction between px
and p.y notationally.

Are these as truly synonymous as they appear, or is there a reason
for doing one value one way and the other value another way?

Thanks,
August

@didier bur said:

... Look at the "raycast" method which is quite simple to use.

@august said:

I finally found that plugin attached at http://www.sketchucation.com/forums/scf/viewtopic.php?f=153&t=5333.

Hi Didier,

It seems I found the wrong "view-based face reverser". I succeeded in getting the script unpacked and printed to the Ruby Console by changing "eval" to "print" and running "load "vbfr.rb"" on the console. I then copy/pasted it into a text file.

Unfortunately, I could find no "raycast" method in that script. I found "pickray" and "raytest" used, but no definition for either. I found "raytest" in the Google SketchUp Ruby API Method Index, but no "pickray".

Could you please point me to where that "raycast" method might be found?

Or is "raycast" a misremembering of the name "raytest"? If so, what/where is "pickray"?

Thanks,
August

@didier bur said:

... Look at the "raycast" method which is quite simple to use.

@august said:

I finally found that plugin attached at http://www.sketchucation.com/forums/scf/viewtopic.php?f=153&t=5333.

The attached file there includes a very nice PDF describing the operation. From the PDF, I would think that the script used a method that I might indeed adapt. Unfortunately, in the vbfr.rb file, the Ruby Script itself is encoded.

Can you suggest where I might find an un-encoded version or advise me on how to decode that one?

Thanks,
August

@didier bur said:

I did something similar for my view-based face reverser. ...

Thanks for the tip, Didier,

I finally found that plugin attached at http://www.sketchucation.com/forums/scf/viewtopic.php?f=153&t=5333.

Searching the Depot for "view reverse" does not turn it up. However, on the Depot, page 1 of the search results says there are 27 results and page 2 says there are 19, back and forth, consistently. Weird.

August

@tomot said:

... Perhaps the fountain pen solution should have been adapted for the printer.

An elegant idea. The Fisher company spent millions of dollars to develop a pen that would write in zero gravity for NASA. It got a closeup in Kubrick's "2001". The Russians used pencils.

August

I'll vote for real. I think the tiny suckers on the tentacles give it away. It's a squid embryo.

August

Hi folks,

I originally posted this in the SketchUp Discussions, but at Gaieus' suggestion, I'm copying it over here in the Ruby thread-group.

I've been thinking about a problem for a while -- if I had a generic solution there are several placed I could apply it.

The issue is using PhotoMatch with photos that just do not have enough straight lines or maybe no lines that can be counted on to be vertical or level. Like making a SketchUp model of the Mystery House at Knott's Berry Farm, or The Santa Cruz Mystery Spot -- or worse, trying to form terrain from photographs.

I assume it would require there to be lots and lots of common points in the photographs that you can match up. But just points, probably not many lines, horizontal or not. Very much the kind of thing that the standard PhotoMatch perspective tools are really bad at.

What I keep coming back to is being able to pick the same point in two or 3 photos and construct lines through the photo image to the camera. The actual 3D point has to lie on that ray from the camera center through the point in the PhotoMatch image, out to infinity. Two or three photos let you find the intersection of the rays.

To play with how the geometry of this works out, to start getting a handle on what the rules of this game have to be, it would be nice to be able to place a PhotoMatch image into a model as a photo texture on a surface, oriented perpendicular to the line to camera for that PM scene. And then, from the viewpoint of that scene, pick a point in the image and run a ruby script that would construct the ray from the camera through that image point.

So has anyone created a script like that, to generate a ray from the camera through a point chosen on a surface or simply through the cursor position?

If no one has done it yet, I'd be willing to hack at it, if someone could toss out hints of what objects and methods would have to be used.

Thanks for any suggestions,
August

@gaieus said:

... But why on (Google) Earth are you posting this in the SU Discussions instead of the Ruby forum?

Oops. I think I must have mistaken which thread-group I was in.

At your suggestion, and with the indulgence of the rest of the group, I'll repost my question over there (since this was the only response I've gotten in the general area).

August

Hi folks,

I've been thinking about a problem for a while -- if I had a generic solution there are several placed I could apply it.

The issue is using PhotoMatch with photos that just do not have enough straight lines or maybe no lines that can be counted on to be vertical or level. Like making a SketchUp model of the Mystery House at Knott's Berry Farm, or The Santa Cruz Mystery Spot -- or worse, trying to form terrain from photographs.

I assume it would require there to be lots and lots of common points in the photographs that you can match up. But just points, probably not many lines, horizontal or not. Very much the kind of thing that the standard PhotoMatch perspective tools are really bad at.

What I keep coming back to is being able to pick the same point in two or 3 photos and construct lines through the photo image to the camera. The actual 3D point has to line on that ray from the camera center through the point in the PM image, out to infinity. Two or three photos let you find the intersection of the rays.

To play with how the geometry of this works out, to start getting a handle on what the rules of this game have to be, it would be nice to be able to place a PhotoMatch image into a model as a photo texture on a surface, oriented perpendicular to the line to camera for that PM scene. And then, from the viewpoint of that scene, pick a point in the image and run a ruby script that would construct the ray from the camera through that image point.

So has anyone created a script like that, to generate a ray from the camera through a point chosen on a surface or simply through the cursor position?

If no one has done it yet, I'd be willing to hack at it, if someone could toss out hints of what objects and methods would have to be used.

Thanks for any suggestions,
August

@frederik said:

Wonder why they've chosen to release it on a Saturday...?!?

Hi Frederik,

I suspect they are installing bits from the bottom up. You can buy a license but it's not there on the main Download page yet. Quite possibly there will more updates to more pages, hour by hour, through the weekend. Once it's all in place, the official Press Release goes out, etc. After all, you can't go announcing it before folks can buy it ... Excuse me ... Vaporware? ... OK, I suppose you can announce it prematurely, but you shouldn't.

August

@edson said:

btw, what app do you use to make your tuts?

Yes, please, a tutorial on how to make that tutorial would be nice!

August

I like this one. It has the look and feel of a SU construction without emphasizing the tools.

Regardless of its user interface, Blender is extremely
useful as a file converter.

In particular, Blender will import Collada/DAE files
and export more "standard" things.

And you can get a Collada/DAE from the free version of
SketchUp.

It turns out that the KMZ file you get as a Google Earth 4
export from the free version of Google SketchUP is actually
a ZIP file. Change the file extension and unZIP it and in
the "models" folder is a DAE file, the Collada format file.

In Blender you can import that DAE file as a Collada 4
format file. The import script requires that you have
Python 2.5 installed (also free).

Blender will then export your model into 3DS format
and many others.

I hope this helps,
August