Model.raytest broken in SU8!

TIG

No, because it's part of a larger code set...

Since writing I have found a 'cause'...

Because the tool is doing solid intersections etc to avoid small facet errors on smaller objects and 'non-solidity' in results the objects are scaled up 100, then processed and then scaled down 1/100.
All other objects are auto-hidden/restored too.
When the raytesting is done the object is already scaled up, so the tested point is 'scaled' so it's then inside a hidden neighboring object. Having that object hidden does prevent most of the false positives BUT occasionally one or two incorrect results occur - it's hard to reproduce.

To avoid this I am now recoding so that the scaling up occurs after the instances are added but before the solid intersections etc - I hope this will avoid the issue - watch this space...

Anton_S

Okay, so Thomthom says its fixed and TIG has some conserns ...well, I never had any issues with raytest, though, I guess I'll note, if discover any.

Anyways, the bellow question is a bit off topic, but to make sure:

Lets, say I write Two of my own simplified raytest functions (similar to
Raytest 2). One on C++ (raytest2cpp), compile it to .dll, and extern it into some of my Ruby module using dl. The other, on Ruby (raytest2rb). On SU, which of these will work faster, why, and approximately by how much percent faster?

TIG

To recap...
In v8M2 model.raytest([point, vector], true) will work [relatively faultlessly].
BUT if you have scaled objects then raytesting can be flaky and sometimes returns nil in areas where it should return a hit, IF the ray passes through space occupied by a hidden object [which of course it should ignore!] - moral = do not scale an object and raytest within it...
I'm removed the scaling from the raytest code loop and it now works faultlessly, so far...

Didier Bur

Hi,
A little bit off topic but I'm using raytest to check if a ComponentInstance is on a face or not. I shoot a ray downwards through the boundingbox bottom corners, and if these are in the same plane than the face, raytest returns nil. Weird.

Dan Rathbun

ComponentInstance.glued_to() should return a Sketchup::Face object if it's "on" a face, nil if not.

thomthom

@anton_s said:

Lets, say I write Two of my own simplified raytest functions (similar to
Raytest 2). One on C++ (raytest2cpp), compile it to .dll, and extern it into some of my Ruby module using dl. The other, on Ruby (raytest2rb). On SU, which of these will work faster, why, and approximately by how much percent faster?

In order to do your own raytesting C++ function you'd have to pass the function all the 3D geometry in the model, and I assume that will eat up any performance gain you'd get from the actual custom raytracing.

Anton_S

@thomthom said:

In order to do your own raytesting C++ function you'd have to pass the function all the 3D geometry in the model, and I assume that will eat up any performance gain you'd get from the actual custom raytracing.

Well, I don't actually plan to raytest throught the all entities, but just throught the one the user chosen: model.entities[3].raytest2, and to make it faster I would just have it get the certain entity's faces, only once the user calls the other method, like entities[3].getfaces, and the getfaces function will store all the groups' faces in the certain hash: {entities[3] => [faces]}

To write my dll, I plan to use Microsoft Visual Studio C++ Express. I just don't yet know how to use the ruby SDK reader and writer, plus my C++ programming skills almost equal to nil. I had the post above to make sure that I don't keep learning C++ for no reason.

TIG

@didier bur said:

Hi,
A little bit off topic but I'm using raytest to check if a ComponentInstance is on a face or not. I shoot a ray downwards through the boundingbox bottom corners, and if these are in the same plane than the face, raytest returns nil. Weird.
Rather than raytest why not use face.classify_point(point) to see if the tested point is 'on' the face, or face.plane etc

TIG

Anton_S
You can already test for a raytest 'hitting' a certain 'object' using the API version, thus...

<span class="syntaxdefault">def raytesterizer</span><span class="syntaxkeyword">(</span><span class="syntaxdefault">point</span><span class="syntaxkeyword">,</span><span class="syntaxdefault">vector</span><span class="syntaxkeyword">,</span><span class="syntaxdefault">the_object</span><span class="syntaxkeyword">,</span><span class="syntaxdefault">seen</span><span class="syntaxkeyword">=</span><span class="syntaxdefault">true</span><span class="syntaxkeyword">)<br /></span><span class="syntaxdefault">  if rayt</span><span class="syntaxkeyword">=</span><span class="syntaxdefault">Sketchup</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">active_model</span><span class="syntaxkeyword">.</span><span class="syntaxdefault">raytest</span><span class="syntaxkeyword">([</span><span class="syntaxdefault">point</span><span class="syntaxkeyword">,</span><span class="syntaxdefault">vector</span><span class="syntaxkeyword">],</span><span class="syntaxdefault">seen</span><span class="syntaxkeyword">)<br /></span><span class="syntaxdefault">    if rayt</span><span class="syntaxkeyword">[</span><span class="syntaxdefault">1</span><span class="syntaxkeyword">].include?(</span><span class="syntaxdefault">the_object</span><span class="syntaxkeyword">)<br /></span><span class="syntaxdefault">      return true<br />    else<br />      return false<br />    end<br />  else<br />    return nil<br />  end<br />end</span>

Typical Usage:
is_it_hit=self.raytesterizer(point,vector,the_object,true)
It returns ' true' if the raytest 'hit' includes 'the_object'.
It returns ' false' if the raytest 'hit' doesn't include 'the_object'.
It returns ' nil' if the raytest doesn't return a 'hit' at all.

The ' seen' 4th argument is optional - if not set at all OR set as ' true' only visible objects are considered in the raytest, but if set as ' false' then even hidden objects can also be 'hit'...

Anton_S

TIG

That still does extra work by searching through the ALL groups, getting ALL the models geometry, and then return's true/false/nil dependending whether the intersection is with-in or on the specified entity.

I already have the raytest function I want written in ruby, but I also wan't to write it in C++. I'm just not sure whether my C++ raytest version would work faster than my ruby raytest version or not.

To me its hard to figrure how to use SketchUp C++ SDKs in C++ code - I never seen, nor found any examples on it. - Strange Sketchup, releasing C++ SDK and no examples on using it.

Anton_S

@thomthom said:

@anton_s said:

Lets, say I write Two of my own simplified raytest functions (similar to
Raytest 2). One on C++ (raytest2cpp), compile it to .dll, and extern it into some of my Ruby module using dl. The other, on Ruby (raytest2rb). On SU, which of these will work faster, why, and approximately by how much percent faster?

In order to do your own raytesting C++ function you'd have to pass the function all the 3D geometry in the model, and I assume that will eat up any performance gain you'd get from the actual custom raytracing.

But, isn't that what the current raytest function does??? Gets all the models geometry, and then calculates the intersections, returning the closest point?

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.