Model.raytest broken in SU8!

daiku

Lads, this needs to be fixed on SU Team level urgently! Looking for a workaround is desired, but why we developers have to fix something that is wrong on C++ level, not in Ruby!
Do you expect new maintenance release in the end of 2011?

Agreed. Has anyone reported it, or gotten confirmation from Google? IIRC, there were some bugs in SU7 that were corrected fairly quickly. CB.

thomthom

I've reported it, and nagged nearly every day. It's being looked into.

Mr.K.1

And I was thinking it's just me.
I found the problem in a different way, but it's still the same one.
In my case it seems raytest is broken by any 2D text added to the model, raytest will work normaly for some directions and hit the text in others(I assume that was the passing axis plane issue), and once I tried hidding the text before raytesting (so it would ignore it) I instantly got a bugsplat.

Anyway, removing all 2D text is a solution for that.

kwalkerman

@unknownuser said:

Lads, this needs to be fixed on SU Team level urgently! Looking for a workaround is desired, but why we developers have to fix something that is wrong on C++ level, not in Ruby!
Do you expect new maintenance release in the end of 2011?

Agreed!!!

--
Karen

Anton_S

I Downloaded "SU8-raytest-bug.skp",opened it in SU8M2, and in the Ruby console, with the same consept wrote model.raytest("construction point position", "vector of construction line") and it worked right; returned the right intersetion point, the right face and group.

So, is this bug already fixed?>

thomthom

Ah, yes! It's been fixed. I'd forgotten about this thread.

TIG

Strange this recurs...
Raytest IS fixed...
Sort of - BUT it can still be flaky !

I'm doing some code for a tool at the moment that adds instances inside a 'group' at set xyz spacings.
If it were a cube it's easy enough to ensure all of the added instances are wholly within the groups enclosing faces by using maths.
However, if for example the group has a sloping 'roof' face then there must be fewer instances inserted in the 'z' at the 'eaves' that at the 'ridge'.
To do this I add the instances progressively upwards and then use
rayt=model.raytest([possible_insertion_point, Z_AXIS], true)***
and
if NOT rayt I know it's outside of the group
but if rayt then I check it to see
if rayt[1].include?(group)
if NOT I know it's outside of the group***
if so it's probably inside the group...
however, it would be possible to have an 'overhang' or 'notch' in the form which then puts the 'possible_insertion_point' outside of the group, BUT rayt will return wrobgly- so the next test is
if rayt[1][-1].class==Sketchup::Face
and
if so rayt[1][-1].normal.z<0
as this is hitting a downward facing surface, so the tested-point is outside of the group's 'skin', but below part of the group, and therefore giving a false positive...

OK... so this works fine most of the time... BUT now and again it misses and returns rayt==nil when it clearly is 'inside' the skin and it should return an array [confirmed by adding cpoints at the tested-points when NOT rayt]. I can't see why this is occurring at all.

***Also the 'true' optional second argument is flawed sometimes.
If I have objects inside the group that I either hide OR put on an OFF layer temporarily, then they do not interfere with the rayt... usually!
BUT now and again the rayt will fail for some test-points that overlap with this hidden object [returning nil when it is clearly inside the group] BUT unexpectedly work correctly for others overlapping points - but it never returns the hidden object, just 'nil'.

I'm trying to resolve all of this, as it is vital to the operation of my new tool !

thomthom

You have a test case?

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...