Model.raytest broken in SU8!

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.

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?