Model.raytest broken in SU8!

thomthom

Looks like it.
I've been doing some tests with my test model.

If I erase all CPoints the rays shot are working.
If I group the CPoints the rays shot are working.
If I group the CPoints, and then enter the group some rays shotstart failing.

So at the moment it appears that CPoints in model.active_entities can cause raytest to fail.

This is a major breakage IMO. I really hope we don't have to wait months for a maintenance release.

Didier Bur

thomthom

I'm still trying to work out why/which rays fail. I've seen no pattern so far.

All I manage to do now is detect incorrect rays, by comparing the vector from the point shot to the point hit, is it's not in the same direction of the ray then it's the bug that has struck. But atm the only workaround I've come up with is manually iterate the model and run intersect_line_* on all the entities. Basically rewrite of the raytest - just slower.

daiku

I can confirm that this bug has broken my scripts as well. I add cpoints based on where the ray interects with a face, and the points get added "out in the weeds", not on the face. CB.

thomthom

@daiku said:

I can confirm that this bug has broken my scripts as well. I add cpoints based on where the ray interects with a face, and the points get added "out in the weeds", not on the face. CB.

If you cache the points for where you place the CPoints until after you have done all the raytracing, does it work then? (Ensuring there are no CPoints in current context before you start)

thomthom

Trying to visualize the data to find a pattern in the failure - without any luck.

At appears that all raytests that fail and return 0,0,0 all report the same CPoint in the path array.
SU8-raytest 01.png

However, removing the CPoint they all refer to and on the next run they all refer to another one. It appear to be random junk data.
SU8-raytest 02.png

Still not seeing any patterns in the rays that fail...

` #Sketchup::ConstructionPoint:0xfea9f70 - Point3d(375.81, 168.165, 306.856)...
#Sketchup::ConstructionPoint:0xfea9bd8 - Point3d(66.8371, -18.5047, 306.856)...

ERROR!
[Point3d(0, 0, 0), [#Sketchup::ConstructionPoint:0xfea9f70]]
Vector3d(-66.8371, 18.5047, -306.856)
#Sketchup::ConstructionPoint:0xfea9854 - Point3d(303.817, -13.1038, 306.856)...
ERROR!
[Point3d(0, 0, 0), [#Sketchup::ConstructionPoint:0xfea9f70]]
Vector3d(-303.817, 13.1038, -306.856)
#Sketchup::ConstructionPoint:0xfea94e4 - Point3d(237.913, 486.227, 306.856)...
ERROR!
[Point3d(0, 0, 0), [#Sketchup::ConstructionPoint:0xfea9f70]]
Vector3d(-237.913, -486.227, -306.856)
#Sketchup::ConstructionPoint:0xfea9174 - Point3d(450.857, 366.827, 306.856)...
#Sketchup::ConstructionPoint:0xfea8e90 - Point3d(390.368, 111.841, 306.856)...
#Sketchup::ConstructionPoint:0xfea8c38 - Point3d(572.779, 146.892, 306.856)...
#Sketchup::ConstructionPoint:0xfea89e0 - Point3d(493.91, 227.955, 306.856)...
#Sketchup::ConstructionPoint:0xfea8724 - Point3d(408.451, 49.9671, 306.856)...
#Sketchup::ConstructionPoint:0xfea8468 - Point3d(626.566, 186.134, 306.856)...
ERROR!
[Point3d(0, 0, 0), [#Sketchup::ConstructionPoint:0xfea9f70]]
Vector3d(-626.566, -186.134, -306.856)
#Sketchup::ConstructionPoint:0xfea80f8 - Point3d(166.294, 262.562, 306.856)...
#Sketchup::ConstructionPoint:0xfea7e28 - Point3d(446.203, -43.8623, 306.856)...
#Sketchup::ConstructionPoint:0xfea7bd0 - Point3d(55.5756, 257.856, 306.856)...
#Sketchup::ConstructionPoint:0xfea7978 - Point3d(115.356, 141.118, 306.856)...
#Sketchup::ConstructionPoint:0xfea7720 - Point3d(139.372, 141.118, 306.856)...
#Sketchup::ConstructionPoint:0xfea74dc - Point3d(48.0672, 203.288, 306.856)...
#Sketchup::ConstructionPoint:0xfea7284 - Point3d(89.6026, 203.288, 306.856)...
#Sketchup::ConstructionPoint:0xfea702c - Point3d(166.34, 114.827, 306.856)...
#Sketchup::ConstructionPoint:0xfea6de8 - Point3d(356.548, 483.582, 306.856)...
ERROR!
[Point3d(0, 0, 0), [#Sketchup::ConstructionPoint:0xfea9f70]]
Vector3d(-356.548, -483.582, -306.856)
#Sketchup::ConstructionPoint:0xfea6a78 - Point3d(448.291, 280.224, 306.856)...
#Sketchup::ConstructionPoint:0xfea67bc - Point3d(134.428, 325.04, 306.856)...
#Sketchup::ConstructionPoint:0xfea6500 - Point3d(76.403, 431.175, 306.856)...
#Sketchup::ConstructionPoint:0xfea62a8 - Point3d(620.561, 43.6718, 306.856)...
ERROR!
[Point3d(0, 0, 0), [#Sketchup::ConstructionPoint:0xfea9f70]]
Vector3d(-620.561, -43.6718, -306.856)
#Sketchup::ConstructionPoint:0xfea5f38 - Point3d(529.611, -73.3759, 306.856)...
ERROR!
[Point3d(0, 0, 0), [#Sketchup::ConstructionPoint:0xfea9f70]]
Vector3d(-529.611, 73.3759, -306.856)
#Sketchup::ConstructionPoint:0xfea5bc8 - Point3d(547.64, 381.779, 306.856)...
#Sketchup::ConstructionPoint:0xfea590c - Point3d(347.374, 357.812, 306.856)...
#Sketchup::ConstructionPoint:0xfea5650 - Point3d(192.506, 404.667, 306.856)...
#Sketchup::ConstructionPoint:0xfea53f8 - Point3d(292.297, 130.784, 306.856)...`

When it detect an error it prints out the return data for raytest and the vector from the ray start point to the hit point.

thomthom

I almost thought it was rays that hit nothing that failed when I looked at this top-down, but then I noticed two rays that crushed that theory.

SU8-raytest 03.png

thomthom

hm... It does seem to be of importance if the ray is suppose to hit an entity or not. But there are still deviant results.

SU8-raytest 04.png

SU8-raytest 05.png

SU8-raytest 06.png

The rouge rays that should hit the surface below is causing problems, had it not been for them one could have assumed the junk results where non-hits.

thomthom

Got it! Looking at if from a fresh angle, literally, it becomes evident what's going on:

model.raytest fails when the ray pass through the Ground Level

Example 1:
Rays that hits entities above Ground Level works correctly, rays that pass through Ground Level returns ORIGIN and a random CPoint as result data.
SU8-raytest 07.png

Example 2:
All rays worked correctly because they hit entities without passing trough Ground Level.
SU8-raytest 08.png

Example 3:
All rays started below Ground Zero, everyone hit because they did not pass Ground Level.
SU8-raytest 09.png

I've only tested rays that go downwards - not sure how things behave for rays in different directions.
It might be possible to write a hack to workaround this. Need to test more cases first.

thomthom

Further details:
model.raytest fails when the rays pass through the XY,XZ or YZ plane when there is a CPoint in model.active_entities.


model = Sketchup.active_model
sel = model.selection

model.entities.clear!

pt = Geom;;Point3d.new( 10, 10, 10 )

puts 'Without CPoints in active_entities;'
[X_AXIS, Y_AXIS, Z_AXIS].each { |v|
  ray = [ pt, v ]
  p model.raytest( ray )
  ray = [ pt, v.reverse ]
  p model.raytest( ray )
}

cp = model.active_entities.add_cpoint( pt )

puts 'With CPoints in active_entities;'
[X_AXIS, Y_AXIS, Z_AXIS].each { |v|
  ray = [ pt, v ]
  p model.raytest( ray )
  ray = [ pt, v.reverse ]
  p model.raytest( ray )
}

puts 'Done'

Resulting data:
Without CPoints in active_entities: nil nil nil nil nil nil With CPoints in active_entities: nil [Point3d(0, 0, 0), [#<Sketchup::ConstructionPoint:0x11bc3660>]] nil [Point3d(0, 0, 0), [#<Sketchup::ConstructionPoint:0x11bc3660>]] nil [Point3d(0, 0, 0), [#<Sketchup::ConstructionPoint:0x11bc3660>]] Done

thomthom

Implemented a workaround to my TT_Lib2: http://forums.sketchucation.com/viewtopic.php?f=323&t=30503

I've wrapped it up into a Ray class, but you can extract the workaround from the .test method.

Ray Class from TT_Lib 2.1.1

tomasz

Thanks Thomas for your efforts! I hope it will be a fix with a high priority.

thomthom

I just found that my workaround isn't perfect. I still have cases with rays straying away.

thomthom

` cl=sel[0]

#Sketchup::ConstructionLine:0x18b6e6a4
r = model.raytest( [cl.start, cl.end] )
[Point3d(0, 0, 0), [#Sketchup::ConstructionPoint:0x18903324]]`

It doesn't hit any of the model axis planes, but yet it returns ORIGIN and a CPoint. I don't know how to work around this one. Can't find the trigger.

SU8-raytest-bug.skp

daiku

@thomthom said:

@daiku said:

I can confirm that this bug has broken my scripts as well. I add cpoints based on where the ray interects with a face, and the points get added "out in the weeds", not on the face. CB.

If you cache the points for where you place the CPoints until after you have done all the raytracing, does it work then? (Ensuring there are no CPoints in current context before you start)

Unfortunately, there are CPoints already in the current context when I try to preform the raytest.

thomthom

@daiku said:

Unfortunately, there are CPoints already in the current context when I try to preform the raytest.

Yea - I'm having the same problem. Trying to find a workaround that doesn't involve grouping the CPoints before processing.

tomasz

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?

daiku

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