Model.raytest broken in SU8!

TIG

The native raytest returns either 'nil', or a array containing the hit-point and another array [listed in reverse order] of the [visible?] entity it hit [face/edge], and where applicable with nested entities its container, then its container, then its container and so on.
The 'include?()' test simply inspects this short list for a match with a specified object - could be a face/edge/group/instance etc.
Any raytest must look for objects in the ray's path, the native one will stop when one hit is encountered or it returns nil.
I would expect [hope] that it will not check every entity in the model for an intersection - to start with only those objects to the 'positive' side of the point/vector direction might be candidates so the rest could be ignored, hidden/off-layer objects can be ignored, as can bounds tests etc...
How will your tool 'know' which objects might be intersected differently ?
There has to be some iteration through potential candidate-objects...
If you want to test a known face and a ray [point,vector] then classify_point will be quicker because there's only one thing to look at - is the point on the face? - but this isn't a raytest in the sense of finding what it hit, rather does this point project onto the face...

Anton_S

TIG, before I go on complain, do you agree with the current raytest task below?
If not ,then simply state how it works, if you know

Current Raytest Tasks

Search throught all the entities
Change its point and vector relative to group's/component's transformation each time it enters the group/component (each group has its own coordinate system)
Check's whether it intersects the face, or the edge
convert intersection position to current transformation of the origin
return the closest point and the object, with its container path

thomthom

Anton, the C++ SDK is for reading and writing SKP files. Not for communicating with an open SketchUp instance like the Ruby API.

Anton_S

@thomthom said:

Anton, the C++ SDK is for reading and writing SKP files. Not for communicating with an open SketchUp instance like the Ruby API.

O , okay then , I guess.

thomthom

You can always create Ruby C Extensions - but you'd have to use the Ruby API interface to communicate with SketchUp.

Anton_S

@thomthom said:

You can always create Ruby C Extensions - but you'd have to use the Ruby API interface to communicate with SketchUp.

something new, any examples???

Dan Rathbun

@anton_s said:

@thomthom said:

You can always create Ruby C Extensions - but you'd have to use the Ruby API interface to communicate with SketchUp.

something new, any examples???

Monitor***** these TWO topics:
[Info] C/C++ Ruby extensions & SketchUp plugins

[Tutorial] SketchUp Ruby C Extension

When in a topic thread (that you wish to Bookmark or Subscribe to ... scroll to the bottom of the topic page, and use the "Subscribe topic" or "Bookmark topic" links on the bottom toolbar.
You can manage your topic Subscriptions to certain topics via the Forum: "User Control Panel" > "Overview" > "Manage subscriptions" (and Bookmarks via: "User Control Panel" > "Overview" > "Manage bookmarks".)

Anton_S

... many thanks, just what I wanted

Bookmarking these links is also what I prefer to do, otherwise I don't know.

For replies, suggestions and pointing out very, very important stuff, I would sugggest a,

Thanks, just Thanks!!!

thomthom

But I still don't think you'll get much joy in Ruby C Extensions to create your own raytracer. Simply because you can't get around the fact you need to obtain geometry data from SketchUp that would have to go via the Ruby API - and that process alone would probably be too slow for making any custom raytracer faster than SU's native.

Anton_S

@thomthom said:

But I still don't think you'll get much joy in Ruby C Extensions to create your own raytracer. Simply because you can't get around the fact you need to obtain geometry data from SketchUp that would have to go via the Ruby API - and that process alone would probably be too slow for making any custom raytracer faster than SU's native.

Thanks, I also got that... I'll just use the native raytest, SU gives a lot of power to its processing.

Learning C++ by interacting with interesting Sketchup is a much better, than learning it with simple "hello world" tutorials.

thomthom

@anton_s said:

Learning C++ by interacting with interesting Sketchup is a much better, than learning it with simple "hello world" tutorials.

Aye! I'm just nowt getting to grips with C. Looked at it before, but never got into it. Working with concrete tasks for my Ruby C Extensions gave me the push I needed to battle these scary pointers and memory management. Latest Ruby method I ported to C, gave me a 300 times performance increase.

Though, not all things are suited. If you need to keep on referring back to SketchUp and the Ruby API interface you quickly loose performance. In my case I was doing lots of calculations on 3D points - which I then first cached into C structs before starting the number-crunching.

Anton_S

@thomthom said:

Aye! I'm just nowt getting to grips with C. Looked at it before, but never got into it.

Well, of course Thom, same thing here. A bit ago started learning it here, but ran out of batteries at chapter 4.

It's not because I'm lazy, its all that there is a language that is much easier, simpler, similar power, really reliable, plus FUN!!! It's Ruby, a Gem ...The programers' task is to develop a better way of interacting with things. Since, Ruby was developed, an easier way of programing, we decided to move to easier step. Moving back to C++, is like experiencing Microsoft Word 2010, and then getting back to 2002 version.

Dan Rathbun

@anton_s said:

A bit ago started learning it here ( learncpp.com ), ....

Here nice tutorial there !! I had to bookmark that site.

I read a few chapters.. and then jumped around looking up things I always wanted to know. I may actually try C++ sooner rather than later.

thomthom

hmm - would be nice with a C++ Hello world of a Ruby Extension.